Odoo 19 Sicherheitsarchitektur: Firewall, 2FA, Berechtigungen und Web RBL richtig kombinieren

Odoo ist auf unseren fünf Webseiten aus dem offenen Internet erreichbar, und das ist keine Ausnahme, sondern der Normalfall: Wer ein Angebot, einen Shop oder eine Kundenanmeldung betreibt, hat einen öffentlichen Server. Ein einzelnes verwundbares Passwort, eine vergessene Konfigurationsdatei oder eine zu großzügige Berechtigung genügt, damit aus einem öffentlichen Server ein offener wird.

Dieser Beitrag zeigt, wie Sie Odoo 19 richtig absichern — nicht mit einer einzelnen Maßnahme, sondern mit mehreren Schichten, die sich gegenseitig ergänzen: Firewall und Reverse Proxy, unser Open-Source-Modul Web RBL, Zwei-Faktor-Authentifizierung, Passwortrichtlinie und Berechtigungen — und welche Angriffsversuche jede davon tatsächlich abfängt. Am Ende steht eine Schritt-für-Schritt-Anleitung, mit der sich jede eigene Odoo-Installation nachziehen lässt.

Verteidigung in der Tiefe: warum eine Maßnahme nie reicht

Jede einzelne Sicherheitsmaßnahme hat eine Lücke. Eine Firewall sieht nicht, was in einer Odoo-Anmeldemaske passiert. Ein starkes Kennwort schützt nicht, wenn es woanders bereits gestohlen wurde. Eine Berechtigungsstruktur hilft nichts gegen einen Angreifer, der sich noch gar nicht angemeldet hat. Das Prinzip, das diese Lücken schließt, heißt Verteidigung in der Tiefe (defense in depth): mehrere unabhängige Schichten, von denen jede einzelne für sich genommen umgehbar wäre — aber alle gemeinsam eben nicht.

Vier Schichten sind es bei uns, jede mit einer anderen Aufgabe:

• Firewall / Reverse Proxy — hält offensichtlich Bösartiges fern, bevor es den Server überhaupt erreicht
• Web RBL — verbindet beide Seiten: Odoo lernt aus dem eigenen Anwendungsprotokoll, was die Firewall gar nicht sehen kann, und speist es an sie zurück
• Odoo selbst — Zwei-Faktor-Authentifizierung, Passwortrichtlinie, Berechtigungen, Sitzungsverwaltung
• Datenbank & Betrieb — Sicherung, Zugriffsschutz auf die Verwaltung, Geheimnisse außerhalb jedes Protokolls

Die folgenden Abschnitte gehen jede Schicht einzeln durch.

Schicht 1: Firewall und Reverse Proxy

Die Firewall ist die erste Instanz, die eine Anfrage sieht, und die einzige, die einen Angreifer von jedem Dienst auf dem Server fernhalten kann — nicht nur von der Webseite, sondern auch vom Mailserver, vom VPN-Zugang und von der eigenen Verwaltungsoberfläche. Was an dieser Stelle sinnvoll aktiviert wird, hängt vom Hersteller ab, aber die Bauformen sind bei OPNsense, pfSense, HAProxy, FortiGate, Sophos oder Check Point dieselben:

RBL-Listen: der Standardweg, auf dem Reputation ausgeliefert wird

RBL steht für Real-time Blackhole List, ein Begriff aus der Mailwelt: eine Adresse je Zeile, über HTTP abrufbar, regelmäßig neu geladen. Praktisch jede Firewall kann eine solche Liste einlesen und daraus Regeln bauen — OPNsense und pfSense als URL Table Alias, HAProxy als ACL-Datei, FortiGate als External Block List, Palo Alto als External Dynamic List, Cisco, Sophos, Juniper und MikroTik mit eigenen Namen für dasselbe Prinzip.

Genau hier setzt unser eigenes Modul an — und genau hier beginnt die zweite Schicht.

Schicht 2: Web RBL — die Brücke zwischen Anwendung und Firewall

Eine Firewall sieht Pakete, keine Anwendungslogik. Sie weiß nicht, dass eine Anfrage nach /xmlrpc/2/common ein Anmeldeversuch ist, dass zwanzig verschiedene Pfade in vierzehn Sekunden ein Scanner sind, oder dass eine Adresse gerade erfolgreich ein Kennwort erraten hat. All das weiß nur Odoo selbst. Web RBL, unser eigenes Open-Source-Modul (AGPL-3), macht dieses Wissen nutzbar — für Odoo selbst und, als RBL-Liste ausgeliefert, auch für die Firewall davor.

Bedrohungslisten laufend abgeglichen, jede mit eigener Stufe.

Kurz zusammengefasst, was in den vorigen Beitrag ausführlich beschrieben ist:

• Mustererkennung in Pfaden: .env-Dateien, .git-Verzeichnisse, Konfigurationsdateien, WordPress- und PHP-Sonden, Pfad-Traversal, Befehlsausführung über neue KI-Schnittstellen
• Anmeldeabwehr, die über Neustarts hinweg zählt — anders als Odoos eigener, im Arbeitsspeicher lebender Zähler
• Bewertung jeder Adresse von 0 bis 100, mit Begründung im Klartext
• Fehlkonfigurationen (QNAP, Autodiscover, Synology) werden erkannt und nie gesperrt, weil eine Sperre den Defekt nicht behebt, sondern nur verbirgt
• Fremde Bedrohungslisten wie Spamhaus, FireHOL und Tor-Ausgangsknoten, laufend abgeglichen
• Freiliste für Adressen, die nie gesperrt werden sollen

Für diesen Beitrag sind zwei Eigenschaften besonders wichtig, weil sie unmittelbar mit der Firewall und mit der Anmeldung zusammenhängen.

Eine träge Liste ist eine Liste, der man vertrauen kann

Die Freiliste — Adressen, die nie gesperrt werden, etwa eigene Standortanbindungen — ändert sich in aller Regel selten. Genau das ist ihr Wert, nicht ihr Mangel: Wenn sich eine ruhige Liste über Tage kaum bewegt, fällt jede seltene Änderung sofort auf. Die tägliche automatische Nachführung existiert nicht, weil sich viel ändern würde, sondern damit die seltene Änderung nicht von Hand nachgetragen werden muss — und genau das ist der Punkt, an dem man es vergisst. Eine unserer eigenen Fehlkonfigurationen im vergangenen Monat ist genau so aufgefallen: nicht durch viele Ereignisse, sondern durch das eine, das niemand kannte, bis die QNAP-Web-API eines Kunden fälschlich gesperrt wurde. Seither steht QNAP auf der Liste der Fehlkonfigurationen, die nie gesperrt, sondern nur gemeldet werden.

Die Anmeldung ist der Ort, den eine Firewall nicht sieht

Eine Firewall kann eine Adresse sperren. Sie kann nicht wissen, ob eine Anmeldung gelungen ist, und schon gar nicht, ob sie von einer Adresse kam, die kurz zuvor noch nach Zugangsdaten gesucht hat. Web RBL schon: Eine Bewertung ab einem einstellbaren Schwellwert verbietet die Anmeldung ganz, und eine gelungene Anmeldung von einer auffälligen Adresse wird gemeldet — das ist das Bindeglied zur nächsten Schicht.

Schicht 3: Odoo selbst absichern

Zwei-Faktor-Authentifizierung: ein zweites Geheimnis, das nicht wiederverwendbar ist

Das größte Problem von Kennwörtern ist nicht ihre Qualität, sondern ihre Wiederverwendung. Ein Kennwort, das bei einem anderen Dienst gestohlen wurde, funktioniert bei uns genauso, solange es dasselbe ist. Die Zwei-Faktor-Authentifizierung (2FA, auch TOTP genannt) setzt dem ein zweites Geheimnis entgegen: einen sechsstelligen Code, der sich alle dreißig Sekunden ändert und aus einem Geheimnis berechnet wird, das nur das eigene Smartphone kennt. Ein gestohlenes Kennwort allein reicht damit nicht mehr.

Odoo 19 Community bringt das eingebaut mit — als installierbares Modul Two-Factor Authentication (TOTP), ergänzt um eine E-Mail-Rückfalloption. Jeder Benutzer richtet es für sich selbst ein, per QR-Code, mit jeder gängigen Authenticator-App:

Die Einrichtung: QR-Code scannen, sechsstelligen Code einmal bestätigen, fertig.

Das allein hilft aber nur denen, die es sich selbst einrichten — und Erfahrung zeigt, dass das ohne Zwang die Minderheit bleibt. Odoo kennt deshalb eine Erzwingungsrichtlinie: entweder nur für Mitarbeiter (interne Benutzer) oder für alle, Portalbenutzer eingeschlossen. Ohne eingerichtetes zweites Geheimnis kommt niemand mehr an der Anmeldemaske vorbei, ohne es zumindest per E-Mail-Code zu bestätigen.

Passwortrichtlinie: eine Mindestlänge ist keine Selbstverständlichkeit

Ohne Zusatzmodul verlässt sich Odoo Community auf keine Mindestlänge für Kennwörter — ein Benutzer kann ein Kennwort aus drei Zeichen vergeben, wenn ihn niemand daran hindert. Das eigene Password Policy-Modul schließt genau diese Lücke: eine Mindestlänge, die serverseitig durchgesetzt wird, nicht nur im Browser vorgeschlagen. Wer mehr will — eine erzwungene Ablaufzeit, eine Historie gegen Wiederverwendung — braucht dafür ein OCA- oder Drittmodul; das ist in der Community-Version bewusst schlank gehalten.

Berechtigungen: nur wer es braucht, bekommt Zugriff

Odoo trennt von Haus aus drei Ebenen: Portalbenutzer (nur das eigene Kunden- oder Lieferantenportal), interne Benutzer (das Backend, mit Rechten je Anwendung) und Administratoren (uneingeschränkter Zugriff samt technischer Einstellungen). Der häufigste Fehler ist nicht ein zu schwaches Kennwort, sondern eine zu großzügig vergebene Administratorrolle: Wer nur Rechnungen erstellen soll, braucht keinen Zugriff auf die Systemeinstellungen.

Zwei Grundsätze tragen die meiste Last:

Beides lässt sich in derselben Ansicht prüfen, in der auch die Zwei-Faktor-Authentifizierung eingerichtet wird:

Eine Übersicht, vier Hebel: Kennwort, zweiter Faktor, API-Schlüssel, angemeldete Geräte.

Sitzungen und Geräte: wer ist gerade angemeldet

Dieselbe Ansicht zeigt auch, von welchen Geräten aus ein Konto gerade angemeldet ist — und erlaubt, ein einzelnes oder alle auf einmal abzumelden. Nach einem verlorenen Laptop oder dem Verdacht auf ein kompromittiertes Kennwort ist das der schnellste wirksame Schritt: Die Sitzung endet sofort, unabhängig davon, ob das Kennwort schon geändert wurde.

Schicht 4: Datenbank und Betrieb

Die vierte Schicht ist die am wenigsten sichtbare und zugleich unverzeihlichste, weil ein Fehler hier alles vorher Aufgebaute zunichtemachen kann.

• Regelmäßige, geprüfte Sicherungen, getrennt vom Server selbst gespeichert. Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung, keine Sicherung.
• Geheimnisse gehören in keine Protokolldatei. Kennwörter, API-Schlüssel, Lizenzdaten — wer eigene Erweiterungen schreibt, sollte sie so behandeln wie das Hauptkennwort selbst: nirgends mitschreiben, auch nicht „nur zum Debuggen".
• Module aktuell halten, auch und gerade Drittmodule. Freie Zusatzmodule (OCA und andere) hinken neuen Odoo-Versionen naturgemäß hinterher; vor jeder Installation lohnt ein Blick, welche Abhängigkeiten automatisch mitkommen.

Der Anmeldeweg im Ganzen

Die vier Schichten wirken nicht nacheinander in getrennten Räumen, sondern an derselben Anfrage, Stufe für Stufe. Am Beispiel einer Anmeldung wird das am deutlichsten:

Fünf Stellen, an denen eine bösartige Anfrage enden kann, bevor sie beim eigentlichen Ziel ankommt — und nur eine einzige, an der ein berechtigter Benutzer sie alle besteht.

Angriffsszenarien und ihre Gegenwehr

Die folgende Übersicht ordnet reale Angriffsmuster den Schichten zu, die sie tatsächlich stoppen. Mehrere davon sind keine Theorie, sondern eigene Beobachtungen aus siebzehn Tagen Echtverkehr auf unseren fünf Webseiten.

Schritt-für-Schritt: die eigene Odoo-Installation absichern

Die folgende Reihenfolge ist die, in der wir selbst vorgehen würden — von der größten Wirkung zur feinsten Einstellung.

1. Zwei-Faktor-Authentifizierung erzwingen

1. Falls noch nicht installiert: Apps öffnen, nach „Two-Factor Authentication" suchen und installieren (bei mehreren Webseiten empfiehlt sich zusätzlich „Two-Factor Authentication by Mail" als Rückfalloption).
2. Einstellungen → Allgemeine Einstellungen → Berechtigungen öffnen.
3. „Zwei-Faktor-Authentifizierung erzwingen" aktivieren.
4. Richtlinie wählen: „Nur Mitarbeiter" für interne Benutzer, „Alle Benutzer", wenn auch Portalbenutzer (Kunden mit Zugang) einbezogen werden sollen.
5. Speichern. Ab dem nächsten Anmeldeversuch verlangt Odoo von jedem Benutzer ohne eingerichtetes zweites Geheimnis mindestens den E-Mail-Code, bis er die Authenticator-App eingerichtet hat.

2. Eine Mindestlänge für Kennwörter festlegen

1. Apps öffnen, nach „Password Policy" suchen und installieren.
2. Einstellungen → Allgemeine Einstellungen → Berechtigungen öffnen.
3. „Mindestlänge des Passworts" setzen — zwölf Zeichen sind ein vernünftiger Ausgangswert.
4. Speichern. Die Regel gilt ab sofort für jede neue oder geänderte Kennwortvergabe, rückwirkend nicht für bestehende Kennwörter.

3. Berechtigungen durchsehen

1. Einstellungen → Benutzer & Unternehmen → Benutzer öffnen.
2. Jeden Benutzer einzeln öffnen und den Reiter mit den Zugriffsrechten je Anwendung prüfen: Braucht diese Person wirklich „Manager" oder „Administrator", oder reicht „Benutzer"?
3. Besonders prüfen: Wer hat Zugriff auf „Einstellungen" selbst? Das sollte eine sehr kleine Gruppe sein.
4. Für jede externe Anbindung (Buchhaltung, eigene Skripte, Zeiterfassung) im Reiter „Kontosicherheit" des jeweiligen technischen Benutzers einen eigenen API-Schlüssel anlegen, statt das Benutzerkennwort weiterzugeben.

4. Web RBL installieren und beobachten, bevor scharf geschaltet wird

1. Modul von github.com/Alex0176/odoo-web-rbl in den Addon-Pfad legen und installieren.
2. Einige Tage beobachten: Menü Web RBL → Auswertung zeigt, welche Muster tatsächlich greifen.
3. Erst danach web_rbl.sperren_aktiv einschalten (Einstellungen → Technisch → Systemparameter) — ab hier werden erkannte Sonden tatsächlich abgewiesen.
4. Die Sperrliste unter der im Modul angegebenen, mit Token geschützten Adresse in die Firewall als RBL-Liste einbinden (bei OPNsense/pfSense als URL Table Alias, bei HAProxy als ACL-Datei).

5. Die Firewall selbst absichern

1. Verwaltungsoberfläche der Firewall ausschließlich aus dem internen Netz erreichbar machen, nie über dieselbe öffentliche Adresse wie die Webseite.
2. Automatische Sicherheitsupdates für die Firewall-Software aktivieren, sofern der Hersteller das anbietet.
3. TLS-Konfiguration prüfen: nur aktuelle Protokollversionen, veraltete Verschlüsselungsverfahren deaktivieren.
4. Falls verfügbar: eine bekannte Reputationsliste (etwa Spamhaus DROP) direkt auf der Firewall einbinden — unabhängig von Web RBL, denn die Firewall sieht damit auch Verkehr zu Diensten, die Odoo nie erreicht.

6. Die Datenbankverwaltung schließen

1. Prüfen, ob /web/database/manager von außen erreichbar ist — wenn ja, in der Odoo-Konfiguration list_db = False setzen oder den Pfad auf Firewall-Ebene sperren.
2. Das Hauptkennwort der Datenbankverwaltung lang und zufällig setzen und an keiner Stelle notieren, die irgendjemand sonst lesen kann.

7. Sicherung prüfen, nicht nur einrichten

1. Eine automatische, regelmäßige Sicherung einrichten, getrennt vom Odoo-Server gespeichert.
2. Mindestens einmal tatsächlich zurückspielen und prüfen, ob die Wiederherstellung funktioniert — eine ungeprüfte Sicherung ist eine Vermutung.

Keiner dieser Schritte ersetzt einen der anderen. Wer nur einen davon umsetzt, hat eine Tür verstärkt und alle anderen offen gelassen — wer alle sieben umsetzt, hat eine Verteidigung, die auch dann noch hält, wenn eine einzelne Schicht versagt.

Was diese Architektur nicht ersetzt

Keine der beschriebenen Maßnahmen macht Sorgfalt überflüssig. Ein Modul, das .env-Sonden abweist, macht eine versehentlich veröffentlichte .env-Datei nicht ungefährlich. Zwei-Faktor-Authentifizierung schützt nicht vor einem Benutzer, der seinen Code einem Anrufer am Telefon vorliest. Und eine Firewall ersetzt keine Entscheidung darüber, wer welche Berechtigung tatsächlich braucht. Sicherheitsarchitektur schafft die Bedingungen, unter denen ein einzelner Fehler nicht gleich zum Vorfall wird — sie nimmt niemandem die Sorgfalt ab.

Häufige Fragen

Reicht ein starkes Passwort, um Odoo 19 abzusichern?

Nein. Ein Passwort kann anderswo gestohlen werden, ganz unabhängig von seiner Qualität, und funktioniert dann bei jedem Dienst, der dasselbe Passwort akzeptiert. Erst die Kombination mit Zwei-Faktor-Authentifizierung, einer Firewall davor und einer sinnvollen Berechtigungsstruktur ergibt eine Absicherung, die auch nach einem gestohlenen Passwort noch hält.

Wie aktiviere ich die Zwei-Faktor-Authentifizierung in Odoo 19?

Das Modul „Two-Factor Authentication (TOTP)" über die Apps-Verwaltung installieren, anschließend unter Einstellungen → Allgemeine Einstellungen → Berechtigungen die Erzwingung aktivieren und zwischen „Nur Mitarbeiter" und „Alle Benutzer" wählen. Jeder Benutzer richtet danach seinen eigenen zweiten Faktor per QR-Code ein.

Was ist eine RBL-Liste, und warum braucht Odoo eine?

RBL (Real-time Blackhole List) ist eine über HTTP abrufbare Adressliste, die praktisch jede Firewall einlesen kann. Odoo selbst liefert keine solche Liste mit — unser Modul Web RBL schließt diese Lücke, indem es Angriffsverkehr aus dem eigenen Anwendungsprotokoll erkennt und als RBL-Liste an die vorgelagerte Firewall zurückgibt.

Ist Odoo 19 Community ohne Zusatzmodule ausreichend abgesichert?

Nicht vollständig. Ohne das Modul Password Policy gibt es keine Mindestlänge für Kennwörter, ohne Two-Factor Authentication keinen zweiten Faktor, und ohne ein Modul wie Web RBL erkennt Odoo weder Sondierungsversuche noch wiederholte Anmeldeversuche über einen Neustart hinweg. Alle vier lassen sich kostenlos nachrüsten.

Verfügbarkeit

Web RBL steht unter der AGPL-3 öffentlich zur Verfügung und läuft bei uns produktiv auf fünf Webseiten:

github.com/Alex0176/odoo-web-rbl

Die vollständige Funktionsbeschreibung mit allen Mustern, der Bewertung und den Bedrohungslisten steht im vorigen Beitrag: Web RBL – Sperrliste für Angriffsverkehr auf den eigenen Webseiten.

Fragen, Anmerkungen und Fehlerberichte nehmen wir gerne entgegen — am liebsten als Issue auf GitHub.