Systemkonfiguration¶

Detta dokument beskriver grundläggande steg för att konfigurera 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 mot internet.

Varning

Om du sätter upp en publik server, se till att kontrollera våra :ref:`säkerhetsrekommendationer!

dbfilter¶

Odoo är ett multi-tenant-system: 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 man arbetar med backend (webbklient) som inloggad företagsanvändare: databasen kan väljas när man loggar in och anpassningar laddas efteråt.

Det är dock ett problem för icke-loggade 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 anger hur databasen ska väljas baserat på det värdnamn (domän) som begärs. Värdet är ett ”regelbundet uttryck”, som kan inkludera det dynamiskt injicerade värdnamnet (%h) eller den första underdomänen (%d) som systemet nås via.

För servrar som är värd för flera databaser i produktion, särskilt om website används, måste dbfilter ställas in, annars kommer ett antal funktioner inte att fungera korrekt.

Konfigurationsprover¶

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

i konfigurationsfilen set:

[options]
dbfilter = ^mycompany.*$

Visa endast databaser som matchar den första subdomänen efter www: till exempel kommer databasen ”mycompany” 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 set:

[options]
dbfilter = ^%d$

Observera

Att ställa in ett korrekt --db-filter är en viktig del av att säkra din distribution. När det fungerar korrekt och bara matchar en enda databas per värdnamn rekommenderas det starkt att blockera åtkomsten 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 åtkomsten till skärmarna för databashanteraren. Se även security.

PostgreSQL¶

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

UNIX-uttag är bra om du vill att Odoo och PostgreSQL ska köras på samma maskin och är standard när ingen värd tillhandahålls, men om du vill att Odoo och PostgreSQL ska köras på olika maskiner 1 måste det lyssna till nätverksgränssnitt 2, antingen:

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

Exempel på konfiguration¶

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

i /etc/postgresql/<DIN POSTGRESQL VERSION>/main/pg_hba.conf set:

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

i /etc/postgresql/<DIN POSTGRESQL VERSION>/main/postgresql.conf set:

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

Konfigurera Odoo¶

Från början ansluter Odoo till en lokal postgres över UNIX-socket via port 5432. Detta kan åsidosättas med hjälp av databasalternativen när din Postgres-distribution inte är lokal och/eller inte använder standardinstallationen.

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

Skärmarna för databashantering skyddas av inställningen admin_passwd. Den här inställningen kan endast anges 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 skärmen för databashantering ska fungera krävs att PostgreSQL-användaren har createdb rätt.
Användare kan alltid släppa databaser 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 * får inte * vara en superanvändare

Exempel på konfiguration¶

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

i konfigurationsfilen set:

[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 genomdriva ssl-anslutning mellan Odoo och PostgreSQL. i Odoo kontrollerar db_sslmode ssl-säkerheten för anslutningen med värde som valts ut av ”inaktivera”, ”tillåt”, ”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 dockercontainrar. Den väljs genom att alternativet --workers utelämnas eller sätts till 0.

Servern multiprocessing är en fullskalig 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 maskinvaran på bästa sätt. En pool av 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.

Servern för flera processorer är en opt-in-server. Den väljs genom att alternativet --workers sätts till ett icke-null heltal.

Observera

Eftersom den är mycket anpassad för Linux-servrar är multiprocessing-servern inte tillgänglig i Windows.

Beräkning av antal arbetare¶

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
I samma scenario beräknas en lättare arbetare förbruka cirka 150 MB RAM-minne

Behövs RAM = #arbetare * ((light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

Livechatt¶

I multiprocessing startas en dedikerad LiveChat-arbetare automatiskt och lyssnar på --gevent-port. Som standard kommer HTTP-förfrågningarna att fortsätta att komma åt 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 (t.ex. 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 är mellan 7 och 7,5 .
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3GB RAM for 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 det nås 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 HTTPS[#switching]_. SSL-terminering kan implementeras via nästan vilken SSL-termineringsproxy som helst, men kräver följande installation:

Aktivera Odoos proxy-läge. Detta bör endast aktiveras när Odoo är bakom en omvänd proxy
Konfigurera proxy för SSL-terminering (exempel på terminering i Nginx)
Konfigurera själva proxyn (Nginx proxyexempel)
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
Proxyförfrågningar till odoo

i konfigurationsfilen set:

proxy_mode = True

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

#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 helt enkelt inte kunna 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-startskript som odoo-wsgi.example.py. Det skriptet bör anpassas (eventuellt efter att ha kopierats från setup-katalogen) för att korrekt ställa in konfigurationen direkt i odoo.tools.config i stället för via kommandoraden eller en konfigurationsfil.

WSGI-servern kommer dock bara 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¶

För att behandla cron-jobb krävs att en av de inbyggda Odoo-servrarna startas bredvid WSGI-servern. Den servern måste konfigureras för att endast behandla cron-jobb och inte HTTP-förfrågningar med hjälp av --no-http cli option eller inställningen http_enable = False i konfigurationsfilen.

På Linux-liknande system rekommenderas att använda multiprocessing-servern framför multi-threading-servern 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 att du använder en WSGI-server som är kompatibel med gevent. 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/processbaserad) 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ågningar. Släpp bara cli-alternativet --no-http från cron-servern och se till att förfrågningar vars sökväg börjar med /websocket/ riktas till den här servern, antingen på --http-port (server med flera trådar) eller på --gevent-port (server med flera processorer).

Servering av statiska filer och bilagor¶

För att underlätta utvecklingen serverar Odoo alla statiska filer och bilagor direkt 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¶

Odoo statiska filer finns i varje moduls static/-mapp, så statiska filer kan serveras genom att fånga upp alla förfrågningar till /MODULE/static/FILE, och leta upp rätt modul (och fil) i de olika tilläggssökvägarna.

Vi rekommenderar att du anger rubriken Content-Security-Policy: default-src 'none' på alla bilder som levereras av webbservern. Det är inte absolut nödvändigt eftersom användare inte kan ändra/injicera innehåll i modulernas static/-mapp och befintliga bilder är slutgiltiga (de hämtar inte nya resurser själva). Det är dock god praxis.

Med hjälp av ovanstående NGINX (https)-konfiguration ska följande block map och location 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 är beroende av din installation, särskilt av 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'.

Det bör root och try_files vara:

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

Säg att Odoo har installerats via källor, att både Community och Enterprise git repositories har klonats 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'.

Det bör root och try_files vara:

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

Serveringstillbehör¶

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 är lagrade och om den aktuella användaren kan komma åt dem eller inte.

När filen väl har lokaliserats och åtkomsträttigheterna har verifierats av Odoo är det dock en bra idé att servera filen med hjälp av den statiska webbservern istället för 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 det är klart startar du Odoo med CLI-flaggan --x-sendfile (denna unika flagga används för både X-Sendfile och X-Accel).

Observera

X-Sendfile-tillägget 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 vilken sökväg du har till ditt filarkiv, starta Odoo med alternativet --x-sendfile och navigera till URL:en /web/filestore direkt via Odoo (navigera inte till URL:en via NGINX). Detta loggar en varning, meddelandet innehåller den konfiguration du behöver.

Säkerhet¶

Till att börja med bör man komma ihåg att säkerheten i ett informationssystem är en kontinuerlig process, inte en engångsföreteelse. I varje ögonblick ä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 säkerhetsåtgärdsplan. 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 vetter mot Internet bör du tänka på följande säkerhetsrelaterade frågor:

Ange alltid ett starkt administratörslösenord för superadmin och begränsa åtkomsten till databashanteringssidorna så snart systemet har installerats. Se Databasansvarig Säkerhet.
Välj unika inloggningar och starka lösenord för alla administratörskonton i 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-/stagingdatabaser.
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 enligt värdnamnet. Se dbfilter. Du kan också använda -d för att tillhandahålla din egen (kommaseparerade) 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 dbfilter är konfigurerade och bara matchar en enda databas per värdnamn, bör du ställa in list_db konfigurationsalternativ till False, för att förhindra listning av databaser helt och blockera åtkomst till databashanteringsskärmarna (detta är också exponerat som --no-database-list kommandoradsalternativ)
Se till 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 din server 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 cleartextkommunikation. 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 tidsgränser och aktivera sedan alternativet proxy mode. Se även HTTPS.
Om du behöver tillåta SSH-fjärråtkomst till dina servrar ska du se till att ange ett starkt lösenord för alla konton, inte bara för root. Det rekommenderas starkt att helt inaktivera lösenordsbaserad autentisering och endast tillåta autentisering med offentliga nycklar. Överväg också att begränsa åtkomsten via ett VPN, tillåta endast 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, hosta dina offentliga demo/test/staging-instanser på andra maskiner än produktionsmaskinerna. Och tillämpa samma säkerhetsåtgärder som för produktion.
Om din Odoo-server som vänder sig till allmänheten har tillgång till känsliga interna nätverksresurser eller tjänster (t.ex. via ett privat VLAN), implementera lämpliga brandväggsregler för att skydda dessa interna resurser. Detta kommer att säkerställa att Odoo-servern inte kan användas av misstag (eller som ett resultat av skadliga användaråtgärder) för att komma åt eller störa dessa interna resurser. Vanligtvis kan detta göras genom att tillämpa en utgående standard DENY-regel på brandväggen och sedan endast uttryckligen godkänna åtkomst till interna resurser som Odoo-servern behöver åtkomst till. Systemd IP-trafikåtkomstkontroll kan också vara användbart för att implementera nätverksåtkomstkontroll per process.
Om din Odoo-server som vänder sig till allmänheten ligger bakom en brandvägg för webbapplikationer, 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 för slutpunkterna på dina Odoo-servrar hemliga. De kan till exempel visas i webbserverloggar när du frågar 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 för allmänheten utom från de specifika IP-adresserna för din WAF, lastbalanserare eller proxytjänst. Tjänsteleverantörer som CloudFlare upprätthåller vanligtvis en offentlig lista över sina IP-adressområden för detta ändamål.
Om du är värd för flera kunder ska du isolera kunddata och filer från varandra med hjälp av containrar eller lämpliga ”fängelsetekniker”.
Gör dagliga säkerhetskopior av dina databaser och fillagringsdata och kopiera dem till en fjärrarkiveringsserver som inte är åtkomlig från själva servern.
Driftsättning av Odoo på Linux rekommenderas starkt framför Windows. Om du ändå väljer att distribuera på en Windows-plattform bör en grundlig säkerhetshärdning av servern genomföras och ligger utanför ramen för denna guide.

Blockering av Brute Force-attacker¶

För implementeringar som vetter mot internet är brute force-attacker på användarlösenord mycket vanliga, och detta hot bör inte försummas för Odoos servrar. Odoo skickar ut en loggpost när ett inloggningsförsök utförs och rapporterar resultatet: framgång eller misslyckande, tillsammans med målinloggningen och käll-IP.

Logguppgifterna 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

Framgångsrik 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 att förebygga intrång, t.ex. fail2ban.

Exempelvis bör följande fail2ban-filterdefinition 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 för att blockera IP-adressen 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

Databasansvarig Säkerhet¶

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

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

Om hanteringsskärmarna inte får vara tillgängliga alls bör du ställa in konfigurationsalternativet list_db till False, för att blockera åtkomst till alla databasvals- och hanteringsskärmar.

Varning

Det är starkt rekommenderat att inaktivera databashanteraren för alla system som vetter mot Internet! Den är avsedd som ett utvecklings-/demoverktyg för att göra det enkelt att snabbt skapa och hantera databaser. Det är inte utformat för att användas i produktion 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 uppläggning av nya databaser och automatiserade säkerhetskopior.

Var noga med att ställa in en lämplig db_name-parameter (och eventuellt även dbfilter) så att systemet kan bestämma måldatabasen för varje begäran, annars blockeras användarna eftersom de inte får välja databas själva.

Om hanteringsskärmarna endast ska vara åtkomliga från en utvald uppsättning maskiner, kan du använda proxyserverns funktioner för att blockera åtkomst till alla rutter som börjar med /web/database utom (kanske) /web/database/selector som visar databasens urvalsskärm.

Om databashanteringsskärmen ska 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 ska 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: Byte av 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 = sommar123

Ä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 = sommar123

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: Databasansvarig Säkerhet.

Webbläsare som stöds¶

Odoo supports the latest version of the following browsers.

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

1: för att få flera Odoo-installationer att använda samma PostgreSQL-databas, eller för att tillhandahålla mer datorresurser till båda programvarorna.
2: tekniskt sett kan ett verktyg som socat användas för att proxy UNIX-socklar över nätverk, men det är mest för programvara som bara kan användas via UNIX-socklar
3: eller endast vara åtkomliga via ett internt paketkopplat nätverk, men det kräver säkra switchar, skydd mot ”ARP-spoofing” och utesluter användning av WiFi. Även i säkra paketkopplade nätverk rekommenderas användning av HTTPS, och eventuella kostnader sänks eftersom ”självsignerade” certifikat är enklare att använda i en kontrollerad miljö än över internet.

Edit on GitHub