Odoo 19 biztonsági architektúra: a tűzfal, a 2FA, a jogosultságok és a Web RBL helyes kombinálása

Az Odoo öt weboldalunkon elérhető a nyílt internetről, és ez nem kivétel, hanem a megszokott eset: aki ajánlatot, webshopot vagy ügyfélbejelentkezést üzemeltet, annak nyilvános szervere van. Egyetlen sebezhető jelszó, egy elfelejtett konfigurációs fájl vagy egy túl bőkezű jogosultság elég ahhoz, hogy a nyilvános szerverből nyitott szerver legyen.

Ez a cikk bemutatja, hogyan teheti biztonságossá az Odoo 19-et — nem egyetlen intézkedéssel, hanem több, egymást kiegészítő réteggel: tűzfal és fordított proxy, saját nyílt forráskódú modulunk, a Web RBL, a kétfaktoros hitelesítés, a jelszószabályzat és a jogosultságok — és hogy ezek közül melyik milyen támadási kísérletet fog el ténylegesen. A végén lépésről lépésre útmutató áll, amellyel bármely saját Odoo-telepítésen követhető a folyamat.

Mélységi védelem: miért nem elég soha egyetlen intézkedés

Minden egyes biztonsági intézkedésnek van egy rése. A tűzfal nem látja, mi történik egy Odoo-bejelentkezési űrlapon. Egy erős jelszó nem véd, ha már máshol ellopták. A jogosultsági struktúra nem segít egy olyan támadó ellen, aki még be sem jelentkezett. Az az elv, amely ezeket a réseket betömi, a mélységi védelem (defense in depth): több független réteg, amelyek mindegyike önmagában megkerülhető lenne — de mind együtt mégsem.

Nálunk négy réteg van, mindegyiknek más a feladata:

• Tűzfal / fordított proxy — távol tartja a nyilvánvalóan rosszindulatút, még mielőtt egyáltalán elérné a szervert
• Web RBL — összeköti a két oldalt: az Odoo a saját alkalmazásnaplójából megtanulja, amit a tűzfal egyáltalán nem láthat, és visszatáplálja neki
• Maga az Odoo — kétfaktoros hitelesítés, jelszószabályzat, jogosultságok, munkamenet-kezelés
• Adatbázis & üzemeltetés — mentés, a kezelőfelület hozzáférés-védelme, titkok minden naplón kívül tartása

A következő szakaszok egyenként végigmennek az egyes rétegeken.

1. réteg: tűzfal és fordított proxy

A tűzfal az első példány, amely egy kérést lát, és az egyetlen, amely a támadót a szerver minden szolgáltatásától távol tudja tartani — nemcsak a weboldaltól, hanem a levelezőszervertől, a VPN-hozzáféréstől és a saját kezelőfelülettől is. Hogy itt mi aktiválható értelmesen, az gyártótól függ, de a felépítések az OPNsense, pfSense, HAProxy, FortiGate, Sophos vagy Check Point esetében ugyanazok:

RBL-listák: a hírnév kiszolgálásának szabványos útja

Az RBL a Real-time Blackhole List rövidítése, a levelezés világából származó fogalom: soronként egy cím, HTTP-n keresztül lekérhető, rendszeresen újratöltve. Gyakorlatilag minden tűzfal be tud olvasni ilyen listát, és szabályokat épít belőle — az OPNsense és a pfSense URL Table Alias néven, a HAProxy ACL-fájlként, a FortiGate External Block List néven, a Palo Alto External Dynamic List néven, a Cisco, a Sophos, a Juniper és a MikroTik pedig saját elnevezésekkel ugyanarra az elvre.

Pontosan itt kapcsolódik be a saját modulunk — és pontosan itt kezdődik a második réteg.

2. réteg: Web RBL — a híd az alkalmazás és a tűzfal között

A tűzfal csomagokat lát, nem alkalmazáslogikát. Nem tudja, hogy egy /xmlrpc/2/common útvonalra irányuló kérés bejelentkezési kísérlet, hogy húsz különböző útvonal tizennégy másodperc alatt szkennert jelent, vagy hogy egy cím éppen sikeresen kitalált egy jelszót. Mindezt csak maga az Odoo tudja. Web RBL, saját nyílt forráskódú modulunk (AGPL-3), ezt a tudást használhatóvá teszi — magának az Odoónak, és RBL-listaként kiszolgálva az előtte álló tűzfalnak is.

Fenyegetési listák folyamatos egyeztetése, mindegyik saját szinttel.

Röviden összefoglalva, ami az előző cikkben részletesen le van írva:

• Mintafelismerés az útvonalakban: .env fájlok, .git könyvtárak, konfigurációs fájlok, WordPress- és PHP-szondák, útvonalbejárás, parancsvégrehajtás új MI-interfészeken keresztül
• Bejelentkezés-védelem, amely újraindításokon át is számol — az Odoo saját, a memóriában élő számlálójával ellentétben
• Minden cím értékelése 0-tól 100-ig, közérthető indoklással
• A hibás konfigurációkat (QNAP, Autodiscover, Synology) a rendszer felismeri, és soha nem tiltja, mert a tiltás nem szünteti meg a hibát, csak elrejti
• Idegen fenyegetési listák, mint a Spamhaus, a FireHOL és a Tor kilépőcsomópontok, folyamatosan egyeztetve
• Engedélyezőlista azokhoz a címekhez, amelyeket soha nem szabad tiltani

Ebben a cikkben két tulajdonság különösen fontos, mert közvetlenül összefüggnek a tűzfallal és a bejelentkezéssel.

A renyhe lista olyan lista, amelyben meg lehet bízni

Az engedélyezőlista — olyan címek, amelyeket soha nem tiltanak, például saját telephelyi kapcsolatok — általában ritkán változik. Éppen ez az értéke, nem a hiányossága: ha egy nyugodt lista napokon át alig mozdul, minden ritka változás azonnal feltűnik. A napi automatikus frissítés nem azért létezik, mert sok minden változna, hanem hogy a ritka változást ne kelljen kézzel pótolni — és éppen ez az a pont, ahol elfelejtik. A múlt hónapban az egyik saját hibás konfigurációnk pontosan így tűnt fel: nem sok esemény által, hanem az az egy által, amelyről addig senki sem tudott, amíg egy ügyfél QNAP webes API-ját tévesen ki nem tiltották. Azóta a QNAP szerepel a hibás konfigurációk listáján, amelyeket soha nem tiltanak, csak jelzik.

A bejelentkezés az a hely, amelyet a tűzfal nem lát

A tűzfal képes letiltani egy címet. Azt nem tudhatja, hogy egy bejelentkezés sikerült-e, és főleg azt nem, hogy olyan címről jött-e, amely röviddel korábban még hozzáférési adatokat keresett. A Web RBL igen: egy beállítható küszöbérték feletti értékelés teljesen megtiltja a bejelentkezést, és egy feltűnő címről érkező sikeres bejelentkezést a rendszer jelzi — ez a következő réteghez vezető kapocs.

3. réteg: magának az Odoónak a védelme

Kétfaktoros hitelesítés: egy második titok, amely nem használható újra

A jelszavak legnagyobb problémája nem a minőségük, hanem az újrahasznosításuk. Egy másik szolgáltatásnál ellopott jelszó nálunk is ugyanúgy működik, amíg ugyanaz. A kétfaktoros hitelesítés (2FA, más néven TOTP) egy második titkot állít ellene: egy hatjegyű kódot, amely harminc másodpercenként változik, és egy olyan titokból számítódik, amelyet csak a saját okostelefon ismer. Egy ellopott jelszó önmagában így már nem elég.

Az Odoo 19 Community ezt beépítve tartalmazza — telepíthető modulként, Two-Factor Authentication (TOTP) néven, kiegészítve egy e-mailes tartalék lehetőséggel. Minden felhasználó maga állítja be, QR-kóddal, bármely elterjedt hitelesítő alkalmazással:

A beállítás: QR-kód beolvasása, a hatjegyű kód egyszeri megerősítése, kész.

Ez azonban csak azoknak segít, akik maguktól beállítják — és a tapasztalat azt mutatja, hogy kényszer nélkül ők maradnak kisebbségben. Az Odoo ezért ismeri a kikényszerítési szabályt: vagy csak a munkatársakra (belső felhasználók), vagy mindenkire, a portálfelhasználókat is beleértve. Beállított második titok nélkül senki nem jut túl a bejelentkezési űrlapon anélkül, hogy legalább e-mailes kóddal megerősítené.

Jelszószabályzat: a minimális hossz nem magától értetődő

Kiegészítő modul nélkül az Odoo Community nem támaszkodik semmilyen minimális jelszóhosszra — egy felhasználó háromkarakteres jelszót is megadhat, ha senki nem akadályozza meg benne. A saját Password Policy modul éppen ezt a rést zárja be: egy kiszolgálóoldalon kikényszerített minimális hossz, nem csak a böngészőben javasolt. Aki többet akar — kikényszerített lejárati időt, az újrafelhasználás elleni előzményt —, ahhoz OCA- vagy harmadik féltől származó modul kell; a Community verzió ezt tudatosan karcsúan tartja.

Jogosultságok: csak az kap hozzáférést, akinek szüksége van rá

Az Odoo alapból három szintet különít el: portálfelhasználók (csak a saját ügyfél- vagy szállítói portál), belső felhasználók (a backend, alkalmazásonkénti jogokkal) és adminisztrátorok (korlátlan hozzáférés a technikai beállításokkal együtt). A leggyakoribb hiba nem a túl gyenge jelszó, hanem a túl bőkezűen kiosztott adminisztrátori szerep: aki csak számlákat készít, annak nincs szüksége hozzáférésre a rendszerbeállításokhoz.

Két alapelv viszi a legnagyobb terhet:

Mindkettő ellenőrizhető ugyanabban a nézetben, amelyben a kétfaktoros hitelesítést is beállítják:

Egy áttekintés, négy kar: jelszó, második faktor, API-kulcsok, bejelentkezett eszközök.

Munkamenetek és eszközök: ki van éppen bejelentkezve

Ugyanez a nézet azt is megmutatja, mely eszközökről van éppen bejelentkezve egy fiók — és lehetővé teszi, hogy egyet vagy az összeset egyszerre kijelentkeztessük. Elveszett laptop vagy egy kompromittált jelszó gyanúja esetén ez a leggyorsabb hatásos lépés: a munkamenet azonnal véget ér, attól függetlenül, hogy a jelszót már megváltoztatták-e.

4. réteg: adatbázis és üzemeltetés

A negyedik réteg a legkevésbé látható, és egyúttal a legmegbocsáthatatlanabb, mert itt egy hiba mindent tönkretehet, amit korábban felépítettünk.

• Rendszeres, ellenőrzött mentések, magától a szervertől elkülönítve tárolva. Egy mentés, amelyet soha nem állítottak vissza, feltételezés, nem mentés.
• A titkok egyetlen naplófájlba sem valók. Jelszavak, API-kulcsok, licencadatok — aki saját bővítményeket ír, kezelje őket úgy, mint magát a főjelszót: sehol ne naplózza őket, „csak hibakeresés céljából” sem.
• A modulok naprakészen tartása, különösen a harmadik féltől származó moduloké. A szabad kiegészítő modulok (OCA és mások) természetüknél fogva lemaradnak az új Odoo-verziók mögött; minden telepítés előtt érdemes megnézni, milyen függőségek települnek automatikusan.

A bejelentkezési út egészében

A négy réteg nem egymás után, elkülönített szobákban hat, hanem ugyanarra a kérésre, lépésről lépésre. Egy bejelentkezés példáján ez látszik a legjobban:

Öt hely, ahol egy rosszindulatú kérés véget érhet, mielőtt a tényleges célhoz érne — és csak egyetlen, ahol egy jogosult felhasználó mindegyiken átjut.

Támadási forgatókönyvek és az ellenük való védekezés

A következő áttekintés valós támadási mintákat rendel azokhoz a rétegekhez, amelyek ténylegesen megállítják őket. Ezek közül több nem elmélet, hanem saját megfigyelés: tizenhét nap éles forgalomból öt weboldalunkon.

Lépésről lépésre: a saját Odoo-telepítés biztonságossá tétele

A következő sorrend az, amelyben mi magunk is eljárnánk — a legnagyobb hatástól a legfinomabb beállításig.

1. A kétfaktoros hitelesítés kikényszerítése

1. Ha még nincs telepítve: nyissa meg az Alkalmazások menüt, keressen rá a „Two-Factor Authentication” modulra, és telepítse (több weboldal esetén ajánlott emellett a „Two-Factor Authentication by Mail” tartalék lehetőségként).
2. Nyissa meg a Beállítások → Általános beállítások → Jogosultságok menüpontot.
3. Aktiválja a „Kétfaktoros hitelesítés kikényszerítése” opciót.
4. Válassza ki a szabályt: „Csak munkatársak” a belső felhasználókhoz, „Minden felhasználó”, ha a portálfelhasználókat (hozzáféréssel rendelkező ügyfeleket) is be kell vonni.
5. Mentés. A következő bejelentkezési kísérlettől kezdve az Odoo minden olyan felhasználótól, akinek nincs beállított második titka, legalább az e-mailes kódot megköveteli, amíg be nem állítja a hitelesítő alkalmazást.

2. Minimális jelszóhossz meghatározása

1. Nyissa meg az Alkalmazások menüt, keressen rá a „Password Policy” modulra, és telepítse.
2. Nyissa meg a Beállítások → Általános beállítások → Jogosultságok menüpontot.
3. Állítsa be a „Jelszó minimális hossza” értéket — tizenkét karakter ésszerű kiindulópont.
4. Mentés. A szabály azonnal érvényes minden új vagy módosított jelszó megadására, a meglévő jelszavakra visszamenőleg nem.

3. Jogosultságok átnézése

1. Nyissa meg a Beállítások → Felhasználók & vállalatok → Felhasználók menüpontot.
2. Nyissa meg egyenként minden felhasználót, és ellenőrizze az alkalmazásonkénti hozzáférési jogokat tartalmazó fület: tényleg szüksége van ennek a személynek „Menedzser” vagy „Adminisztrátor” szintre, vagy elég a „Felhasználó”?
3. Különösen ellenőrizze: kinek van hozzáférése magukhoz a „Beállítások”-hoz? Ennek nagyon kis csoportnak kell lennie.
4. Minden külső kapcsolathoz (könyvelés, saját szkriptek, időrögzítés) hozzon létre a megfelelő technikai felhasználó „Fiókbiztonság” fülén egy saját API-kulcsot, ahelyett, hogy a felhasználó jelszavát adná tovább.

4. A Web RBL telepítése és megfigyelése éles bekapcsolás előtt

1. A modult innen töltheti le: github.com/Alex0176/odoo-web-rbl — helyezze az addon-útvonalba, és telepítse.
2. Figyelje néhány napig: a Web RBL → Kiértékelés menü megmutatja, mely minták ténylegesen találnak.
3. Csak ezután kapcsolja be a web_rbl.sperren_aktiv paramétert (Beállítások → Műszaki → Rendszerparaméterek) — ettől kezdve a felismert szondákat ténylegesen elutasítja a rendszer.
4. A tiltólistát a modulban megadott, tokennel védett címen építse be a tűzfalba RBL-listaként (OPNsense/pfSense esetén URL Table Alias, HAProxy esetén ACL-fájl).

5. Magának a tűzfalnak a védelme

1. A tűzfal kezelőfelületét kizárólag a belső hálózatról tegye elérhetővé, soha nem ugyanazon a nyilvános címen, mint a weboldalt.
2. Aktiválja az automatikus biztonsági frissítéseket a tűzfalszoftverhez, amennyiben a gyártó kínálja.
3. Ellenőrizze a TLS-konfigurációt: csak aktuális protokollverziók, az elavult titkosítási eljárásokat kapcsolja ki.
4. Ha elérhető: építsen be egy ismert hírnévlistát (például a Spamhaus DROP-ot) közvetlenül a tűzfalba — a Web RBL-től függetlenül, mert a tűzfal így az olyan szolgáltatásokhoz irányuló forgalmat is látja, amelyek az Odoót sosem érik el.

6. Az adatbázis-kezelés lezárása

1. Ellenőrizze, hogy a /web/database/manager kívülről elérhető-e — ha igen, állítsa be az Odoo konfigurációjában a list_db = False értéket, vagy tiltsa le az útvonalat tűzfalszinten.
2. Állítsa be az adatbázis-kezelés főjelszavát hosszúra és véletlenszerűre, és sehol ne jegyezze fel, ahol bárki más elolvashatja.

7. A mentés ellenőrzése, nem csak beállítása

1. Állítson be automatikus, rendszeres mentést, az Odoo-szervertől elkülönítve tárolva.
2. Legalább egyszer ténylegesen állítsa vissza, és ellenőrizze, hogy a helyreállítás működik-e — egy ellenőrizetlen mentés feltételezés.

E lépések egyike sem helyettesíti a többit. Aki közülük csak egyet valósít meg, az egy ajtót megerősített, és az összes többit nyitva hagyta — aki mind a hetet megvalósítja, annak olyan védelme van, amely akkor is tart, ha egyetlen réteg csődöt mond.

Amit ez az architektúra nem helyettesít

A leírt intézkedések egyike sem teszi feleslegessé a gondosságot. Egy modul, amely elutasítja a .env szondákat, nem teszi veszélytelenné a véletlenül közzétett .env fájlt. A kétfaktoros hitelesítés nem véd egy olyan felhasználótól, aki felolvassa a kódját egy telefonáló idegennek. És egy tűzfal nem helyettesíti annak eldöntését, hogy ki milyen jogosultságra van ténylegesen szüksége. A biztonsági architektúra megteremti azokat a feltételeket, amelyek között egyetlen hiba nem lesz rögtön incidens — a gondosságot senkitől sem veszi át.

Gyakori kérdések

Elég egy erős jelszó az Odoo 19 biztonságossá tételéhez?

Nem. Egy jelszót máshol is ellophatnak, minőségétől teljesen függetlenül, és akkor minden olyan szolgáltatásnál működik, amely ugyanazt a jelszót elfogadja. Csak a kétfaktoros hitelesítéssel, egy előtte álló tűzfallal és egy értelmes jogosultsági struktúrával együtt jön létre olyan védelem, amely egy ellopott jelszó után is tart.

Hogyan aktiválom a kétfaktoros hitelesítést az Odoo 19-ben?

Telepítse a „Two-Factor Authentication (TOTP)” modult az alkalmazáskezelőn keresztül, majd a Beállítások → Általános beállítások → Jogosultságok alatt aktiválja a kikényszerítést, és válasszon a „Csak munkatársak” és a „Minden felhasználó” között. Ezután minden felhasználó maga állítja be a saját második faktorát QR-kóddal.

Mi az az RBL-lista, és miért van rá szüksége az Odoónak?

Az RBL (Real-time Blackhole List) egy HTTP-n keresztül lekérhető címlista, amelyet gyakorlatilag minden tűzfal be tud olvasni. Maga az Odoo nem szállít ilyen listát — a Web RBL modulunk ezt a rést zárja be azzal, hogy a támadó forgalmat a saját alkalmazásnaplóból felismeri, és RBL-listaként visszaadja az előtte álló tűzfalnak.

Elég biztonságos az Odoo 19 Community kiegészítő modulok nélkül?

Nem teljesen. A Password Policy modul nélkül nincs minimális jelszóhossz, a Two-Factor Authentication nélkül nincs második faktor, és egy olyan modul nélkül, mint a Web RBL, az Odoo sem a szondázási kísérleteket, sem az újraindításon átívelő ismételt bejelentkezési kísérleteket nem ismeri fel. Mind a négy ingyenesen pótolható.

Elérhetőség

A Web RBL AGPL-3 licenc alatt nyilvánosan elérhető, és nálunk éles üzemben fut öt weboldalon:

github.com/Alex0176/odoo-web-rbl

A teljes funkcióleírás az összes mintával, az értékeléssel és a fenyegetési listákkal az előző cikkben található: Web RBL – tiltólista a saját weboldalakat érő támadó forgalom ellen.

Kérdéseket, észrevételeket és hibajelentéseket szívesen fogadunk — a legszívesebben GitHub-issue formájában.