Systemkonfiguration¶

This document describes basic steps to set up Odoo in production or on an internet-facing server. It follows installation, and is not generally necessary for a development systems that is not exposed on the internet.

Warnung

Wenn Sie einen öffentlichen Server einrichten, sollten Sie unbedingt unsere Empfehlungen zur Sicherheit beachten!

dbfilter¶

Odoo ist ein System mit mehreren Mandaten: Ein einziges Odoo-System kann eine Reihe von Datenbankinstanzen betreiben und bedienen. Es ist außerdem in hohem Maße anpassbar, wobei die Anpassungen (angefangen bei den geladenen Modulen) von der „aktuellen Datenbank“ abhängen.

Dies ist kein Problem, wenn Sie als angemeldeter Benutzer des Unternehmens mit dem Backend (Web-Client) arbeiten: Die Datenbank kann bei der Anmeldung ausgewählt und die Anpassungen anschließend geladen werden.

Es ist jedoch ein Problem für nicht angemeldete Benutzer (Portal, Website), die nicht an eine Datenbank gebunden sind: Odoo muss wissen, welche Datenbank verwendet werden soll, um die Website-Seite zu laden oder den Vorgang durchzuführen. Wenn keine Mandantenfähigkeit verwendet wird, ist dies kein Problem, da nur eine Datenbank verwendet werden muss. Wenn jedoch mehrere Datenbanken verfügbar sind, benötigt Odoo eine Regel, um zu wissen, welche Datenbank verwendet werden soll.

Das ist einer der Zwecke von --db-filter: Sie legt fest, wie die Datenbank auf der Grundlage des angeforderten Hostnamens (Domain) ausgewählt werden soll. Der Wert ist ein regulärer Ausdruck, der möglicherweise den dynamisch eingespeisten Hostnamen (%h) oder die erste Subdomain (%d) enthält, über die auf das System zugegriffen wird.

Bei Servern, die mehrere Datenbanken in der Produktion hosten, insbesondere wenn Website verwendet wird, muss dbfilter gesetzt sein, da sonst eine Reihe von Funktionen nicht korrekt funktionieren.

Konfigurationsbeispiel¶

Zeigen Sie nur Datenbanken an, deren Name mit „mycompany“ beginnt

in der eingestellten Konfigurationsdatei:

[options]
dbfilter = ^mycompany.*$

Zeigen Sie nur Datenbanken an, die der ersten Subdomain nach www entsprechen: zum Beispiel wird die Datenbank „mycompany“ angezeigt, wenn die eingehende Anfrage an www.mycompany.com oder mycompany.co.uk gesendet wurde, aber nicht für www2.mycompany.com oder helpdesk.mycompany.com.

in der eingestellten Konfigurationsdatei:

[options]
dbfilter = ^%d$

Bemerkung

Die Einstellung eines geeigneten --db-filter ist ein wichtiger Teil zur Gewährleistung Ihrer Implementierung. Sobald es korrekt funktioniert und nur eine einzige Datenbank pro Hostname abgleicht, wird dringend empfohlen, den Zugriff auf die Bildschirme des Datenbankmanagers zu blockieren und den Startparameter --no-database-list zu verwenden, um die Auflistung Ihrer Datenbanken zu verhindern und den Zugriff auf die Bildschirme der Datenbankverwaltung zu blockieren. Siehe auch Sicherheit.

PostgreSQL¶

Standardmäßig erlaubt PostgreSQL nur Verbindungen über UNIX-Sockets und Loopback-Verbindungen (von „localhost“, demselben Rechner, auf dem der PostgreSQL-Server installiert ist).

UNIX-Socket ist in Ordnung, wenn Sie möchten, dass Odoo und PostgreSQL auf demselben Rechner ausgeführt werden, und ist die Standardeinstellung, wenn kein Host angegeben wird. Wenn Sie jedoch möchten, dass Odoo und PostgreSQL auf verschiedenen Rechnern 1 ausgeführt werden, muss es auch auf Netzwerkschnittstellen 2 hören:

Akzeptieren Sie nur Loopback-Verbindungen und verwenden Sie einen SSH-Tunnel zwischen dem Rechner, auf dem Odoo läuft, und dem Rechner, auf dem PostgreSQL läuft, und konfigurieren Sie Odoo so, dass es sich mit seinem Ende des Tunnels verbindet
Akzeptieren Sie Verbindungen zu dem Rechner, auf dem Odoo installiert ist, möglicherweise über SSL (siehe PostgreSQL-Verbindungseinstellungen für Details), und konfigurieren Sie dann Odoo für die Verbindung über das Netzwerk

Konfigurationsbeispiel¶

tcp-Verbindung auf localhost erlauben
tcp-Verbindung aus 192.168.1.x-Netzwerk erlauben

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

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

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

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

Odoo konfigurieren¶

Odoo stellt standardmäßig eine Verbindung zu einem lokalen Postgres über einen UNIX-Socket über Port 5432 her. Dies kann mit den Datenbankoptionen überschrieben werden, wenn Ihre Postgres-Implementierung nicht lokal ist und/oder nicht die Installationsvorgaben verwendet.

Die Installationsprogramme erstellen automatisch einen neuen Benutzer (odoo) und legen ihn als Datenbankbenutzer fest.

Die Bildschirme der Datenbankverwaltung sind durch die Einstellung admin_passwd geschützt. Diese Einstellung kann nur mit Hilfe von Konfigurationsdateien festgelegt werden und wird einfach überprüft, bevor Änderungen an der Datenbank vorgenommen werden. Sie sollte auf einen zufällig generierten Wert gesetzt werden, um sicherzustellen, dass Dritte diese Schnittstelle nicht nutzen können.
Alle Datenbankvorgänge verwenden die Datenbankoptionen, auch der Datenbankverwaltungsbildschirm. Damit der Datenbankverwaltungsbildschirm funktioniert, muss der PostgreSQL-Benutzer das Recht createdb haben.
Benutzer können Datenbanken, die ihnen gehören, jederzeit löschen. Damit der Datenbankverwaltungsbildschirm nicht mehr funktioniert, muss der PostgreSQL-Benutzer mit no-createdb angelegt werden und die Datenbank muss einem anderen PostgreSQL-Benutzer gehören.

Warnung
Der PostgreSQL-Benutzer darf kein Superuser sein.

Konfigurationsbeispiel¶

Mit einem PostgreSQL-Server auf 192.168.1.2 verbinden
Port 5432
Mithilfe eines „Odoo“-Benutzerkontos
Mit „pwd“ als Passwort
Filterung nur von Datenbanken, deren Name mit „mycompany“ beginnt

in der eingestellten Konfigurationsdatei:

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

SSL zwischen Odoo und PostgreSQL¶

Seit Odoo 11.0 können Sie SSL-Verbindungen zwischen Odoo und PostgreSQL erzwingen. In Odoo steuert der db_sslmode die SSL-Sicherheit der Verbindung mit einem Wert, der aus „disable“, „allow“, „prefer“, „require“, „verify-ca“ oder „verify-full“ ausgewählt werden kann.

PostgreSQL-Dokumentation

Builtin-Server¶

Odoo enthält integrierte HTTP-Server, die entweder Multithreading oder Multiprocessing verwenden.

Der Multithreading-Server ist ein einfacherer Server, der hauptsächlich für die Entwicklung, für Demonstrationen und für seine Kompatibilität mit verschiedenen Betriebssystemen (einschließlich Windows) verwendet wird. Für jede neue HTTP-Anfrage wird ein neuer Thread gestartet, auch für langlebige Verbindungen wie Websockets. Es werden auch zusätzliche daemonische Cron-Threads erzeugt. Aufgrund einer Python-Beschränkung (GIL) nutzt er die Hardware nicht optimal aus.

Der Multithreading-Server ist der Standardserver, auch für Docker-Container. Er wird ausgewählt, indem Sie die Option --workers weglassen oder auf 0 setzen.

Der Multiprocessing-Server ist ein vollwertiger Server, der hauptsächlich für die Produktion verwendet wird. Er unterliegt nicht der gleichen Python-Beschränkung (GIL) für die Ressourcennutzung und nutzt daher die Hardware optimal aus. Beim Starten des Servers wird ein Pool von Workern erstellt. Neue HTTP-Anfragen werden vom Betriebssystem in eine Warteschlange gestellt, bis die Worker bereit sind, sie zu verarbeiten. Ein zusätzlicher ereignisgesteuerter HTTP-Worker für den Livechat wird auf einem anderen Port gestartet. Es werden auch zusätzliche Cron-Worker erzeugt. Ein konfigurierbarer Process Reaper überwacht die Ressourcennutzung und kann fehlgeschlagene Worker beenden/neustarten.

Der Multiprocessing-Server ist optional. Er wird ausgewählt, indem Sie die Option --workers auf eine Ganzzahl, die nicht Null ist, einstellen.

Bemerkung

Da er stark an Linux-Server angepasst ist, ist der Multiprocessing-Server nicht unter Windows verfügbar.

Berechnung der Worker-Anzahl¶

Faustregel: (#CPU * 2) + 1
Cron-Worker benötigen CPU
1 worker ~= 6 gleichzeitige Benutzer

Berechnung der Speicherplatzgröße¶

Wir gehen davon aus, dass 20 % der Anfragen umfangreiche Anfragen sind, während 80 % einfachere Anfragen sind.
Ein schwerer Worker, bei dem alle berechneten Felder gut gestaltet sind, SQL-Anfragen gut gestaltet sind, … verbraucht schätzungsweise etwa 1 GB RAM
Ein leichterer Worker verbraucht in demselben Szenario schätzungsweise 150 MB RAM.

Benötigter RAM = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

Livechat¶

Beim Multiprocessing wird automatisch ein spezieller Livechat-Worker gestartet, der auf --gevent-port hört. Standardmäßig greifen die HTTP-Anfragen weiterhin auf die normalen HTTP-Worker zu und nicht auf den Livechat-Worker. Sie müssen einen Proxy vor Odoo einsetzen und eingehende Anfragen, deren Pfad mit /websocket/ beginnt, an den Livechat-Worker umleiten. Außerdem müssen Sie Odoo mit --proxy-mode starten, damit es die echten Client-Header (wie Hostname, Schema und IP) anstelle der Proxy-Header verwendet.

Konfigurationsbeispiel¶

Server mit 4 CPU, 8 Thread
60 gleichzeitige Benutzer
60 Benutzer / 6 = 10 <- Theoretisch benötigte Anzahl von Workern
(4 * 2) + 1 = 9 <- Theoretische maximale Anzahl von Workern
Wir werden 8 Worker + 1 für Cron verwenden. Wir werden auch ein Überwachungssystem verwenden, um die CPU-Auslastung zu messen und zu prüfen, ob sie zwischen 7 und 7,5 liegt.
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3Go RAM für Odoo

in der Konfigurationsdatei:

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

Unabhängig davon, ob der Zugriff über eine Website/Webclient oder einen Webservice erfolgt, überträgt Odoo die Authentifizierungsinformationen im Klartext. Das bedeutet, dass eine sichere Bereitstellung von Odoo HTTPS verwenden muss. Die SSL-Terminierung kann über jeden beliebigen SSL-Terminierungs-Proxy implementiert werden, erfordert jedoch die folgende Einrichtung:

Odoos Proxy-Modus aktivieren. Diese Option sollte nur aktiviert werden, wenn sich Odoo hinter einem Reverse-Proxy befindet.
Den SSL-Terminierungs-Proxy einrichten (Nginx-Terminierungsbeispiel)
Das Proxying selbst einrichten (Nginx-Proxying-Beispiel)
Ihr SSL-Terminierungsproxy sollte außerdem nicht sichere Verbindungen automatisch auf den sicheren Port umleiten

Konfigurationsbeispiel¶

http-Anfragen auf https umleiten
Proxy-Anfragen an Odoo

in der eingestellten Konfigurationsdatei:

proxy_mode = True

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

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

Add the Strict-Transport-Security header to all requests, in order to prevent browsers from ever sending a plain HTTP request to this domain. You will need to maintain a working HTTPS service with a valid certificate on this domain at all times, otherwise your users will see security alerts or be entirely unable to access it.

Force HTTPS connections during a year for every visitor in NGINX with the line:

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

Für den Cookie session_id können zusätzliche Konfigurationen definiert werden. Die Kennzeichnung Secure (Sicher) kann hinzugefügt werden, um sicherzustellen, dass es niemals über HTTP übertragen wird und SameSite=Lax, um authentifizierte CSRF zu verhindern.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Odoo als WSGI-Anwendung¶

Es ist auch möglich, Odoo als Standard-WSGI_application zu mounten. Odoo liefert die Basis für ein WSGI-Startskript wie odoo-wsgi.example.py. Dieses Skript sollte angepasst werden (möglicherweise nachdem Sie es aus dem Einstellungsverzeichnis kopiert haben), um die Konfiguration direkt in odoo.tools.config korrekt einzustellen und nicht über die Befehlszeile oder eine Konfigurationsdatei.

Der WSGI-Server stellt jedoch nur den Haupt-HTTP-Endpunkt für den Web-Client, die Website und die Webservice-API zur Verfügung. Da Odoo die Erstellung von Workern nicht mehr kontrolliert, kann es keine Cron- oder Livechat-Worker einrichten.

Cron-Worker¶

Um Cron-Jobs zu verarbeiten, müssen Sie einen der integrierten Odoo-Server neben dem WSGI-Server starten. Dieser Server muss so konfiguriert sein, dass er nur Cron-Jobs und keine HTTP-Anfragen verarbeitet. Verwenden Sie dazu die Befehlszeilenoption --no-http oder die Einstellung http_enable = False in der Konfigurationsdatei.

Auf Linux-ähnlichen Systemen wird empfohlen, den Multipocessing-Server dem Multithreading-Server vorzuziehen, um von einer besseren Hardware-Auslastung und höherer Stabilität zu profitieren, d. h. die Optionen --workers=-1 und --max-cron-threads=n zu verwenden.

Livechat¶

Die Verwendung eines gevent-kompatiblen WSGI-Servers ist für den korrekten Betrieb der Livechat-Funktion erforderlich. Dieser Server sollte in der Lage sein, viele gleichzeitige, langlebige Verbindungen zu verarbeiten, muss aber nicht viel Rechenleistung haben. Alle Anfragen, deren Pfad mit /websocket/ beginnt, sollten an diesen Server gerichtet werden. Für alle anderen Anfragen sollte ein normaler (thread- oder prozessbasierter) WSGI-Server verwendet werden.

Der Cron-Server von Odoo kann auch dazu verwendet werden, die Livechat-Anfragen zu bedienen. Lassen Sie einfach die Option --no-http im Cron-Server weg und stellen Sie sicher, dass Anfragen, deren Pfad mit /websocket/ beginnt, an diesen Server geleitet werden, entweder über --http-port (Multithreading-Server) oder über --gevent-port (Multiprocessing-Server).

Statische Dateien und Anhänge bereitstellen¶

Um die Entwicklung zu erleichtern, stellt Odoo alle statischen Dateien und Anhänge direkt in seinen Modulen bereit. Dies ist nicht ideal, wenn es um die Leistung geht, und statische Dateien sollten im Allgemeinen von einem statischen HTTP-Server bereitgestellt werden.

Statische Dateien bereitstellen¶

Die statischen Dateien von Odoo befinden sich im Ordner static/ des jeweiligen Moduls. Daher können statische Dateien bereitgestellt werden, indem alle Anfragen an /MODULE/static/FILE abgefangen werden und das richtige Modul (und die richtige Datei) in den verschiedenen Add-ons-Pfaden gesucht wird.

It is recommended to set the Content-Security-Policy: default-src 'none' header on all images delivered by the web server. It is not strictly necessary as users cannot modify/inject content inside of modules‘ static/ folder and existing images are final (they do not fetch new resources by themselves). However, it is good practice.

Using the above NGINX (https) configuration, the following map and location blocks should be added to serve static files 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;
    }
}

The actual root and try_files directives are dependant on your installation, specifically on your --addons-path.

Example

Say Odoo has been installed via the debian packages for Community and Enterprise, and that the --addons-path is '/usr/lib/python3/dist-packages/odoo/addons'.

The root and try_files should be:

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

Say Odoo has been installed via the sources, that both the Community and Enterprise git repositories were cloned in /opt/odoo/community and /opt/odoo/enterprise respectively, and that the --addons-path is '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

The root and try_files should be:

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

Anhänge bereitstellen¶

Anhänge sind im Dateispeicher gespeicherte Dateien, deren Zugriff von Odoo geregelt wird. Sie können nicht direkt über einen statischen Webserver aufgerufen werden, da der Zugriff auf sie mehrere Abfragen in der Datenbank erfordert, um festzustellen, wo die Dateien gespeichert sind und ob der aktuelle Benutzer darauf zugreifen kann oder nicht.

Sobald die Datei jedoch gefunden und die Zugriffsrechte von Odoo überprüft wurden, ist es eine gute Idee, die Datei über den statischen Webserver und nicht über Odoo bereitzustellen. Damit Odoo die Bereitstellung von Dateien an den statischen Webserver delegieren kann, müssen die Erweiterungen X-Sendfile (apache) oder X-Accel (nginx) auf dem statischen Webserver aktiviert und konfiguriert sein. Sobald dies geschehen ist, starten Sie Odoo mit der Befehlszeilenkennzeichnung --x-sendfile (diese eindeutige Kennzeichnung wird sowohl für X-Sendfile als auch für X-Accel verwendet).

Bemerkung

Die X-Sendfile-Erweiterung für Apache (und kompatible Webserver) erfordert keine zusätzliche Konfiguration.
Die X-Accel-Erweiterung für NGINX erfordert die folgende zusätzliche Konfiguration:
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}
```
Für den Fall, dass Sie den Pfad zu Ihrem Dateispeicher nicht kennen, starten Sie Odoo mit der Option --x-sendfile und rufen Sie die URL /web/filestore direkt über Odoo auf (rufen Sie die URL nicht über NGINX auf). Dadurch wird eine Warnung protokolliert. Die Meldung enthält die erforderliche Konfiguration.

Sicherheit¶

Bedenken Sie zunächst, dass die Sicherung eines Informationssystems ein kontinuierlicher Prozess ist und keine einmalige Aktion. Sie sind immer nur so sicher wie das schwächste Glied in Ihrer Umgebung.

Verstehen Sie diesen Abschnitt also bitte nicht als die ultimative Liste von Maßnahmen, die alle Sicherheitsprobleme verhindern werden. Er ist lediglich als Zusammenfassung der ersten wichtigen Dinge gedacht, die Sie unbedingt in Ihren Sicherheitsaktionsplan aufnehmen sollten. Der Rest ergibt sich aus den besten Sicherheitspraktiken für Ihr Betriebssystem und Ihre Distribution, den besten Praktiken in Bezug auf Benutzer, Passwörter und die Verwaltung der Zugriffskontrolle usw.

Wenn Sie einen Server mit Internetanschluss einrichten, sollten Sie die folgenden sicherheitsrelevanten Themen berücksichtigen:

Legen Sie immer ein sicheres Superadmin-Passwort fest und beschränken Sie den Zugriff auf die Seiten der Datenbankverwaltung, sobald das System eingerichtet ist. Siehe Sicherheit des Datenbankmanager.
Wählen Sie eindeutige Anmeldedaten und sichere Passwörter für alle Administratorkonten in allen Datenbanken. Verwenden Sie nicht „admin“ als Login. Verwenden Sie diese Logins nicht für den alltäglichen Betrieb, sondern nur für die Kontrolle/Verwaltung der Installation. Verwenden Sie nie irgendwelche Standardpasswörter wie admin/admin, auch nicht für Test-/Staging-Datenbanken.
Installieren Sie keine Demodaten auf Servern, die mit dem Internet verbunden sind. Datenbanken mit Demodaten enthalten Standardanmeldungen und Passwörter, die dazu verwendet werden können, in Ihre Systeme einzudringen und erhebliche Probleme zu verursachen, selbst auf Staging-/Entwicklungssystemen.
Verwenden Sie geeignete Datenbankfilter ( --db-filter), um die Sichtbarkeit Ihrer Datenbanken entsprechend dem Hostnamen einzuschränken. Siehe dbfilter. Sie können auch -d verwenden, um eine eigene (durch Komma getrennte) Liste der verfügbaren Datenbanken zu erstellen, aus der Sie filtern können, anstatt das System alle Datenbanken aus dem Datenbank-Backend abrufen zu lassen.
Sobald Sie db_name und db_filter so konfiguriert haben, dass nur eine einzige Datenbank pro Hostname in Frage kommt, sollten Sie die Konfigurationsoption list_db auf False setzen, um die Auflistung der Datenbanken vollständig zu verhindern und den Zugriff auf die Datenbankverwaltungsbildschirme zu blockieren (dies ist auch als Befehlszeilenoption --no-database-list sichtbar)
Stellen Sie sicher, dass der PostgreSQL-Benutzer (--db_user) kein Superuser ist und dass Ihre Datenbanken einem anderen Benutzer gehören. Sie könnten zum Beispiel dem Superuser postgres gehören, wenn Sie einen dedizierten, nicht privilegierten db_user verwenden. Siehe auch Odoo konfigurieren.
Halten Sie Ihre Installationen auf dem neuesten Stand, indem Sie regelmäßig die neuesten Builds installieren, entweder über GitHub oder indem Sie die neueste Version von https://www.odoo.com/page/download oder http://nightly.odoo.com herunterladen.
Konfigurieren Sie Ihren Server im Multiprocessing-Modus mit den richtigen Grenzen für Ihre typische Nutzung (Speicher/CPU/Zeitüberschreitungen). Siehe auch Builtin-Server.
Führen Sie Odoo hinter einem Webserver mit HTTPS-Terminierung und einem gültigen SSL-Zertifikat aus, um das Abhören der Klartextkommunikation zu verhindern. SSL-Zertifikate sind billig, und es gibt viele kostenlose Optionen. Konfigurieren Sie den Web-Proxy, um die Größe der Anfragen zu begrenzen, setzen Sie geeignete Zeitüberschreitungen und aktivieren Sie dann die Option proxy mode. Siehe auch HTTPS.
Wenn Sie den SSH-Fernzugriff auf Ihre Server zulassen müssen, stellen Sie sicher, dass Sie ein sicheres Passwort für alle Konten festlegen, nicht nur für root. Es wird dringend empfohlen, die passwortbasierte Authentifizierung vollständig zu deaktivieren und nur die Authentifizierung mit öffentlichen Schlüsseln zuzulassen. Ziehen Sie außerdem in Erwägung, den Zugriff über ein VPN zu beschränken, nur vertrauenswürdige IPs in der Firewall zuzulassen und/oder ein Brute-Force-Erkennungssystem wie fail2ban oder ein vergleichbares System einzusetzen.
Erwägen Sie die Installation einer geeigneten Ratenbegrenzung auf Ihrem Proxy oder Ihrer Firewall, um Brute-Force-Angriffe und Denial-of-Service-Angriffe zu verhindern. Siehe auch Brute-Force-Angriffe blockieren für spezifische Maßnahmen.

Viele Netzwerkanbieter bieten eine automatische Entschärfung von DDOS-Angriffen (Distributed Denial of Service) an, aber dies ist oft ein optionaler Service, so dass Sie sich mit ihnen in Verbindung setzen sollten.
Wann immer möglich, sollten Sie Ihre öffentlich zugänglichen Demo-/Test-/Staging-Instanzen auf anderen Rechnern als die Produktionsinstanzen hosten. Und wenden Sie die gleichen Sicherheitsvorkehrungen an wie bei der Produktion.
Wenn Ihr öffentlicher Odoo-Server Zugang zu sensiblen internen Netzwerkressourcen oder -diensten hat (z. B. über ein privates VLAN), implementieren Sie geeignete Firewall-Regeln zum Schutz dieser internen Ressourcen. Auf diese Weise wird sichergestellt, dass der Odoo-Server nicht versehentlich (oder als Folge böswilliger Benutzeraktionen) für den Zugriff auf diese internen Ressourcen oder deren Störung verwendet werden kann. In der Regel kann dies durch die Anwendung einer Standard-DENY-Regel für ausgehende Verbindungen auf der Firewall erreicht werden, wobei der Zugriff auf interne Ressourcen, auf die der Odoo-Server zugreifen muss, explizit zugelassen wird. Die Systemd IP Traffic Access Control <http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html> kann auch nützlich sein, um eine prozessspezifische Netzwerkzugangskontrolle zu implementieren.
Wenn sich Ihr öffentlicher Odoo-Server hinter einer Web Application Firewall, einem Load-Balancer, einem transparenten DDoS-Schutzdienst (wie CloudFlare) oder einem ähnlichen Gerät auf Netzwerkebene befindet, möchten Sie vielleicht den direkten Zugriff auf das Odoo-System vermeiden. Es ist im Allgemeinen schwierig, die IP-Adressen der Endpunkte Ihrer Odoo-Server geheim zu halten. Sie können zum Beispiel in Webserver-Protokollen auftauchen, wenn öffentliche Systeme abgefragt werden, oder in den Kopfzeilen von E-Mails, die von Odoo aus verschickt werden. In einer solchen Situation sollten Sie Ihre Firewall so konfigurieren, dass die Endpunkte nicht öffentlich zugänglich sind, außer von den spezifischen IP-Adressen Ihres WAF-, Load-Balancer- oder Proxy-Dienstes. Dienstanbieter wie CloudFlare führen zu diesem Zweck normalerweise eine öffentliche Liste ihrer IP-Adressbereiche.
Wenn Sie mehrere Kunden hosten, trennen Sie die Kundendaten und -dateien von einander, indem Sie Container oder angemessene „Gefängnis“-Techniken verwenden.
Erstellen Sie tägliche Back-ups Ihrer Datenbanken und Dateispeicherdaten und kopieren Sie diese auf einen entfernten Archivierungsserver, der vom Server selbst nicht zugänglich ist.
Es wird dringend empfohlen, Odoo auf Linux statt auf Windows zu installieren. Sollten Sie sich dennoch für eine Bereitstellung auf einer Windows-Plattform entscheiden, sollte eine gründliche Sicherheitsüberprüfung des Servers durchgeführt werden, die nicht in den Rahmen dieses Leitfadens fällt.

Brute-Force-Angriffe blockieren¶

Bei Implementierungen mit Internetanschluss sind Brute-Force-Angriffe auf Benutzerpasswörter sehr häufig, und diese Bedrohung sollte bei Odoo-Servern nicht vernachlässigt werden. Odoo gibt bei jedem Anmeldeversuch einen Protokolleintrag aus und meldet das Ergebnis: Erfolg oder Misserfolg, zusammen mit der Zielanmeldung und der Quell-IP.

Die Protokolleinträge haben folgendes Format.

Fehlgeschlagener Login:

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

Erfolgreicher Login:

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

Diese Protokolle können leicht von einem Intrusion Prevention System wie fail2ban analysiert werden.

Die folgende fail2ban-Filterdefinition sollte zum Beispiel zu einem fehlgeschlagenen :Login passen:

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

Dies könnte mit einer „Gefängnis“-Definition verwendet werden, um die angreifende IP auf HTTP(S) zu blockieren.

So könnte es aussehen, wenn die IP für 15 Minuten blockiert wird, wenn innerhalb von 1 Minute 10 fehlgeschlagene Anmeldeversuche von derselben IP festgestellt werden:

[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

Sicherheit des Datenbankmanager¶

In Odoo konfigurieren wird admin_passwd beiläufig erwähnt.

Diese Einstellung wird auf allen Datenbankverwaltungsbildschirmen verwendet (zum Erstellen, Löschen, Dumpen oder Wiederherstellen von Datenbanken).

Wenn die Verwaltungsbildschirme überhaupt nicht zugänglich sein sollen, sollten Sie die Konfigurationsoption list_db auf False setzen, um den Zugriff auf alle Datenbankauswahl- und Verwaltungsbildschirme zu blockieren.

Warnung

Es wird dringend empfohlen, den Datenbankmanager für jedes System mit Internetanschluss zu deaktivieren! Er ist als Entwicklungs-/Demo-Tool gedacht, um das schnelle Erstellen und Verwalten von Datenbanken zu erleichtern. Er ist nicht für den Einsatz in der Produktion gedacht und kann sogar gefährliche Funktionen für Angreifer bereitstellen. Er ist auch nicht für die Verwaltung großer Datenbanken ausgelegt und kann zu Speicherbeschränkungen führen.

Auf Produktionssystemen sollten Datenbankverwaltungsvorgänge immer vom Systemadministrator durchgeführt werden, einschließlich der Bereitstellung neuer Datenbanken und automatischer Back-ups.

Stellen Sie sicher, dass Sie einen angemessenen db_name-Parameter (und optional db_filter) einstellen, damit das System die Zieldatenbank für jede Anfrage festlegen kann. Andernfalls werden die Benutzer blockiert, da sie die Datenbank nicht selbst auswählen können.

Wenn die Verwaltungsbildschirme nur von bestimmten Rechnern aus zugänglich sein sollen, verwenden Sie die Funktionen des Proxy-Servers, um den Zugriff auf alle Routen zu blockieren, die mit /web/database beginnen, mit Ausnahme von (vielleicht) /web/database/selector, das den Datenbank-Auswahlbildschirm anzeigt.

Wenn der Datenbankverwaltungsbildschirm zugänglich bleiben soll, muss die Einstellung admin_passwd vom admin-Standard geändert werden: Dieses Passwort wird überprüft, bevor Datenbank-Änderungsoperationen zugelassen werden.

Es sollte sicher gespeichert werden und zufällig generiert werden, wie z. B.

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

was eine 32-stellige pseudozufällige druckbare Zeichenkette erzeugt.

Unterstützte Browser¶

Odoo unterstützt alle wichtigen Desktop- und Handy-Browser, die auf dem Markt erhältlich sind, sofern sie von ihren Herausgebern unterstützt werden.

Das sind die unterstützten Browser:

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

Warnung

Bitte vergewissern Sie sich, dass Ihr Browser auf dem neuesten Stand ist und noch von seinem Herausgeber unterstützt wird, bevor Sie einen Fehlerbericht einreichen.

Bemerkung

Seit Odoo 13.0 wird ES6 unterstützt. Daher entfällt die IE-Unterstützung.

1: Um mehrere Odoo-Installationen auf dieselbe PostgreSQL-Datenbank zugreifen zu lassen, oder um beiden Programmen mehr Rechenressourcen zur Verfügung zu stellen.
2: Technisch gesehen kann ein Tool wie socat verwendet werden, um UNIX-Sockets über Netzwerke zu projizieren, aber das ist hauptsächlich für Software, die nur über UNIX-Sockets verwendet werden kann
3: oder nur über ein internes paketvermitteltes Netz zugänglich sein, was jedoch gesicherte Switches und Schutzmaßnahmen gegen ARP spoofing erfordert und die Verwendung von WiFi ausschließt. Selbst über sichere paketvermittelte Netzwerke wird der Einsatz über HTTPS empfohlen, und mögliche Kosten werden gesenkt, da „selbstsignierte“ Zertifikate in einer kontrollierten Umgebung einfacher einzusetzen sind als über das Internet.

Edit on GitHub