Bezpečnostná architektúra Odoo 19: správna kombinácia firewallu, 2FA, oprávnení a Web RBL

Odoo je na našich piatich webových stránkach dostupné z otvoreného internetu, a to nie je výnimka, ale normálny stav: Kto prevádzkuje ponuku, obchod alebo zákaznícke prihlásenie, má verejný server. Stačí jediné zraniteľné heslo, zabudnutý konfiguračný súbor alebo príliš veľkorysé oprávnenie, aby sa z verejného servera stal otvorený.

Tento príspevok ukazuje, ako správne zabezpečiť Odoo 19 — nie jediným opatrením, ale niekoľkými vrstvami, ktoré sa navzájom dopĺňajú: firewall a reverzný proxy, náš open-source modul Web RBL, dvojfaktorové overenie, politika hesiel a oprávnenia — a ktoré pokusy o útok každá z nich skutočne zachytí. Na konci je návod krok za krokom, podľa ktorého možno postupovať pri každej vlastnej inštalácii Odoo.

Obrana do hĺbky: prečo jedno opatrenie nikdy nestačí

Každé jednotlivé bezpečnostné opatrenie má medzeru. Firewall nevidí, čo sa deje v prihlasovacom formulári Odoo. Silné heslo nechráni, ak bolo už inde ukradnuté. Štruktúra oprávnení nepomôže proti útočníkovi, ktorý sa ešte vôbec neprihlásil. Princíp, ktorý tieto medzery zaceľuje, sa volá obrana do hĺbky (defense in depth): niekoľko nezávislých vrstiev, z ktorých by sa každá samostatne dala obísť — ale všetky spolu práve nie.

U nás sú to štyri vrstvy, každá s inou úlohou:

• Firewall / reverzný proxy — drží ďalej zjavne škodlivé veci ešte skôr, než sa vôbec dostanú k serveru
• Web RBL — spája obe strany: Odoo sa z vlastného aplikačného protokolu učí to, čo firewall vôbec nemôže vidieť, a posiela to späť do neho
• Samotné Odoo — dvojfaktorové overenie, politika hesiel, oprávnenia, správa relácií
• Databáza & prevádzka — zálohovanie, ochrana prístupu k správe, tajomstvá mimo každého protokolu

Nasledujúce časti prechádzajú každú vrstvu zvlášť.

Vrstva 1: firewall a reverzný proxy

Firewall je prvá inštancia, ktorá vidí žiadosť, a jediná, ktorá dokáže držať útočníka ďalej od každej služby na serveri — nielen od webovej stránky, ale aj od poštového servera, prístupu VPN a vlastného administračného rozhrania. Čo sa na tomto mieste zmysluplne aktivuje, závisí od výrobcu, ale základné prvky sú pri OPNsense, pfSense, HAProxy, FortiGate, Sophos alebo Check Point rovnaké:

Zoznamy RBL: štandardná cesta, ktorou sa reputácia poskytuje

RBL znamená Real-time Blackhole List, pojem zo sveta e-mailov: jedna adresa na riadok, dostupná cez HTTP, pravidelne načítavaná znova. Prakticky každý firewall dokáže takýto zoznam načítať a vytvoriť z neho pravidlá — OPNsense a pfSense ako URL Table Alias, HAProxy ako súbor ACL, FortiGate ako External Block List, Palo Alto ako External Dynamic List, Cisco, Sophos, Juniper a MikroTik s vlastnými názvami pre ten istý princíp.

Presne tu nastupuje náš vlastný modul — a presne tu začína druhá vrstva.

Vrstva 2: Web RBL — most medzi aplikáciou a firewallom

Firewall vidí pakety, nie aplikačnú logiku. Nevie, že žiadosť o /xmlrpc/2/common je pokus o prihlásenie, že dvadsať rôznych ciest za štrnásť sekúnd je skener, alebo že nejaká adresa práve úspešne uhádla heslo. To všetko vie iba samotné Odoo. Web RBL, náš vlastný open-source modul (AGPL-3), túto znalosť sprístupňuje — pre samotné Odoo a, poskytovaný ako zoznam RBL, aj pre firewall pred ním.

Zoznamy hrozieb sa priebežne porovnávajú, každý s vlastnou úrovňou.

Stručné zhrnutie toho, čo je podrobne opísané v predchádzajúcom príspevku:

• Rozpoznávanie vzorov v cestách: súbory .env, adresáre .git, konfiguračné súbory, sondy WordPress a PHP, path traversal, spúšťanie príkazov cez nové rozhrania AI
• Obrana prihlásenia, ktorá počíta aj cez reštarty — na rozdiel od vlastného počítadla Odoo, ktoré žije v pamäti
• Hodnotenie každej adresy od 0 do 100, s odôvodnením čitateľne
• Chybné konfigurácie (QNAP, Autodiscover, Synology) sa rozpoznajú a nikdy sa neblokujú, pretože blokovanie chybu neodstráni, ale len zakryje
• Cudzie zoznamy hrozieb ako Spamhaus, FireHOL a výstupné uzly Tor, priebežne porovnávané
• Zoznam povolených adries pre adresy, ktoré sa nemajú nikdy blokovať

Pre tento príspevok sú dôležité najmä dve vlastnosti, pretože priamo súvisia s firewallom a s prihlásením.

Pomalý zoznam je zoznam, ktorému možno dôverovať

Zoznam povolených adries — adresy, ktoré sa nikdy neblokujú, napríklad vlastné pripojenia pobočiek — sa spravidla mení zriedka. Práve to je jeho hodnota, nie nedostatok: Ak sa pokojný zoznam počas dní sotva pohne, každá zriedkavá zmena okamžite upúta. Denné automatické dopĺňanie nejestvuje preto, že by sa veľa menilo, ale preto, aby sa zriedkavá zmena nemusela dopĺňať ručne — a práve to je miesto, kde sa na ňu zabúda. Jedna z našich vlastných chybných konfigurácií v minulom mesiaci sa odhalila presne takto: nie množstvom udalostí, ale tou jednou, ktorú nikto nepoznal, až kým sa omylom nezablokovalo webové API QNAP jedného zákazníka. Odvtedy je QNAP v zozname chybných konfigurácií, ktoré sa nikdy neblokujú, ale iba nahlasujú.

Prihlásenie je miesto, ktoré firewall nevidí

Firewall môže zablokovať adresu. Nemôže vedieť, či bolo prihlásenie úspešné, a už vôbec nie, či prišlo z adresy, ktorá krátko predtým ešte hľadala prístupové údaje. Web RBL to vie: Hodnotenie od nastaviteľnej prahovej hodnoty prihlásenie úplne zakáže a úspešné prihlásenie z nápadnej adresy sa nahlási — to je spojovací článok k ďalšej vrstve.

Vrstva 3: zabezpečenie samotného Odoo

Dvojfaktorové overenie: druhé tajomstvo, ktoré sa nedá znova použiť

Najväčším problémom hesiel nie je ich kvalita, ale ich opakované používanie. Heslo, ktoré bolo ukradnuté pri inej službe, funguje aj u nás rovnako, pokiaľ je rovnaké. Dvojfaktorové overenie (2FA, nazývané aj TOTP) proti tomu stavia druhé tajomstvo: šesťmiestny kód, ktorý sa mení každých tridsať sekúnd a vypočíta sa z tajomstva, ktoré pozná iba vlastný smartfón. Samotné ukradnuté heslo už teda nestačí.

Odoo 19 Community to má vstavané — ako inštalovateľný modul Two-Factor Authentication (TOTP), doplnený o záložnú možnosť cez e-mail. Každý používateľ si ho nastaví sám, pomocou QR kódu, s ľubovoľnou bežnou aplikáciou na overovanie:

Nastavenie: naskenovať QR kód, raz potvrdiť šesťmiestny kód, hotovo.

To však pomôže iba tým, ktorí si ho nastavia sami — a skúsenosť ukazuje, že bez nátlaku ich zostane menšina. Odoo preto pozná politiku vynútenia: buď iba pre zamestnancov (interných používateľov), alebo pre všetkých, vrátane používateľov portálu. Bez nastaveného druhého tajomstva sa už nikto nedostane za prihlasovací formulár bez toho, aby aspoň potvrdil kód zaslaný e-mailom.

Politika hesiel: minimálna dĺžka nie je samozrejmosťou

Bez dodatočného modulu sa Odoo Community nespolieha na žiadnu minimálnu dĺžku hesiel — používateľ môže nastaviť heslo z troch znakov, ak mu v tom nikto nezabráni. Vlastný modul Password Policy túto medzeru zaceľuje: minimálna dĺžka, ktorá sa vynucuje na strane servera, nielen odporúča v prehliadači. Kto chce viac — vynútenú dobu platnosti, históriu proti opätovnému použitiu — potrebuje na to modul OCA alebo od tretej strany; vo verzii Community je to zámerne udržiavané štíhle.

Oprávnenia: prístup dostane len ten, kto ho potrebuje

Odoo oddeľuje už od základu tri úrovne: používateľov portálu (iba vlastný zákaznícky alebo dodávateľský portál), interných používateľov (backend, s oprávneniami pre každú aplikáciu) a administrátorov (neobmedzený prístup vrátane technických nastavení). Najčastejšou chybou nie je príliš slabé heslo, ale príliš veľkoryso pridelená rola administrátora: Kto má iba vystavovať faktúry, nepotrebuje prístup k systémovým nastaveniam.

Dve zásady nesú najväčšiu záťaž:

Oboje sa dá skontrolovať v tom istom zobrazení, v ktorom sa nastavuje aj dvojfaktorové overenie:

Jeden prehľad, štyri páky: heslo, druhý faktor, kľúče API, prihlásené zariadenia.

Relácie a zariadenia: kto je práve prihlásený

To isté zobrazenie ukazuje aj to, z ktorých zariadení je účet práve prihlásený — a umožňuje odhlásiť jedno alebo všetky naraz. Po strate notebooku alebo pri podozrení na kompromitované heslo je to najrýchlejší účinný krok: Relácia sa skončí okamžite, bez ohľadu na to, či sa heslo už zmenilo.

Vrstva 4: databáza a prevádzka

Štvrtá vrstva je najmenej viditeľná a zároveň najneodpustiteľnejšia, pretože chyba tu môže zničiť všetko, čo sa predtým vybudovalo.

• Pravidelné, overené zálohy, uložené oddelene od samotného servera. Záloha, ktorá sa nikdy neobnovila, je domnienka, nie záloha.
• Tajomstvá nepatria do žiadneho súboru protokolu. Heslá, kľúče API, licenčné údaje — kto píše vlastné rozšírenia, mal by s nimi zaobchádzať ako so samotným hlavným heslom: nikde ich nezaznamenávať, ani „len na ladenie“.
• Udržiavať moduly aktuálne, aj a práve moduly tretích strán. Voľné doplnkové moduly (OCA a ďalšie) prirodzene zaostávajú za novými verziami Odoo; pred každou inštaláciou sa oplatí pozrieť, aké závislosti sa nainštalujú automaticky.

Prihlasovacia cesta ako celok

Štyri vrstvy nepôsobia postupne v oddelených miestnostiach, ale na tej istej žiadosti, stupeň za stupňom. Najjasnejšie je to vidieť na príklade prihlásenia:

Päť miest, na ktorých môže škodlivá žiadosť skončiť, skôr než dorazí k skutočnému cieľu — a len jediné, na ktorom ich oprávnený používateľ všetky prejde.

Scenáre útokov a obrana proti nim

Nasledujúci prehľad priraďuje reálne vzory útokov k vrstvám, ktoré ich skutočne zastavia. Viaceré z nich nie sú teória, ale vlastné pozorovania zo sedemnástich dní reálnej prevádzky na našich piatich webových stránkach.

Krok za krokom: zabezpečenie vlastnej inštalácie Odoo

Nasledujúce poradie je to, v ktorom by sme postupovali my sami — od najväčšieho účinku po najjemnejšie nastavenie.

1. Vynútiť dvojfaktorové overenie

1. Ak ešte nie je nainštalované: otvoriť Apps, vyhľadať „Two-Factor Authentication“ a nainštalovať (pri viacerých webových stránkach sa odporúča navyše „Two-Factor Authentication by Mail“ ako záložná možnosť).
2. Otvoriť Nastavenia → Všeobecné nastavenia → Oprávnenia.
3. Aktivovať „Vynútiť dvojfaktorové overenie“.
4. Zvoliť politiku: „Iba zamestnanci“ pre interných používateľov, „Všetci používatelia“, ak sa majú zahrnúť aj používatelia portálu (zákazníci s prístupom).
5. Uložiť. Od nasledujúceho pokusu o prihlásenie bude Odoo od každého používateľa bez nastaveného druhého tajomstva vyžadovať minimálne kód zaslaný e-mailom, kým si nenastaví aplikáciu na overovanie.

2. Stanoviť minimálnu dĺžku hesiel

1. Otvoriť Apps, vyhľadať „Password Policy“ a nainštalovať.
2. Otvoriť Nastavenia → Všeobecné nastavenia → Oprávnenia.
3. Nastaviť „Minimálna dĺžka hesla“ — dvanásť znakov je rozumná východisková hodnota.
4. Uložiť. Pravidlo platí odteraz pre každé nové alebo zmenené heslo, spätne neplatí pre existujúce heslá.

3. Skontrolovať oprávnenia

1. Otvoriť Nastavenia → Používatelia & spoločnosti → Používatelia.
2. Otvoriť každého používateľa zvlášť a skontrolovať záložku s prístupovými právami pre každú aplikáciu: Potrebuje táto osoba skutočne „Manažér“ alebo „Administrátor“, alebo stačí „Používateľ“?
3. Osobitne skontrolovať: Kto má prístup k samotným „Nastaveniam“? Mala by to byť veľmi malá skupina.
4. Pre každé externé napojenie (účtovníctvo, vlastné skripty, evidencia času) vytvoriť v záložke „Zabezpečenie účtu“ príslušného technického používateľa vlastný kľúč API, namiesto odovzdávania hesla používateľa.

4. Nainštalovať Web RBL a sledovať, než sa prepne naostro

1. Modul z github.com/Alex0176/odoo-web-rbl umiestniť do cesty addonov a nainštalovať.
2. Niekoľko dní sledovať: ponuka Web RBL → Vyhodnotenie ukazuje, ktoré vzory skutočne zaberajú.
3. Až potom zapnúť web_rbl.sperren_aktiv (Nastavenia → Technické → Systémové parametre) — odtiaľto sa rozpoznané sondy skutočne odmietajú.
4. Zoznam blokovaných adries zapojiť do firewallu ako zoznam RBL pod adresou uvedenou v module, chránenou tokenom (pri OPNsense/pfSense ako URL Table Alias, pri HAProxy ako súbor ACL).

5. Zabezpečiť samotný firewall

1. Administračné rozhranie firewallu sprístupniť výlučne z internej siete, nikdy cez tú istú verejnú adresu ako webová stránka.
2. Aktivovať automatické bezpečnostné aktualizácie softvéru firewallu, ak ich výrobca ponúka.
3. Skontrolovať konfiguráciu TLS: iba aktuálne verzie protokolov, zastarané šifrovacie postupy deaktivovať.
4. Ak je to k dispozícii: známy zoznam reputácie (napríklad Spamhaus DROP) zapojiť priamo na firewalle — nezávisle od Web RBL, pretože firewall tak vidí aj prevádzku k službám, ktoré Odoo nikdy nedosiahne.

6. Uzavrieť správu databáz

1. Skontrolovať, či je /web/database/manager dostupné zvonka — ak áno, v konfigurácii Odoo nastaviť list_db = False alebo cestu zablokovať na úrovni firewallu.
2. Hlavné heslo správy databáz nastaviť dlhé a náhodné a nezapisovať ho na žiadne miesto, ktoré by mohol čítať ktokoľvek iný.

7. Zálohu overiť, nielen nastaviť

1. Nastaviť automatickú, pravidelnú zálohu, uloženú oddelene od servera Odoo.
2. Aspoň raz ju skutočne obnoviť a skontrolovať, či obnova funguje — neoverená záloha je domnienka.

Žiadny z týchto krokov nenahrádza iný. Kto zavedie iba jeden z nich, posilnil jedny dvere a všetky ostatné nechal otvorené — kto zavedie všetkých sedem, má obranu, ktorá drží aj vtedy, keď zlyhá jedna vrstva.

Čo táto architektúra nenahrádza

Žiadne z opísaných opatrení nerobí starostlivosť zbytočnou. Modul, ktorý odmieta sondy na .env, neurobí z omylom zverejneného súboru .env neškodný súbor. Dvojfaktorové overenie nechráni pred používateľom, ktorý svoj kód prečíta volajúcemu do telefónu. A firewall nenahrádza rozhodnutie o tom, kto skutočne potrebuje aké oprávnenie. Bezpečnostná architektúra vytvára podmienky, za ktorých sa jediná chyba hneď nezmení na incident — nikoho však nezbavuje starostlivosti.

Časté otázky

Stačí silné heslo na zabezpečenie Odoo 19?

Nie. Heslo môže byť ukradnuté inde, úplne nezávisle od jeho kvality, a potom funguje pri každej službe, ktorá akceptuje to isté heslo. Až kombinácia s dvojfaktorovým overením, firewallom pred ním a zmysluplnou štruktúrou oprávnení vytvára zabezpečenie, ktoré drží aj po ukradnutí hesla.

Ako aktivujem dvojfaktorové overenie v Odoo 19?

Modul „Two-Factor Authentication (TOTP)“ nainštalovať cez správu Apps, potom v Nastavenia → Všeobecné nastavenia → Oprávnenia aktivovať vynútenie a vybrať medzi „Iba zamestnanci“ a „Všetci používatelia“. Každý používateľ si potom nastaví vlastný druhý faktor pomocou QR kódu.

Čo je zoznam RBL a prečo ho Odoo potrebuje?

RBL (Real-time Blackhole List) je zoznam adries dostupný cez HTTP, ktorý dokáže načítať prakticky každý firewall. Samotné Odoo takýto zoznam neposkytuje — náš modul Web RBL túto medzeru zaceľuje tým, že rozpoznáva útočnú prevádzku z vlastného aplikačného protokolu a vracia ju ako zoznam RBL predradenému firewallu.

Je Odoo 19 Community bez dodatočných modulov dostatočne zabezpečené?

Nie úplne. Bez modulu Password Policy neexistuje minimálna dĺžka hesiel, bez Two-Factor Authentication žiadny druhý faktor a bez modulu ako Web RBL Odoo nerozpoznáva ani pokusy o sondovanie, ani opakované pokusy o prihlásenie cez reštart. Všetky štyri sa dajú doplniť bezplatne.

Dostupnosť

Web RBL je verejne dostupný pod licenciou AGPL-3 a u nás beží produkčne na piatich webových stránkach:

github.com/Alex0176/odoo-web-rbl

Úplný popis funkcií so všetkými vzormi, hodnotením a zoznamami hrozieb je v predchádzajúcom príspevku: Web RBL – zoznam blokovaných adries pre útočnú prevádzku na vlastných webových stránkach.

Otázky, pripomienky a hlásenia chýb rád prijmeme — najradšej ako issue na GitHube.