Systeem configuratie¶

Dit document beschrijft de basisstappen voor het instellen van Odoo in productie of op een internetgerichte server. Het volgt installation, en is over het algemeen niet nodig voor ontwikkelsystemen die niet op internet beschikbaar zijn.

dbfilter¶

Odoo is een multi-tenant systeem: één enkel Odoo-systeem kan een aantal database-instanties runnen en bedienen. Het is ook zeer aanpasbaar, met maatwerk (vanaf de modules die worden geladen) afhankelijk van de “huidige database”.

Bij het werken met de backend (webclient) als aangemelde bedrijfsgebruiker is dit geen probleem: bij het aanmelden kan de database worden geselecteerd en achteraf kunnen maatoplossingen worden geladen.

Het is echter een probleem voor niet-ingelogde gebruikers (portaal, website) die niet gebonden zijn aan een database: Odoo moet weten welke database gebruikt moet worden om de websitepagina te laden of de bewerking uit te voeren. Als multi-tenancy niet wordt gebruikt, is dat geen probleem. Er is slechts één database om te gebruiken, maar als er meerdere databases toegankelijk zijn, heeft Odoo een regel nodig om te weten welke database moet worden gebruikt.

Dat is een van de doeleinden van :option:`--db-filter<odoo-bin --db-filter> `: het specificeert hoe de database moet worden geselecteerd op basis van de hostnaam (domein) die wordt opgevraagd. De waarde is een `reguliere expressie`_, mogelijk inclusief de dynamisch geïnjecteerde hostnaam (%h) of het eerste subdomein (%d) waarmee toegang wordt verkregen tot het systeem.

Voor servers die in productie meerdere databases hosten, vooral als website wordt gebruikt, moet dbfilter **worden ingesteld, anders zullen een aantal functies niet correct werken.

Configuratievoorbeelden¶

• Toon alleen databases waarvan de naam begint met ‘mijnbedrijf’

in het configuratiebestand set:

[options]
dbfilter = ^mycompany.*$

• Toon alleen databases die overeenkomen met het eerste subdomein na www: de database “mijnbedrijf” wordt bijvoorbeeld getoond als het binnenkomende verzoek is verzonden naar www.mijnbedrijf.com of mijnbedrijf.co.uk , maar niet voor www2.mijnbedrijf.com of helpdesk.mijnbedrijf.com.

in het configuratiebestand set:

[options]
dbfilter = ^%d$

PostgreSQL¶

Standaard staat PostgreSQL alleen verbindingen toe via UNIX-sockets en loopback-verbindingen (vanaf “localhost”, dezelfde machine waarop de PostgreSQL-server is geïnstalleerd).

UNIX-socket is prima als je wilt dat Odoo en PostgreSQL op dezelfde machine worden uitgevoerd, en is de standaard als er geen host is opgegeven, maar als je wilt dat Odoo en PostgreSQL op verschillende machines worden uitgevoerd 1, dan zal het nodig zijn luister naar netwerkinterfaces 2, ofwel:

• Accepteer alleen loopback-verbindingen en gebruik een SSH-tunnel tussen de machine waarop Odoo draait en die waarop PostgreSQL draait, configureer Odoo vervolgens om verbinding te maken met het einde van de tunnel

• Accepteer verbindingen met de machine waarop Odoo is geïnstalleerd, mogelijk via SSL (zie PostgreSQL-verbindingsinstellingen voor details), configureer vervolgens Odoo om verbinding te maken via het netwerk

Configuratievoorbeeld¶

• Sta TCP-verbinding toe op localhost

• TCP-verbinding vanaf 192.168.1.x-netwerk toestaan

in /etc/postgresql/<YOUR POSTGRESQL VERSION> /main/pg_hba.conf ingesteld:

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

in /etc/postgresql/<YOUR POSTGRESQL VERSION> /main/postgresql.conf ingesteld:

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

Odoo configureren¶

Out-of-the-box maakt Odoo verbinding met een lokale postgres via UNIX-socket via poort 5432. Dit kan worden overschreven met behulp van de database-opties wanneer jouw Postgres-implementatie niet lokaal is en/of gebruikt niet de standaardinstallatieinstellingen.

De verpakte installatieprogramma’s<packages> ` zal automatisch een nieuwe gebruiker aanmaken (``odoo`) en deze instellen als databasegebruiker.

• De databasebeheerschermen zijn beveiligd door de admin_passwd instelling. Deze instelling kan alleen worden ingesteld met behulp van configuratiebestanden en wordt eenvoudigweg gecontroleerd voordat databasewijzigingen worden uitgevoerd. Het moet worden ingesteld op een willekeurig gegenereerde waarde om ervoor te zorgen dat derden deze interface niet kunnen gebruiken.

• Alle databasebewerkingen gebruiken de database-opties, inclusief het databasebeheerscherm. Om het databasebeheerscherm te laten werken, moet de PostgreSQL-gebruiker het recht createdb hebben.

• Gebruikers kunnen altijd de databases waarvan zij eigenaar zijn, verwijderen. Om het databasebeheerscherm volledig niet-functioneel te laten zijn, moet de PostgreSQL-gebruiker zijn aangemaakt met no-createdb en moet de database eigendom zijn van een andere PostgreSQL-gebruiker.

  Waarschuwing

  de PostgreSQL-gebruiker mag geen superuser zijn

Configuratievoorbeeld¶

• maak verbinding met een PostgreSQL-server op 192.168.1.2

• poort 5432

• met behulp van een ‘odoo’-gebruikersaccount,

• met ‘pwd’ als wachtwoord

• alleen db filteren met een naam die begint met ‘mijnbedrijf’

in het configuratiebestand set:

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

SSL tussen Odoo en PostgreSQL¶

Sinds Odoo 11.0 kunt je een SSL-verbinding tussen Odoo en PostgreSQL afdwingen. in Odoo controleert de db_sslmode de ssl-beveiliging van de verbinding met de waarde gekozen uit ‘disable’, ‘allow’, ‘prefer’, ‘require’, ‘verify-ca’ of ‘verify-full’

PostgreSQL-document

Ingebouwde server¶

Odoo bevat ingebouwde HTTP-, cron- en livechatservers, die gebruik maken van multi-threading of multi-processing.

De multi-threaded server is een eenvoudigere server die voornamelijk wordt gebruikt voor ontwikkeling, demonstraties en de compatibiliteit ervan met verschillende besturingssystemen (waaronder Windows). Voor elk nieuw HTTP-verzoek wordt een nieuwe thread gegenereerd, zelfs voor langlevende verbindingen zoals websocket. Er worden ook extra daemonische cron-threads gegenereerd. Vanwege een Python-beperking (GIL) wordt er niet optimaal gebruik gemaakt van de hardware.

De multi-threaded server is de standaardserver, ook voor dockercontainers. Het wordt geselecteerd door de --workers te verlaten<odoo-bin --workers> ` optie uit of zet deze op ``0`.

De multi-processing-server is een volwaardige server die voornamelijk wordt gebruikt voor productie. Het is niet onderworpen aan dezelfde Python-beperking (GIL) op het gebied van het gebruik van bronnen en maakt daarom optimaal gebruik van de hardware. Bij het opstarten van de server wordt een pool van werknemers aangemaakt. Nieuwe HTTP-aanvragen worden door het besturingssysteem in de wachtrij geplaatst totdat er werknemers klaar zijn om ze te verwerken. Een extra gebeurtenisgestuurde HTTP-werker voor de livechat wordt op een alternatieve poort voortgebracht. Er worden ook extra cronwerkers voortgebracht. Een configureerbare procesreaper bewaakt het gebruik van bronnen en kan mislukte werknemers doden/herstarten.

De multi-processing server is opt-in. Het wordt geselecteerd door de :option:`–workers in te stellen<odoo-bin –workers> ` optie naar een niet-null geheel getal.

Berekening van het aantal werknemers¶

• Vuistregel: (#CPU * 2) + 1

• Cron-workers hebben CPU nodig

• 1 werknemer ~= 6 gelijktijdige gebruikers

berekening van de geheugengrootte¶

• We beschouwen 20% ovan de verzoeken als zware verzoeken, terwijl 80% aeenvoudigere verzoeken zijn

• Een zware werker, wanneer alle computervelden goed zijn ontworpen, SQL-verzoeken goed zijn ontworpen, … verbruikt naar schatting ongeveer 1 GB RAM

• Een lichtere werknemer verbruikt in hetzelfde scenario naar schatting ongeveer 150 MB RAM

Benodigd RAM = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

Live chat¶

Bij multi-processing wordt automatisch een speciale LiveChat-werker gestart die luistert op de --gevent-port<odoo-bin --gevent-port> `. Standaard blijven de HTTP-verzoeken toegang krijgen tot de normale HTTP-werknemers in plaats van tot de LiveChat-werknemers. Je moet een proxy voor Odoo implementeren en inkomende verzoeken waarvan het pad begint met `/websocket/`` omleiden naar de LiveChat-werknemer. Jij moet Odoo ook starten in :option:`–proxy-modus<odoo-bin –proxy-mode> ` dus het gebruikt de echte clientheaders (zoals hostnaam, schema en IP) in plaats van de proxyheaders.

Configuratievoorbeeld¶

• Server met 4 CPU’s, 8 threads

• 60 gelijktijdige gebruikers

• 60 gebruikers / 6 = 10 <- theoretisch aantal benodigde werknemers

• (4 * 2) + 1 = 9 <- theoretisch maximaal aantal werknemers

• We gebruiken 8 werkers + 1 voor cron. We zullen ook een monitoringsysteem gebruiken om de CPU-belasting te meten en te controleren of deze tussen 7 en 7.5 ligt.

• RAM = 9 * ((0,8*150) + (0,2*1024)) ~= 3Go RAM voor Odoo

in het configuratiebestand:

[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¶

Of het nu toegankelijk is via een website/webclient of webservice, Odoo verzendt authenticatie-informatie in leesbare tekst. Dit betekent dat een veilige implementatie van Odoo HTTPS3 moet gebruiken. SSL-beëindiging kan worden geïmplementeerd via vrijwel elke SSL-beëindigingsproxy, maar vereist de volgende instellingen:

• Schakel de :option:`proxy-modus van Odoo in<odoo-bin –proxy-mode> `. Dit zou alleen ingeschakeld moeten worden als Odoo zich achter een reverse proxy bevindt

• Stel de SSL-beëindigingsproxy in (Nginx-beëindigingsvoorbeeld)

• Stel de proxying zelf in (Nginx proxying voorbeeld)

• Jouw SSL-beëindigingsproxy moet ook automatisch niet-beveiligde verbindingen omleiden naar de beveiligde poort

Configuratievoorbeeld¶

• Leid http-verzoeken om naar https

• Proxyverzoeken voor odoo

in het configuratiebestand set:

proxy_mode = True

in /etc/nginx/sites-enabled/odoo.conf ingesteld:

#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-verharding¶

Voeg de Strict-Transport-Security header toe aan alle verzoeken, om te voorkomen dat browsers ooit een gewoon HTTP-verzoek naar dit domein sturen. Je moet te allen tijde een werkende HTTPS-service met een geldig certificaat op dit domein onderhouden, anders krijgen jouw gebruikers beveiligingswaarschuwingen te zien of hebben ze er helemaal geen toegang toe.

Forceer HTTPS-verbindingen gedurende een jaar voor elke bezoeker in NGINX met de regel:

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

Er kan aanvullende configuratie worden gedefinieerd voor de session_id cookie. De vlag Secure kan worden toegevoegd om ervoor te zorgen dat deze nooit via HTTP wordt verzonden en SameSite=Lax om geauthenticeerde CSRF te voorkomen.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Odoo als een WSGI-applicatie¶

Het is ook mogelijk om Odoo te koppelen als een standaard WSGI applicatie. Odoo levert de basis voor een WSGI-opstartscript als odoo-wsgi.example.py. Dat script moet worden aangepast (mogelijk nadat het vanuit de setup-directory is gekopieerd) om de configuratie correct in te stellen rechtstreeks in odoo.tools.config in plaats van via de opdrachtregel of een configuratiebestand.

De WSGI-server zal echter alleen het belangrijkste HTTP-eindpunt voor de webclient, website en webservice-API vrijgeven. Omdat Odoo geen controle meer heeft over het aanmaken van werknemers, kan het geen cron- of livechat-werkers instellen

Cron-werknemers¶

Het starten van een van de ingebouwde Odoo-servers naast de WSGI-server is vereist om cron-taken te verwerken. Die server moet worden geconfigureerd om alleen crons te verwerken en geen HTTP-verzoeken met behulp van de --no-http<odoo-bin --no-http> ` cli optie of de ``http_enable = False` configuratiebestandsinstelling.

Op Linux-achtige systemen wordt het gebruik van de multi-processing server in plaats van de multi-threading aanbevolen om te profiteren van beter hardwaregebruik en verhoogde stabiliteit, dat wil zeggen door gebruik te maken van de --workers=-1<odoo-bin --workers> ` en :optie:–max-cron-threads=n<odoo-bin –max-cron-threads> `cli-opties.

Live chat¶

Voor een correcte werking van de livechatfunctie is het gebruik van een gevent-compatibele WSGI-server vereist. Die server zou veel gelijktijdige, langlevende verbindingen moeten kunnen verwerken, maar heeft niet veel rekenkracht nodig. Alle verzoeken waarvan het pad begint met /websocket/ moeten naar die server worden geleid. Voor alle andere verzoeken moet een reguliere (thread/process-gebaseerde) WSGI-server worden gebruikt.

De Odoo cron-server kan ook worden gebruikt om de livechatverzoeken af te handelen. Laat gewoon de --no-http vallen<odoo-bin --no-http> ` cli optie van de cron-server en zorg ervoor dat verzoeken waarvan het pad begint met `/websocket/`` naar deze server worden geleid, hetzij op de --http-port<odoo-bin --http-port> ` (multi-threading server) of op de :option:–gevent-port<odoo-bin –gevent-port> ` (multi-verwerkingsserver).

Het serveren van statische bestanden en bijlagen¶

Voor ontwikkelingsgemak bedient Odoo rechtstreeks alle statische bestanden en bijlagen in zijn modules. Dit is misschien niet ideaal als het om prestaties gaat, en statische bestanden moeten over het algemeen worden bediend door een statische HTTP-server.

Statische bestanden serveren¶

Odoo statische bestanden bevinden zich in de map static/ van elke module, zodat statische bestanden kunnen worden aangeboden door alle verzoeken aan /MODULE/static/FILE te onderscheppen en de juiste module op te zoeken (en bestand) in de verschillende add-onspaden.

Het wordt aanbevolen om de header Content-Security-Policy: default-src 'none' in te stellen op alle afbeeldingen die door de webserver worden geleverd. Het is niet strikt noodzakelijk omdat gebruikers geen inhoud kunnen wijzigen/injecteren in de map static/ van de modules en bestaande afbeeldingen definitief zijn (ze halen zelf geen nieuwe bronnen op). Het is echter een goede gewoonte.

Met behulp van de bovenstaande NGINX (https)-configuratie moeten de volgende map en location blokken worden toegevoegd om statische bestanden via NGINX te bedienen.

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 daadwerkelijke root en try_files richtlijnen zijn afhankelijk van jouw installatie, in het bijzonder van jouw :option:`–addons-pad<odoo-bin –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;

Serveerbijlagen¶

Bijlagen zijn bestanden die zijn opgeslagen in de bestandsopslag en waarvan de toegang wordt geregeld door Odoo. Ze zijn niet rechtstreeks toegankelijk via een statische webserver, omdat voor toegang tot deze bestanden meerdere zoekopdrachten in de database nodig zijn om te bepalen waar de bestanden zijn opgeslagen en of de huidige gebruiker er toegang toe heeft of niet.

Niettemin, zodra het bestand is gelokaliseerd en de toegangsrechten zijn geverifieerd door Odoo, is het een goed idee om het bestand aan te bieden met behulp van de statische webserver in plaats van Odoo. Om ervoor te zorgen dat Odoo het serveren van bestanden delegeert aan de statische webserver, moet het bestand X-Sendfile<https://tn123.org/mod_xsendfile/> `_ (apache) of `X-Accel<https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/> `_ (nginx) extensies moeten zijn ingeschakeld en geconfigureerd op de statische webserver. Zodra het is ingesteld, start Odoo met de :option:–x-sendfile<odoo-bin –x-sendfile> ` CLI-vlag (deze unieke vlag wordt gebruikt voor zowel X-Sendfile als X-Accel).

Beveiliging¶

Houd er om te beginnen rekening mee dat het beveiligen van een informatiesysteem een continu proces is en geen eenmalige operatie. Je bent op elk moment zo veilig als de zwakste schakel in jouw omgeving.

Beschouw dit gedeelte dus niet als de ultieme lijst met maatregelen die alle beveiligingsproblemen zullen voorkomen. Het is alleen bedoeld als samenvatting van de eerste belangrijke zaken die je zeker moet opnemen in jouw beveiligingsactieplan. De rest komt van de beste beveiligingspraktijken voor jouw besturingssysteem en distributie, best practices op het gebied van gebruikers, wachtwoorden en toegangscontrolebeheer, enz.

Wanneer je een internetgerichte server implementeert, moet je rekening houden met de volgende beveiligingsgerelateerde onderwerpen:

• Stel altijd een sterk beheerderswachtwoord in en beperk de toegang tot de databasebeheerpagina’s zodra het systeem is ingesteld. Zie Databasebeheer Beveiliging.

• Kies unieke logins en sterke wachtwoorden voor alle beheerdersaccounts in alle databases. Gebruik niet ‘admin’ als login. Gebruik deze logins niet voor de dagelijkse werkzaamheden, alleen voor het besturen/beheren van de installatie. Gebruik nooit standaardwachtwoorden zoals admin/admin, zelfs niet voor test-/staging-databases.

• Installeer geen demogegevens op internetgerichte servers. Databases met demogegevens bevatten standaard logins en wachtwoorden die kunnen worden gebruikt om toegang te krijgen tot jouw systemen en aanzienlijke problemen te veroorzaken, zelfs op staging-/dev-systemen.

• Gebruik de juiste databasefilters ( --db-filter<odoo-bin --db-filter> `) om de zichtbaarheid van jouw databases te beperken op basis van de hostnaam. Zie :ref:`dbfilter. Je kunt ook :optie:`-d gebruiken<odoo-bin -d> ` om jouw eigen (door komma’s gescheiden) lijst met beschikbare databases aan te bieden waaruit je kunt filteren, in plaats van het systeem ze allemaal uit de database-backend te laten ophalen.

• Zodra jouw db_name en dbfilter zijn geconfigureerd en slechts met één database per hostnaam overeenkomen, moet je de list_db configuratie-optie op False instellen, om te voorkomen dat databases volledig worden weergegeven en om toegang tot de databasebeheerschermen (dit wordt ook weergegeven als de :option:`–no-database-list<odoo-bin –no-database-list> ` opdrachtregeloptie)

• Zorg ervoor dat de PostgreSQL-gebruiker (--db_user<odoo-bin --db_user> `) *geen* supergebruiker is, en dat jouw databases eigendom zijn van een andere gebruiker. Ze kunnen bijvoorbeeld eigendom zijn van de ``postgres` supergebruiker als je een speciale, niet-bevoorrechte db_user gebruikt. Zie ook Odoo configureren.

• Houd installaties up-to-date door regelmatig de nieuwste builds te installeren, via GitHub of door de nieuwste versie te downloaden van https://www.odoo.com/page/download of http://nightly.odoo.com

• Configureer jouw server in de multi-procesmodus met de juiste limieten die overeenkomen met jouw typische gebruik (geheugen/CPU/time-outs). Zie ook ingebouwde_server.

• Voer Odoo uit achter een webserver die HTTPS-beëindiging biedt met een geldig SSL-certificaat, om afluisteren van cleartext-communicatie te voorkomen. SSL-certificaten zijn goedkoop en er zijn veel gratis opties. Configureer de webproxy om de grootte van verzoeken te beperken, stel de juiste time-outs in en schakel vervolgens de proxy-modus in<odoo-bin --proxy-mode> ` optie. Zie ook :ref:`https_proxy.

• Als je externe SSH-toegang tot jouw servers moet toestaan, zorg er dan voor dat je een sterk wachtwoord instelt voor alle accounts, niet alleen voor root. Het wordt ten zeerste aanbevolen om op wachtwoorden gebaseerde authenticatie volledig uit te schakelen en alleen authenticatie met openbare sleutels toe te staan. Overweeg ook om de toegang via een VPN te beperken, alleen vertrouwde IP’s in de firewall toe te staan, en/of een brute-force detectiesysteem uit te voeren, zoals fail2ban of een gelijkwaardig systeem.

• Overweeg om geschikte snelheidsbeperkingen op jouw proxy of firewall te installeren om brute-force-aanvallen en denial-of-service-aanvallen te voorkomen. Zie ook Brute Force-aanvallen blokkeren voor specifieke maatregelen.

  Veel netwerkproviders bieden automatische bescherming tegen Distributed Denial of Service-aanvallen (DDOS), maar dit is vaak een optionele service, dus je moet contact met hen opnemen.

• Host waar mogelijk jouw openbare demo-/test-/staging-instanties op andere machines dan de productiemachines. En pas dezelfde veiligheidsmaatregelen toe als bij de productie.

• Als jouw openbare Odoo-server toegang heeft tot gevoelige interne netwerkbronnen of -diensten (bijvoorbeeld via een privé VLAN), implementeer dan passende firewallregels om die interne bronnen te beschermen. Dit zorgt ervoor dat de Odoo-server niet per ongeluk (of als resultaat van kwaadwillige gebruikersacties) kan worden gebruikt om toegang te krijgen tot deze interne bronnen of deze te verstoren. Meestal kan dit worden gedaan door een uitgaande standaard DENY-regel op de firewall toe te passen, en vervolgens alleen expliciet toegang te verlenen tot interne bronnen waartoe de Odoo-server toegang moet hebben. Systemd IP-verkeer toegangscontrole kan ook nuttig zijn om netwerktoegangscontrole per proces te implementeren.

• Als jouw openbare Odoo-server zich achter een webapplicatie-firewall, een load-balancer, een transparante DDoS-beschermingsdienst (zoals CloudFlare) of een soortgelijk apparaat op netwerkniveau bevindt, wilt je mogelijk directe toegang tot het Odoo-systeem vermijden. Het is over het algemeen moeilijk om de eindpunt-IP-adressen van jouw Odoo-servers geheim te houden. Ze kunnen bijvoorbeeld verschijnen in webserverlogboeken bij het bevragen van openbare systemen, of in de headers van e-mails die vanuit Odoo worden gepost. In een dergelijke situatie wilt je wellicht jouw firewall zo configureren dat de eindpunten niet openbaar toegankelijk zijn, behalve vanaf de specifieke IP-adressen van jouw WAF, load-balancer of proxyservice. Serviceproviders zoals CloudFlare houden voor dit doel meestal een openbare lijst bij van hun IP-adresbereiken.

• Als je meerdere klanten host, isoleer dan klantgegevens en bestanden van elkaar met behulp van containers of geschikte ‘gevangenistechnieken’.

• Maak dagelijkse back-ups van jouw databases en filestore-gegevens en kopieer deze naar een externe archiveringsserver die niet toegankelijk is vanaf de server zelf.

• Het implementeren van Odoo op Linux wordt sterk aanbevolen boven Windows. Mocht je er toch voor kiezen om op een Windows-platform te implementeren, dan moet een grondige beoordeling van de beveiliging van de server worden uitgevoerd. Dit valt buiten het bestek van deze handleiding.

Brute Force-aanvallen blokkeren¶

Voor internetgerichte implementaties zijn brute force-aanvallen op gebruikerswachtwoorden heel gebruikelijk, en deze bedreiging mag niet worden verwaarloosd voor Odoo-servers. Odoo verzendt een loginvoer telkens wanneer een inlogpoging wordt uitgevoerd en rapporteert het resultaat: succes of mislukking, samen met de doellogin en het bron-IP.

De logboekvermeldingen hebben de volgende vorm.

Mislukt inloggen:

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

Succesvolle log in:

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

Deze logs kunnen eenvoudig worden geanalyseerd door een inbraakpreventiesysteem zoals fail2ban.

De volgende fail2ban-filterdefinitie moet bijvoorbeeld overeenkomen met een mislukte aanmelding:

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

Dit kan worden gebruikt met een jaildefinitie om het aanvallende IP-adres op HTTP(S) te blokkeren.

Hier ziet je hoe het eruit zou kunnen zien als het IP-adres gedurende 15 minuten wordt geblokkeerd wanneer binnen 1 minuut 10 mislukte inlogpogingen vanaf hetzelfde IP-adres worden gedetecteerd:

[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

Databasebeheer Beveiliging¶

Odoo configureren vermeldde terloops admin_passwd.

Deze instelling wordt gebruikt op alle databasebeheerschermen (om databases aan te maken, te verwijderen, te dumpen of te herstellen).

Als de beheerschermen helemaal niet toegankelijk moeten zijn, moet je de configuratieoptie list_db instellen op False, om de toegang tot alle databaseselectie- en beheerschermen te blokkeren.

Zorg ervoor dat je een geschikte db_name parameter instelt (en optioneel ook dbfilter) zodat het systeem de doeldatabase voor elk verzoek kan bepalen, anders worden gebruikers geblokkeerd omdat ze niet mogen kiezen de databank zelf.

Als de beheerschermen alleen toegankelijk moeten zijn vanaf een geselecteerde set machines, gebruik dan de functies van de proxyserver om de toegang te blokkeren tot alle routes die beginnen met /web/database behalve (misschien) /web/database/selector waardoor het databaseselectiescherm wordt weergegeven.

Als het databasebeheerscherm toegankelijk moet blijven, moet de admin_passwd instelling worden gewijzigd van de admin standaard: dit wachtwoord wordt gecontroleerd voordat bewerkingen voor databasewijzigingen worden toegestaan.

Het moet veilig worden opgeslagen en willekeurig worden gegenereerd, b.v.

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

Ondersteunde browsers¶

Odoo ondersteunt alle grote desktop- en mobiele browsers die op de markt beschikbaar zijn, zolang ze ondersteund worden door hun uitgevers.

Dit zijn de ondersteunde browsers:

• Google Chrome

• Mozilla Firefox

• Microsoft Edge

• Apple Safari

1

om meerdere Odoo-installaties dezelfde PostgreSQL-database te laten gebruiken, of om meer computerbronnen aan beide software te leveren.

2

technisch gezien kan een tool als socat worden gebruikt om UNIX-sockets in netwerken te proxyen, maar dat is meestal voor software die alleen via UNIX-sockets kan worden gebruikt

3

of alleen toegankelijk zijn via een intern pakketgeschakeld netwerk, maar dat vereist beveiligde schakelaars, bescherming tegen ‘ARP-spoofing’ en sluit het gebruik van WiFi uit. Zelfs via beveiligde pakketgeschakelde netwerken wordt implementatie via HTTPS aanbevolen, en worden de mogelijke kosten verlaagd omdat ‘zelfondertekende’ certificaten gemakkelijker in een gecontroleerde omgeving kunnen worden geïmplementeerd dan via internet.