Odoo 19-beveiligingsarchitectuur: firewall, 2FA, rechten en Web RBL juist combineren

Odoo is op onze vijf websites bereikbaar vanaf het open internet, en dat is geen uitzondering maar de normale situatie: wie een aanbod, een webshop of een klantenaanmelding aanbiedt, heeft een openbare server. Eén enkel kwetsbaar wachtwoord, een vergeten configuratiebestand of een te ruimhartige machtiging volstaat om van een openbare server een open server te maken.

Dit artikel laat zien hoe u Odoo 19 juist beveiligt — niet met één enkele maatregel, maar met meerdere lagen die elkaar aanvullen: firewall en reverse proxy, onze opensourcemodule Web RBL, tweefactorauthenticatie, wachtwoordbeleid en rechten — en welke aanvalspogingen elk daarvan daadwerkelijk onderschept. Aan het eind staat een stapsgewijze handleiding waarmee elke eigen Odoo-installatie kan worden aangepast.

Defense in depth: waarom één maatregel nooit volstaat

Elke afzonderlijke beveiligingsmaatregel heeft een gat. Een firewall ziet niet wat er in een Odoo-aanmeldscherm gebeurt. Een sterk wachtwoord beschermt niet als het elders al is gestolen. Een rechtenstructuur helpt niet tegen een aanvaller die zich nog helemaal niet heeft aangemeld. Het principe dat deze gaten dicht, heet defense in depth: meerdere onafhankelijke lagen, die elk afzonderlijk te omzeilen zouden zijn — maar samen juist niet.

Bij ons zijn het vier lagen, elk met een andere taak:

• Firewall / reverse proxy — houdt kennelijk kwaadaardig verkeer weg voordat het de server zelfs maar bereikt
• Web RBL — verbindt beide kanten: Odoo leert uit het eigen applicatielogboek wat de firewall helemaal niet kan zien, en voedt dat terug aan de firewall
• Odoo zelf — tweefactorauthenticatie, wachtwoordbeleid, rechten, sessiebeheer
• Database & beheer — back-up, toegangsbescherming voor het beheer, geheimen buiten elk logboek

De volgende paragrafen behandelen elke laag afzonderlijk.

Laag 1: firewall en reverse proxy

De firewall is de eerste instantie die een verzoek ziet, en de enige die een aanvaller van elke dienst op de server kan weghouden — niet alleen van de website, maar ook van de mailserver, de VPN-toegang en de eigen beheerinterface. Wat op dit punt zinvol wordt geactiveerd, hangt af van de fabrikant, maar de bouwstenen zijn bij OPNsense, pfSense, HAProxy, FortiGate, Sophos of Check Point dezelfde:

RBL-lijsten: de standaardroute waarlangs reputatie wordt geleverd

RBL staat voor Real-time Blackhole List, een term uit de mailwereld: één adres per regel, via HTTP op te halen, regelmatig opnieuw geladen. Vrijwel elke firewall kan zo’n lijst inlezen en er regels van maken — OPNsense en pfSense als URL Table Alias, HAProxy als ACL-bestand, FortiGate als External Block List, Palo Alto als External Dynamic List, Cisco, Sophos, Juniper en MikroTik met eigen namen voor hetzelfde principe.

Precies hier zet onze eigen module in — en precies hier begint de tweede laag.

Laag 2: Web RBL — de brug tussen applicatie en firewall

Een firewall ziet pakketten, geen applicatielogica. Hij weet niet dat een verzoek om /xmlrpc/2/common een aanmeldpoging is, dat twintig verschillende paden in veertien seconden een scanner zijn, of dat een adres zojuist met succes een wachtwoord heeft geraden. Dat alles weet alleen Odoo zelf. Web RBL, onze eigen opensourcemodule (AGPL-3), maakt die kennis bruikbaar — voor Odoo zelf en, als RBL-lijst geleverd, ook voor de firewall ervoor.

Dreigingslijsten voortdurend vergeleken, elk met een eigen niveau.

Kort samengevat wat in het vorige artikel uitvoerig is beschreven:

• Patroonherkenning in paden: .env-bestanden, .git-mappen, configuratiebestanden, WordPress- en PHP-sondes, padtraversal, opdrachtuitvoering via nieuwe AI-interfaces
• Aanmeldafweer die over herstarts heen telt — anders dan de eigen teller van Odoo, die in het werkgeheugen leeft
• Score van elk adres van 0 tot 100, met motivering in duidelijke taal
• Foutieve configuraties (QNAP, Autodiscover, Synology) worden herkend en nooit geblokkeerd, omdat een blokkade het defect niet verhelpt maar slechts verbergt
• Externe dreigingslijsten zoals Spamhaus, FireHOL en Tor-exitnodes, voortdurend vergeleken
• Vrijlijst voor adressen die nooit geblokkeerd mogen worden

Voor dit artikel zijn twee eigenschappen bijzonder belangrijk, omdat ze rechtstreeks met de firewall en met de aanmelding samenhangen.

Een trage lijst is een lijst die je kunt vertrouwen

De vrijlijst — adressen die nooit worden geblokkeerd, bijvoorbeeld eigen locatieverbindingen — verandert doorgaans zelden. Juist dat is haar waarde, niet haar tekortkoming: als een rustige lijst dagenlang nauwelijks beweegt, valt elke zeldzame wijziging meteen op. De dagelijkse automatische bijwerking bestaat niet omdat er veel zou veranderen, maar opdat de zeldzame wijziging niet met de hand hoeft te worden bijgehouden — en juist dat is het punt waarop men het vergeet. Een van onze eigen foutieve configuraties van de afgelopen maand is precies zo opgevallen: niet door veel gebeurtenissen, maar door die ene die niemand kende, totdat de QNAP-web-API van een klant ten onrechte werd geblokkeerd. Sindsdien staat QNAP op de lijst van foutieve configuraties die nooit worden geblokkeerd, maar alleen gemeld.

De aanmelding is de plek die een firewall niet ziet

Een firewall kan een adres blokkeren. Hij kan niet weten of een aanmelding geslaagd is, en al helemaal niet of die kwam van een adres dat kort daarvoor nog naar toegangsgegevens zocht. Web RBL wel: een score vanaf een instelbare drempelwaarde verbiedt de aanmelding helemaal, en een geslaagde aanmelding vanaf een opvallend adres wordt gemeld — dat is de schakel naar de volgende laag.

Laag 3: Odoo zelf beveiligen

Tweefactorauthenticatie: een tweede geheim dat niet herbruikbaar is

Het grootste probleem van wachtwoorden is niet hun kwaliteit, maar hun hergebruik. Een wachtwoord dat bij een andere dienst is gestolen, werkt bij ons net zo goed, zolang het hetzelfde is. De tweefactorauthenticatie (2FA, ook TOTP genoemd) zet daar een tweede geheim tegenover: een zescijferige code die elke dertig seconden verandert en wordt berekend uit een geheim dat alleen de eigen smartphone kent. Een gestolen wachtwoord alleen volstaat dan niet meer.

Odoo 19 Community heeft dit ingebouwd — als installeerbare module Two-Factor Authentication (TOTP), aangevuld met een e-mailterugvaloptie. Elke gebruiker stelt het zelf in, via QR-code, met elke gangbare authenticator-app:

De installatie: QR-code scannen, zescijferige code eenmaal bevestigen, klaar.

Dat helpt echter alleen degenen die het zelf instellen — en de ervaring leert dat dit zonder verplichting een minderheid blijft. Odoo kent daarom een afdwingbeleid: ofwel alleen voor medewerkers (interne gebruikers) ofwel voor iedereen, portalgebruikers inbegrepen. Zonder ingestelde tweede factor komt niemand meer langs het aanmeldscherm zonder dat minstens met een e-mailcode te bevestigen.

Wachtwoordbeleid: een minimale lengte is geen vanzelfsprekendheid

Zonder extra module vertrouwt Odoo Community niet op een minimale wachtwoordlengte — een gebruiker kan een wachtwoord van drie tekens kiezen als niemand dat verhindert. De eigen Password Policy-module sluit precies dit gat: een minimale lengte die aan de serverzijde wordt afgedwongen, niet alleen in de browser wordt voorgesteld. Wie meer wil — een afgedwongen geldigheidsduur, een historie tegen hergebruik — heeft daarvoor een OCA- of externe module nodig; dat is in de Community-versie bewust sober gehouden.

Rechten: alleen wie het nodig heeft, krijgt toegang

Odoo scheidt standaard drie niveaus: portalgebruikers (alleen het eigen klanten- of leveranciersportaal), interne gebruikers (de backend, met rechten per applicatie) en beheerders (onbeperkte toegang inclusief technische instellingen). De meest voorkomende fout is niet een te zwak wachtwoord, maar een te ruimhartig toegekende beheerdersrol: wie alleen facturen hoeft te maken, heeft geen toegang tot de systeeminstellingen nodig.

Twee principes dragen het grootste deel van de last:

Beide zijn te controleren in dezelfde weergave waarin ook de tweefactorauthenticatie wordt ingesteld:

Eén overzicht, vier hefbomen: wachtwoord, tweede factor, API-sleutels, aangemelde apparaten.

Sessies en apparaten: wie is er nu aangemeld

Dezelfde weergave toont ook vanaf welke apparaten een account op dit moment is aangemeld — en maakt het mogelijk één apparaat of alle tegelijk af te melden. Na een verloren laptop of bij vermoeden van een gecompromitteerd wachtwoord is dat de snelste effectieve stap: de sessie eindigt onmiddellijk, ongeacht of het wachtwoord al is gewijzigd.

Laag 4: database en beheer

De vierde laag is de minst zichtbare en tegelijk de meest onvergeeflijke, omdat een fout hier alles wat eerder is opgebouwd teniet kan doen.

• Regelmatige, gecontroleerde back-ups, gescheiden van de server zelf opgeslagen. Een back-up die nooit is teruggezet, is een vermoeden, geen back-up.
• Geheimen horen in geen enkel logbestand. Wachtwoorden, API-sleutels, licentiegegevens — wie eigen uitbreidingen schrijft, moet ze behandelen als het hoofdwachtwoord zelf: nergens meeloggen, ook niet “alleen om te debuggen”.
• Modules actueel houden, ook en juist externe modules. Vrije extra modules (OCA en andere) lopen van nature achter op nieuwe Odoo-versies; vóór elke installatie loont een blik op welke afhankelijkheden automatisch worden meegeïnstalleerd.

De aanmeldroute als geheel

De vier lagen werken niet na elkaar in gescheiden ruimten, maar op hetzelfde verzoek, stap voor stap. Aan de hand van een aanmelding wordt dat het duidelijkst:

Vijf plekken waar een kwaadaardig verzoek kan eindigen voordat het bij het eigenlijke doel aankomt — en slechts één waar een bevoegde gebruiker ze allemaal doorloopt.

Aanvalsscenario’s en hun tegenmaatregelen

Het volgende overzicht koppelt reële aanvalspatronen aan de lagen die ze daadwerkelijk stoppen. Meerdere daarvan zijn geen theorie, maar eigen waarnemingen uit zeventien dagen echt verkeer op onze vijf websites.

Stap voor stap: de eigen Odoo-installatie beveiligen

De volgende volgorde is die waarin wijzelf te werk zouden gaan — van de grootste werking naar de fijnste instelling.

1. Tweefactorauthenticatie afdwingen

1. Indien nog niet geïnstalleerd: open Apps, zoek naar “Two-Factor Authentication” en installeer het (bij meerdere websites is aanvullend “Two-Factor Authentication by Mail” als terugvaloptie aan te raden).
2. Open Instellingen → Algemene instellingen → Rechten.
3. Activeer “Tweefactorauthenticatie afdwingen”.
4. Kies het beleid: “Alleen medewerkers” voor interne gebruikers, “Alle gebruikers” als ook portalgebruikers (klanten met toegang) moeten worden meegenomen.
5. Opslaan. Vanaf de volgende aanmeldpoging eist Odoo van elke gebruiker zonder ingestelde tweede factor minimaal de e-mailcode, totdat hij de authenticator-app heeft ingesteld.

2. Een minimale wachtwoordlengte vastleggen

1. Open Apps, zoek naar “Password Policy” en installeer het.
2. Open Instellingen → Algemene instellingen → Rechten.
3. Stel “Minimale wachtwoordlengte” in — twaalf tekens is een redelijke beginwaarde.
4. Opslaan. De regel geldt vanaf nu voor elke nieuwe of gewijzigde wachtwoordtoekenning, niet met terugwerkende kracht voor bestaande wachtwoorden.

3. Rechten doornemen

1. Open Instellingen → Gebruikers & bedrijven → Gebruikers.
2. Open elke gebruiker afzonderlijk en controleer het tabblad met de toegangsrechten per applicatie: heeft deze persoon werkelijk “Manager” of “Beheerder” nodig, of volstaat “Gebruiker”?
3. Let in het bijzonder op: wie heeft toegang tot “Instellingen” zelf? Dat moet een zeer kleine groep zijn.
4. Maak voor elke externe koppeling (boekhouding, eigen scripts, tijdregistratie) op het tabblad “Accountbeveiliging” van de betreffende technische gebruiker een eigen API-sleutel aan, in plaats van het gebruikerswachtwoord door te geven.

4. Web RBL installeren en observeren voordat het scherp wordt gezet

1. Plaats de module van github.com/Alex0176/odoo-web-rbl in het addonpad en installeer hem.
2. Enkele dagen observeren: menu Web RBL → Analyse toont welke patronen daadwerkelijk toeslaan.
3. Pas daarna web_rbl.sperren_aktiv inschakelen (Instellingen → Technisch → Systeemparameters) — vanaf dat moment worden herkende sondes daadwerkelijk geweigerd.
4. Neem de blokkeerlijst op het in de module vermelde, met een token beveiligde adres als RBL-lijst op in de firewall (bij OPNsense/pfSense als URL Table Alias, bij HAProxy als ACL-bestand).

5. De firewall zelf beveiligen

1. Maak de beheerinterface van de firewall uitsluitend bereikbaar vanuit het interne netwerk, nooit via hetzelfde openbare adres als de website.
2. Activeer automatische beveiligingsupdates voor de firewallsoftware, voor zover de fabrikant dat aanbiedt.
3. Controleer de TLS-configuratie: alleen actuele protocolversies, verouderde versleutelingsmethoden uitschakelen.
4. Indien beschikbaar: neem een bekende reputatielijst (bijvoorbeeld Spamhaus DROP) rechtstreeks op in de firewall — onafhankelijk van Web RBL, want de firewall ziet daarmee ook verkeer naar diensten die Odoo nooit bereikt.

6. Het databasebeheer sluiten

1. Controleer of /web/database/manager van buitenaf bereikbaar is — zo ja, stel in de Odoo-configuratie list_db = False in of blokkeer het pad op firewallniveau.
2. Stel het hoofdwachtwoord van het databasebeheer lang en willekeurig in en noteer het nergens waar iemand anders het kan lezen.

7. Back-up controleren, niet alleen instellen

1. Stel een automatische, regelmatige back-up in, gescheiden van de Odoo-server opgeslagen.
2. Zet hem minstens één keer daadwerkelijk terug en controleer of het herstel werkt — een ongecontroleerde back-up is een vermoeden.

Geen van deze stappen vervangt een andere. Wie er slechts één uitvoert, heeft één deur versterkt en alle andere open gelaten — wie alle zeven uitvoert, heeft een verdediging die standhoudt, ook als één enkele laag faalt.

Wat deze architectuur niet vervangt

Geen van de beschreven maatregelen maakt zorgvuldigheid overbodig. Een module die .env-sondes weigert, maakt een per ongeluk gepubliceerd .env-bestand niet ongevaarlijk. Tweefactorauthenticatie beschermt niet tegen een gebruiker die zijn code voorleest aan een beller aan de telefoon. En een firewall vervangt geen beslissing over wie welk recht werkelijk nodig heeft. Beveiligingsarchitectuur schept de voorwaarden waaronder een enkele fout niet meteen een incident wordt — ze neemt niemand de zorgvuldigheid uit handen.

Veelgestelde vragen

Is een sterk wachtwoord genoeg om Odoo 19 te beveiligen?

Nee. Een wachtwoord kan elders worden gestolen, geheel onafhankelijk van zijn kwaliteit, en werkt dan bij elke dienst die hetzelfde wachtwoord accepteert. Pas de combinatie met tweefactorauthenticatie, een firewall ervoor en een zinvolle rechtenstructuur levert een beveiliging op die ook na een gestolen wachtwoord standhoudt.

Hoe activeer ik tweefactorauthenticatie in Odoo 19?

Installeer de module “Two-Factor Authentication (TOTP)” via het appbeheer, activeer vervolgens onder Instellingen → Algemene instellingen → Rechten het afdwingen en kies tussen “Alleen medewerkers” en “Alle gebruikers”. Elke gebruiker stelt daarna zijn eigen tweede factor in via QR-code.

Wat is een RBL-lijst, en waarom heeft Odoo er een nodig?

RBL (Real-time Blackhole List) is een via HTTP op te halen adreslijst die vrijwel elke firewall kan inlezen. Odoo zelf levert geen dergelijke lijst mee — onze module Web RBL dicht dat gat door aanvalsverkeer uit het eigen applicatielogboek te herkennen en als RBL-lijst terug te geven aan de voorgeschakelde firewall.

Is Odoo 19 Community zonder extra modules voldoende beveiligd?

Niet volledig. Zonder de module Password Policy is er geen minimale wachtwoordlengte, zonder Two-Factor Authentication geen tweede factor, en zonder een module als Web RBL herkent Odoo noch verkenningspogingen noch herhaalde aanmeldpogingen over een herstart heen. Alle vier zijn gratis achteraf toe te voegen.

Beschikbaarheid

Web RBL is onder de AGPL-3 openbaar beschikbaar en draait bij ons in productie op vijf websites:

github.com/Alex0176/odoo-web-rbl

De volledige functiebeschrijving met alle patronen, de score en de dreigingslijsten staat in het vorige artikel: Web RBL – blokkeerlijst voor aanvalsverkeer op de eigen websites.

Vragen, opmerkingen en foutrapporten nemen wij graag in ontvangst — het liefst als issue op GitHub.