Preskoči na vsebino

Odoo 19 Community: Web RBL – blokirni seznam za napadalni promet na lastnih spletnih straneh

24. september 2026 napisal
Odoo 19 Community: Web RBL – blokirni seznam za napadalni promet na lastnih spletnih straneh

Izvorna koda: github.com/Alex0176/odoo-web-rbl — AGPL-3, prosto uporabno.

Kdor upravlja strežnik Odoo na internetu, dobi obiske. Ne občasno, temveč neprekinjeno. Skozi sedemnajst dni smo na naših petih spletnih straneh zabeležili in analizirali 731.297 zahtev. 110.511 od teh ni bilo obiskovalcev, temveč avtomatizirano iskanje ranljivosti, dostopnih podatkov in konfiguracijskih datotek.

Ta prispevek opisuje Web RBL, odprtokodni modul za Odoo 19 Community, ki ta promet prepoznava, ocenjuje, beleži in zavrača — in ki blokirni seznam objavlja kot seznam RBL, torej v formatu, ki ga požarni zidovi in reverse proxyji bereta neposredno. Vse številke izvirajo iz resničnega delovanja.

Kaj modul zmore — funkcije na kratko

FunkcijaKaj počneOb dobavi
Prepoznavanje vzorcevPrepoznava sondiranja po poti in končnici: .env, .git, konfiguracijske datoteke, ključi v oblaku, navodila za gradnjo CI/CD, WordPress, PHP, path traversal, upravljalniki zbirk podatkov, GraphQL, izvajanje ukazov prek /api/fs/exec in podobnih vmesnikovblokirati
Tri stopnje na vzorecblokirati, šteti ali javiti — nastavljivo za vsak vzorec, brez kodena vzorec
PragoviToliko zadetkov istega vzorca, preden se blokira; pri prijavah deset10 pri prijavi
Obramba prijaveSpodletele prijave prek obrazca in XML-RPC/JSON-RPC, spodletela preverjanja seje, dostopi do upravljalnika zbirk podatkov — v zbirki podatkov, ne v delovnem pomnilnikuvklopljeno
Prepoznavanje botov pri prijaviKdor po desetih spodletelih poskusih prezre sporočilo o čakanju in trka naprej, je takoj blokiranblokirati
Prepoznavanje vedenjaNaslovi, ki v petih minutah povzročijo dvajset napačnih strani in komaj kakšno zadetno stran — torej ugibajo namesto da berejojaviti
Ocena 0–100Kako gotovo je, da za naslovom stoji napadalec? Iz resnosti vzorca, števila različnih vzorcev, nenavadnih dni, prizadetih domen in števila zadetkov — z obrazložitvijo v navadnem besediluvklopljeno
Blokada prijave po oceniOd nastavljive ocene naprej je prijava prepovedana, spletna stran ostane berljivaod 40
Sum na ukradene dostopne podatkeUspešna prijava z sumljivega naslova se javi in se po želji dodeli kot naloga — enkrat na naslov in danvklopljeno
Seznami groženjIzhodna vozlišča Tor, Spamhaus DROP, FireHOL Level 1, blocklist.de so že prednastavljeni; vsak drug seznam RBL je mogoče dodati z naslovom, dnevno primerjanje, za vsak seznam lastna stopnjajaviti
Brez dostopa do prijaveČetrta stopnja za sezname in države: spletna stran ostane berljiva, prijavna maska in vmesniki so zaprti — pravi odgovor na TorMožnost
Država izvoraDržava za vsak zadetek in naslov prek GeoLite2; modul bazo podatkov sam posodablja z brezplačnim licenčnim ključemprikaži
Pravila po državahBlokiraj, brez dostopa do prijave, javi ali izrecno dovoli — za vsako državo, namenoma brez privzete vrednostibrez
Napačne konfiguracijeQNAP, Synology, Exchange Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV se prepoznajo, nikoli ne blokirajo in se z izsledkom ter prizadeto domeno uvrstijo na delovni seznamjaviti
Tiket na naslovIz izsledka po želji nastane tiket — natanko eden na naslov, zaprt tiket se ponovno odpre, namesto da bi se podvojilizklj.
Obvezne strani in zbiralciKanonična pot do impresuma je vedno dosegljiva; strojno preizkušanje tujih zapisov se prepozna in se po želji blokirajaviti
Seznam izjemNaslovi in omrežja, ki se nikoli ne blokirajo; dnevno se polni iz požarnega zidu (nasprotne točke VPN) in iz objavljenih naslovnih območij Googlebota in Bingbotavklopljeno
Dodelitev strankiZadetek iz omrežja stranke se dodeli njej — iz seznama izjem, nikoli ugibano na rokevklopljeno
Domena in identifikator za vsak zadetekKatera spletna stran je bila poklicana in s kakšnim User-Agentom — oboje manjka v dnevniku dostopovvklopljeno
AnalizaDiagram in vrtilna tabela prek vseh zadetkov: po vzorcu, dnevu, domeni, državi, naslovuvklopljeno
VabaSonde dobijo izmišljene odgovore z vrednostjo kanarček; kdor jo pozneje pokliče, je odgovore prebralizklj.
Dostava RBLSeznam blokiranih naslovov kot navaden seznam naslovov ali JSON na lastnem naslovu, zaščitenem z žetonom — za HAProxy, OPNsense in vsak požarni zid, ki bere sezname URLvklopljeno

Vse, kar je dobavljeno z javi, izklj. ali možnost, je tako namenoma: kdor blokado vklopi, naj to stori, ker je nekaj dni opazoval, kdo nasede — ne ker je tako zahtevala privzeta nastavitev.

Analiza Web RBL: zadetki po vzorcu v sedmih dneh

Analiza: zadetki po vzorcu v sedmih dneh. Najvišji stolpec je iskanje datotek .env.

Seznami RBL: standardiziran način dostave blokad

RBL pomeni Real-time Blackhole List. Izraz izvira iz sveta e-pošte, kjer Spamhaus in drugi od devetdesetih let objavljajo sezname zlonamernih naslovov pošiljateljev. Načelo je zelo preprosto in prav zato tako razširjeno: en naslov v vrstici, dostopen prek HTTP, redno znova naložen. Brez oblike, ki bi jo bilo treba najprej razčleniti, brez vmesnika, za katerega bi potrebovali orodje.

Praktično vsak požarni zid in vsak povratni posrednik (reverse proxy) lahko prebere tak seznam in iz njega ustvari pravila. Proizvajalci to imenujejo različno, mehanizem pa je povsod enak:

  • OPNsense in pfSense — URL Table Alias: seznam naslovov se naloži prek HTTP, uporabi kot alias v pravilih požarnega zidu, posodobitev v urnem ali dnevnem ritmu
  • HAProxy — datoteke ACL in zemljevidi (Maps): src -f sperrliste.txt v pravilu http-request deny, ponovno naložljivo prek API-ja med delovanjem brez ponovnega zagona
  • nginx — modul geo z vključeno datoteko naslovov ali ukazi deny iz ustvarjene datoteke include
  • Fortinet FortiGate — External Block List oziroma Threat Feed: en URL, iz katerega požarni zid prejme seznam IP in ga uporablja v pravilnikih
  • Palo Alto Networks — External Dynamic List (EDL): isto načelo, kot lasten tip objekta v varnostnih pravilnikih
  • Check Point — Custom Intelligence Feeds in IP Block Lists prek URL-ja
  • Cisco Secure Firewall (Firepower) — Security Intelligence Feeds z lastnimi viri seznamov
  • Sophos Firewall — Third-Party Threat Feeds: seznami naslovov z URL-ja kot vir za pravila blokiranja
  • Juniper SRX — Dynamic Address Entries iz virov
  • MikroTik RouterOS — Address Lists, napolnjeni s skriptom in fetch z URL-ja
  • CrowdSec — lastni seznami kot vir za bouncerje na vsakem podprtem sistemu

Natanko v tej obliki Web RBL dostavlja svoj seznam blokiranih naslovov. Požarni zid zavrže pakete, še preden dosežejo spletni strežnik — in z njimi tudi vsak drug poskus istega naslova, na primer na poštni strežnik ali prehod VPN.

Obe smeri, a na pravem mestu

Pot deluje tudi obratno: v Web RBL je mogoče vnesti kateri koli seznam RBL — URL, ena stopnja, končano. Izhodna vozlišča Tor, Spamhaus DROP, FireHOL in blocklist.de so že prednastavljeni, nadaljnji se dodajo s tremi kliki. Modul vsak seznam razčleni na naslovna območja in vsako vprašanje preveri z njimi, v nekaj mikrosekundah.

A vendar: smiselneje je tuje sezname uporabljati na požarnem zidu pred njim. Iz treh razlogov. Požarni zid vidi vse storitve, ne le HTTP — naslov s seznama Spamhaus naj ne uspe niti na poštnem strežniku niti na VPN. Zavrača na ravni paketov, še preden sploh nastane povezava, in tako aplikacijskega strežnika ne stane nič. In je mesto, kjer se taki seznami vsekakor vzdržujejo; druga kopija v aplikaciji je drugo mesto, ki lahko zastara.

Čemu so potem seznami v modulu še vedno koristni: za tisto, česar požarni zid ne zna. Prijavne maske ne pozna. Web RBL lahko naslovu s seznama Tor zavrne dostop do prijave in kljub temu dostavi spletno stran — kdor želi brati anonimno, naj to lahko počne; kdor želi anonimno preizkušati gesla, ne. In lahko uspešno prijavo z naslova s seznama javi kot primer suma. Oboje potrebuje seznam tam, kjer se prijava dogaja.

Ocena namesto občutka

Naslov, ki je enkrat vprašal po /wp-login.php, je nekaj drugega kot tisti, ki je v dveh dneh s petimi različnimi vzorci obiskal tri domene. Web RBL to preračuna v oceno od 0 do 100 — iz tega, kar je videl sam, brez tuje storitve in brez poizvedbe navzven.

Vnos Web RBL z oceno 84 in obrazložitvijo

En vnos: 99 zadetkov, ocena 84 in obrazložitev v jasnem besedilu — najtežji vzorec, pet različnih resnih vzorcev, dva sumljiva dneva, več kot dvajset zadetkov.

Ocena odloča o dveh stvareh. Od nastavljive vrednosti naprej je prijava prepovedana — spletna stran ostane berljiva, a kdor je že iskal dostopne podatke, ne dobi priložnosti, da bi najdene preizkusil. In uspešna prijava z naslova z oceno se javi: takrat nekdo ni več ugibal, ampak je vedel. Bodisi je bil upravičeni uporabnik na poti bodisi so dostopni podatki izginili — modul tega ne odloča, ampak to predloži nekomu, ki lahko povpraša. Samega gesla se pri tem nikjer ne dotakne.

Seznam blokiranih naslovov Web RBL, filtriran po oceni od 40 naprej

Seznam blokiranih naslovov, filtriran po oceni od 40 naprej: število zadetkov, sumljivi dnevi, prizadete domene in zadnja pot za vsak naslov.

Kaj Web RBL ščiti — zaščitni učinek podrobno

1. Dostopni podatki ostanejo neodkriti

Največji izmerjeni razred napadov ne išče lukenj v Odoo, temveč pozabljene skrivnosti. V sedemnajstih dneh:

  • 57.721 poizvedb po datotekah .env — v njih so gesla baz podatkov, ključi API in skrivnosti sej
  • 5.535 poizvedb po konfiguracijskih datotekah
  • 4.388 poizvedb po dostopnih podatkih za oblak: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
  • 2.811 poizvedb po imenikih .git — kdor jih najde, prenese celotno izvorno kodo skupaj z zgodovino
  • 1.907 poizvedb po navodilih za gradnjo, kot sta .github/workflows/deploy.yml ali .gitlab-ci.yml, v katerih so navedeni registri in imena ključev

Odločilno pri tem ni število poizvedb, temveč število različnih naslovov: /credentials.json je prišel iz 98 naslovov, /.git-credentials iz 92. To ni posamezen skener, temveč standardni repertoar, ki po vsem svetu teče hkrati.

2. Poskusi prijave tečejo v prazno — trajno

Odoo ima vgrajeno lastno zavoro proti preizkušanju gesel. Ima tri omejitve, ki so dokumentirane v samem izvorni kodi Odoo: števec je v delovnem pomnilniku delovnega procesa in se ob vsakem ponovnem zagonu ponastavi, samo zakasni, namesto da bi blokiral, in šteje izključno poskuse, ki pridejo do preverjanja gesla.

Web RBL poseže na istih mestih, a zapisuje v bazo podatkov. Zato velja:

  • Stanje preživi vsak ponovni zagon in velja za vse delovne procese
  • Zajeti sta obe poti: prijavna maska /web/login in vmesnika /xmlrpc/2/common in /jsonrpc
  • Zajeti so tudi poskusi, ki nikoli ne pridejo do preverjanja gesla — na primer prijave brez veljavne oznake seje
  • Neuspel dostop do upravitelja baz podatkov se všteje; to je najresnejši poskus prijave sploh

Prag za prijave je nastavljen na deset, razlog pa je meritev: od devetih neuspelih prijav v sedemnajstih dneh je večina izhajala od strank, ki so si dostop sami nastavljale na drugi napravi in pri tem vnesle napačno domeno — v enem primeru lastno, le z vezajem namesto pike. Blokada ob prvem neuspelem poskusu bi tako zadela ne napadalcev, temveč stranke pri nastavljanju.

Kdor pa kljub temu trka naprej, čeprav je strežnik že odgovoril „prosimo, malo počakajte“, je takoj blokiran. To sporočilo prebere človek in počaka; kdor ga ignorira, je program. Lasten vzorec s pragom nič ujame prav ta primer in ne more zadeti sodelavca: tja pride samo kdor ima za sabo že deset neuspelih poskusov in nato nadaljuje.

3. Napad strežnika ne stane več nič

Sonda na pot, kot je /@fs/../../.env, je bila pred modulom draga: Odoo poišče stran z napako, jo izriše, se pri sestavljanju naslova spotakne ob segmente s pikami in zato nato spodleti tudi pri strani z napako strani z napako. Dva sklada dnevniških zapisov (stack trace) na sondo. Izmerjenih je bilo 28.401 takih napak v sedemnajstih dneh, poleg tega 9.467 posledičnih napak.

Web RBL poseže v ir.http._match, torej pred iskanjem poti. Odgovor nastane brez predloge, brez dostopa do baze podatkov zunaj preverjanja blokade in brez vrstice v dnevniku. Preverjanje glede na seznam izjem, sezname groženj in pravila po državah teče iz predpomnilnika prek razvrščenih naslovnih območij — nekaj mikrosekund, tudi pri več kot trideset tisoč območjih.

4. Požarni zid napadalca vrže ven, še preden pride

Seznam blokiranih naslovov se objavi kot seznam RBL, ki ga HAProxy in OPNsense neposredno preberejo. Napadalec tako sploh ne doseže več spletnega strežnika — niti nobene druge storitve na istem gostitelju. Enkrat kot zlonamerno prepoznan dostop tako nazaj zaščiti celoten stroj.

Tri stopnje: blokiraj, štej, javi

Vsaka poizvedba v prazno ni napad. Web RBL zato razlikuje tri stopnje, stopnjo pa je mogoče spremeniti za vsak vzorec, ne da bi se dotaknili kode.

StopnjaSprožilna poizvedbaPosledica za naslov
blokirajse zavrneblokiran 24 ur, po treh sumljivih dneh trajno
štejsteče skozile zabeleženo, brez blokade
javisteče skozizabeleženo z besedilom izsledka, nikoli blokirano

Za sezname groženj in države obstaja četrta: brez dostopa do prijave. Spletna stran ostane berljiva, prijavna maska in vmesniki so zaprti. To je srednja pot za vse, kar je sumljivo, a ni nujno zlonamerno — Tor, območje datacentra, država brez strank.

Kateri napadi se prepoznajo

Vsi vzorci so preverjeni na pravem prometu. Število različnih naslovov je namenoma ob njih — pokaže, ali vzorec zadene posamezen skener ali razširjen način delovanja.

Razred napadaPoizvedbeNaslovi
Odtekanje datotek .env57.721223
Sonde PHP12.237256
Path traversal z vrednim ciljem10.04664
Konfiguracijske datoteke5.535114
Dostopni ključi za oblak4.388152
Sonde WordPress3.366385
Odtekanje .git2.811255
Izvidovanje Odoo (upravitelj baz podatkov, poizvedba po različici)2.500213
Verige orodij umetne inteligence in izvajanje ukazov (/mcp, /api/fs/exec)2.45074
Navodila za gradnjo (CI/CD)1.90788
Končne točke GraphQL1.87871

Pozornost vzbuja najnovejši razred. /api/fs/exec je bil poklican 369-krat iz 54 različnih naslovov — to ni branje, temveč poskus izvajanja ukazov. Takih cijev pred dvema letoma ni bilo; izvirajo iz vmesnikov novih orodij umetne inteligence in čakalnih vrst opravil. Kdor svojo obrambo usmeri le na WordPress in PHP, od tega ne vidi ničesar. V ocenjevanju ta razred ustrezno težko tehta.

Seznami groženj in država izvora

Seznami groženj Web RBL: Tor, Spamhaus DROP, FireHOL, blocklist.de

Štirje seznami, 32.851 naslovnih območij, vsi na „samo javi“. Vsak nadaljnji seznam je naslov in stopnja.

Tuj seznam je trditev, ki jo postavi nekdo drug, iz razlogov, ki jih ne poznamo, o prometu, ki ga nismo nikoli videli. Lahko je napačen, zastarel ali namenjen drugemu namenu: blocklist.de zbira predvsem naslove, ki so drugje preizkušali prijave SSH, kar o spletnem strežniku pove malo. Zato Web RBL vodi tuje sezname ločeno od lastnega seznama blokiranih naslovov in zato je privzeta nastavitev javi. In lasten seznam izjem vedno zmaga: stranka, ki jo poznamo, tehta več kot ocena tretje osebe.

Država izvora je ob vsakem zadetku in vsakem naslovu. Za presojo je nenadomestljiva — poskus prijave iz lastne države ob desetih dopoldne je nekaj drugega kot poskus iz države brez ene same stranke. Za splošno izključevanje je manj uporabna, in to povedo lastne številke: napadalci na našem seznamu so večinoma prihajali iz oblačnih območij v Belgiji, Finski in na Nizozemskem. Blokada vsega zunaj nemško govorečega prostora jih ne bi zadela — zadela pa bi lastne sodelavce na dopustu in stranke na poslovni poti.

Pravila po državah v Web RBL: dostavljena prazna, s pojasnilom

Pravila po državah so dostavljena prazna, pogled pa pove, zakaj.

Napačne konfiguracije javiti, ne blokirati

Najpogostejši primer v pravem prometu ni niti napad niti obiskovalec, temveč pokvarjena programska oprema, ki spletni strežnik poistoveti z nečim drugim:

  • 1.367 klicev spletnega vmesnika NAS QNAP — odjemalec za sinhronizacijo, katerega cilj ni več pravilen. En sam priključek je trkal 962-krat.
  • 65 poizvedb Autodiscover — Outlook, ki spletno domeno šteje za svoj Exchange

Takšni naslovi se nikoli ne blokirajo. Blokada napake ne odpravi, ampak jo skrije — in zadene tistega, čigar naprava je že tako napačno nastavljena. Namesto tega nastane vnos z besedilom izsledka in prizadetimi domenami, iz katerega po želji samodejno nastane tiket: natanko eden na naslov, in če se zapre in naslov spet vzbudi pozornost, se isti tiket ponovno odpre, namesto da bi nastal drugi.

Prepoznajo se QNAP, Synology, Exchange Autodiscover, ActiveSync ter odjemalci WebDAV, CalDAV in CardDAV. Vzorci pri tem navajajo natančna imena datotek in imenike, nikoli golih končnic: v istem imeniku /cgi-bin/ so nedolžni klici za sinhronizacijo tik ob klasičnih sondah, kot je printenv.pl.

Seznam izjem: naslovi, ki se nikoli ne blokirajo

Cena zmote ni pri vseh naslovih enaka. Pri skenerju iz datacentra lažni alarm ne stane nič. Pri nasprotni točki tunela med lokacijama pa stane lokacijo.

Zato obstaja drugi seznam, ki stoji pred prvim: naslovi in omrežja, ki se nikoli ne blokirajo. Pri tem nič ne utiša — kdor je na njem, se še naprej preverja in beleži, odpade le posledica. To je razlika do izjeme v požarnem zidu: ta naredi slepega, ta naredi le potrpežljivega.

Polni se dnevno iz dveh virov: iz samega požarnega zidu z vsemi nasprotnimi točkami VPN, da novo vzpostavljen tunel ni odvisen od tega, ali kdo misli na seznam blokiranih naslovov — in iz objavljenih naslovnih območij Googla in Microsofta za njuna iskalna pajka. Samo tako je mogoče razlikovati pravi Googlebot od skenerja, ki se tako imenuje. Iskalnikov se ne sme nikoli blokirati; kdor jih izključi, svojo stran brez poti nazaj odstrani iz indeksiranja.

Pri tem velja pravilo, ki je pomembnejše od primerjave: Prazen odgovor nikoli ne briše. Če vir ne odgovori, odgovori prazno ali nerazumljivo, seznam ostane nespremenjen. Seznam izjem, ki se ob motnji sam izprazni, v najslabšem možnem trenutku odnese s seboj vse tunele.

Če vnos na seznamu izjem nosi stranko, se vsak zadetek iz njenega omrežja dodeli njej. Napačna konfiguracija ima tako takoj kontaktno osebo, ne da bi moral kdo iskati naslove.

Obvezni podatki in avtomatizirani zbiralci podatkov

Impresum ni navadna stran. Ostati mora dosegljiv za ljudi, saj blokada na njem ustvari prav tisto kršitev, ki jo zbiralec išče. Hkrati je to stran, na kateri sta ime in naslov — in s tem cilj strojnega pobiranja.

Pri avstrijskem valu opominov zaradi vdelanih Googlovih pisav so dnevniki pokazali, da dopisi niso izhajali iz posameznih obiskov, temveč iz avtomatiziranega obsežnega pregleda: različni, nepovezani gostitelji v razmiku milisekund.

Web RBL to reši z znižanjem stopnje namesto izjeme. Kanonična pot /impressum ne ustreza nobenemu vzorcu in ostane vedno dosegljiva. Tuji zapisi, kot je /impressum.php — ki ga na strani Odoo ne more biti — se javijo, in kdor strojnega pobiranja ne želi sprejeti, spremeni en parameter. sitemap in robots sta iz tega izvzeta in načeloma ne moreta biti blokirana: ne vsebujeta osebnih podatkov, njuno pridobivanje pa je naloga vsakega iskalnega pajka.

Domena in identifikator: kar manjka v dnevniku dostopov

Dnevnik dostopov werkzeug ne zapisuje niti poklicanega gostitelja niti identifikatorja klicatelja. Odoo seveda dobi oboje — brez gostitelja pri več spletnih straneh sploh ne bi mogel izbrati prave. Naknadno pa branja ni mogoče.

Web RBL oboje shrani za vsak zadetek. To odgovori na dve vprašanji, na kateri sicer ni mogoče odgovoriti: katera spletna stran napačno konfiguriran odjemalec kliče — in s tem, kateri stranki domena pripada — ter ali naslov obišče eno stran ali vse. Več nepovezanih domen istega naslova je znak obsežnega pregleda in povišajo oceno.

Koliko pomeni identifikator, je pokazala analiza na eni naših spletnih strani: več kot sedemdeset odstotkov celotnega prometa je tam odpadlo na enega samega klicatelja, razporejenega prek več kot sto naslovov. Brez identifikatorja bi to izgledalo kot porazdeljen scraper. Bil je GPTBot, pajek podjetja OpenAI — ponovno in ponovno je spraševal po robots.txt in se obnašal povsem korektno.

Varnostni vidiki podrobno

1. Prepoznavanje posrednika (proxy) — najnevarnejše mesto sploh

Če Odoo teče za povratnim posrednikom in je proxy_mode napačno nastavljen, modul pri vsaki poizvedbi vidi isti naslov: naslov posrednika. Blokada bi potem izključila vse obiskovalce hkrati.

Zato Web RBL pred vsako blokado preveri, ali je določitev naslova zanesljiva. Zahteva proxy_mode skupaj z glavo za posredovanje, zavrne delo, če posredovanje brez proxy_mode prispe, in prav tako zavrne delo pri več kot enem vmesnem posredniku. Ob dvomu se ne blokira.

2. Lastnih omrežij nikoli

Zasebna naslovna območja, loopback, link-local in CGNAT so trdno izvzeti. Na seznam ne morejo priti v nobenem primeru, tudi na roke ne. Enako velja za tuje sezname: zasebna in rezervirana območja ter absurdno velika omrežja se pri branju zavržejo.

3. Lastna napaka ne sme odnesti spletne strani

Celotno preverjanje teče v zaščiti, ki ujame vsako napako. Kar tu spodleti, se zabeleži, poizvedba pa teče nespremenjeno naprej. Zaščitni modul, ki ob lastni napaki odnese spletno stran, je slabši od nobenega. Vse poizvedbe v poti zahteve tečejo poleg tega brez jezika brskalnika obiskovalca in brez razvrščanja po prevedenih poljih — obiskovalec z nenameščenim jezikom ne sme spraviti preverjanja v spodletelo stanje.

4. Opazovati pred blokiranjem

Po namestitvi je blokiranje naslovov s seznama pri običajnih poizvedbah izklopljeno. Sonde se zavračajo in beležijo, vse drugo teče skozi. Tako je mogoče nekaj dni brati, kdo dejansko pristane na seznamu, preden je kdo izključen. Enako velja za prepoznavanje vedenja, sezname groženj in pravila po državah: najprej javi, blokiraj po presoji.

5. Ozki vzorci namesto širokih mrež

Napačno prepoznan obiskovalec je dražji od spregledane sonde. Vsak vzorec zato nosi svojo stopnjo, ki jo je mogoče spremeniti za vsak vzorec. Sama končnica datoteke redko zadošča: pri .php stoji 14.012 pravih sond proti peščici starih povezav, pri .asp je razmerje obratno. Take odločitve je treba meriti, ne ocenjevati.

6. Ročna sprostitev ostane

Kdor naslov sprosti, je imel razlog. Nadaljnji zadetek te odločitve ne razveljavi tiho.

7. Seznam je zaščiten, a ni skrivnost

Končna točka zahteva žeton in brez veljavnega žetona odgovori z 404, ne s 403 — obstoj naslova se tako sploh ne potrdi. Primerjava teče v konstantnem času. Sam seznam ne vsebuje ničesar zaupnega: sestavljajo ga naslovi, ki so sami potrkali pri nas.

8. Nobenih skrivnosti v knjigovodstvu

Pri neuspelih prijavah se zabeleži poskusno uporabniško ime, nikoli geslo. Pri upravitelju baz podatkov se iz posredovanih vrednosti sploh nič ne prebere: tam je na prvem mestu glavno geslo, vnos v seznamu blokiranih naslovov pa se znajde v vsaki varnostni kopiji baze podatkov. Licenčni ključ za GeoLite2 je samo v sistemskem parametru in v nobeni vrstici dnevnika.

9. Vaba ne izda nič uporabnega

Po želji Web RBL odgovarja na sonde z izmišljeno vsebino, ki vsebuje enolično vrednost kanarček. Kdor to vrednost pozneje pokliče, je prebral ponarejen odgovor in na podlagi tega ukrepal — lažni alarm je pri tem izključen. Vabe ne vsebujejo uporabnih podatkov, pravih poti in veljavnih dostopnih podatkov. Ta funkcija je dobavljena izklopljena, saj navzven opazno spreminja vedenje.

Česa modul ne zmore

Ne nadomešča ne požarnega zidu ne požarnega zidu za spletne aplikacije (WAF). Prepozna znane vzorce sondiranja v poteh, neuspele prijave in sumljivo vedenje — ne napadov na obrazce, ne poskusov vrivanja v parametre.

Poleg tega vidi samo to, kar se vrne prek HTTP. Kar napadalec stori z odtujenimi dostopi do baze podatkov ali poštnega predala, ostane nevidno — in prav zato so vrednosti kanarček poti in ne dostopni podatki.

In ne nadomešča skrbnosti: modul, ki zavrača sonde .env, po pomoti dostavljene datoteke .env ne naredi neškodljive.

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

Modul zahteva Odoo 19 Community in nima odvisnosti razen base in web. Povezava s tiketi je izbirna in ne potrebuje določenega sistema tiketov; brez njega se preprosto nič ne zgodi. Država izvora potrebuje brezplačno bazo GeoLite2 podjetja MaxMind; če je ni, polje ostane prazno in vse drugo deluje nespremenjeno.

Več o tem: Kako se Web RBL umesti v celovito varnostno arhitekturo -- skupaj s požarnim zidom, dvofaktorsko overitvijo in pooblastili, vključno z navodili po korakih: Pravilna kombinacija varnostne arhitekture Odoo 19.

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