Odoo-Server absichern: Firewall, Ports, Zugriffe

Was Sie vorab brauchen

Diese Schritte gelten für eine eigene Odoo-Installation auf einem Linux-Server, der aus dem Internet erreichbar ist (Odoo 20.0, Stand 14. Oktober 2026). Bei Odoo Online, Odoo.sh und Odoo Cloud verwaltet Odoo diese Ebene. Sie brauchen:

• Root- oder sudo-Zugang, die Firewall des Servers und die Regeln der Netz-Firewall oder des Routers davor.
• Einen Reverse Proxy mit gültigem Zertifikat, siehe Eigene Domain und SSL-Zertifikat.
• Die Odoo-Konfigurationsdatei, die Ihre Installation verwendet: Das Community-Paket legt sie unter /etc/odoo/odoo.conf ab und der Dienst startet Odoo mit --config /etc/odoo/odoo.conf (odoo/odoo, Branch 20.0, debian/install und debian/odoo.service); die Administration-Dokumentation nennt für die Paketinstallation abweichend /etc/odoo.conf. Bei einer Quellinstallation gilt die Datei, die --config oder die Umgebungsvariable ODOO_RC nennt; ohne beides sucht Odoo $HOME/.odoorc, /home/$USER/.config/odoo/odoo.conf und einen XDG-Pfad (CLI-Referenz 20.0). Nehmen Sie den Pfad aus dem Startbefehl, mit dem Odoo auf Ihrem Server läuft.
• Zugang zu postgresql.conf und pg_hba.conf sowie eine frische Sicherung, siehe Odoo sichern.
• Etwa eine Stunde ohne laufenden Betrieb: Änderungen an Proxy und Odoo verlangen einen Neustart.

Welche Ports offen bleiben dürfen

Odoo gehört hinter einen Reverse Proxy, der TLS beendet. Das Nginx-Beispiel der Dokumentation leitet auf 127.0.0.1:8069 und 127.0.0.1:8072 weiter; das sind Upstream-Ziele, keine Bindung des Odoo-Listeners: Ohne eigene Einstellung lauscht Odoo auf allen Adressen (0.0.0.0). Binden Sie Odoo deshalb ausdrücklich an die lokale Adresse — die CLI-Option --http-interface beziehungsweise der Eintrag http_interface = 127.0.0.1 in der Konfigurationsdatei (CLI-Referenz 20.0). PostgreSQL hört als Vorgabe nur auf localhost an Port 5432 (PostgreSQL-Dokumentation, Connection Settings).

Port	Dienst	Wer darf ihn erreichen?
443/TCP	HTTPS; TLS endet im Reverse Proxy	die Kundschaft aus dem Internet
80/TCP	HTTP, im Nginx-Beispiel nur dauerhafte Weiterleitung auf HTTPS	aus dem Internet
8069/TCP	Odoo: Web-Client, Website, Schnittstelle	nur der Reverse Proxy auf demselben Rechner
8072/TCP	Odoo-Websocket: im Multiprozess-Modus lauscht der Livechat-Worker auf diesem Port, im voreingestellten Thread-Modus laufen dieselben Anfragen über 8069	nur der Reverse Proxy auf demselben Rechner
5432/TCP	PostgreSQL	nur Odoo
22/TCP	SSH-Administration	nur Ihr Verwaltungsnetz, wenn möglich über VPN

Verlassen Sie sich nicht allein auf die Bindung: Nach dem IT-Grundschutz muss die gesamte Kommunikation zwischen den beteiligten Netzen über die Firewall laufen, und nur ausdrücklich definierte Verbindungen werden zugelassen (NET.3.2.A2). Das IT-Grundschutz-Kompendium ist kein Gesetz: Es bindet nur, wenn eine Rechtsvorschrift oder ein Vertrag darauf verweist, und dient hier als Maßstab für die technischen Schritte.

Schritt für Schritt: Proxy, Firewall und Zugriffe härten

Schritt 1: Angriffsfläche aufnehmen

Halten Sie fest, welche Dienste auf welchen Ports lauschen, und prüfen Sie von einem Rechner außerhalb Ihres Netzes, was davon aus dem Internet antwortet. Nicht benötigte Serverrollen, Funktionen und Dienste müssen deaktiviert oder deinstalliert werden, vor allem Netzdienste, und alle nicht genutzten Schnittstellen abgeschaltet sein (SYS.1.1.A6, SYS.1.1.A5); die getroffene Auswahl soll dokumentiert sein.

Auf einem reinen Odoo-Server bleiben Webserver, Datenbank und SSH.

Ergebnis: Sie kennen die offenen Ports und die Dienste, die Sie wirklich brauchen.

Schritt 2: TLS im Reverse Proxy beenden

Odoo überträgt Anmeldeinformationen im Klartext; ein Zertifikat ist deshalb Voraussetzung für den Betrieb am Internet (Dokumentation 20.0, Abschnitt HTTPS). Setzen Sie in der Odoo-Konfiguration proxy_mode = True; die Dokumentation verlangt, das nur hinter einem Reverse Proxy zu tun.

Binden Sie Odoo zugleich ausdrücklich an die lokale Adresse: Die Vorgabe des HTTP-Servers ist 0.0.0.0, also alle Adressen (CLI-Referenz 20.0, --http-interface). Im Multiprozess-Modus startet zusätzlich ein eigener Livechat-Worker, der auf dem getrennten Port --gevent-port lauscht (Vorgabe 8072); im voreingestellten Thread-Modus laufen Anfragen an /websocket/ über den HTTP-Port (CLI-Referenz 20.0; Odoo-Dokumentation 20.0, Abschnitt LiveChat). Welche Adresse dieser Worker bindet, nennt die öffentliche Dokumentation nicht; im Community-Serverkern übernimmt der Websocket-Dienst die Listen-Adresse des HTTP-Servers (odoo/service/server.py: GeventServer erbt self.interface von CommonServer, das aus http_interface mit der Vorgabe 0.0.0.0 gebildet wird). Für Enterprise ist das aus öffentlichen Quellen nicht belegt. Prüfen Sie die Bindung deshalb am laufenden System mit ss -ltn: 8069 und, im Multiprozess-Modus, 8072 müssen nur auf 127.0.0.1 lauschen.

Der Proxy trägt Zertifikat und Schlüssel, leitet Port 80 dauerhaft auf HTTPS um und gibt die Angaben der anfragenden Seite weiter. Gekürzter Auszug aus dem Nginx-Beispiel der Dokumentation:

upstream odoo     { server 127.0.0.1:8069; }
upstream odoochat { server 127.0.0.1:8072; }
map $http_upgrade $connection_upgrade { default upgrade; '' close; }
server {
  listen 80;  server_name odoo.beispiel.de;
  rewrite ^(.*) https://$host$1 permanent;
}
server {
  listen 443 ssl;  server_name odoo.beispiel.de;
  ssl_certificate     /etc/ssl/nginx/server.crt;
  ssl_certificate_key /etc/ssl/nginx/server.key;
  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;
  }
  location / {
    proxy_pass http://odoo;
    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;
  }
}

Einstellung	Wirkung
proxy_mode = True (Odoo-Konfiguration)	Odoo nutzt die echten Client-Angaben statt der des Proxys; die Dokumentation verlangt, die Option nur hinter einem Reverse Proxy einzuschalten
proxy_set_header für X-Forwarded-Host, X-Forwarded-For, X-Forwarded-Proto und X-Real-IP	Name, Ursprungsadresse und Schema erreichen Odoo; ohne sie arbeitet Odoo mit den Angaben des Proxys
location /websocket mit proxy_pass auf 8072, den Kopfzeilen Upgrade und Connection sowie denselben X-Forwarded-Kopfzeilen	leitet die Websocket-Anfragen im Multiprozess-Modus an den Livechat-Worker; das offizielle Beispiel setzt die X-Forwarded-Kopfzeilen auch in diesem Block
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains"	HSTS: der Browser ruft die Domain ein Jahr lang nur über HTTPS; der Dienst mit gültigem Zertifikat muss durchgehend stehen
proxy_cookie_flags session_id samesite=lax secure	Sitzungscookie nur über HTTPS und gegen gefälschte Anfragen mit angemeldetem Zugriff (nginx ab 1.19.8)
Timeouts und client_max_body_size	Zeitüberschreitungen setzen; die nginx-Vorgabe für den Anfragekörper ist 1m, darüber antwortet nginx mit der Antwort 413 (nginx-Dokumentation)

Die Dokumentation verlangt, die Größe der Anfragen zu begrenzen, passende Zeitüberschreitungen zu setzen und erst dann den Proxy-Modus einzuschalten. Ein unbeschränkter Wert für client_max_body_size hebt diese Begrenzung wieder auf.

Ergebnis: Odoo ist über Port 443 mit gültigem Zertifikat erreichbar, HTTP-Aufrufe landen auf HTTPS, der Livechat findet seinen Worker, und Odoo lauscht auf 8069 nur auf der lokalen Adresse.

Schritt 3: Firewall-Regeln als Allowlist schreiben

Der IT-Grundschutz verlangt Regeln, die festlegen, welche Verbindungen zugelassen sind; alles andere wird unterbunden, und die Entscheidungen werden dokumentiert (NET.3.2.A2). Für den Odoo-Server heißt das:

• 443 aus dem Internet für alle; 80 nur für die Weiterleitung auf HTTPS.
• 22 nur aus Ihrem Verwaltungsnetz oder über ein VPN, nicht aus dem Internet.
• 8069, 8072 und 5432 gar nicht aus dem Internet.
• Ausgehend Standard-DENY, danach nur die Ziele, die der Server wirklich braucht. Die Odoo-Dokumentation empfiehlt diesen Weg für den Fall, dass der Server Zugang zu internen Netzressourcen hat, damit er nicht als Sprungbrett dorthin dient.

Die Verwaltungszugänge der Firewall selbst gehören auf einzelne Quelladressen und sichere Protokolle begrenzt (NET.3.2.A6); Dienste, die aus dem Internet erreichbar sind, gehören in eine externe DMZ (NET.1.1.A10). Liegt ein Lastverteiler, eine Web Application Firewall oder ein transparenter DDoS-Schutzdienst davor, rät die Dokumentation, direkten Zugang zum Odoo-System zu vermeiden, und empfiehlt, in der Firewall nur die Adressbereiche dieses Dienstes zuzulassen (Odoo-Dokumentation 20.0, Abschnitt Security); beides ist eine Empfehlung, keine Vorgabe.

Ergebnis: Ein Portscan von außen zeigt 443 und, wenn Sie ihn offen lassen, 80; die übrigen Ports sollen nicht antworten.

Schritt 4: Datenbank und Datenbankmanager abschotten

Läuft PostgreSQL auf demselben Rechner, bleibt die Verbindung auf der lokalen Adresse. Läuft er auf einem anderen Rechner, nennt die Dokumentation zwei Wege: einen SSH-Tunnel oder eine Netzverbindung, bei Bedarf mit SSL. Dann muss PostgreSQL auf der Netzadresse lauschen, und die Zugriffsregeln stehen in pg_hba.conf; für verschlüsselte TCP-Verbindungen ist dort der Eintragstyp hostssl vorgesehen, der ein auf dem Server aktiviertes SSL voraussetzt (PostgreSQL-Dokumentation). Zwischen Odoo und PostgreSQL steuert die Option db_sslmode die Verschlüsselung; sie nimmt die Werte disable, allow, prefer, require, verify-ca und verify-full an (Odoo-Dokumentation 20.0). require, verify-ca und verify-full verlangen eine verschlüsselte Verbindung; verify-ca und verify-full prüfen zusätzlich das Serverzertifikat, verify-full auch den Hostnamen. Die Vorgabe von sslmode ist prefer; sie lässt eine unverschlüsselte Verbindung zu, wenn der Server kein SSL anbietet (PostgreSQL-Dokumentation, libpq-SSL-Modi).

Der PostgreSQL-Benutzer von Odoo darf kein Superuser sein, und die Datenbanken sollen einem anderen Benutzer gehören. Soll die Datenbankverwaltung gar nicht arbeiten, legen Sie den Benutzer ohne das Recht createdb an.

In der Konfigurationsdatei Ihrer Installation — ihren Pfad nennt der Startbefehl, siehe „Was Sie vorab brauchen“ — schalten list_db = False und der gleichbedeutende Startparameter --no-database-list die Auflistung der Datenbanken sowie die Auswahl- und Verwaltungsbildschirme ab. Bleibt der Datenbankmanager erreichbar, muss admin_passwd von der Vorgabe abweichen und zufällig erzeugt sein. Für jede Datenbank setzen Sie db_name und, bei mehreren Datenbanken, dbfilter, damit Odoo die richtige Datenbank zur angefragten Adresse findet. Der IT-Grundschutz verlangt für Datenbanksysteme eine Basishärtung nach Checkliste und keine Passwörter im Klartext (APP.4.3.A3) und sieht verschlüsselte Datenbankverbindungen vor (APP.4.3.A16).

Ergebnis: Port 5432 ist von außen dicht, die Datenbankverwaltung im Browser ist gesperrt, und das Master-Passwort steht nicht in einer Vorgabe.

Schritt 5: Zugänge, Schlüssel und Rechte ordnen

Für SSH empfiehlt die Dokumentation, die Passwortanmeldung ganz abzuschalten und nur öffentliche Schlüssel zuzulassen, den Zugriff nach Möglichkeit über ein VPN oder vertrauenswürdige IP-Adressen zu begrenzen und eine Brute-Force-Erkennung einzusetzen. Nach SYS.1.3.A8 soll für den interaktiven Zugriff ausschließlich SSH dienen, und zur Authentisierung sind Zertifikate dem Passwort vorzuziehen.

In Odoo gilt: eigene Anmeldenamen, sichere Passwörter je Administratorkonto, „admin“ nicht als Anmeldename, Administratorkonten nicht für die tägliche Arbeit, keine Standardpasswörter auch in Testdatenbanken und keine Demodaten auf einem internetzugewandten Server. Fehlgeschlagene Anmeldungen schreibt Odoo mit Zielanmeldung und Quelladresse ins Protokoll; die Dokumentation zeigt eine fail2ban-Regel, die eine Adresse nach zehn Fehlversuchen in einer Minute für 15 Minuten sperrt.

Der IT-Grundschutz verlangt, festzulegen, welche Zugriffsrechte je Funktion vergeben und entzogen werden; bei längeren Abwesenheiten sollen berechtigte Personen dagegen vorübergehend gesperrt werden (ORP.4.A6, ORP.4.A7; die Vergabe ist als MUSS, die Sperre als SOLLTE formuliert). Mehrstufige Authentisierung nennt er für höheren Schutzbedarf (ORP.4.A21). In Odoo gehören Rollen und Datensatzregeln dazu: Benutzer anlegen und Zugriffsgruppen, Zwei-Faktor-Anmeldung und SSO. Ergänzend empfiehlt die Dokumentation eine Ratenbegrenzung auf Proxy oder Firewall gegen Brute-Force- und Überlastungsangriffe.

Ergebnis: Anmeldung nur mit Schlüssel, ein eigener Anmeldename je Person, kein Standardkonto.

Schritt 6: Protokolle, Aktualisierungen und Sicherungen

Die Firewall soll abgewiesene Verbindungen mit Quell- und Zieladresse, Port und Zeit protokollieren, dazu fehlgeschlagene Zugriffe und Konfigurationsänderungen (NET.3.2.A9); der Webserver soll erfolgreiche und fehlgeschlagene Zugriffe sowie Fehlermeldungen schreiben, und diese Daten sollen regelmäßig ausgewertet werden (APP.3.2.A4).

Patches sind nach der Veröffentlichung zu bewerten und zu priorisieren; Entscheidungen gegen ein Einspielen werden dokumentiert, und Produkte ohne Herstellerunterstützung dürfen nur weiterlaufen, wenn sie nachweislich sicher zu betreiben sind (OPS.1.1.3.A15).

Sichern Sie Datenbank und Dateispeicher täglich und kopieren Sie die Sicherungen auf einen entfernten Archivierungsserver, der vom Server selbst nicht erreichbar ist. Der IT-Grundschutz verlangt einen Sicherungsplan je System, Aufbewahrung getrennt vom gesicherten System, Schutz vor fremdem Zugriff und Überschreiben sowie regelmäßige Wiederherstellungstests (CON.3.A4, CON.3.A12, CON.3.A14, CON.3.A15); den Weg in Odoo beschreibt Odoo sichern.

Zwei weitere Punkte aus der Dokumentation: Öffentlich erreichbare Demo-, Test- und Staging-Instanzen gehören nach Möglichkeit auf andere Rechner als die Produktion und erhalten dieselben Schutzmaßnahmen. Wer mehrere Kundschaften auf einer Maschine hostet, trennt deren Daten und Dateien mit Containern oder vergleichbaren Techniken.

Ergebnis: Änderungen und abgewiesene Zugriffe sind nachvollziehbar, und eine Sicherung liegt außerhalb des Servers.

So prüfen Sie das Ergebnis

1. Prüfen Sie von einem Rechner außerhalb Ihres Netzes, welche Ports antworten. Offen bleiben 443 und, wenn Sie ihn dafür nutzen, 80; 8069, 8072, 5432 und 22 antworten nicht.
2. Sehen Sie auf dem Server nach, an welche Adresse Odoo gebunden ist: 8069 und, im Multiprozess-Modus, 8072 müssen 127.0.0.1 zeigen, nicht 0.0.0.0. Steht dort die öffentliche Adresse, fehlt http_interface.
3. Rufen Sie Ihre Adresse mit http:// auf: Der Aufruf muss auf https:// enden und das Zertifikat zum Namen passen; sonst prüfen Sie die Schritte aus Eigene Domain und SSL-Zertifikat.
4. Öffnen Sie /web/database/manager. Mit list_db = False sperrt Odoo die Auswahl- und Verwaltungsbildschirme; erscheint noch die Liste Ihrer Datenbanken, ist die Option nicht aktiv.
5. Prüfen Sie die Antwortköpfe Ihrer Startseite auf strict-transport-security und das Sitzungscookie session_id auf die Kennzeichen Secure und SameSite=Lax.
6. Melden Sie sich bewusst mit einem falschen Passwort an und sehen Sie im Odoo-Protokoll nach: Der Eintrag muss Ihre echte Quelladresse nennen, nicht die des Proxys. Steht dort die Proxy-Adresse, fehlen proxy_mode oder die X-Forwarded-Kopfzeilen.

Härtungs-Checkliste für Ihren Server

Prüfpunkt	Soll-Zustand
Aus dem Internet erreichbar	nur 443/TCP; 80/TCP nur für die Weiterleitung auf HTTPS
Odoo-Port 8069	über http_interface an die lokale Adresse gebunden, nicht an 0.0.0.0, und zusätzlich in der Firewall gesperrt
Websocket-Port 8072	im Multiprozess-Modus am laufenden System als nur lokal gebunden geprüft (ss -ltn); im Community-Serverkern bindet er an dieselbe Adresse wie der HTTP-Server; /websocket im Proxy auf den Livechat-Worker geleitet; im Thread-Modus läuft /websocket über 8069
PostgreSQL 5432	nur von Odoo erreichbar, lokale Bindung oder SSH-Tunnel
SSH 22	nur aus dem Verwaltungsnetz oder über VPN; Passwortanmeldung abgeschaltet
Proxy-Modus	proxy_mode = True, und zwar weil ein Reverse Proxy davorsteht
Kopfzeilen	X-Forwarded-Host, X-Forwarded-For, X-Forwarded-Proto, X-Real-IP gesetzt
HSTS und Sitzungscookie	Strict-Transport-Security gesetzt; session_id mit Secure und SameSite=Lax
Anfragegröße und Zeiten	client_max_body_size und die Timeouts bewusst gesetzt, nicht unbeschränkt
Datenbankmanager	list_db = False, zufälliges admin_passwd, db_name und dbfilter gesetzt
Datenbankbenutzer	kein Superuser, ohne createdb, Datenbanken gehören einem anderen Benutzer
Firewall-Regelwerk	Allowlist, ausgehend Standard-DENY, Verwaltungszugänge auf Quelladressen begrenzt
Rechte	je Funktion vergeben und entzogen; vorübergehende Sperre bei längerer Abwesenheit empfohlen; mehrstufige Anmeldung bei höherem Schutzbedarf
Protokolle	abgewiesene Verbindungen und fehlgeschlagene Anmeldungen werden geschrieben und ausgewertet
Aktualisierungen	Odoo und Betriebssystem aktuell; Entscheidungen gegen einen Patch dokumentiert
Sicherungen	täglich, Kopie außerhalb des Servers, Wiederherstellung getestet

Wenn etwas nicht klappt

Symptom	Ursache	Abhilfe
Die Anmeldung nennt falsche Adressen oder falsche Absender	proxy_mode ist aus, oder die X-Forwarded-Kopfzeilen fehlen	beides setzen; die Option nur zusammen mit einem Reverse Proxy
Der Livechat bricht ab, Echtzeit-Anzeigen bleiben stehen	/websocket wird nicht auf den Livechat-Worker geleitet, die Kopfzeilen Upgrade und Connection fehlen, oder Odoo läuft im Thread-Modus, in dem diese Anfragen über 8069 laufen	Standortblock im Proxy ergänzen; im Thread-Modus /websocket auf 8069 statt 8072 zeigen lassen
Odoo antwortet auf 8069 direkt aus dem Internet	Odoo lauscht ohne http_interface auf allen Adressen	http_interface = 127.0.0.1 setzen, 8069 neu binden und den Port in der Firewall sperren
Große Anhänge scheitern mit der Antwort 413	client_max_body_size steht auf der Vorgabe 1m	Wert bewusst erhöhen
Im Protokoll wiederholen sich fehlgeschlagene Anmeldungen von einer Adresse	Passwortraten von außen	Ratenbegrenzung in Proxy oder Firewall, Sperre nach Fehlversuchen (fail2ban)
Website oder Anmeldung landet in der falschen Datenbank	db_name oder dbfilter fehlen	Filter je Hostname setzen; bei mehreren Datenbanken ist er laut Dokumentation erforderlich
Nach einer Änderung erreicht niemand mehr den Server	Eine Firewall-Regel ist zu eng geworden	Regeln aus der Dokumentation der Firewall zurückspielen, Zugang über die Konsole offenhalten

Wann Sie Hilfe holen sollten

Verwaltet ein Anbieter oder Dienstleister Ihre Firewall-Regeln, können Sie Regeln anfordern und prüfen, aber nicht selbst setzen; dasselbe gilt für eine Web Application Firewall oder einen DDoS-Schutzdienst.

Diese Anleitung deckt einen Server mit einer Datenbank ab. Betreiben Sie für mehrere Kundschaften getrennte Datenbanken auf einer Maschine, brauchen Sie zusätzlich eine Abschottung, die über Firewall-Regeln hinausgeht; die Dokumentation verweist dafür auf Container oder vergleichbare Techniken. Auf Windows verlangt die Dokumentation eine eigene Sicherheitsüberprüfung, die hier nicht beschrieben ist.

Halten Sie für Änderungen an Proxy und Firewall einen Zugang über die Konsole bereit: Ein zu enges Regelwerk sperrt im schlimmsten Fall alle aus.