Systemkonfiguration¶

Detta dokument beskriver grundläggande steg för att installera Odoo i produktion eller på en server som vetter mot internet. Det följer installation, och är i allmänhet inte nödvändigt för ett utvecklingssystem som inte är exponerat på internet.

Varning

Om du installerar en offentlig server bör du kontrollera våra rekommendationer för säkerhet!

dbfilter¶

Odoo är ett system med flera hyresgäster: ett enda Odoo-system kan köra och betjäna ett antal databasinstanser. Det är också mycket anpassningsbart, med anpassningar (med början från de moduler som laddas) beroende på den ”aktuella databasen”.

Detta är inte ett problem när du arbetar med backend (webbklient) som en inloggad företagsanvändare: databasen kan väljas när du loggar in och anpassningar laddas efteråt.

Det är dock ett problem för icke inloggade användare (portal, webbplats) som inte är bundna till en databas: Odoo behöver veta vilken databas som ska användas för att ladda webbplatssidan eller utföra operationen. Om multi-tenancy inte används är det inte ett problem, det finns bara en databas att använda, men om det finns flera databaser tillgängliga behöver Odoo en regel för att veta vilken den ska använda.

Det är ett av syftena med --db-filter: det specificerar hur databasen ska väljas baserat på det värdnamn (domän) som efterfrågas. Värdet är ett regular expression, som kan inkludera det dynamiskt injicerade värdnamnet (%h) eller den första underdomänen (%d) genom vilken systemet nås.

För servrar med flera databaser i produktion, särskilt om website används, måste dbfilter anges, annars kommer ett antal funktioner inte att fungera korrekt.

Konfigurationsmallar¶

Visa endast databaser med namn som börjar med ’mycompany’

i konfigurationsfilen inställd:

[options]
dbfilter = ^mycompany.*$

Visa endast databaser som matchar den första subdomänen efter www: till exempel databasen ”mycompany” kommer att visas om den inkommande begäran skickades till www.mycompany.com eller mycompany.co.uk, men inte för www2.mycompany.com eller helpdesk.mycompany.com.

i konfigurationsfilen inställd:

[options]
dbfilter = ^%d$

Observera

Att ställa in ett korrekt --db-filter är en viktig del av att säkra din driftsättning. När det fungerar korrekt och bara matchar en enda databas per värdnamn rekommenderas det starkt att blockera åtkomst till skärmarna för databashanteraren och att använda startparametern --no-database-list för att förhindra att dina databaser listas och för att blockera åtkomst till skärmarna för databashanteraren. Se även security.

PostgreSQL¶

Som standard tillåter PostgreSQL endast anslutning via UNIX-socklar och loopback-anslutningar (från ”localhost”, samma maskin som PostgreSQL-servern är installerad på).

UNIX-socket är bra om du vill att Odoo och PostgreSQL ska köras på samma maskin, och är standard när ingen värd anges, men om du vill att Odoo och PostgreSQL ska köras på olika maskiner 1 kommer det att behöva lyssna på nätverksgränssnitt 2, antingen:

Acceptera endast loopback-anslutningar och använd en SSH-tunnel mellan den maskin som Odoo körs på och den som PostgreSQL körs på, konfigurera sedan Odoo att ansluta till sin ände av tunneln
Acceptera anslutningar till den maskin där Odoo är installerat, eventuellt via ssl (se PostgreSQL anslutningsinställningar för detaljer), konfigurera sedan Odoo att ansluta via nätverket

Exempel på konfiguration¶

Tillåt tcp-anslutning på localhost
Tillåt tcp-anslutning från nätverket 192.168.1.x

i /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/pg_hba.conf-uppsättningen:

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
host    all             all             192.168.1.0/24          md5

i /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf-uppsättningen:

listen_addresses = 'localhost,192.168.1.2'
port = 5432
max_connections = 80

Konfigurera Odoo¶

Som standard ansluter Odoo till en lokal postgres över UNIX-socket via port 5432. Detta kan åsidosättas med databasalternativen när din Postgres-distribution inte är lokal och/eller inte använder standardinställningarna för installationen.

packaged installers kommer automatiskt att skapa en ny användare (odoo) och ange den som databasanvändare.

Skärmbilderna för databashantering skyddas av inställningen admin_passwd. Denna inställning kan endast göras med hjälp av konfigurationsfiler, och kontrolleras helt enkelt innan databasändringar utförs. Den bör sättas till ett slumpmässigt genererat värde för att säkerställa att tredje part inte kan använda detta gränssnitt.
Alla databasoperationer använder databasalternativ, inklusive skärmen för databashantering. För att databashanteringsskärmen ska fungera krävs att PostgreSQL-användaren har rätten createdb.
Användare kan alltid släppa databaser som de äger. För att skärmen för databashantering ska vara helt icke-funktionell måste PostgreSQL-användaren skapas med no-createdb och databasen måste ägas av en annan PostgreSQL-användare.

Varning
PostgreSQL-användaren bör inte vara en superanvändare

Exempel på konfiguration¶

ansluta till en PostgreSQL-server på 192.168.1.2
port 5432
använder ett ”odoo”-användarkonto,
med ’pwd’ som lösenord
filtrerar endast db med ett namn som börjar med ’mycompany’

i konfigurationsfilen inställd:

[options]
admin_passwd = mysupersecretpassword
db_host = 192.168.1.2
db_port = 5432
db_user = odoo
db_password = pwd
dbfilter = ^mycompany.*$

SSL mellan Odoo och PostgreSQL¶

Sedan Odoo 11.0 kan du tvinga ssl-anslutning mellan Odoo och PostgreSQL. i Odoo styr db_sslmode ssl-säkerheten för anslutningen med värde valt ur ’inaktivera’, ’tillåta’, ’föredra’, ’kräva’, ’verifiera-ca’ eller ’verifiera-full’

PostgreSQL Doc

Inbyggd server¶

Odoo innehåller inbyggda HTTP-, cron- och live-chat-servrar, som använder antingen multi-threading eller multi-processing.

Servern multi-threaded är en enklare server som främst används för utveckling, demonstrationer och kompatibilitet med olika operativsystem (inklusive Windows). En ny tråd skapas för varje ny HTTP-begäran, även för långlivade anslutningar som websocket. Extra daemoniska cron-trådar skapas också. På grund av en Python-begränsning (GIL) utnyttjar den inte hårdvaran på bästa sätt.

Den flertrådade servern är standardservern, även för docker-containrar. Den väljs genom att utelämna alternativet --workers eller sätta det till 0.

Servern multi-processing är en fullfjädrad server som främst används för produktion. Den omfattas inte av samma Python-begränsning (GIL) för resursanvändning och utnyttjar därför hårdvaran på bästa sätt. En pool med arbetare skapas när servern startas. Nya HTTP-förfrågningar köas av operativsystemet tills det finns arbetare som är redo att bearbeta dem. En extra händelsestyrd HTTP-arbetare för livechatten skapas på en alternativ port. Extra cron-arbetare skapas också. En konfigurerbar process reaper övervakar resursanvändningen och kan döda/starta om misslyckade arbetare.

Multi-processing-servern är opt-in. Den väljs genom att alternativet --workers sätts till ett heltal som inte är noll.

Observera

Eftersom den är skräddarsydd för Linux-servrar finns multiprocessing-servern inte tillgänglig för Windows.

Beräkning av antalet anställda¶

Tumregel: (#CPU * 2) + 1
Cron-arbetare behöver CPU
1 arbetare ~= 6 samtidiga användare

beräkning av minnesstorlek¶

Vi anser att 20% av förfrågningarna är tunga förfrågningar, medan 80% är enklare
En tung arbetare, när alla beräkningsfält är väl utformade, SQL-förfrågningar är väl utformade, … beräknas förbruka cirka 1 GB RAM-minne
En lättare anställd beräknas i samma scenario förbruka cirka 150 MB RAM-minne

RAM-minne som behövs = #arbetare * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

Livechatt¶

I multi-processing startas en dedikerad LiveChat-arbetare automatiskt och lyssnar på --gevent-port. Som standard kommer HTTP-förfrågningarna att fortsätta att nå de vanliga HTTP-arbetarna istället för LiveChat-arbetaren. Du måste distribuera en proxy framför Odoo och omdirigera inkommande förfrågningar vars sökväg börjar med /websocket/ till LiveChat-arbetaren. Du måste också starta Odoo i --proxy-mode så att den använder de riktiga klienthuvudena (som värdnamn, schema och IP) istället för proxyhuvudena.

Exempel på konfiguration¶

Server med 4 CPU, 8 trådar
60 samtidiga användare
60 användare / 6 = 10 <- teoretiskt antal arbetare som behövs
(4 * 2) + 1 = 9 <- teoretiskt maximalt antal arbetare
Vi kommer att använda 8 arbetare + 1 för cron. Vi kommer också att använda ett övervakningssystem för att mäta cpu-belastningen och kontrollera om den ligger mellan 7 och 7,5 .
RAM = 9 * ((0,8*150) + (0,2*1024)) ~= 3Go RAM för Odoo

i konfigurationsfilen:

[options]
limit_memory_hard = 1677721600
limit_memory_soft = 629145600
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200
max_cron_threads = 1
workers = 8

HTTPS¶

Oavsett om åtkomst sker via webbplats/webbklient eller webbtjänst överför Odoo autentiseringsinformation i klartext. Detta innebär att en säker driftsättning av Odoo måste använda HTTPS3. SSL-terminering kan implementeras via nästan vilken SSL-termineringsproxy som helst, men kräver följande konfiguration:

Aktivera Odoo:s proxy-läge. Detta bör endast aktiveras när Odoo är bakom en omvänd proxy
Konfigurera SSL-termineringsproxyn (Nginx termineringsexempel)
Konfigurera själva proxyn (Nginx proxying example)
Din proxy för SSL-terminering bör också automatiskt omdirigera icke-säkra anslutningar till den säkra porten

Exempel på konfiguration¶

Omdirigera http-förfrågningar till https
Proxy-förfrågningar till odoo

i konfigurationsfilen inställd:

proxy_mode = True

i uppsättningen /etc/nginx/sites-enabled/odoo.conf:

#odoo server
upstream odoo {
  server 127.0.0.1:8069;
}
upstream odoochat {
  server 127.0.0.1:8072;
}
map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

# http -> https
server {
  listen 80;
  server_name odoo.mycompany.com;
  rewrite ^(.*) https://$host$1 permanent;
}

server {
  listen 443 ssl;
  server_name odoo.mycompany.com;
  proxy_read_timeout 720s;
  proxy_connect_timeout 720s;
  proxy_send_timeout 720s;

  # SSL parameters
  ssl_certificate /etc/ssl/nginx/server.crt;
  ssl_certificate_key /etc/ssl/nginx/server.key;
  ssl_session_timeout 30m;
  ssl_protocols TLSv1.2;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
  ssl_prefer_server_ciphers off;

  # log
  access_log /var/log/nginx/odoo.access.log;
  error_log /var/log/nginx/odoo.error.log;

  # Redirect websocket requests to odoo gevent port
  location /websocket {
    proxy_pass http://odoochat;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # Redirect requests to odoo backend server
  location / {
    # Add Headers for odoo proxy mode
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_redirect off;
    proxy_pass http://odoo;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # common gzip
  gzip_types text/css text/scss text/plain text/xml application/xml application/json application/javascript;
  gzip on;
}

HTTPS-härdning¶

Lägg till rubriken Strict-Transport-Security i alla förfrågningar för att förhindra att webbläsare någonsin skickar en vanlig HTTP-förfrågan till den här domänen. Du måste alltid ha en fungerande HTTPS-tjänst med ett giltigt certifikat på den här domänen, annars kommer dina användare att se säkerhetsvarningar eller vara helt oförmögna att komma åt den.

Tvinga HTTPS-anslutningar under ett år för varje besökare i NGINX med raden:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Ytterligare konfiguration kan definieras för cookien session_id. Flaggan Secure kan läggas till för att säkerställa att den aldrig överförs via HTTP och SameSite=Lax för att förhindra autentiserad CSRF.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Odoo som en WSGI-applikation¶

Det är också möjligt att montera Odoo som en standard WSGI-applikation. Odoo tillhandahåller basen för ett WSGI-launcher-skript som odoo-wsgi.example.py. Detta skript bör anpassas (eventuellt efter att ha kopierats från installationskatalogen) för att korrekt ställa in konfigurationen direkt i odoo.tools.config snarare än via kommandoraden eller en konfigurationsfil.

WSGI-servern kommer dock endast att exponera den huvudsakliga HTTP-slutpunkten för webbklienten, webbplatsen och webbtjänstens API. Eftersom Odoo inte kontrollerar skapandet av arbetare längre kan det inte ställa in cron- eller livechat-arbetare

Cron-arbetare¶

En av de inbyggda Odoo-servrarna bredvid WSGI-servern måste startas för att bearbeta cron-jobb. Den servern måste konfigureras så att den endast bearbetar cronjobb och inte HTTP-förfrågningar med hjälp av klientalternativet --no-http eller konfigurationsfilinställningen http_enable = False.

På Linux-liknande system rekommenderas att använda en server med flera processorer framför en med flera trådar för att dra nytta av bättre maskinvaruanvändning och ökad stabilitet, dvs. genom att använda cli-alternativen --workers=-1 och --max-cron-threads=n.

Livechatt¶

För att livechattfunktionen ska fungera korrekt krävs en gevent-kompatibel WSGI-server. Den servern bör kunna hantera många samtidiga långlivade anslutningar men behöver inte mycket processorkraft. Alla förfrågningar vars sökväg börjar med /websocket/ bör riktas till den servern. En vanlig (tråd/process-baserad) WSGI-server bör användas för alla andra förfrågningar.

Odoo cron-servern kan också användas för att betjäna livechattförfrågningarna. Ta bara bort klientalternativet --no-http från cron-servern och se till att förfrågningar vars sökväg börjar med /websocket/ skickas till denna server, antingen på --http-port (multi-threading-server) eller på --gevent-port (multi-processing-server).

Servering av statiska filer och bilagor¶

För att underlätta utvecklingen serverar Odoo direkt alla statiska filer och bilagor i sina moduler. Detta kanske inte är idealiskt när det gäller prestanda, och statiska filer bör i allmänhet serveras av en statisk HTTP-server.

Servering av statiska filer¶

Odoos statiska filer finns i varje moduls static/-mapp, så statiska filer kan användas genom att fånga upp alla begäranden till /MODULE/static/FILE, och leta upp rätt modul (och fil) i de olika addons-sökvägarna.

Det rekommenderas att sätta Content-Security-Policy: default-src 'none' header på alla bilder som levereras av webbservern. Det är inte absolut nödvändigt eftersom användare inte kan ändra/injicera innehåll i modulens static/-mapp och befintliga bilder är slutgiltiga (de hämtar inte nya resurser på egen hand). Det är dock god praxis.

Med hjälp av ovanstående NGINX (https)-konfiguration bör följande map- och location-block läggas till för att servera statiska filer via NGINX.

map $sent_http_content_type $content_type_csp {
    default "";
    ~image/ "default-src 'none'";
}

server {
    # the rest of the configuration

    location @odoo {
        # copy-paste the content of the / location block
    }

    # Serve static files right away
    location ~ ^/[^/]+/static/.+$ {
        # root and try_files both depend on your addons paths
        root ...;
        try_files ... @odoo;
        expires 24h;
        add_header Content-Security-Policy $content_type_csp;
    }
}

De faktiska direktiven root och try_files beror på din installation, särskilt på ditt --addons-path.

Example

Säg att Odoo har installerats via debian-paketen för Community och Enterprise, och att --addons-path är '/usr/lib/python3/dist-packages/odoo/addons'.

root och try_files bör vara det:

root /usr/lib/python3/dist-packages/odoo/addons;
try_files $uri @odoo;

Säg att Odoo har installerats via sources, att både Community- och Enterprise-gitlagren klonades i /opt/odoo/community respektive /opt/odoo/enterprise, och att --addons-path är '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

root och try_files bör vara det:

root /opt/odoo;
try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;

Tillbehör för servering¶

Bilagor är filer som lagras i filarkivet och vars åtkomst regleras av Odoo. De kan inte nås direkt via en statisk webbserver eftersom åtkomst till dem kräver flera uppslagningar i databasen för att avgöra var filerna lagras och om den aktuella användaren kan komma åt dem eller inte.

När filen har lokaliserats och åtkomsträttigheterna har verifierats av Odoo är det dock en bra idé att servera filen med den statiska webbservern istället för med Odoo. För att Odoo ska kunna delegera servering av filer till den statiska webbservern måste tilläggen X-Sendfile (apache) eller X-Accel (nginx) vara aktiverade och konfigurerade på den statiska webbservern. När allt är konfigurerat startar du Odoo med CLI-flaggan --x-sendfile (denna unika flagga används för både X-Sendfile och X-Accel).

Observera

Tillägget X-Sendfile för apache (och kompatibla webbservrar) kräver ingen ytterligare konfiguration.
X-Accel-tillägget för NGINX kräver följande ytterligare konfiguration:
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}
```
Om du inte vet vad som är sökvägen till ditt filarkiv, starta Odoo med alternativet --x-sendfile och navigera till /web/filestore URL direkt via Odoo (navigera inte till URL via NGINX). Detta loggar en varning, meddelandet innehåller den konfiguration du behöver.

Säkerhet¶

Till att börja med måste du komma ihåg att ett informationssystem måste säkras kontinuerligt, inte bara en gång. Vid varje tidpunkt är du bara så säker som den svagaste länken i din miljö.

Se därför inte detta avsnitt som den ultimata listan över åtgärder som kan förhindra alla säkerhetsproblem. Det är endast avsett som en sammanfattning av de första viktiga sakerna som du bör se till att inkludera i din handlingsplan för säkerhet. Resten kommer från bästa säkerhetspraxis för ditt operativsystem och din distribution, bästa praxis när det gäller användare, lösenord och hantering av åtkomstkontroll etc.

När du installerar en server som vänder sig mot Internet bör du ta hänsyn till följande säkerhetsrelaterade frågor:

Ange alltid ett starkt lösenord för superadmin och begränsa åtkomsten till sidorna för databashantering så snart systemet har konfigurerats. Se Säkerhet för databashanterare.
Välj unika inloggningar och starka lösenord för alla administratörskonton på alla databaser. Använd inte ”admin” som inloggning. Använd inte dessa inloggningar för den dagliga driften, utan endast för att kontrollera/hantera installationen. Använd aldrig några standardlösenord som admin/admin, inte ens för test/staging-databaser.
Installera inte demodata på servrar som vetter mot internet. Databaser med demodata innehåller standardinloggningar och lösenord som kan användas för att ta sig in i dina system och orsaka betydande problem, även på staging/dev-system.
Använd lämpliga databasfilter ( --db-filter) för att begränsa synligheten för dina databaser i enlighet med värdnamnet. Se dbfilter. Du kan också använda -d för att ange en egen (kommaseparerad) lista över tillgängliga databaser att filtrera från, istället för att låta systemet hämta dem alla från databasens backend.
När db_name och db_filter är konfigurerade och bara matchar en enda databas per värdnamn, bör du ställa in list_db till False, för att helt förhindra listning av databaser, och för att blockera åtkomst till databashanteringsskärmarna (detta finns också som --no-database-list kommandoradsalternativet)
Kontrollera att PostgreSQL-användaren (--db_user) inte är en superanvändare, och att dina databaser ägs av en annan användare. De kan till exempel ägas av superanvändaren postgres om du använder en dedikerad icke-privilegierad db_user. Se även Konfigurera Odoo.
Håll installationerna uppdaterade genom att regelbundet installera de senaste versionerna, antingen via GitHub eller genom att ladda ner den senaste versionen från https://www.odoo.com/page/download eller http://nightly.odoo.com
Konfigurera servern i multiprocessläge med lämpliga gränser som matchar din typiska användning (minne/CPU/timeouts). Se även Inbyggd server.
Kör Odoo bakom en webbserver som tillhandahåller HTTPS-terminering med ett giltigt SSL-certifikat, för att förhindra avlyssning av kommunikation i klartext. SSL-certifikat är billiga och det finns många gratisalternativ. Konfigurera webbproxyn för att begränsa storleken på förfrågningar, ange lämpliga timeouts och aktivera sedan alternativet proxy-mode. Se även HTTPS.
Om du behöver tillåta SSH-fjärråtkomst till dina servrar, se till att ange ett starkt lösenord för alla konton, inte bara root. Det rekommenderas starkt att helt inaktivera lösenordsbaserad autentisering och endast tillåta autentisering med offentlig nyckel. Överväg också att begränsa åtkomsten via ett VPN, endast tillåta betrodda IP-adresser i brandväggen och/eller köra ett brute-force-detekteringssystem som fail2ban eller motsvarande.
Överväg att installera lämplig hastighetsbegränsning på din proxy eller brandvägg, för att förhindra brute-force-attacker och denial of service-attacker. Se även Blockering av Brute Force-attacker för specifika åtgärder.

Många nätverksleverantörer erbjuder automatisk begränsning av DDOS-attacker (Distributed Denial of Service), men detta är ofta en tillvalstjänst, så du bör rådfråga dem.
När det är möjligt ska du hosta dina publika demo/test/staging-instanser på andra maskiner än de som används i produktionen. Och tillämpa samma säkerhetsåtgärder som för produktion.
Om din publika Odoo-server har åtkomst till känsliga interna nätverksresurser eller tjänster (t.ex. via ett privat VLAN) ska du implementera lämpliga brandväggsregler för att skydda dessa interna resurser. Detta säkerställer att Odoo-servern inte kan användas oavsiktligt (eller som ett resultat av skadliga användaråtgärder) för att komma åt eller störa dessa interna resurser. Detta kan vanligtvis göras genom att tillämpa en utgående standard DENY-regel på brandväggen och sedan endast uttryckligen auktorisera åtkomst till interna resurser som Odoo-servern behöver åtkomst till. Systemd IP traffic access control kan också vara användbart för att implementera per-process nätverksåtkomstkontroll.
Om din offentliga Odoo-server ligger bakom en Web Application Firewall, en lastbalanserare, en transparent DDoS-skyddstjänst (som CloudFlare) eller en liknande enhet på nätverksnivå, kanske du vill undvika direkt åtkomst till Odoo-systemet. Det är i allmänhet svårt att hålla IP-adresserna till Odoo-servrarna hemliga. De kan t.ex. visas i webbserverloggar vid förfrågningar till offentliga system eller i rubrikerna på e-postmeddelanden som skickas från Odoo. I en sådan situation kanske du vill konfigurera din brandvägg så att slutpunkterna inte är tillgängliga offentligt förutom från de specifika IP-adresserna för din WAF, lastbalanserare eller proxytjänst. Tjänsteleverantörer som CloudFlare brukar ha en offentlig lista över sina IP-adresser för detta ändamål.
Om du hostar flera kunder ska du isolera kundernas data och filer från varandra med hjälp av containrar eller lämpliga ”jail”-tekniker.
Gör dagliga säkerhetskopior av databaser och filarkivsdata och kopiera dem till en fjärrserver som inte är åtkomlig från själva servern.
Att driftsätta Odoo på Linux rekommenderas starkt framför Windows. Om du ändå väljer att driftsätta på en Windows-plattform bör du göra en grundlig säkerhetsgranskning av servern, vilket ligger utanför ramen för den här guiden.

Blockering av Brute Force-attacker¶

För internetinriktade driftsättningar är brute force-attacker på användarlösenord mycket vanliga, och detta hot bör inte försummas för Odoo-servrar. Odoo avger en loggpost när ett inloggningsförsök utförs och rapporterar resultatet: framgång eller misslyckande, tillsammans med målinloggningen och källans IP-adress.

Loggposterna kommer att ha följande form.

Misslyckad inloggning:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login failed for db:db_name login:admin from 127.0.0.1

Lyckad inloggning:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login successful for db:db_name login:admin from 127.0.0.1

Dessa loggar kan enkelt analyseras av ett system för intrångsskydd, t.ex. fail2ban.

Följande fail2ban-filterdefinition ska t.ex. matcha en misslyckad inloggning:

[Definition]
failregex = ^ \d+ INFO \S+ \S+ Login failed for db:\S+ login:\S+ from <HOST>
ignoreregex =

Detta kan användas med en fängelsedefinition för att blockera den angripande IP:n på HTTP(S).

Så här kan det se ut om IP-adressen blockeras i 15 minuter när 10 misslyckade inloggningsförsök upptäcks från samma IP-adress inom 1 minut:

[odoo-login]
enabled = true
port = http,https
bantime = 900  ; 15 min ban
maxretry = 10  ; if 10 attempts
findtime = 60  ; within 1 min  /!\ Should be adjusted with the TZ offset
logpath = /var/log/odoo.log  ;  set the actual odoo log path here

Säkerhet för databashanterare¶

Konfigurera Odoo nämnde admin_passwd i förbigående.

Denna inställning används på alla databashanteringsskärmar (för att skapa, radera, dumpa eller återställa databaser).

Om administrationsskärmarna inte får vara tillgängliga alls, bör du sätta konfigurationsalternativet list_db till False, för att blockera åtkomst till alla skärmar för val och administration av databaser.

Varning

Vi rekommenderar starkt att du inaktiverar databashanteraren för alla system med internetuppkoppling! Databashanteraren är avsedd som ett utvecklings-/demoverktyg som gör det enkelt att snabbt skapa och hantera databaser. Det är inte avsett för produktionsanvändning och kan till och med exponera farliga funktioner för angripare. Det är inte heller utformat för att hantera stora databaser och kan utlösa minnesgränser.

På produktionssystem bör databashanteringsåtgärder alltid utföras av systemadministratören, inklusive provisionering av nya databaser och automatiska säkerhetskopior.

Se till att ställa in en lämplig db_name parameter (och eventuellt db_filter också) så att systemet kan bestämma måldatabasen för varje begäran, annars kommer användarna att blockeras eftersom de inte får välja databasen själva.

Om administrationsskärmarna endast skall vara tillgängliga från en utvald grupp av datorer, använd proxyserverns funktioner för att blockera åtkomst till alla vägar som börjar med /web/database utom (kanske) /web/database/selector som visar skärmen för val av databas.

Om databashanteringsskärmen skall vara tillgänglig måste inställningen admin_passwd ändras från standardinställningen admin: detta lösenord kontrolleras innan databasändringar tillåts.

Den ska förvaras på ett säkert sätt och genereras slumpmässigt, t.ex.

$ python3 -c 'import base64, os; print(base64.b64encode(os.urandom(24)))'

som genererar en 32 tecken lång pseudorandomisk utskrivbar sträng.

Återställ huvudlösenordet¶

Det kan finnas fall där huvudlösenordet har tappats bort eller äventyrats och måste återställas. Följande process är avsedd för systemadministratörer av en lokal Odoo-databas och beskriver hur man manuellt återställer och återkrypterar huvudlösenordet.

Se även

Mer information om hur du ändrar lösenordet för ett Odoo.com-konto finns i den här dokumentationen: Ändra lösenord för Odoo.com-konto.

När du skapar en ny lokal databas genereras ett slumpmässigt huvudlösenord. Odoo rekommenderar att du använder detta lösenord för att säkra databasen. Detta lösenord är implementerat som standard, så det finns ett säkert huvudlösenord för alla Odoo on-premise-distributioner.

Varning

När du skapar en Odoo on-premise-databas är installationen tillgänglig för alla på internet, tills detta lösenord har ställts in för att säkra databasen.

Huvudlösenordet anges i konfigurationsfilen för Odoo (odoo.conf eller odoorc (dold fil)). Odoo-masterlösenordet behövs för att ändra, skapa eller ta bort en databas via det grafiska användargränssnittet (GUI).

Leta reda på konfigurationsfilen¶

Först öppnar du konfigurationsfilen för Odoo (odoo.conf eller odoorc (dold fil)).

Konfigurationsfilen finns på följande adress: c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf

Beroende på hur Odoo är installerat på Linux-maskinen finns konfigurationsfilen på en av två olika platser:

Paketinstallation: /etc/odoo.conf
Installationskälla: ~/.odoorc

Ändra gammalt lösenord¶

När den aktuella filen har öppnats ändrar du det gamla lösenordet i konfigurationsfilen till ett tillfälligt lösenord.

När du har hittat konfigurationsfilen öppnar du den med hjälp av ett (GUI). Detta kan göras genom att helt enkelt dubbelklicka på filen. Då bör enheten ha ett standard GUI för att öppna filen med.

Därefter ändrar du raden för huvudlösenordet admin_passwd = $pbkdf2-sha... till exempelvis admin_passwd = newpassword1234. Lösenordet kan vara vad som helst så länge det sparas temporärt. Se till att ändra alla tecken efter =.

Example

Raden ser ut så här: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

Den modifierade raden ser ut så här: admin_passwd = nytt lösenord1234

Ändra raden med huvudlösenordet med hjälp av följande Unix-kommando som beskrivs nedan.

Anslut till Odoo-serverns terminal via Secure Shell (SSH)-protokollet och redigera konfigurationsfilen. För att ändra konfigurationsfilen, ange följande kommando: sudo nano /etc/odoo.conf

När du har öppnat konfigurationsfilen ändrar du raden för huvudlösenordet admin_passwd = $pbkdf2-sha... till admin_passwd = newpassword1234. Detta lösenord kan vara vad som helst, så länge det sparas tillfälligt. Se till att ändra alla tecken efter =.

Example

Raden ser ut så här: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

Den modifierade raden ser ut så här: admin_passwd = nytt lösenord1234

Viktigt

Det är viktigt att lösenordet ändras till något annat, i stället för att utlösa en ny lösenordsåterställning genom att lägga till ett semikolon ; i början av raden. På så sätt säkerställs att databasen är säker under hela processen för återställning av lösenordet.

Restart Odoo server¶

Efter att du har ställt in det tillfälliga lösenordet krävs en omstart av Odoo-servern krav.

För att starta om Odoo-servern skriver du först in services i Windows Search-fält. Välj sedan programmet Services och bläddra ner till tjänsten Odoo.

Högerklicka sedan på Odoo och välj Start eller Restart. Denna åtgärd startar om Odoo-servern manuellt.

Starta om Odoo-servern genom att skriva kommandot: sudo service odoo15 restart

Observera

Ändra numret efter odoo så att det passar den specifika version som servern körs på.

Använd webbgränssnittet för att kryptera lösenordet igen¶

Navigera först till /web/database/manager eller http://server_ip:port/web/database/manager i en webbläsare.

Observera

Ersätt server_ip med databasens IP-adress. Ersätt port med den numrerade port som databasen är tillgänglig från.

Klicka sedan på Set Master Password och skriv in det tidigare valda tillfälliga lösenordet i fältet Master Password. Efter detta steg skriver du in ett New Master Password. Det New Master Password hashas (eller krypteras), när du klickar på Continue-knappen.

Lösenordet har nu återställts och en hashad version av det nya lösenordet visas nu i konfigurationsfilen.

Se även

Mer information om databasens säkerhet i Odoo finns i den här dokumentationen: Säkerhet för databashanterare.

Webbläsare som stöds¶

Odoo stöder alla större stationära och mobila webbläsare som finns på marknaden, så länge de stöds av sina utgivare.

Här är de webbläsare som stöds:

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

Varning

Kontrollera att din webbläsare är uppdaterad och fortfarande stöds av utgivaren innan du skickar in en felrapport.

Observera

Sedan Odoo 13.0 stöds ES6. Därför har stödet för IE tagits bort.

1: att låta flera Odoo-installationer använda samma PostgreSQL-databas, eller att ge mer datorresurser till båda programvarorna.
2: tekniskt sett kan ett verktyg som socat användas för att proxy UNIX sockets över nätverk, men det är främst för programvara som endast kan användas över UNIX sockets
3: eller endast vara tillgänglig via ett internt paketförmedlat nätverk, men det kräver säkrade switchar, skydd mot ARP spoofing och utesluter användning av WiFi. Även över säkra paketförmedlade nätverk rekommenderas driftsättning via HTTPS, och eventuella kostnader sänks eftersom ”självsignerade” certifikat är lättare att driftsätta i en kontrollerad miljö än över Internet.

Edit on GitHub