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.

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$

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.

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.

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

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).

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.

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)))'

which generates a 32-character pseudorandom printable string.

Reset the master password¶

There may be instances where the master password is misplaced, or compromised, and needs to be reset. The following process is for system administrators of an Odoo on-premise database detailing how to manually reset and re-encrypt the master password.

When creating a new on-premise database, a random master password is generated. Odoo recommends using this password to secure the database. This password is implemented by default, so there is a secure master password for any Odoo on-premise deployment.

The master password is specified in the Odoo configuration file (odoo.conf or odoorc (hidden file)). The Odoo master password is needed to modify, create, or delete a database through the graphical user interface (GUI).

Locate configuration file¶

First, open the Odoo configuration file (odoo.conf or odoorc (hidden file)).

Change old password¶

Once the appropriate file has been opened, proceed to modify the old password in the configuration file to a temporary password.

Restart Odoo server¶

After setting the temporary password, a restart of the Odoo server is required.

Use web interface to re-encrypt password¶

First, navigate to /web/database/manager or http://server_ip:port/web/database/manager in a browser.

Next, click Set Master Password, and type in the previously-selected temporary password into the Master Password field. Following this step, type in a New Master Password. The New Master Password is hashed (or encrypted), once the Continue button is clicked.

At this point, the password has been successfully reset, and a hashed version of the new password now appears in the configuration file.

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

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.