Odoo 19 Community: Web RBL – tiltólista a saját weboldalakat érő támadási forgalom ellen

Forráskód: github.com/Alex0176/odoo-web-rbl — AGPL-3, szabadon felhasználható.

Aki egy Odoo-szervert üzemeltet az interneten, látogatást kap. Nem alkalmanként, hanem megszakítás nélkül. Tizenhét napon át öt weboldalunkon 731.297 kérést naplóztunk és értékeltünk ki. Ebből 110.511 nem látogató volt, hanem automatizált keresés sebezhetőségek, hozzáférési adatok és konfigurációs fájlok után.

Ez a bejegyzés a Web RBL-t írja le, egy nyílt forráskódú modult az Odoo 19 Community-hez, amely felismeri, értékeli, könyveli és elutasítja ezt a forgalmat – és amely a tiltólistát RBL-listaként tesz közzé, vagyis olyan formátumban, amelyet a tűzfalak és reverse proxyk közvetlenül olvasnak. Minden szám éles üzemből származik.

Mit tud a modul — a funkciók áttekintése

Funkció	Mit csinál	Kiszolgálás
Mintafelismerés	Felismeri a szondázásokat az útvonal és a kiterjesztés alapján: .env, .git, konfigurációs fájlok, felhőkulcsok, CI/CD-építési utasítások, WordPress, PHP, útvonal-bejárás (path traversal), adatbázis-kezelők, GraphQL, parancsvégrehajtás a /api/fs/exec és hasonló interfészeken keresztül	letiltás
Három szint mintánként	letiltás, számlálás vagy jelentés — mintánként átállítható, kód nélkül	mintánként
Küszöbök	Ugyanazon minta ennyi találata, mielőtt letiltás történik; bejelentkezéseknél tíz	10 bejelentkezésnél
Bejelentkezés-védelem	Sikertelen bejelentkezések a felületen és XML-RPC/JSON-RPC-n keresztül, sikertelen munkamenet-ellenőrzések, hozzáférések az adatbázis-kezelőhöz — az adatbázisban, nem a memóriában	be
Botfelismerés a bejelentkezésnél	Aki tíz sikertelen kísérlet után figyelmen kívül hagyja a várakoztató üzenetet, és tovább próbálkozik, azonnal letiltásra kerül	letiltás
Viselkedésfelismerés	Azok a címek, amelyek öt perc alatt húsz hibás oldalt és alig egy találati oldalt generálnak — vagyis találgatnak, nem olvasnak	jelentés
Értékelés 0–100	Mennyire biztos, hogy a cím mögött támadó áll? A minta súlyosságából, a különböző minták számából, feltűnő napokból, érintett domainekből és a találatok számából — nyílt szöveges indoklással	be
Bejelentkezési tiltás értékelés alapján	Egy beállítható értékeléstől a bejelentkezés tiltott, a weboldal olvasható marad	40-től
Gyanú ellopott hozzáférési adatokra	Egy gyanús címről érkező sikeres bejelentkezést a rendszer jelzi, és kérésre feladatként kiosztja — címenként és naponta egyszer	be
Fenyegetési listák	Tor kilépőcsomópontok, Spamhaus DROP, FireHOL Level 1, blocklist.de előre beállítva; bármely további RBL-lista címmel felvehető, napi egyeztetés, listánként külön szint	jelentés
Nincs hozzáférés a bejelentkezéshez	A negyedik szint listákhoz és országokhoz: a weboldal olvasható, a bejelentkezési űrlap és az interfészek zárva — a megfelelő válasz a Torra	Opció
Származási ország	Ország találatonként és címenként a GeoLite2 segítségével; az adatbázist a modul egy ingyenes licenckulccsal maga frissíti	megjelenítés
Országszabályok	Tiltás, nincs hozzáférés a bejelentkezéshez, jelentés vagy kifejezetten engedélyezés — országonként, tudatosan alapértelmezés nélkül	nincs
Hibás konfigurációk	A QNAP, Synology, Exchange Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV kéréseket a rendszer felismeri, soha nem tiltja, és a megállapítással és az érintett domainnel együtt munkalistára teszi	jelentés
Jegy címenként	Egy megállapításból kérésre jegy lesz — címenként pontosan egy; a lezárt jegy újra megnyílik, nem duplázódik	ki
Kötelező oldalak és gyűjtők	A kanonikus impresszum-útvonal mindig elérhető marad; idegen írásmódok gépi kipróbálgatását a rendszer felismeri, és kérésre tiltja	jelentés
Engedélyezőlista	Címek és hálózatok, amelyeket soha nem tiltanak; naponta feltöltődik a tűzfalból (VPN-ellenállomások), valamint a Googlebot és a Bingbot közzétett címtartományaiból	be
Ügyfélhozzárendelés	Az ügyfél hálózatából érkező találatot a rendszer hozzárendeli az ügyfélhez — az engedélyezőlista alapján, soha nem találgatásból	be
Domain és azonosító találatonként	Melyik weboldalt kérték le, milyen User-Agenttel — mindkettő hiányzik a hozzáférési naplóból	be
Kiértékelés	Diagram és pivot az összes találatról: mintánként, naponta, domainenként, országonként, címenként	be
Csali	A szondák kitalált válaszokat kapnak kanári-értékkel; aki ezt később lekéri, az elolvasta a választ	ki
RBL-kiszolgálás	A tiltólista egyszerű címlistaként vagy JSON-ként, saját, tokennel védett címen — HAProxyhoz, OPNsense-hez és minden olyan tűzfalhoz, amely URL-listákat olvas	be

Minden, ami jelentés, ki vagy opció beállítással kerül kiszállításra, tudatos döntés: aki éles tiltást kapcsol be, tegye azt azért, mert néhány napig figyelte a működést, aki a rendszer hatálya alá esik — nem azért, mert az alapértelmezés ezt írta elő.

A kiértékelés: találatok mintánként hét napra. A legmagasabb oszlop a .env fájlok keresése.

RBL-listák: szabványos módszer a tiltások kiszolgálására

Az RBL a Real-time Blackhole List rövidítése. A kifejezés a levelezés világából származik, ahol a Spamhaus és mások a kilencvenes évek óta közzéteszik a rosszindulatú feladócímek listáit. Az elv rendkívül egyszerű, és éppen ezért olyan elterjedt: soronként egy cím, HTTP-n keresztül lekérhető, rendszeresen újratöltve. Nincs formátum, amit először értelmezni kell, nincs interfész, amihez külön eszköz kellene.

Gyakorlatilag minden tűzfal és minden fordított proxy be tudja olvasni az ilyen listát, és szabályokat épít belőle. A gyártók különbözőképpen nevezik, a mechanizmus mindenhol ugyanaz:

• OPNsense és pfSense — URL Table Alias: a címlista betöltése HTTP-n keresztül, használata aliasként a tűzfalszabályokban, frissítés óránként vagy naponta
• HAProxy — ACL-fájlok és Maps: src -f sperrliste.txt egy http-request deny szabályban, újratölthető a futásidejű API-n keresztül újraindítás nélkül
• nginx — geo modul beillesztett címfájllal, vagy deny utasítások egy generált include fájlból
• Fortinet FortiGate — External Block List, illetve Threat Feed: egy URL, amelyből a tűzfal IP-listát tölt le, és a szabályzatokban használja
• Palo Alto Networks — External Dynamic List (EDL): ugyanaz az elv, önálló objektumtípusként a biztonsági szabályzatokban
• Check Point — Custom Intelligence Feeds és IP Block Lists egy URL-en keresztül
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds saját listaforrásokkal
• Sophos Firewall — Third-Party Threat Feeds: egy URL-ről származó címlisták a blokkoló szabályok forrásaként
• Juniper SRX — Dynamic Address Entries feedekből
• MikroTik RouterOS — Address Lists, szkripttel és fetch paranccsal egy URL-ből feltöltve
• CrowdSec — saját listák a bouncerek forrásaként minden támogatott rendszeren

A Web RBL pontosan ebben a formátumban szolgáltatja a tiltólistát. A tűzfal eldobja a csomagokat, mielőtt azok elérnék a webszervert — és velük együtt ugyanannak a címnek minden más próbálkozását is, például a levelezőszerverre vagy a VPN-átjáróra irányulókat.

Mindkét irány, de a megfelelő helyen

Az út fordítva is működik: a Web RBL-be bármilyen RBL-lista felvehető — egy URL, egy szint, kész. A Tor kilépőcsomópontok, a Spamhaus DROP, a FireHOL és a blocklist.de előre be vannak állítva, továbbiak három kattintással adhatók hozzá. A modul minden listát címtartományokra bont, és minden kérést ezekkel vet össze, néhány mikroszekundum alatt.

Mégis: értelmesebb az idegen listákat a megelőző tűzfalon használni. Három okból. A tűzfal minden szolgáltatást lát, nem csak a HTTP-t — a Spamhaus-listán szereplő címnek a levelezőszervernél és a VPN-nél is el kell akadnia. Csomagszinten dob el, mielőtt egyáltalán kapcsolat jönne létre, így az alkalmazásszervernek semmibe sem kerül. És ez az a hely, ahol az ilyen listákat többnyire amúgy is karbantartják; egy második másolat az alkalmazásban egy második hely, amely elavulhat.

Hogy mire jók akkor a listák a modulban: arra, amire a tűzfal nem képes. Nem ismer bejelentkezési űrlapot. A Web RBL egy Tor-listás címtől megtagadhatja a bejelentkezéshez való hozzáférést, miközben a weboldalt továbbra is kiszolgálja — aki anonim módon akar olvasni, olvashasson; aki anonim módon próbálgat jelszavakat, az ne. És egy listán szereplő címről érkező sikeres bejelentkezést gyanúsként tud jelezni. Mindkettőhöz a listára ott van szükség, ahol a bejelentkezés történik.

Értékelés megérzés helyett

Az a cím, amely egyszer rákérdezett a /wp-login.php útvonalra, más, mint az, amelyik két napon át öt különböző mintával, három domainen végigment. A Web RBL ezt egy 0 és 100 közötti értékelésre számítja át — abból, amit maga látott, külső szolgáltatás és kifelé irányuló lekérdezés nélkül.

Egy bejegyzés: 99 találat, 84-es értékelés, és az indoklás közérthetően — legsúlyosabb minta, öt különböző súlyos minta, két feltűnő nap, húsznál több találat.

Az értékelés két dologról dönt. Egy beállítható érték felett a bejelentkezés tiltott — a weboldal olvasható marad, de aki már hozzáférési adatokat keresett, nem kap lehetőséget a megtaláltak kipróbálására. És az értékeléssel rendelkező címről érkező sikeres bejelentkezést a rendszer jelzi: ekkor valaki már nem találgatott, hanem tudta. Vagy a jogosult felhasználó volt úton, vagy a hozzáférési adatok elvesztek — a modul ezt nem dönti el, hanem olyasvalaki elé teszi, aki rákérdezhet. A jelszóhoz közben sehol nem nyúl hozzá.

A tiltólista 40-es értékeléstől szűrve: találatok száma, feltűnő napok, érintett domainek és az utolsó útvonal címenként.

Mit véd a Web RBL — a védelem hatása részletesen

1. A hozzáférési adatok rejtve maradnak

A legnagyobb mért támadási osztály nem az Odoo hibáit keresi, hanem ottfelejtett titkokat. Tizenhét nap alatt:

• 57 721 kérés .env fájlokra — ezekben adatbázisjelszavak, API-kulcsok és munkamenet-titkok találhatók
• 5535 kérés konfigurációs fájlokra
• 4388 kérés felhő-hozzáférési adatokra: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2811 kérés .git könyvtárakra — aki talál ilyet, letölti a teljes forráskódot az előzményekkel együtt
• 1907 kérés olyan buildleírásokra, mint a .github/workflows/deploy.yml vagy a .gitlab-ci.yml, amelyekben registryk és kulcsnevek szerepelnek

Nem a kérések száma a döntő, hanem a különböző címek száma: a /credentials.json útvonalat 98 cím kérte, a /.git-credentials útvonalat 92. Ez nem egyetlen szkenner, hanem egy általános repertoár, amely világszerte egyidejűleg fut.

2. A bejelentkezési kísérletek tartósan a semmibe futnak

Az Odoo saját fékkel rendelkezik a jelszavak végigpróbálása ellen. Három korlátja van, amelyeket maga az Odoo-forráskód dokumentál: a számláló a munkafolyamat memóriájában van, és minden újraindításkor nullázódik, csak késleltet, nem tilt, és kizárólag azokat a kísérleteket számolja, amelyek eljutnak a jelszó-ellenőrzésig.

A Web RBL ugyanezeken a pontokon avatkozik be, de az adatbázisba ír. Így:

• Az állapot túléli az újraindítást, és az összes munkafolyamatra érvényes
• Mindkét útvonalat rögzíti: a /web/login bejelentkezési űrlapot és a /xmlrpc/2/common és /jsonrpc interfészeket
• Rögzíti azokat a kísérleteket is, amelyek sosem jutnak el a jelszó-ellenőrzésig — például érvényes munkamenet-azonosító nélküli bejelentkezéseket
• Az adatbázis-kezelőhöz való sikertelen hozzáférést is beszámítja; ez a legsúlyosabb bejelentkezési kísérlet

A bejelentkezések küszöbe tízre van állítva, és az indok egy mérés: a tizenhét nap alatt kilenc sikertelen bejelentkezésből a többség ügyfelektől származott, akik maguk állították be a hozzáférést egy másik eszközön, és közben rossz domaint írtak be — egy esetben a sajátjukat, csak kötőjellel pont helyett. Az első sikertelen kísérletnél alkalmazott tiltás így nem a támadókat sújtotta volna, hanem az ügyfeleket a beállítás közben.

Aki viszont tovább próbálkozik, miután a szerver már azt válaszolta, hogy „kérem, várjon egy kicsit", azt azonnal kitiltják. Ezt az üzenetet ember olvassa, és vár; aki figyelmen kívül hagyja, az program. Egy nulla küszöbű külön minta pontosan ezt az esetet fogja meg, és kollégát nem érinthet: oda csak az kerül, aki már tíz sikertelen kísérleten van túl, és utána tovább folytatja.

3. A támadás már semmibe sem kerül a szervernek

Egy olyan útvonalra irányuló szonda, mint a /@fs/../../.env, a modul előtt költséges volt: az Odoo megkeresi a hibaoldalt, legenerálja, elbotlik a cím felépítésekor a pont-szegmenseken, és ezért a hibaoldal hibaoldalán is elbukik. Két stack trace szondánként. Tizenhét nap alatt 28 401 ilyen hibát mértünk, emellett 9467 következményhibát.

A Web RBL az ir.http._match függvénybe avatkozik be, tehát az útvonalkeresés előtt. A válasz sablon nélkül, a tiltásellenőrzésen túli adatbázis-hozzáférés nélkül és naplósor nélkül születik. Az engedélyezőlistával, fenyegetési listákkal és országszabályokkal való összevetés a gyorsítótárból fut, rendezett címtartományokon — néhány mikroszekundum, még harmincezernél több tartomány esetén is.

4. A tűzfal kidobja a támadót, mielőtt megérkezne

A tiltólista RBL-listaként kerül közzétételre, amelyet a HAProxy és az OPNsense közvetlenül olvas. A támadó így egyáltalán nem éri el a webszervert — és az ugyanazon a gépen futó többi szolgáltatást sem. Egy egyszer rosszindulatúként felismert hozzáférés így visszamenőleg védi az egész gépet.

Három szint: tiltás, számlálás, jelentés

Nem minden a semmibe futó kérés támadás. A Web RBL ezért három szintet különböztet meg, és a szint mintánként átállítható, a kód módosítása nélkül.

Szint	A kiváltó kérés	Következmény a címre nézve
tiltás	elutasításra kerül	24 órára tiltva, három feltűnő nap után tartósan
számlálás	átmegy	csak könyvelve, nincs tiltás
jelentés	átmegy	megállapítási szöveggel könyvelve, soha nem tiltják

A fenyegetési listákhoz és országokhoz van egy negyedik is: nincs hozzáférés a bejelentkezéshez. A weboldal olvasható marad, a bejelentkezési űrlap és az interfészek zárva. Ez a középút mindenre, ami gyanús, de nem feltétlenül rosszindulatú — Tor, egy adatközponti tartomány, egy olyan ország, ahol nincsenek ügyfeleink.

Mely támadásokat ismeri fel

Minden mintát valós forgalommal teszteltünk. A különböző címek száma tudatosan mellette áll — megmutatja, hogy egy minta egyetlen szkennert talál-e el, vagy egy elterjedt módszert.

Támadási osztály	Kérések	Címek
.env lekérés	57.721	223
PHP-szondák	12.237	256
Útvonalbejárás értékes céllal	10.046	64
Konfigurációs fájlok	5.535	114
Felhő-hozzáférési kulcsok	4.388	152
WordPress-szondák	3.366	385
.git lekérés	2.811	255
Odoo-felderítés (adatbázis-kezelő, verziólekérdezés)	2.500	213
MI-eszközláncok és parancsvégrehajtás (/mcp, /api/fs/exec)	2.450	74
Buildleírások (CI/CD)	1.907	88
GraphQL-végpontok	1.878	71

Figyelemre méltó a legújabb osztály. A /api/fs/exec útvonalat 369 alkalommal kérte le 54 különböző cím — ez nem olvasási hozzáférés, hanem parancsvégrehajtási kísérlet. Ilyen célpontok két éve még nem léteztek; új MI-eszközök és feladatsorok interfészeiből származnak. Aki a védelmét csak WordPressre és PHP-ra állítja be, ebből semmit sem lát. Az értékelésben ez az osztály ennek megfelelően súlyosan esik latba.

Fenyegetési listák és származási ország

Négy lista, 32 851 címtartomány, mind „csak jelentés" beállításon. Minden további lista egy cím és egy szint.

Egy idegen lista egy állítás, amelyet valaki más tesz, számunkra ismeretlen okokból, olyan forgalomról, amelyet mi sosem láttunk. Lehet téves, elavult vagy más célra készült: a blocklist.de főleg olyan címeket gyűjt, amelyek máshol SSH-bejelentkezéseket próbálgattak, és ez egy webszerverről keveset árul el. Ezért a Web RBL az idegen listákat elkülönítve kezeli a saját tiltólistától, és ezért az alapértelmezés jelentés. És a saját engedélyezőlista mindig nyer: egy általunk ismert ügyfél többet nyom a latban, mint egy harmadik fél megítélése.

A származási ország minden találatnál és minden címnél ott áll. Értékeléshez nélkülözhetetlen — egy saját országból délelőtt tízkor érkező bejelentkezési kísérlet más, mint egy olyan országból érkező, ahol egyetlen ügyfelünk sincs. Általános kizárásra viszont kevéssé alkalmas, és ezt a saját számaink mutatják: a listánkon szereplő támadók túlnyomórészt belgiumi, finnországi és hollandiai felhős tartományokból jöttek. A német nyelvterületen kívüli mindenre vonatkozó tiltás őket nem érte volna el — viszont szabadságon lévő saját munkatársainkat és üzleti úton lévő ügyfeleinket igen.

Az országszabályok üresen kerülnek kiszállításra, és a nézet megmondja, miért.

Hibás konfigurációk jelzése tiltás helyett

A valós forgalomban a leggyakoribb eset nem támadás és nem látogató, hanem hibás szoftver, amely a webszervert valami másnak nézi:

• 1367 hívás egy QNAP NAS webes interfészére — egy szinkronizáló kliens, amelynek már nem stimmel a célja. Egyetlen csatlakozás 962 alkalommal kopogtatott.
• 65 Autodiscover-lekérdezés — egy Outlook, amely a webdomaint az Exchange-ének hiszi

Az ilyen címeket a rendszer soha nem tiltja. A tiltás nem szünteti meg a hibát, hanem elrejti — és azt sújtja, akinek az eszköze amúgy is rosszul van beállítva. Ehelyett egy megállapítási szöveggel és az érintett domainekkel ellátott bejegyzés jön létre, amelyből kérésre automatikusan jegy lesz: címenként pontosan egy, és ha lezárják, majd a cím újra feltűnik, ugyanaz a jegy nyílik meg újra, ahelyett, hogy második jönne létre.

A rendszer felismeri a QNAP-ot, a Synologyt, az Exchange Autodiscovert, az ActiveSyncet valamint a WebDAV-, CalDAV- és CardDAV-klienseket. A minták pontos fájlneveket és könyvtárakat neveznek meg, soha nem puszta kiterjesztéseket: ugyanabban a /cgi-bin/ könyvtárban találhatók az ártalmatlan szinkronizálási hívások közvetlenül a klasszikus szondák mellett, mint a printenv.pl.

Az engedélyezőlista: címek, amelyeket soha nem tiltanak

A tévedés ára nem minden címnél egyforma. Egy adatközpontból érkező szkenner esetén a téves riasztás semmibe sem kerül. Egy telephelyi alagút ellenállomásánál viszont a telephelybe kerül.

Ezért van egy második lista, amely az első előtt áll: címek és hálózatok, amelyeket soha nem tiltanak. Nem hallgat el semmit — aki rajta van, azt továbbra is ellenőrzi és könyveli a rendszer, csak a következmény marad el. Ez a különbség a tűzfalbeli kivételhez képest: az vakká tesz, ez csak türelmessé.

Naponta két forrásból töltődik fel: magából a tűzfalból az összes VPN-ellenállomással, hogy egy újonnan beállított alagútnak ne legyen szüksége arra, hogy valaki gondoljon a tiltólistára — valamint a Google és a Microsoft közzétett címtartományaiból a crawlereik számára. Csak így lehet megkülönböztetni egy valódi Googlebotot egy szkennertől, amely annak nevezi magát. A keresőmotorokat soha nem szabad tiltani; aki kizárja őket, saját oldalát távolítja el az indexelésből, visszaút nélkül.

Közben egy olyan szabály érvényesül, amely fontosabb az egyeztetésnél: Az üres válasz soha nem töröl. Ha a forrás nem válaszol, üres vagy érthetetlen választ ad, a lista változatlan marad. Egy engedélyezőlista, amely zavar esetén kiüresíti önmagát, a lehető legrosszabb pillanatban elviszi az összes alagutat.

Ha egy engedélyezőlista-bejegyzés ügyfelet hordoz, a hálózatából érkező minden találat hozzá lesz rendelve. Egy hibás konfigurációnak így azonnal van kapcsolattartója, anélkül, hogy bárkinek címeket kellene utánanéznie.

Kötelező adatok és automatizált adatgyűjtők

Az impresszum nem szokványos oldal. Emberek számára elérhetőnek kell maradnia, mert a rá vonatkozó tiltás éppen azt a jogsértést hozza létre, amit egy gyűjtő keres. Ugyanakkor ez az az oldal, amelyen név és cím áll — és így a gépi aratás célpontja.

Az osztrák figyelmeztetőlevél-hullámnál, amely a beágyazott Google-betűtípusok miatt indult, a naplók azt mutatták, hogy a levelek nem egyedi látogatásokból származtak, hanem egy automatizált körbe-körbe támadásból: különböző, egymással össze nem függő hostok néhány ezredmásodperces közönként.

A Web RBL ezt lefokozással kivétel helyett oldja meg. A kanonikus /impressum útvonal egyetlen mintára sem illik, és mindig elérhető marad. Idegen írásmódokat, mint a /impressum.php — amely egy Odoo-oldalon nem létezhet —, jelez a rendszer, és aki a gépi aratást nem akarja eltűrni, átállít egy paramétert. A sitemap és a robots ez alól ki van véve, és elvileg nem tiltható: nem tartalmaznak személyes adatot, és lekérésük minden keresőmotor-crawler feladata.

Domain és azonosító: ami a hozzáférési naplóból hiányzik

A werkzeug hozzáférési naplója sem a megszólított hostot, sem a hívó azonosítóját nem rögzíti. Az Odoo mindkettőt természetesen megkapja — a host nélkül több weboldal esetén egyáltalán nem tudná kiválasztani a megfelelőt. Utólag azonban nem olvasható vissza.

A Web RBL mindkettőt rögzíti találatonként. Ez két olyan kérdésre ad választ, amelyekre egyébként nincs válasz: melyik weboldalt szólítja meg egy hibás konfiguráció — és ezáltal, melyik ügyfélhez tartozik a domain — és hogy egy cím egy oldalt látogat-e, vagy mindet. Ugyanazon cím több, egymással össze nem függő domainje a körbe-körbe támadás ismérve, és növelik az értékelést.

Hogy mennyit számít az azonosító, azt egy weboldalunkon végzett kiértékelés mutatta: a teljes forgalom hetven százaléka feletti része egyetlen hívótól származott, több mint száz címre elosztva. Az azonosító nélkül ez elosztott scrapernek látszott volna. A GPTBot volt, az OpenAI crawlere — újra és újra a robots.txt fájlt kérte, és teljesen szabályosan viselkedett.

A biztonsági szempontok részletesen

1. A proxy-felismerés — egyáltalán a legveszélyesebb pont

Ha az Odoo fordított proxy mögött fut, és a proxy_mode helytelenül van beállítva, a modul minden kérésnél ugyanazt a címet látja: a proxyét. Egy tiltás ekkor az összes látogatót egyszerre kizárná.

Ezért a Web RBL minden tiltás előtt ellenőrzi, hogy a címmeghatározás megbízható-e. A proxy_mode mellett továbbítási fejlécet követel, megtagadja a munkát, ha továbbítás érkezik proxy_mode nélkül, és ugyanígy megtagadja egynél több közbenső proxy esetén. Kétség esetén nem tilt.

2. Saját hálózatokat soha

A privát címtartományok, a loopback, a link-local és a CGNAT fixen ki vannak véve. Semmilyen körülmények között nem kerülhetnek a listára, kézzel sem. Ugyanez érvényes az idegen listákra: a privát és fenntartott tartományokat, valamint az abszurdan nagy hálózatokat beolvasáskor elveti a rendszer.

3. Egy saját hiba nem viheti magával a weboldalt

A teljes ellenőrzés egy olyan védelemben fut, amely minden hibát elkap. Ami itt balul sül el, naplózásra kerül, és a kérés változatlanul fut tovább. Az a védőmodul, amely saját hiba esetén magával viszi a weboldalt, rosszabb, mint egyáltalán nincs. A kérési útvonalban minden lekérdezés ezenkívül a látogató böngészőnyelve nélkül és a lefordított mezők szerinti rendezés nélkül fut — egy telepítetlen nyelvű látogató nem akaszthatja meg az ellenőrzést.

4. Megfigyelés a tiltás előtt

A telepítés után a listán szereplő címek tiltása szokásos kéréseknél ki van kapcsolva. A szondákat elutasítja és könyveli a rendszer, minden más átmegy. Így néhány napig megfigyelhető, hogy ki kerül ténylegesen a listára, mielőtt bárkit kizárnának. Ugyanez érvényes a viselkedésfelismerésre, fenyegetési listákra és országszabályokra: először jelentés, tiltás megtekintés után.

5. Szűk minták széles hálók helyett

Egy tévesen felismert látogató drágább, mint egy elnézett szonda. Minden minta ezért hordozza a saját szintjét, és az mintánként átállítható. Egy fájlkiterjesztés önmagában ritkán elég: a .php esetén 14 012 valódi szonda áll szemben egy maroknyi régi linkkel, a .asp esetén fordított az arány. Az ilyen döntéseket mérni kell, nem becsülni.

6. A kézi feloldás megmarad

Aki feloldott egy címet, annak oka volt rá. Egy újabb találat ezt a döntést nem írja felül szó nélkül.

7. A lista védett, de nem titok

A végpont tokent követel, és érvényes token nélkül 404-gyel válaszol, nem 403-mal — a cím léte így egyáltalán nem erősödik meg. Az összehasonlítás állandó idő alatt fut. Maga a lista nem tartalmaz semmi bizalmasat: olyan címekből áll, amelyek maguktól kopogtattak nálunk.

8. Nincsenek titkok a könyvelésben

A sikertelen bejelentkezéseknél a megkísérelt felhasználónevet rögzíti a rendszer, a jelszót soha. Az adatbázis-kezelőnél az átadott értékekből semmit nem olvas ki: ott legelöl a főjelszó áll, és egy tiltólistabeli bejegyzés minden adatbázis-mentésbe átkerül. A GeoLite2 licenckulcs csak a rendszerparaméterben szerepel, és egyetlen naplósorban sem.

9. A csali nem árul el semmi hasznosítható dolgot

Opcionálisan a Web RBL a szondákra kitalált tartalommal válaszol, amely egy egyedi kanári-értéket tartalmaz. Aki ezt az értéket később lekéri, elolvasta a hamisított választ, és annak alapján cselekedett — ebben nincs téves riasztás. A csalik nem tartalmaznak hasznosítható adatot, valódi útvonalakat és érvényes hozzáférési adatokat. Ez a funkció kikapcsolva kerül kiszállításra, mert a viselkedést kívülről láthatóan megváltoztatja.

Amit a modul nem tud

Nem helyettesít tűzfalat és webalkalmazás-tűzfalat. Felismeri az útvonalakban lévő ismert szondázási mintákat, a sikertelen bejelentkezéseket és a feltűnő viselkedést — nem az űrlapok elleni támadásokat, nem a paraméterekbe beleszőtt behatolási kísérleteket.

Emellett csak azt látja, ami HTTP-n visszajön. Hogy egy támadó zsákmányolt adatbázis- vagy postafiók-hozzáférésekkel mit kezd, az láthatatlan marad — és éppen ezért a kanári-értékek útvonalak, nem hozzáférési adatok.

És nem helyettesíti a gondosságot: egy modul, amely elutasítja a .env szondákat, nem teszi veszélytelenné a véletlenül kiszolgált .env fájlt.

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 modul az Odoo 19 Community-t feltételezi, és a base és a web kivételével nincsenek függőségei. A jegyrendszer-kapcsolat opcionális, és nem igényel meghatározott jegyrendszert; ilyen nélkül egyszerűen nem történik semmi. A származási országhoz a MaxMind ingyenes GeoLite2 adatbázisa kell; ha hiányzik, a mező üres marad, és minden más változatlanul működik.

További olvasnivaló: Hogyan illeszkedik a Web RBL egy teljes biztonsági architektúrába -- a tűzfallal, a kétfaktoros hitelesítéssel és a jogosultságokkal együtt, lépésről lépésre útmutatóval: Az Odoo 19 biztonsági architektúra helyes kombinálása.

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