Varnostna arhitektura Odoo 19: pravilna kombinacija požarnega zidu, 2FA, pooblastil in Web RBL

Odoo je na naših petih spletnih straneh dosegljiv iz odprtega interneta, in to ni izjema, ampak običajen primer: kdor upravlja ponudbo, spletno trgovino ali prijavo strank, ima javni strežnik. Zadošča eno samo ranljivo geslo, ena pozabljena konfiguracijska datoteka ali eno preveč radodarno pooblastilo, da iz javnega strežnika nastane odprt.

Ta prispevek prikazuje, kako pravilno zaščitite Odoo 19 — ne z enim samim ukrepom, temveč z več plastmi, ki se medsebojno dopolnjujejo: požarni zid in povratni posrednik (reverse proxy), naš odprtokodni modul Web RBL, dvofaktorska overitev, pravilnik o geslih in pooblastila — ter katere poskuse napada vsaka od njih dejansko prestreže. Na koncu so navodila po korakih, po katerih je mogoče posnemati vsako lastno namestitev Odoo.

Obramba v globino: zakaj en ukrep nikoli ne zadošča

Vsak posamezen varnostni ukrep ima vrzel. Požarni zid ne vidi, kaj se dogaja v prijavni maski Odoo. Močno geslo ne ščiti, če je bilo drugje že ukradeno. Struktura pooblastil ne pomaga proti napadalcu, ki se sploh še ni prijavil. Načelo, ki te vrzeli zapre, se imenuje obramba v globino (defense in depth): več neodvisnih plasti, od katerih bi bilo vsako posamezno mogoče zaobiti — vse skupaj pa ravno ne.

Pri nas so štiri plasti, vsaka z drugo nalogo:

• Požarni zid / povratni posrednik — odganja očitno zlonamerno, še preden sploh doseže strežnik
• Web RBL — povezuje obe strani: Odoo se iz lastnega aplikacijskega dnevnika nauči tistega, česar požarni zid sploh ne more videti, in mu to posreduje nazaj
• Sam Odoo — dvofaktorska overitev, pravilnik o geslih, pooblastila, upravljanje sej
• Baza podatkov & obratovanje — varnostno kopiranje, zaščita dostopa do upravljanja, skrivnosti zunaj vsakega dnevnika

V naslednjih razdelkih obravnavamo vsako plast posebej.

Plast 1: požarni zid in povratni posrednik

Požarni zid je prva instanca, ki vidi poizvedbo, in edina, ki lahko napadalca odvrne od vsake storitve na strežniku — ne le od spletne strani, temveč tudi od poštnega strežnika, dostopa VPN in lastnega upravljalskega vmesnika. Kaj je na tem mestu smiselno vklopiti, je odvisno od proizvajalca, vendar so oblike pri OPNsense, pfSense, HAProxy, FortiGate, Sophos ali Check Point enake:

Seznami RBL: standardna pot, po kateri se dostavlja ugled

RBL pomeni Real-time Blackhole List, izraz iz sveta e-pošte: en naslov v vrstici, dostopen prek HTTP, redno znova naložen. Praktično vsak požarni zid lahko prebere tak seznam in iz njega ustvari pravila — OPNsense in pfSense kot URL Table Alias, HAProxy kot datoteko ACL, FortiGate kot External Block List, Palo Alto kot External Dynamic List, Cisco, Sophos, Juniper in MikroTik z lastnimi imeni za isto načelo.

Prav tu se začne naš lasten modul — in prav tu se začne druga plast.

Plast 2: Web RBL — most med aplikacijo in požarnim zidom

Požarni zid vidi pakete, ne aplikacijske logike. Ne ve, da je poizvedba po /xmlrpc/2/common poskus prijave, da je dvajset različnih poti v štirinajstih sekundah skener, ali da je neki naslov pravkar uspešno uganil geslo. Vse to ve samo Odoo sam. Web RBL, naš lasten odprtokodni modul (AGPL-3), to znanje naredi uporabno — za sam Odoo in, dostavljen kot seznam RBL, tudi za požarni zid pred njim.

Seznami groženj se sproti primerjajo, vsak z lastno stopnjo.

Na kratko povzeto, kar je v prejšnjem prispevku podrobno opisano:

• Prepoznavanje vzorcev v poteh: datoteke .env, imeniki .git, konfiguracijske datoteke, sonde WordPress in PHP, path traversal, izvajanje ukazov prek novih vmesnikov umetne inteligence
• Obramba prijave, ki šteje prek ponovnih zagonov — drugače kot Odoojev lastni števec, ki živi v delovnem pomnilniku
• Ocena vsakega naslova od 0 do 100, z obrazložitvijo v jasnem besedilu
• Napačne konfiguracije (QNAP, Autodiscover, Synology) se prepoznajo in nikoli ne blokirajo, ker blokada napake ne odpravi, ampak jo le skrije
• Tuji seznami groženj, kot so Spamhaus, FireHOL in izhodna vozlišča Tor, sproti primerjani
• Seznam izjem za naslove, ki se ne smejo nikoli blokirati

Za ta prispevek sta zlasti pomembni dve lastnosti, ker sta neposredno povezani s požarnim zidom in s prijavo.

Počasen seznam je seznam, ki mu je mogoče zaupati

Seznam izjem — naslovi, ki se nikoli ne blokirajo, na primer lastne povezave lokacij — se praviloma spreminja redko. Prav to je njegova vrednost, ne pomanjkljivost: če se miren seznam skozi dneve komaj premakne, vsaka redka sprememba takoj pade v oči. Dnevno samodejno posodabljanje ne obstaja zato, ker bi se veliko spreminjalo, ampak zato, da redke spremembe ni treba ročno dopolnjevati — in prav tu je točka, kjer jo pozabimo. Ena naših lastnih napačnih konfiguracij se je v preteklem mesecu pokazala ravno tako: ne z mnogimi dogodki, temveč z enim, ki ga nihče ni poznal, dokler ni bil spletni API QNAP neke stranke napačno blokiran. Od takrat je QNAP na seznamu napačnih konfiguracij, ki se nikoli ne blokirajo, temveč se samo javijo.

Prijava je mesto, ki ga požarni zid ne vidi

Požarni zid lahko blokira naslov. Ne more pa vedeti, ali je bila prijava uspešna, še manj, ali je prišla z naslova, ki je malo prej še iskal dostopne podatke. Web RBL to zna: ocena nad nastavljivim pragom prijavo povsem prepove, uspešna prijava s sumljivega naslova pa se javi — to je vez do naslednje plasti.

Plast 3: zaščita samega Odoo

Dvofaktorska overitev: druga skrivnost, ki je ni mogoče ponovno uporabiti

Največja težava gesel ni njihova kakovost, temveč ponovna uporaba. Geslo, ukradeno pri drugi storitvi, pri nas deluje enako, dokler je isto. Dvofaktorska overitev (2FA, imenovana tudi TOTP) temu nasproti postavi drugo skrivnost: šestmestno kodo, ki se spreminja vsakih trideset sekund in se izračuna iz skrivnosti, ki jo pozna samo lastni pametni telefon. Samo ukradeno geslo tako ne zadošča več.

Odoo 19 Community to prinaša vgrajeno — kot namestljiv modul Two-Factor Authentication (TOTP), dopolnjen z nadomestno možnostjo prek e-pošte. Vsak uporabnik ga nastavi sam zase, s kodo QR, s katero koli običajno aplikacijo za overjanje:

Nastavitev: skenirajte kodo QR, enkrat potrdite šestmestno kodo, končano.

To pa pomaga samo tistim, ki si jo nastavijo sami — in izkušnje kažejo, da to brez prisile ostane manjšina. Odoo zato pozna pravilnik o obveznosti: bodisi samo za zaposlene (notranji uporabniki) bodisi za vse, vključno s portalskimi uporabniki. Brez nastavljene druge skrivnosti nihče več ne pride mimo prijavne maske, ne da bi vsaj potrdil kodo prek e-pošte.

Pravilnik o geslih: najmanjša dolžina ni samoumevna

Brez dodatnega modula Odoo Community ne zahteva nobene najmanjše dolžine gesel — uporabnik lahko določi geslo iz treh znakov, če ga nihče ne ovira. Lasten modul Password Policy zapre prav to vrzel: najmanjša dolžina, ki se uveljavlja na strani strežnika, ne le predlaga v brskalniku. Kdor želi več — vsiljen rok veljavnosti, zgodovino proti ponovni uporabi — za to potrebuje modul OCA ali tretje osebe; v različici Community je to namenoma skromno.

Pooblastila: dostop dobi samo, kdor ga potrebuje

Odoo že po naravi ločuje tri ravni: portalske uporabnike (samo lastni portal za stranke ali dobavitelje), notranje uporabnike (zaledje, s pravicami po aplikaciji) in skrbnike (neomejen dostop vključno s tehničnimi nastavitvami). Najpogostejša napaka ni preveč šibko geslo, temveč preveč radodarno dodeljena vloga skrbnika: kdor mora le izdajati račune, ne potrebuje dostopa do sistemskih nastavitev.

Dve načeli nosita največ bremena:

Oboje je mogoče preveriti v istem pogledu, v katerem se nastavi tudi dvofaktorska overitev:

En pregled, štirje vzvodi: geslo, drugi faktor, ključi API, prijavljene naprave.

Seje in naprave: kdo je trenutno prijavljen

Isti pogled prikazuje tudi, iz katerih naprav je račun trenutno prijavljen — in omogoča odjavo posamezne ali vseh naenkrat. Po izgubljenem prenosniku ali pri sumu na ogroženo geslo je to najhitrejši učinkovit korak: seja se konča takoj, ne glede na to, ali je bilo geslo že spremenjeno.

Plast 4: baza podatkov in obratovanje

Četrta plast je najmanj vidna in hkrati najbolj neodpustljiva, ker lahko napaka tu uniči vse, kar je bilo prej zgrajeno.

• Redne, preverjene varnostne kopije, shranjene ločeno od samega strežnika. Varnostna kopija, ki je nikoli nismo obnovili, je domneva, ne varnostna kopija.
• Skrivnosti ne sodijo v nobeno dnevniško datoteko. Gesla, ključi API, licenčni podatki — kdor piše lastne razširitve, naj jih obravnava kot glavno geslo samo: nikjer jih ne beležiti, tudi „samo za razhroščevanje“ ne.
• Module redno posodabljajte, tudi in zlasti module tretjih oseb. Prosti dodatni moduli (OCA in drugi) novim različicam Odoo po naravi zaostajajo; pred vsako namestitvijo se splača pogledati, katere odvisnosti pridejo samodejno zraven.

Pot prijave kot celota

Štiri plasti ne delujejo ena za drugo v ločenih prostorih, temveč na isti poizvedbi, stopnja za stopnjo. Na primeru prijave je to najbolj očitno:

Pet mest, na katerih se lahko zlonamerna poizvedba konča, preden doseže pravi cilj — in samo eno, na katerem jih upravičen uporabnik vse opravi.

Scenariji napadov in obramba pred njimi

Naslednji pregled razvršča resnične vzorce napadov po plasteh, ki jih dejansko ustavijo. Več od njih ni teorija, temveč lastna opažanja iz sedemnajstih dni pravega prometa na naših petih spletnih straneh.

Korak za korakom: zaščita lastne namestitve Odoo

Naslednji vrstni red je tisti, po katerem bi postopali sami — od največjega učinka do najfinejše nastavitve.

1. Uveljavite dvofaktorsko overitev

1. Če še ni nameščeno: odprite Apps, poiščite „Two-Factor Authentication“ in namestite (pri več spletnih straneh priporočamo dodatno „Two-Factor Authentication by Mail“ kot nadomestno možnost).
2. Odprite Nastavitve → Splošne nastavitve → Pooblastila.
3. Vklopite „Uveljavi dvofaktorsko overitev“.
4. Izberite pravilnik: „Samo zaposleni“ za notranje uporabnike, „Vsi uporabniki“, če naj bodo vključeni tudi portalski uporabniki (stranke z dostopom).
5. Shranite. Od naslednjega poskusa prijave Odoo od vsakega uporabnika brez nastavljene druge skrivnosti zahteva vsaj kodo po e-pošti, dokler ne nastavi aplikacije za overjanje.

2. Določite najmanjšo dolžino gesel

1. Odprite Apps, poiščite „Password Policy“ in namestite.
2. Odprite Nastavitve → Splošne nastavitve → Pooblastila.
3. Nastavite „Najmanjša dolžina gesla“ — dvanajst znakov je smiselna izhodiščna vrednost.
4. Shranite. Pravilo velja od zdaj naprej za vsako novo ali spremenjeno določitev gesla, ne velja za obstoječa gesla za nazaj.

3. Preglejte pooblastila

1. Odprite Nastavitve → Uporabniki & podjetja → Uporabniki.
2. Odprite vsakega uporabnika posebej in preverite zavihek s pravicami dostopa po aplikaciji: Ali ta oseba res potrebuje „Upravitelj“ ali „Skrbnik“, ali zadošča „Uporabnik“?
3. Še posebej preverite: Kdo ima dostop do samih „Nastavitev“? To bi morala biti zelo majhna skupina.
4. Za vsako zunanjo povezavo (računovodstvo, lastni skripti, beleženje časa) v zavihku „Varnost računa“ posameznega tehničnega uporabnika ustvarite lasten ključ API, namesto da posredujete uporabniško geslo.

4. Namestite Web RBL in opazujte, preden ga vklopite v polni moči

1. Modul od github.com/Alex0176/odoo-web-rbl položite v pot za dodatke (addon) in namestite.
2. Nekaj dni opazujte: meni Web RBL → Analiza pokaže, kateri vzorci dejansko delujejo.
3. Šele nato vklopite web_rbl.sperren_aktiv (Nastavitve → Tehnično → Sistemski parametri) — od tu naprej se prepoznane sonde dejansko zavračajo.
4. Seznam blokiranih naslovov na naslovu, ki je naveden v modulu in zaščiten z žetonom, vključite v požarni zid kot seznam RBL (pri OPNsense/pfSense kot URL Table Alias, pri HAProxy kot datoteko ACL).

5. Zaščitite sam požarni zid

1. Upravljalski vmesnik požarnega zidu naredite dosegljiv izključno iz notranjega omrežja, nikoli prek istega javnega naslova kot spletna stran.
2. Vklopite samodejne varnostne posodobitve za programsko opremo požarnega zidu, če proizvajalec to ponuja.
3. Preverite konfiguracijo TLS: samo aktualne različice protokolov, zastarele šifrirne postopke izklopite.
4. Če je na voljo: znan seznam ugleda (na primer Spamhaus DROP) vključite neposredno na požarnem zidu — neodvisno od Web RBL, saj požarni zid tako vidi tudi promet do storitev, ki jih Odoo nikoli ne doseže.

6. Zaprite upravljanje baz podatkov

1. Preverite, ali je /web/database/manager dosegljiv od zunaj — če je, v konfiguraciji Odoo nastavite list_db = False ali pot blokirajte na ravni požarnega zidu.
2. Glavno geslo upravljanja baz podatkov nastavite dolgo in naključno ter ga nikjer ne zapišite, kjer bi ga lahko prebral kdor koli drug.

7. Preverite varnostno kopijo, ne le nastavite je

1. Nastavite samodejno, redno varnostno kopiranje, shranjeno ločeno od strežnika Odoo.
2. Vsaj enkrat jo dejansko obnovite in preverite, ali obnovitev deluje — nepreverjena varnostna kopija je domneva.

Noben od teh korakov ne nadomešča drugega. Kdor izvede samo enega, je okrepil ena vrata, vsa druga pa pustil odprta — kdor izvede vseh sedem, ima obrambo, ki zdrži tudi takrat, ko ena sama plast odpove.

Česa ta arhitektura ne nadomešča

Noben od opisanih ukrepov ne naredi skrbnosti odveč. Modul, ki zavrača sonde .env, po pomoti objavljene datoteke .env ne naredi neškodljive. Dvofaktorska overitev ne ščiti pred uporabnikom, ki svojo kodo prebere klicatelju po telefonu. In požarni zid ne nadomešča odločitve o tem, kdo dejansko potrebuje katero pooblastilo. Varnostna arhitektura ustvari pogoje, v katerih posamezna napaka ne postane takoj incident — nikomur ne odvzame skrbnosti.

Pogosta vprašanja

Ali močno geslo zadošča za zaščito Odoo 19?

Ne. Geslo je mogoče ukrasti drugje, povsem neodvisno od njegove kakovosti, in nato deluje pri vsaki storitvi, ki sprejme isto geslo. Šele kombinacija z dvofaktorsko overitvijo, požarnim zidom pred njim in smiselno strukturo pooblastil da zaščito, ki zdrži tudi po ukradenem geslu.

Kako vklopim dvofaktorsko overitev v Odoo 19?

Modul „Two-Factor Authentication (TOTP)“ namestite prek upravljanja Apps, nato pod Nastavitve → Splošne nastavitve → Pooblastila vklopite uveljavitev in izberite med „Samo zaposleni“ in „Vsi uporabniki“. Vsak uporabnik nato sam nastavi svoj drugi faktor s kodo QR.

Kaj je seznam RBL in zakaj ga Odoo potrebuje?

RBL (Real-time Blackhole List) je seznam naslovov, dostopen prek HTTP, ki ga lahko prebere praktično vsak požarni zid. Odoo sam takega seznama ne vsebuje — naš modul Web RBL to vrzel zapre tako, da iz lastnega aplikacijskega dnevnika prepozna napadalni promet in ga kot seznam RBL vrne požarnemu zidu pred njim.

Ali je Odoo 19 Community brez dodatnih modulov dovolj zaščiten?

Ne povsem. Brez modula Password Policy ni najmanjše dolžine gesel, brez Two-Factor Authentication ni drugega faktorja, brez modula, kot je Web RBL, pa Odoo ne prepozna niti poskusov sondiranja niti ponavljajočih se poskusov prijave prek ponovnega zagona. Vse štiri je mogoče brezplačno dograditi.

Razpoložljivost

Web RBL je javno na voljo pod licenco AGPL-3 in pri nas produktivno teče na petih spletnih straneh:

github.com/Alex0176/odoo-web-rbl

Celoten opis funkcij z vsemi vzorci, oceno in seznami groženj je v prejšnjem prispevku: Web RBL – seznam blokiranih naslovov za napadalni promet na lastnih spletnih straneh.

Vprašanja, pripombe in poročila o napakah sprejemamo z veseljem — najraje kot Issue na GitHubu.