Zdrojový kód: github.com/Alex0176/odoo-web-rbl — AGPL-3, volně k použití.
Kdo provozuje server Odoo na internetu, dostává návštěvy. Ne občas, ale nepřetržitě. Za sedmnáct dní jsme na našich pěti webových stránkách zaznamenali a vyhodnotili 731 297 požadavků. 110 511 z nich nebyli návštěvníci, ale automatizované vyhledávání slabých míst, přístupových údajů a konfiguračních souborů.
Tento článek představuje Web RBL, open source modul pro Odoo 19 Community, který tento provoz rozpoznává, vyhodnocuje, zaznamenává a odmítá — a seznam blokovaných adres zveřejňuje jako seznam RBL, tedy ve formátu, který firewally a reverzní proxy dokážou přímo načíst. Všechna čísla pocházejí z reálného provozu.
Co modul umí — přehled funkcí
| Funkce | Co dělá | Výchozí nastavení |
|---|---|---|
| Rozpoznávání vzorů | Rozpoznává průzkumné pokusy podle cesty a přípony: .env, .git, konfigurační soubory, cloudové klíče, předpisy pro sestavení CI/CD, WordPress, PHP, procházení adresářů mimo povolenou cestu, správce databází, GraphQL, spouštění příkazů přes /api/fs/exec a podobná rozhraní | blokovat |
| Tři režimy pro každý vzor | blokovat, počítat nebo hlásit — lze nastavit pro každý vzor bez úprav kódu | podle vzoru |
| Prahové hodnoty | Počet výskytů stejného vzoru před zablokováním; u přihlašování deset | 10 při přihlašování |
| Ochrana přihlašování | Neúspěšná přihlášení přes formulář i XML-RPC/JSON-RPC, neúspěšné kontroly relací, přístupy ke správci databází — ukládají se do databáze, nikoli do operační paměti | zapnuto |
| Rozpoznávání botů při přihlašování | Kdo po deseti neúspěšných pokusech ignoruje výzvu k vyčkání a zkouší to dál, je okamžitě zablokován | blokovat |
| Rozpoznávání podle chování | Adresy, které během pěti minut vyvolají dvacet chybových stránek a téměř žádnou úspěšně načtenou stránku — tedy hádají, místo aby četly | hlásit |
| Skóre 0–100 | Jak jisté je, že za adresou stojí útočník? Podle závažnosti vzoru, počtu různých vzorů, dnů s podezřelou aktivitou, dotčených domén a počtu záchytů — se srozumitelným slovním zdůvodněním | zapnuto |
| Blokování přihlášení podle skóre | Od nastavitelné hodnoty skóre je přihlášení zakázáno, web zůstává přístupný pro čtení | od 40 |
| Podezření na odcizené přihlašovací údaje | Úspěšné přihlášení z podezřelé adresy se ohlásí a na přání přidělí jako úkol — jednou za den pro každou adresu | zapnuto |
| Seznamy hrozeb | Přednastavené výstupní uzly Tor, Spamhaus DROP, FireHOL Level 1, blocklist.de; jakýkoli další seznam RBL lze přidat zadáním adresy, denní synchronizace, samostatný režim pro každý seznam | hlásit |
| Zákaz přístupu k přihlášení | Čtvrtý režim pro seznamy a země: web lze číst, přihlašovací formulář a rozhraní jsou nepřístupné — vhodné řešení pro Tor | Volitelné |
| Země původu | Země pro každý záchyt a adresu podle GeoLite2; databázi modul sám aktualizuje pomocí bezplatného licenčního klíče | zobrazovat |
| Pravidla podle zemí | Blokovat, zakázat přístup k přihlášení, hlásit nebo výslovně povolit — pro každou zemi zvlášť, záměrně bez přednastavených pravidel | žádná |
| Chybné konfigurace | QNAP, Synology, Exchange-Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV se rozpoznají, nikdy se neblokují a zařadí se do seznamu k řešení spolu s popisem zjištění a dotčenou doménou | hlásit |
| Jeden tiket pro každou adresu | Ze zjištění lze na přání vytvořit tiket — právě jeden pro každou adresu; uzavřený tiket se znovu otevře, místo aby vznikl duplicitní | vypnuto |
| Povinné stránky a sběrače údajů | Kanonická cesta ke stránce s identifikačními údaji provozovatele zůstává vždy dostupná; automatické zkoušení jiných variant názvu se rozpozná a na přání zablokuje | hlásit |
| Seznam povolených adres | Adresy a sítě, které se nikdy neblokují; seznam se denně doplňuje z firewallu (protistrany VPN) a ze zveřejněných rozsahů adres Googlebot a Bingbot | zapnuto |
| Přiřazení k zákazníkovi | Záchyt ze sítě zákazníka se přiřadí k danému zákazníkovi — podle seznamu povolených adres, nikdy ručním odhadem | zapnuto |
| Doména a identifikátor u každého záchytu | Na který web požadavek směřoval a s jakým User-Agent — oba údaje v přístupovém protokolu chybí | zapnuto |
| Vyhodnocení | Graf a kontingenční tabulka všech záchytů: podle vzoru, dne, domény, země a adresy | zapnuto |
| Návnady | Průzkumné požadavky dostávají smyšlené odpovědi s návnadovým identifikátorem; kdo ho později použije v požadavku, prokazuje, že si odpověď přečetl | vypnuto |
| Poskytování seznamu RBL | Seznam blokovaných adres jako prostý seznam adres nebo JSON na vlastní adrese chráněné tokenem — pro HAProxy, OPNsense a každý firewall, který načítá seznamy z URL | zapnuto |
Vše, co má při dodání nastaveno hlásit, vypnuto nebo Volitelné, je tak nastaveno záměrně: Kdo zapne blokování, měl by to udělat proto, že několik dní sledoval, koho by zasáhlo — ne proto, že to tak určovalo výchozí nastavení.
Vyhodnocení: záchyty podle vzoru za sedm dní. Nejvyšší sloupec představuje hledání souborů .env.
Seznamy RBL: standardizovaný způsob poskytování seznamů blokovaných adres
RBL je zkratka pro Real-time Blackhole List. Pojem pochází ze světa e-mailu, kde Spamhaus a další už od devadesátých let zveřejňují seznamy adres škodlivých odesílatelů. Princip je velmi jednoduchý, a právě proto tak rozšířený: jedna adresa na řádek, dostupnost přes HTTP, pravidelné opětovné načítání. Žádný formát, který je nejprve nutné parsovat, žádné rozhraní, pro které potřebujete zvláštní nástroj.
Prakticky každý firewall a každá reverzní proxy dokážou takový seznam načíst a vytvořit z něj pravidla. Výrobci pro to používají různé názvy, mechanismus je ale všude stejný:
- OPNsense a pfSense — URL Table Alias: načtení seznamu adres přes HTTP, použití jako aliasu v pravidlech firewallu, aktualizace každou hodinu nebo každý den
- HAProxy — soubory ACL a Maps:
src -f sperrliste.txtv pravidlehttp-request deny, opětovné načtení přes běhové API bez restartu - nginx — modul geo s připojeným souborem adres nebo direktivy
denyz vygenerovaného souboruinclude - Fortinet FortiGate — External Block List, případně Threat Feed: URL, ze které firewall získává seznam IP adres a používá ho v zásadách
- Palo Alto Networks — External Dynamic List (EDL): stejný princip, samostatný typ objektu v bezpečnostních zásadách
- Check Point — Custom Intelligence Feeds a IP Block Lists prostřednictvím URL
- Cisco Secure Firewall (Firepower) — Security Intelligence Feeds s vlastními zdroji seznamů
- Sophos Firewall — Third-Party Threat Feeds: seznamy adres z URL jako zdroj pro blokovací pravidla
- Juniper SRX — Dynamic Address Entries z datových zdrojů
- MikroTik RouterOS — Address Lists, plněné z URL pomocí skriptu a příkazu
fetch - CrowdSec — vlastní seznamy jako zdroj pro komponenty Bouncer na každém podporovaném systému
Právě v tomto formátu poskytuje Web RBL svůj seznam blokovaných adres. Firewall zahodí pakety dříve, než dorazí na webový server — a spolu s nimi i všechny další pokusy ze stejné adresy, například o přístup k poštovnímu serveru nebo VPN bráně.
Oběma směry, ale na správném místě
Funguje to i opačně: Do Web RBL lze přidat libovolný seznam RBL — URL, režim a hotovo. Výstupní uzly Tor, Spamhaus DROP, FireHOL a blocklist.de jsou přednastavené, další přidáte třemi kliknutími. Modul každý seznam rozloží na rozsahy adres a každý požadavek proti nim zkontroluje během několika mikrosekund.
Přesto platí: Externí seznamy je rozumnější používat na firewallu před serverem. Ze tří důvodů. Firewall vidí všechny služby, nejen HTTP — adresa ze seznamu Spamhaus by neměla projít ani k poštovnímu serveru nebo VPN. Zahazuje provoz na úrovni paketů ještě před navázáním spojení, takže aplikační server nijak nezatěžuje. A právě na firewallu se takové seznamy už tak jako tak spravují; druhá kopie v aplikaci je další místo, kde mohou data zastarat.
K čemu jsou tedy seznamy v modulu ještě užitečné? K tomu, co firewall neumí. Přihlašovací formulář nezná. Web RBL může adrese ze seznamu Tor odepřít přístup k přihlášení a přitom jí dál poskytovat webové stránky — kdo chce anonymně číst, má mít tu možnost; kdo chce anonymně zkoušet hesla, nikoli. A úspěšné přihlášení z adresy uvedené na seznamu může nahlásit jako podezřelé. V obou případech musí být seznam k dispozici tam, kde přihlašování probíhá.
Skóre místo intuice
Adresa, která jednou požádala o /wp-login.php, je něco jiného než adresa, která během dvou dnů zkoušela pět různých vzorů na třech doménách. Web RBL to převádí na skóre od 0 do 100 — podle toho, co sám zaznamenal, bez externí služby a bez dotazů mimo systém.
Jeden záznam: 99 záchytů, skóre 84 a srozumitelné slovní zdůvodnění — nejzávažnější vzor, pět různých závažných vzorů, dva dny s podezřelou aktivitou, přes dvacet záchytů.
Skóre rozhoduje o dvou věcech. Od nastavitelné hodnoty je přihlášení zakázáno — web zůstává čitelný, ale kdo už hledal přístupové údaje, nedostane příležitost nalezené vyzkoušet. A úspěšné přihlášení z adresy se skóre je nahlášeno: Tehdy nějaký člověk už nehádal, ale věděl. Buď byl oprávněný uživatel na cestách, nebo se přístupové údaje ztratily — modul to nerozhoduje, předloží to někomu, kdo se může zeptat. Samotné heslo se přitom nikde nedotkne.
Seznam blokovaných adres filtrovaný podle skóre od 40: počet záchytů, dny s podezřelou aktivitou, dotčené domény a poslední cesta pro každou adresu.
Co Web RBL chrání — podrobný přehled ochrany
1. Přihlašovací údaje zůstávají neodhalené
Největší zaznamenaná kategorie útoků nehledá zranitelnosti v Odoo, ale zapomenuté citlivé údaje. Za sedmnáct dní:
- 57.721 požadavků na soubory
.env— v nich jsou hesla k databázím, klíče API a tajemství relací - 5.535 požadavků na konfigurační soubory
- 4.388 požadavků na přístupové údaje do cloudu:
credentials.json,service-account.json,firebase-adminsdk.json,rclone.conf,.git-credentials - 2.811 požadavků na adresáře
.git— kdo nějaký najde, stáhne si kompletní zdrojový kód včetně historie - 1.907 požadavků na sestavovací předpisy jako
.github/workflows/deploy.ymlnebo.gitlab-ci.yml, v nichž jsou registry a názvy klíčů
Rozhodující přitom není počet požadavků, ale počet různých adres: Požadavky na /credentials.json přišly z 98 adres, na /.git-credentials z 92. Nejde o jediný skener, ale o běžnou sadu postupů, které současně běží po celém světě.
2. Pokusy o přihlášení vyjdou naprázdno — trvale
Odoo má vlastní mechanismus zpomalující opakované zkoušení hesel. Má tři omezení, která jsou zdokumentovaná přímo ve zdrojovém kódu Odoo: Počítadlo se nachází v operační paměti pracovního procesu a při každém restartu se vynuluje, pokusy pouze zpomaluje, místo aby je blokovalo, a počítá výhradně pokusy, které dospějí až k ověření hesla.
Web RBL zasahuje na stejných místech, ale zapisuje do databáze. Díky tomu platí:
- Stav se zachová při každém restartu a sdílí se mezi všemi pracovními procesy
- Zaznamenávají se oba způsoby: přihlašovací formulář
/web/logini rozhraní/xmlrpc/2/commona/jsonrpc - Zaznamenávají se i pokusy, které se k ověření hesla vůbec nedostanou — například přihlášení bez platného identifikátoru relace
- Započítává se i neúspěšný přístup ke správci databází; ten je vůbec nejzávažnějším pokusem o přihlášení
Prahová hodnota pro přihlašování je nastavena na deset a důvod vychází z měření: Z devíti neúspěšných přihlášení během sedmnácti dnů pocházela většina od zákazníků, kteří si sami nastavovali přístup na dalším zařízení a zadali přitom nesprávnou doménu — v jednom případě svou vlastní, jen s pomlčkou místo tečky. Blokování po prvním neúspěšném pokusu by tak nezasáhlo útočníky, ale zákazníky při nastavování.
Kdo to naopak zkouší dál, přestože server už odpověděl „chvíli prosím počkejte“, je zablokován okamžitě. Člověk si zprávu přečte a počká; kdo ji ignoruje, je program. Právě tento případ zachytává samostatný vzor s nulovou prahovou hodnotou a nemůže zasáhnout žádného kolegu: Do této situace se dostane jen ten, kdo už má za sebou deset neúspěšných pokusů a přesto pokračuje.
3. Útok už server nijak nezatěžuje
Sonda na cestu jako /@fs/../../.env byla před
modulem drahá: Odoo hledá chybovou stránku, vykreslí ji, zakopne
při sestavování adresy o segmenty s tečkami a selže
potom i na chybové stránce chybové stránky. Dva
výpisy zásobníku na každou sondu. Naměřeno bylo 28.401 takových chyb
za sedmnáct dní a k tomu 9.467 následných chyb.
Web RBL zasahuje v ir.http._match, tedy ještě před směrováním požadavku. Odpověď se odešle bez šablony, bez dalších přístupů do databáze nad rámec kontroly blokování a bez zápisu do protokolu. Kontrola proti seznamu povolených adres, seznamům hrozeb a pravidlům podle zemí probíhá z mezipaměti nad seřazenými rozsahy adres — během několika mikrosekund i při více než třiceti tisících rozsahů.
4. Firewall zastaví útočníka dříve, než dorazí
Seznam blokovaných adres se zveřejňuje jako seznam RBL, který HAProxy a OPNsense přímo načítají. Útočník se tak k webovému serveru vůbec nedostane — ani k žádné jiné službě na stejném hostiteli. Přístup, který byl jednou rozpoznán jako škodlivý, tak zpětně chrání celý stroj.
Tři režimy: blokovat, počítat, hlásit
Ne každý požadavek na neexistující stránku je útok. Web RBL proto rozlišuje tři režimy, které lze nastavit pro každý vzor bez zásahu do kódu.
| Režim | Požadavek, který pravidlo aktivoval | Důsledek pro adresu |
|---|---|---|
| blokovat | je odmítnut | zablokována na 24 hodin, po třech dnech s podezřelou aktivitou trvale |
| počítat | je povolen | pouze se zaznamená, bez blokování |
| hlásit | je povolen | zaznamená se s popisem zjištění, nikdy se neblokuje |
Pro seznamy hrozeb a země existuje ještě čtvrtý režim: zákaz přístupu k přihlášení. Web zůstává přístupný pro čtení, přihlašovací formulář a rozhraní jsou nepřístupné. Je to kompromis pro vše, co je podezřelé, ale nemusí být škodlivé — Tor, rozsah adres datového centra nebo země, ve které nemáte zákazníky.
Jaké útoky modul rozpoznává
Všechny vzory byly ověřeny na reálném provozu. Počet různých adres je vedle nich uveden záměrně — ukazuje, zda vzor zachytává jediný skener, nebo rozšířený postup.
| Kategorie útoku | Požadavky | Adresy |
|---|---|---|
Pokusy o získání .env | 57.721 | 223 |
| Průzkumné požadavky na PHP | 12.237 | 256 |
| Procházení adresářů mimo povolenou cestu s hodnotným cílem | 10.046 | 64 |
| Konfigurační soubory | 5.535 | 114 |
| Přístupové klíče ke cloudu | 4.388 | 152 |
| Průzkumné požadavky na WordPress | 3.366 | 385 |
Pokusy o získání .git | 2.811 | 255 |
| Průzkum Odoo (správce databází, dotaz na verzi) | 2.500 | 213 |
Řetězce nástrojů AI a spouštění příkazů (/mcp, /api/fs/exec) | 2.450 | 74 |
| Předpisy pro sestavení (CI/CD) | 1.907 | 88 |
| Koncové body GraphQL | 1.878 | 71 |
Pozoruhodná je nejnovější kategorie. Na /api/fs/exec přišlo 369 požadavků z 54 různých adres — nejde o čtení dat, ale o pokus spustit příkazy. Takové cíle před dvěma lety neexistovaly; pocházejí z rozhraní nových nástrojů AI a front úloh. Kdo zaměřuje ochranu pouze na WordPress a PHP, nic z toho nezaznamená. Ve skóre má proto tato kategorie odpovídající vysokou váhu.
Seznamy hrozeb a země původu
Čtyři seznamy, 32.851 rozsahů adres, všechny nastaveny jen na „hlásit“. Každý další seznam je jedna adresa a jedna úroveň.
Externí seznam je tvrzení někoho jiného, založené na důvodech, které neznáme, a na provozu, který jsme nikdy neviděli. Může být chybný, zastaralý nebo určený k jinému účelu: blocklist.de shromažďuje především adresy, ze kterých se jinde zkoušely přihlašovací údaje k SSH, což o provozu vůči webovému serveru mnoho nevypovídá. Proto Web RBL vede externí seznamy odděleně od vlastního seznamu blokovaných adres a proto je výchozím nastavením hlásit. Vlastní seznam povolených adres má navíc vždy přednost: zákazník, kterého známe, má větší váhu než hodnocení třetí strany.
Země původu se uvádí u každého záchytu i každé adresy. Pro vyhodnocení je nepostradatelná — pokus o přihlášení z vlastní země v deset dopoledne je něco jiného než pokus ze země, kde nemáme jediného zákazníka. K plošnému blokování se ale příliš nehodí, jak ukazují naše vlastní čísla: útočníci na našem seznamu pocházeli převážně z cloudových rozsahů v Belgii, Finsku a Nizozemsku. Blokování všeho mimo německy mluvící země by je nezastavilo — zato by zasáhlo naše zaměstnance na dovolené a zákazníky na služebních cestách.
Pravidla podle zemí jsou ve výchozím stavu prázdná a příslušné zobrazení vysvětluje proč.
Chybné konfigurace hlásit místo blokování
Nejčastějším případem v reálném provozu není útok ani návštěvník, ale chybně fungující software, který webový server považuje za něco jiného:
- 1.367 přístupů na webové rozhraní NAS od QNAP — synchronizační klient, jehož cíl už nesedí. Jediná přípojka klepala 962krát.
- 65 dotazů Autodiscover — Outlook, který webovou doménu považuje za svůj Exchange
Takové adresy se nikdy neblokují. Blokování chybu neopraví, jen ji skryje — a postihne člověka, jehož zařízení už tak má nesprávné nastavení. Místo toho vznikne záznam s popisem zjištění a dotčenými doménami, ze kterého lze na přání automaticky vytvořit tiket: pro každou adresu právě jeden. Pokud se tiket uzavře a adresa na sebe znovu upozorní, otevře se tentýž tiket znovu, místo aby vznikl další.
Rozpoznávají se QNAP, Synology, Exchange-Autodiscover, ActiveSync a klienti WebDAV, CalDAV a CardDAV. Vzory přitom uvádějí přesné názvy souborů a adresářů, nikdy jen přípony: ve stejném adresáři /cgi-bin/ míří neškodné synchronizační požadavky hned vedle klasických průzkumných požadavků, například na printenv.pl.
Seznam povolených adres: adresy, které se nikdy neblokují
Cena omylu není u všech adres stejná. U skeneru z datového centra falešný poplach nic nestojí. U protistrany tunelu propojujícího pobočku znamená odříznutí celé pobočky.
Proto existuje druhý seznam, který má před prvním přednost: adresy a sítě, které se nikdy neblokují. Nic se tím ale nepřestává sledovat — adresy na seznamu se dál kontrolují a jejich aktivita zaznamenává, pouze se nevyvodí důsledek. V tom spočívá rozdíl oproti výjimce ve firewallu: ta vás připraví o přehled, tento seznam vám jen umožní být trpěliví.
Denně se doplňuje ze dvou zdrojů: ze samotného firewallu o všechny protistrany VPN, aby nově vytvořený tunel nezávisel na tom, zda si někdo vzpomene na seznam blokovaných adres — a ze zveřejněných rozsahů adres společností Google a Microsoft pro jejich crawlery. Jen tak lze odlišit skutečný Googlebot od skeneru, který se za něj vydává. Vyhledávače se nikdy nesmějí blokovat; kdo jim zablokuje přístup, vyřadí svůj web z indexace bez možnosti návratu.
Přitom platí pravidlo, které je důležitější než porovnání: Prázdná odpověď nikdy nic nemaže. Pokud zdroj neodpoví, odpoví prázdně nebo nesrozumitelně, seznam zůstane beze změny. Seznam výjimek, který se při poruše sám vyprázdní, v nejhorším myslitelném okamžiku vezme s sebou všechny tunely.
Pokud je u položky seznamu povolených adres uveden zákazník, přiřadí se mu každý záchyt z jeho sítě. Chybná konfigurace tak má ihned konkrétní kontaktní osobu, aniž by někdo musel dohledávat adresy.
Povinné údaje a automatizovaní sběrači dat
Stránka s povinnými údaji o provozovateli není obyčejná stránka. Musí zůstat přístupná lidem, protože její zablokování by vytvořilo právě to porušení předpisů, které sběrač hledá. Zároveň je to stránka, na které je uvedeno jméno a adresa — a tedy i cíl automatizovaného sběru.
Při rakouské vlně právních výzev kvůli vloženým písmům Google protokoly ukázaly, že dopisy nevycházely z jednotlivých návštěv, ale z plošného automatizovaného procházení: různé, vzájemně nesouvisející hostitele dělily pouhé milisekundy.
Web RBL to řeší snížením úrovně místo výjimky. Kanonická cesta /impressum neodpovídá žádnému vzoru a zůstává vždy přístupná. Cizí varianty jako /impressum.php — které na webu v Odoo nemohou existovat — se hlásí. Kdo nechce automatizovaný sběr tolerovat, změní jeden parametr. Na sitemap a robots se toto nevztahuje a zásadně je nelze blokovat: neobsahují žádné osobní údaje a jejich načítání je úkolem každého crawleru vyhledávače.
Doména a identifikátor klienta: co chybí v přístupovém protokolu
Přístupový protokol werkzeug nezaznamenává ani cílového hostitele, ani identifikátor klienta, který požadavek odeslal. Odoo samozřejmě dostává obojí — bez hostitele by při provozu více webů ani nemohlo vybrat ten správný. Zpětně to ale dohledat nelze.
Web RBL zaznamenává oba údaje u každého záchytu. Tím odpovídá na dvě otázky, na které by jinak nebylo možné odpovědět: na který web míří chybně nakonfigurovaný klient — a tedy kterému zákazníkovi doména patří — a zda jedna adresa navštěvuje jeden web, nebo všechny. Přístup z jedné adresy na několik nesouvisejících domén je znakem plošného skenování a zvyšuje rizikové skóre.
Jak důležitý je identifikátor klienta, ukázala analýza jednoho z našich webů: přes sedmdesát procent veškerého provozu tam připadalo na jediného klienta, rozloženého na více než sto adres. Bez identifikátoru by to vypadalo jako distribuovaný scraper. Byl to GPTBot, crawler společnosti OpenAI — opakovaně žádal o robots.txt a choval se zcela korektně.
Podrobný přehled bezpečnostních aspektů
1. Rozpoznání proxy — vůbec nejrizikovější místo
Pokud Odoo běží za reverzní proxy a proxy_mode je nesprávně nastavený, modul u každého požadavku vidí stejnou adresu: adresu proxy. Zablokování by pak odřízlo všechny návštěvníky najednou.
Proto Web RBL před každým zablokováním ověřuje, zda je určení adresy spolehlivé. Vyžaduje proxy_mode spolu s hlavičkou předávání, odmítne zasáhnout, pokud přijde předaný požadavek bez proxy_mode, a stejně tak při více než jedné zprostředkující proxy. V případě pochybností neblokuje.
2. Vlastní sítě nikdy neblokovat
Privátní rozsahy adres, loopback, link-local a CGNAT mají pevně danou výjimku. Na seznam se nemohou dostat za žádných okolností, ani ručně. Totéž platí pro externí seznamy: privátní a rezervované rozsahy i nesmyslně velké sítě se při načítání zahazují.
3. Vlastní chyba nesmí vyřadit web
Celá kontrola běží v ochranném bloku, který zachytí každou chybu. Pokud se zde něco pokazí, zapíše se to do protokolu a požadavek pokračuje beze změny. Ochranný modul, který při vlastní chybě vyřadí web, je horší než žádný. Všechny databázové dotazy při zpracování požadavku navíc běží bez použití jazyka prohlížeče návštěvníka a bez řazení podle překládaných polí — návštěvník s nenainstalovaným jazykem nesmí způsobit selhání kontroly.
4. Před blokováním nejprve sledovat
Po instalaci je blokování adres ze seznamu u běžných požadavků vypnuté. Průzkumné požadavky se odmítají a zaznamenávají, vše ostatní prochází. Několik dní tak lze sledovat, kdo se na seznam skutečně dostává, než někomu zablokujete přístup. Totéž platí pro rozpoznávání chování, seznamy hrozeb a pravidla podle zemí: nejprve hlásit, po vyhodnocení blokovat.
5. Přesné vzory místo plošného záběru
Chybně rozpoznaný návštěvník je dražší než přehlédnutá sonda.
Každý vzor proto nese svou úroveň a ta je pro každý vzor
měnitelná. Samotná přípona souboru zřídka stačí: U
.php stojí 14.012 skutečných sond proti hrstce
starých odkazů, u .asp je poměr opačný. Taková
rozhodnutí je třeba měřit, ne odhadovat.
6. Ruční povolení zůstává v platnosti
Kdo adresu povolil, měl k tomu důvod. Další záchyt toto rozhodnutí bez upozornění neruší.
7. Seznam je chráněný, ale není tajný
Koncový bod vyžaduje token a bez platného tokenu odpovídá kódem 404, nikoli 403 — existenci adresy tak vůbec nepotvrdí. Porovnání probíhá v konstantním čase. Samotný seznam neobsahuje nic důvěrného: tvoří ho adresy, které nás samy kontaktovaly.
8. Žádné citlivé údaje v záznamech
Při neúspěšných přihlášeních se zaznamenává zadané uživatelské jméno, nikdy heslo. U správce databází se z předaných hodnot nečte vůbec nic: na prvním místě je tam hlavní heslo a záznam v seznamu blokovaných adres se dostane do každé zálohy databáze. Licenční klíč pro GeoLite2 je uložen pouze v systémovém parametru a neobjeví se v žádném řádku protokolu.
9. Návnada neprozradí nic využitelného
Web RBL může na průzkumné požadavky volitelně odpovídat smyšleným obsahem, který obsahuje jednoznačnou nástražnou hodnotu. Kdo tuto hodnotu později vyžádá, přečetl si podvrženou odpověď a jednal podle ní — falešný poplach je zde vyloučen. Návnady neobsahují žádné využitelné údaje, skutečné cesty ani platné přihlašovací údaje. Ve výchozím nastavení je tato funkce vypnutá, protože mění chování způsobem viditelným navenek.
Co modul neumí
Nenahrazuje firewall ani webový aplikační firewall. Rozpoznává známé vzory průzkumných požadavků v cestách, neúspěšná přihlášení a podezřelé chování — nikoli útoky na formuláře nebo pokusy o injekci prostřednictvím parametrů.
Navíc vidí jen to, co se vrací přes HTTP. Co útočník provede se získanými přístupy k databázi nebo poštovní schránce, zůstává neviditelné — a právě proto jsou nástražné hodnoty cestami, nikoli přihlašovacími údaji.
A nenahrazuje ani obezřetnost: modul, který odmítá průzkumné požadavky na .env, nezbaví omylem zpřístupněný soubor .env jeho nebezpečnosti.
Dostupnost
Web RBL je veřejně dostupný pod licencí AGPL-3 a u nás běží v produkčním provozu na pěti webech:
github.com/Alex0176/odoo-web-rbl
Modul vyžaduje Odoo 19 Community a kromě base a web nemá žádné závislosti. Napojení na tikety je volitelné a nevyžaduje konkrétní tiketovací systém; bez něj se jednoduše nic nestane. Pro určení země původu je potřeba bezplatná databáze GeoLite2 od MaxMind; pokud chybí, pole zůstane prázdné a vše ostatní funguje beze změny.
Další informace: Jak Web RBL zapadá do celkové bezpečnostní architektury — společně s firewallem, dvoufaktorovým ověřováním a oprávněními, včetně návodu krok za krokem: Jak správně kombinovat prvky bezpečnostní architektury Odoo 19.
Uvítáme dotazy, připomínky i hlášení chyb — nejlépe jako issue na GitHub.