Sikkerhetsarkitekturen i Odoo 19: kombinere brannmur, 2FA, rettigheter og Web RBL riktig

Odoo er tilgjengelig fra det åpne internett på våre fem nettsteder, og det er ikke noe unntak, men normaltilfellet: Den som driver et tilbud, en nettbutikk eller en kundeinnlogging, har en offentlig server. Ett eneste sårbart passord, en glemt konfigurasjonsfil eller en for sjenerøs rettighet er nok til å gjøre en offentlig server til en åpen en.

Dette innlegget viser hvordan du sikrer Odoo 19 riktig — ikke med ett enkelt tiltak, men med flere lag som utfyller hverandre: brannmur og reverse proxy, vår åpen kildekode-modul Web RBL, tofaktorautentisering, passordpolicy og rettigheter — og hvilke angrepsforsøk hvert av dem faktisk fanger opp. Til slutt kommer en trinn-for-trinn-veiledning som lar deg gjennomføre det samme i din egen Odoo-installasjon.

Forsvar i dybden: hvorfor ett tiltak aldri er nok

Hvert enkelt sikkerhetstiltak har et hull. En brannmur ser ikke hva som skjer i et Odoo-innloggingsskjema. Et sterkt passord beskytter ikke hvis det allerede er stjålet et annet sted. En rettighetsstruktur hjelper ikke mot en angriper som ennå ikke har logget inn. Prinsippet som tetter disse hullene, heter forsvar i dybden (defense in depth): flere uavhengige lag, der hvert enkelt for seg kunne omgås — men alle sammen ikke.

Hos oss er det fire lag, hvert med sin egen oppgave:

• Brannmur / reverse proxy — holder det åpenbart ondsinnede unna før det i det hele tatt når serveren
• Web RBL — forbinder begge sider: Odoo lærer av sin egen applikasjonslogg det brannmuren ikke kan se, og mater det tilbake til den
• Odoo selv — tofaktorautentisering, passordpolicy, rettigheter, sesjonshåndtering
• Database & drift — sikkerhetskopi, tilgangsbeskyttelse for administrasjonen, hemmeligheter utenfor enhver logg

De følgende avsnittene går gjennom hvert lag for seg.

Lag 1: brannmur og reverse proxy

Brannmuren er den første instansen som ser en forespørsel, og den eneste som kan holde en angriper unna enhver tjeneste på serveren — ikke bare nettstedet, men også e-postserveren, VPN-tilgangen og det egne administrasjonsgrensesnittet. Hva som er fornuftig å aktivere her, avhenger av produsenten, men byggeformene er de samme hos OPNsense, pfSense, HAProxy, FortiGate, Sophos eller Check Point:

RBL-lister: standardveien for å levere omdømme

RBL står for Real-time Blackhole List, et begrep fra e-postverdenen: én adresse per linje, tilgjengelig via HTTP, lastet inn på nytt jevnlig. Praktisk talt enhver brannmur kan lese inn en slik liste og bygge regler av den — OPNsense og pfSense som URL Table Alias, HAProxy som ACL-fil, FortiGate som External Block List, Palo Alto som External Dynamic List, Cisco, Sophos, Juniper og MikroTik med egne navn på det samme prinsippet.

Akkurat her setter vår egen modul inn — og akkurat her begynner det andre laget.

Lag 2: Web RBL — broen mellom applikasjon og brannmur

En brannmur ser pakker, ikke applikasjonslogikk. Den vet ikke at en forespørsel etter /xmlrpc/2/common er et innloggingsforsøk, at tjue forskjellige stier på fjorten sekunder er en skanner, eller at en adresse akkurat har gjettet et passord. Alt dette vet bare Odoo selv. Web RBL, vår egen åpen kildekode-modul (AGPL-3), gjør denne kunnskapen brukbar — for Odoo selv og, levert som RBL-liste, også for brannmuren foran.

Trusselister som kontinuerlig avstemmes, hver med eget nivå.

Kort oppsummert det som er beskrevet utførlig i forrige innlegg:

• Mønstergjenkjenning i stier: .env-filer, .git-kataloger, konfigurasjonsfiler, WordPress- og PHP-sonder, sti-traversering, kommandokjøring via nye KI-grensesnitt
• Innloggingsforsvar som teller på tvers av omstarter — i motsetning til Odoos egen teller som lever i arbeidsminnet
• Vurdering av hver adresse fra 0 til 100, med begrunnelse i klartekst
• Feilkonfigurasjoner (QNAP, Autodiscover, Synology) gjenkjennes og blir aldri blokkert, fordi en blokkering ikke utbedrer feilen, men bare skjuler den
• Fremmede trusselister som Spamhaus, FireHOL og Tor-utgangsnoder, kontinuerlig avstemt
• Tillatelsesliste for adresser som aldri skal blokkeres

For dette innlegget er to egenskaper særlig viktige, fordi de henger direkte sammen med brannmuren og med innloggingen.

En treg liste er en liste man kan stole på

Tillatelseslisten — adresser som aldri blir blokkert, for eksempel egne stedstilkoblinger — endrer seg som regel sjelden. Akkurat det er dens verdi, ikke dens mangel: Når en rolig liste knapt beveger seg over dager, faller hver sjeldne endring umiddelbart i øynene. Den daglige automatiske oppdateringen finnes ikke fordi mye ville endre seg, men for at den sjeldne endringen ikke skal måtte føres inn for hånd — og akkurat det er punktet der man glemmer det. En av våre egne feilkonfigurasjoner forrige måned ble oppdaget akkurat slik: ikke gjennom mange hendelser, men gjennom den ene som ingen kjente til, helt til en kundes QNAP-web-API ved en feil ble blokkert. Siden den gang står QNAP på listen over feilkonfigurasjoner som aldri blokkeres, men bare rapporteres.

Innloggingen er stedet en brannmur ikke ser

En brannmur kan blokkere en adresse. Den kan ikke vite om en innlogging lyktes, og slett ikke om den kom fra en adresse som kort tid før fortsatt lette etter innloggingsdata. Web RBL kan: En vurdering fra en justerbar terskelverdi forbyr innloggingen helt, og en vellykket innlogging fra en mistenkelig adresse blir rapportert — det er leddet til neste lag.

Lag 3: sikre Odoo selv

Tofaktorautentisering: en andre hemmelighet som ikke kan gjenbrukes

Det største problemet med passord er ikke kvaliteten, men gjenbruken. Et passord som er stjålet hos en annen tjeneste, fungerer hos oss på akkurat samme måte, så lenge det er det samme. Tofaktorautentisering (2FA, også kalt TOTP) setter en andre hemmelighet opp mot dette: en sekssifret kode som endres hvert trettiende sekund — og beregnes ut fra en hemmelighet som bare den egne smarttelefonen kjenner. Et stjålet passord alene er dermed ikke lenger nok.

Odoo 19 Community har dette innebygd — som installerbar modul Two-Factor Authentication (TOTP), supplert med en e-post-reserveløsning. Hver bruker setter det opp selv, via QR-kode, med en hvilken som helst vanlig autentiseringsapp:

Oppsettet: skanne QR-koden, bekrefte den sekssifrede koden én gang, ferdig.

Men dette hjelper bare dem som setter det opp selv — og erfaring viser at uten tvang forblir de et mindretall. Odoo har derfor en håndhevingspolicy: enten bare for medarbeidere (interne brukere) eller for alle, portalbrukere inkludert. Uten en oppsatt andre hemmelighet kommer ingen lenger forbi innloggingsskjemaet uten i det minste å bekrefte med en e-postkode.

Passordpolicy: en minstelengde er ikke en selvfølge

Uten tilleggsmodul forholder Odoo Community seg ikke til noen minstelengde for passord — en bruker kan sette et passord på tre tegn hvis ingen hindrer vedkommende i det. Den egne Password Policy-modulen tetter akkurat dette hullet: en minstelengde som håndheves på serversiden, ikke bare foreslås i nettleseren. Den som vil ha mer — en påtvunget utløpstid, en historikk mot gjenbruk — trenger en OCA- eller tredjepartsmodul for det; Community-versjonen er bevisst holdt slank.

Rettigheter: bare den som trenger det, får tilgang

Odoo skiller fra fabrikken av mellom tre nivåer: portalbrukere (bare egen kunde- eller leverandørportal), interne brukere (backend, med rettigheter per applikasjon) og administratorer (ubegrenset tilgang inkludert tekniske innstillinger). Den vanligste feilen er ikke et for svakt passord, men en for sjenerøst tildelt administratorrolle: Den som bare skal skrive fakturaer, trenger ikke tilgang til systeminnstillingene.

To grunnprinsipper bærer mesteparten av lasten:

Begge deler kan kontrolleres i den samme visningen der tofaktorautentiseringen også settes opp:

Én oversikt, fire spaker: passord, andre faktor, API-nøkler, påloggede enheter.

Sesjoner og enheter: hvem er pålogget akkurat nå

Den samme visningen viser også fra hvilke enheter en konto er pålogget akkurat nå — og lar deg logge ut én enkelt eller alle på én gang. Etter en mistet bærbar PC eller mistanke om et kompromittert passord er dette det raskeste effektive trinnet: Sesjonen tar slutt umiddelbart, uavhengig av om passordet allerede er endret.

Lag 4: database og drift

Det fjerde laget er det minst synlige og samtidig det mest utilgivelige, fordi en feil her kan gjøre alt som er bygget opp før, til intet.

• Regelmessige, kontrollerte sikkerhetskopier, lagret atskilt fra selve serveren. En sikkerhetskopi som aldri er blitt gjenopprettet, er en antakelse, ikke en sikkerhetskopi.
• Hemmeligheter hører ikke hjemme i noen loggfil. Passord, API-nøkler, lisensdata — den som skriver egne utvidelser, bør behandle dem som selve hovedpassordet: ikke logge dem noe sted, heller ikke «bare for feilsøking».
• Hold moduler oppdatert, også og særlig tredjepartsmoduler. Frie tilleggsmoduler (OCA og andre) henger naturlig nok etter nye Odoo-versjoner; før hver installasjon lønner det seg å se hvilke avhengigheter som kommer med automatisk.

Innloggingsveien som helhet

De fire lagene virker ikke etter hverandre i atskilte rom, men på den samme forespørselen, trinn for trinn. Eksempelet med en innlogging gjør dette tydeligst:

Fem steder der en ondsinnet forespørsel kan ende før den når det egentlige målet — og bare ett eneste der en rettmessig bruker består dem alle.

Angrepsscenarier og forsvaret mot dem

Den følgende oversikten ordner virkelige angrepsmønstre etter lagene som faktisk stopper dem. Flere av dem er ikke teori, men våre egne observasjoner fra sytten dager med reell trafikk på våre fem nettsteder.

Trinn for trinn: sikre din egen Odoo-installasjon

Den følgende rekkefølgen er den vi selv ville gått frem etter — fra størst virkning til fineste innstilling.

1. Håndheve tofaktorautentisering

1. Hvis det ikke allerede er installert: åpne Apper, søk etter «Two-Factor Authentication» og installer (ved flere nettsteder anbefales i tillegg «Two-Factor Authentication by Mail» som reserveløsning).
2. Åpne Innstillinger → Generelle innstillinger → Rettigheter.
3. Aktiver «Håndheve tofaktorautentisering».
4. Velg policy: «Bare medarbeidere» for interne brukere, «Alle brukere» hvis også portalbrukere (kunder med tilgang) skal omfattes.
5. Lagre. Fra neste innloggingsforsøk krever Odoo av hver bruker uten oppsatt andre hemmelighet i det minste e-postkoden, helt til vedkommende har satt opp autentiseringsappen.

2. Fastsette en minstelengde for passord

1. Åpne Apper, søk etter «Password Policy» og installer.
2. Åpne Innstillinger → Generelle innstillinger → Rettigheter.
3. Sett «Minstelengde for passord» — tolv tegn er en fornuftig startverdi.
4. Lagre. Regelen gjelder fra nå av for hver ny eller endret passordtildeling, ikke med tilbakevirkende kraft for eksisterende passord.

3. Gjennomgå rettigheter

1. Åpne Innstillinger → Brukere & selskaper → Brukere.
2. Åpne hver bruker for seg og kontroller fanen med tilgangsrettighetene per applikasjon: Trenger denne personen virkelig «Manager» eller «Administrator», eller er «Bruker» nok?
3. Kontroller særlig: Hvem har tilgang til «Innstillinger» selv? Det bør være en svært liten gruppe.
4. For hver ekstern tilkobling (regnskap, egne skript, tidsregistrering) opprettes i fanen «Kontosikkerhet» hos den aktuelle tekniske brukeren en egen API-nøkkel, i stedet for å gi videre brukerpassordet.

4. Installere Web RBL og observere før den slås på for alvor

1. Legg modulen fra github.com/Alex0176/odoo-web-rbl i addon-stien og installer.
2. Observer i noen dager: menyen Web RBL → Analyse viser hvilke mønstre som faktisk slår til.
3. Slå først deretter på web_rbl.sperren_aktiv (Innstillinger → Teknisk → Systemparametere) — fra da av avvises gjenkjente sonder faktisk.
4. Bind blokkeringslisten på adressen som er oppgitt i modulen og er beskyttet med token, inn i brannmuren som RBL-liste (ved OPNsense/pfSense som URL Table Alias, ved HAProxy som ACL-fil).

5. Sikre selve brannmuren

1. Gjør administrasjonsgrensesnittet til brannmuren utelukkende tilgjengelig fra det interne nettet, aldri via den samme offentlige adressen som nettstedet.
2. Aktiver automatiske sikkerhetsoppdateringer for brannmurprogramvaren, såfremt produsenten tilbyr det.
3. Kontroller TLS-konfigurasjonen: bare gjeldende protokollversjoner, deaktiver utdaterte krypteringsmetoder.
4. Hvis tilgjengelig: bind inn en kjent omdømmeliste (for eksempel Spamhaus DROP) direkte på brannmuren — uavhengig av Web RBL, for da ser brannmuren også trafikk mot tjenester som Odoo aldri når.

6. Stenge databaseadministrasjonen

1. Kontroller om /web/database/manager er tilgjengelig utenfra — hvis ja, sett list_db = False i Odoo-konfigurasjonen eller steng stien på brannmurnivå.
2. Sett hovedpassordet til databaseadministrasjonen langt og tilfeldig, og noter det ikke noe sted der noen andre kan lese det.

7. Kontrollere sikkerhetskopien, ikke bare sette den opp

1. Sett opp en automatisk, regelmessig sikkerhetskopi, lagret atskilt fra Odoo-serveren.
2. Gjenopprett den faktisk minst én gang og kontroller om gjenopprettingen fungerer — en ukontrollert sikkerhetskopi er en antakelse.

Ingen av disse trinnene erstatter noen av de andre. Den som bare gjennomfører ett av dem, har forsterket én dør og latt alle de andre stå åpne — den som gjennomfører alle sju, har et forsvar som holder selv når ett enkelt lag svikter.

Hva denne arkitekturen ikke erstatter

Ingen av de beskrevne tiltakene gjør aktsomhet overflødig. En modul som avviser .env-sonder, gjør ikke en ved en feil publisert .env-fil ufarlig. Tofaktorautentisering beskytter ikke mot en bruker som leser koden sin opp for en som ringer på telefonen. Og en brannmur erstatter ikke en beslutning om hvem som faktisk trenger hvilken rettighet. Sikkerhetsarkitektur skaper betingelsene der en enkelt feil ikke umiddelbart blir en hendelse — den fritar ingen fra aktsomhet.

Ofte stilte spørsmål

Er et sterkt passord nok til å sikre Odoo 19?

Nei. Et passord kan bli stjålet et annet sted, helt uavhengig av kvaliteten, og fungerer da hos hver tjeneste som godtar det samme passordet. Først kombinasjonen med tofaktorautentisering, en brannmur foran og en fornuftig rettighetsstruktur gir en sikring som holder selv etter et stjålet passord.

Hvordan aktiverer jeg tofaktorautentisering i Odoo 19?

Installer modulen «Two-Factor Authentication (TOTP)» via apphåndteringen, aktiver deretter håndhevingen under Innstillinger → Generelle innstillinger → Rettigheter og velg mellom «Bare medarbeidere» og «Alle brukere». Hver bruker setter deretter opp sin egen andre faktor via QR-kode.

Hva er en RBL-liste, og hvorfor trenger Odoo en?

RBL (Real-time Blackhole List) er en adresseliste som kan hentes via HTTP, og som praktisk talt enhver brannmur kan lese inn. Odoo selv leverer ingen slik liste — vår modul Web RBL tetter dette hullet ved å gjenkjenne angrepstrafikk fra den egne applikasjonsloggen og gi den tilbake som RBL-liste til brannmuren foran.

Er Odoo 19 Community tilstrekkelig sikret uten tilleggsmoduler?

Ikke fullstendig. Uten modulen Password Policy finnes det ingen minstelengde for passord, uten Two-Factor Authentication ingen andre faktor, og uten en modul som Web RBL gjenkjenner Odoo verken sonderingsforsøk eller gjentatte innloggingsforsøk på tvers av en omstart. Alle fire kan ettermonteres gratis.

Tilgjengelighet

Web RBL er offentlig tilgjengelig under AGPL-3 og kjører produktivt hos oss på fem nettsteder:

github.com/Alex0176/odoo-web-rbl

Den fullstendige funksjonsbeskrivelsen med alle mønstre, vurderingen og trusselistene står i forrige innlegg: Web RBL – blokkeringsliste for angrepstrafikk på egne nettsteder.

Spørsmål, merknader og feilrapporter tar vi gjerne imot — helst som issue på GitHub.