Odoo 19 Community: Web RBL – blokeerimisloend ründeliikluse vastu oma veebilehtedel

Lähtekood: github.com/Alex0176/odoo-web-rbl — AGPL-3, vabalt kasutatav.

Kes haldab Odoo serverit internetis, saab külalisi. Mitte juhuslikult, vaid katkematult. Seitsmeteistkümne päeva jooksul oleme oma viiel veebilehel kirja pannud ja analüüsinud 731 297 päringut. Neist 110 511 ei olnud külastajad, vaid automatiseeritud otsing nõrkuste, sisselogimisandmete ja konfiguratsioonifailide järele.

See postitus kirjeldab Web RBL-i, avatud lähtekoodiga moodulit Odoo 19 Community jaoks, mis tuvastab selle liikluse, hindab, registreerib ja tagasi lükkab – ning avaldab blokeerimisloendi RBL-loendina, ehk vormingus, mida tulemüürid ja pöördproksid otse loevad. Kõik arvud pärinevad tootmiskeskkonnast.

Mida moodul oskab — funktsioonid ülevaatlikult

Funktsioon	Mida see teeb	Edastamine
Mustrituvastus	Tuvastab sondeerimisi tee ja laiendi järgi: .env, .git, konfiguratsioonifailid, pilvevõtmed, CI/CD ehitusjuhendid, WordPress, PHP, tee läbimine (path traversal), andmebaasihaldurid, GraphQL, käskude käivitamine liidese /api/fs/exec ja sarnaste liideste kaudu	blokeeri
Kolm taset mustri kohta	blokeeri, loe või teata — mustri kaupa ümberlülitatav, ilma koodita	mustri kohta
Läved	Nii mitu sama mustri tabamust, enne kui blokeeritakse; sisselogimiste puhul kümme	10 sisselogimisel
Sisselogimiskaitse	Ebaõnnestunud sisselogimised nii sisselogimisvormi kui ka XML-RPC/JSON-RPC kaudu, ebaõnnestunud seansikontrollid, juurdepääsud andmebaasihaldurile — andmebaasis, mitte töömälus	sees
Robotituvastus sisselogimisel	Kes eirab ooteteadet pärast kümmet ebaõnnestunud katset ja jätkab koputamist, blokeeritakse kohe	blokeeri
Käitumistuvastus	Aadressid, mis tekitavad viie minuti jooksul kakskümmend vealehte ja vaevu ühe tabamuslehe — ehk oletavad lugemise asemel	teata
Hinnang 0–100	Kui kindel on, et aadressi taga on ründaja? Mustri raskusest, erinevate mustrite arvust, silmatorkavatest päevadest, mõjutatud domeenidest ja tabamuste arvust — koos selge tekstiga põhjenduse kohta	sees
Sisselogimispiirang hinnangu alusel	Seatava hinnangu saavutamisel on sisselogimine keelatud, veebileht jääb loetavaks	alates 40
Kahtlus varastatud sisselogimisandmete kohta	Kahtlasest aadressist õnnestunud sisselogimisest teatatakse ja soovi korral määratakse see ülesandeks — üks kord aadressi ja päeva kohta	sees
Ohunimekirjad	Tor-i väljumissõlmed, Spamhaus DROP, FireHOL Level 1 ja blocklist.de on eelseadistatud; iga muu RBL-nimekirja saab lisada aadressi kaudu, igapäevane võrdlus, igal nimekirjal oma tase	teata
Sisselogimisele ligipääsu pole	Neljas tase nimekirjadele ja riikidele: veebileht on loetav, sisselogimisvorm ja liidesed on suletud — sobiv vastus Tor-ile	Valik
Päritoluriik	Riik iga tabamuse ja aadressi kohta GeoLite2 kaudu; andmebaasi hoiab moodul ise ajakohasena tasuta litsentsivõtmega	kuva
Riigireeglid	Blokeerimine, sisselogimisele ligipääsu keelamine, teatamine või sõnaselgelt lubatud — riigi kaupa, teadlikult ilma vaikeväärtuseta	puudub
Valekonfiguratsioonid	QNAP, Synology, Exchange Autodiscover, ActiveSync ning WebDAV/CalDAV/CardDAV tuvastatakse, mitte kunagi ei blokeerita ning lisatakse tööloendisse koos tuvastuse ja mõjutatud domeeniga	teata
Pilet aadressi kohta	Tuvastusest saab soovi korral pilet — täpselt üks aadressi kohta, suletud pilet avatakse uuesti, mitte ei dubleerita	välja
Kohustuslikud lehed ja kogujad	Kanooniline impressumi tee jääb alati kättesaadavaks; võõraste kirjapiltide masinlik läbiproovimine tuvastatakse ja soovi korral blokeeritakse	teata
Lubatud nimekiri	Aadressid ja võrgud, mida kunagi ei blokeerita; täieneb iga päev tulemüürist (VPN-i vastuspooled) ning Googlebot'i ja Bingbot'i avaldatud aadressivahemikest	sees
Kliendi seostamine	Kliendi võrgust pärinev tabamus seostatakse temaga — lubatud nimekirja põhjal, mitte kunagi käsitsi ära arvates	sees
Domeen ja tunnus iga tabamuse kohta	Millisele veebilehele pöörduti ja millise User-Agent'iga — mõlemad puuduvad ligipääsulogist	sees
Analüüs	Diagramm ja pivot kõigi tabamuste kohta: mustri, päeva, domeeni, riigi ja aadressi kaupa	sees
Peibutis	Sondid saavad väljamõeldud vastused kanaarilinnu väärtusega; kes selle hiljem välja küsib, on neid lugenud	välja
RBL-i väljastamine	Blokeerimisnimekiri puhta aadressinimekirjana või JSON-ina eraldi, tokeniga kaitstud aadressil — HAProxy, OPNsense'i ja iga URL-nimekirju lugeva tulemüüri jaoks	sees

Kõik, mis tarnitakse seadega teata, välja või valik, on teadlikult nii: kes blokeeringu käivitab, peaks seda tegema seepärast, et on mõned päevad jälginud, kes sinna jääb — mitte seepärast, et vaikeväärtus seda nõudis.

Analüüs: tabamused mustri kaupa seitsme päeva jooksul. Kõrgeim tulp on .env-failide otsimine.

RBL-nimekirjad: standardne viis blokeeringute edastamiseks

RBL tähendab Real-time Blackhole List. Mõiste pärineb e-posti maailmast, kus Spamhaus ja teised avaldavad alates üheksakümnendatest lurjuslike saatjate aadresside nimekirju. Põhimõte on ülimalt lihtne ja just seetõttu nii levinud: üks aadress rea kohta, kättesaadav HTTP kaudu, korrapäraselt uuesti laaditav. Pole vormingut, mida peaks kõigepealt parsima, pole liidest, mille jaoks oleks vaja vahendit.

Praktiliselt iga tulemüür ja iga pöördvaheserver (reverse proxy) oskab sellist nimekirja sisse lugeda ja sellest reegleid koostada. Tootjad nimetavad seda erinevalt, kuid mehhanism on kõikjal sama:

• OPNsense ja pfSense — URL Table Alias: aadressinimekiri laaditakse HTTP kaudu, kasutatakse aliasena tulemüürireeglites, värskendamine tunni- või päevarütmis
• HAProxy — ACL-failid ja Maps: src -f sperrliste.txt http-request deny-reeglis, uuesti laaditav käitusaja API kaudu ilma taaskäivituseta
• nginx — geo-moodul koos kaasatud aadressifailiga või deny-direktiivid genereeritud include-failist
• Fortinet FortiGate — External Block List ehk Threat Feed: üks URL, mille kaudu tulemüür hangib IP-nimekirja ja kasutab seda poliitikates
• Palo Alto Networks — External Dynamic List (EDL): sama põhimõte, eraldi objektitüübina turvapoliitikates
• Check Point — Custom Intelligence Feeds ja IP Block Lists URL-i kaudu
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds oma nimekirjaallikatega
• Sophos Firewall — Third-Party Threat Feeds: URL-ilt pärinevad aadressinimekirjad blokeerimisreeglite allikana
• Juniper SRX — Dynamic Address Entries voogudest
• MikroTik RouterOS — Address Lists, täidetud skripti ja fetch-käsuga URL-ilt
• CrowdSec — oma nimekirjad allikana bouncer'itele igas toetatud süsteemis

Just selles vormingus väljastab Web RBL oma blokeerimisnimekirja. Tulemüür viskab paketid minema enne, kui need veebiserverini jõuavad — ja koos nendega ka sama aadressi iga teise katse, näiteks e-posti serverisse või VPN-lüüsi.

Mõlemad suunad, aga õige koht

See tee toimib ka vastupidi: Web RBL-i saab lisada mis tahes RBL-nimekirja — üks URL, üks tase, valmis. Tor-i väljumissõlmed, Spamhaus DROP, FireHOL ja blocklist.de on eelseadistatud, rohkem lisandub kolme klõpsuga. Moodul jagab iga nimekirja aadressivahemikeks ja kontrollib iga päringut nende vastu, mõne mikrosekundiga.

Ja siiski: mõttekam on kasutada võõraid nimekirju tulemüüris enne seda. Kolmel põhjusel. Tulemüür näeb kõiki teenuseid, mitte ainult HTTP-d — Spamhausi nimekirjas olev aadress peaks ebaõnnestuma ka e-posti serveris ja VPN-is. Tulemüür viskab minema pakettide tasemel, enne kui ühendus üldse tekib, ja ei koorma seega rakendusserverit. Ja see on koht, kus selliseid nimekirju niikuinii hallatakse; teine koopia rakenduses on teine koht, mis võib aeguda.

Mida siis nimekirjad moodulis veel annavad: seda, mida tulemüür ei oska. Ta ei tunne sisselogimisvormi. Web RBL oskab Tor-i nimekirja aadressilt keelata ligipääsu sisselogimisele ja ometi veebilehe kätte toimetada — kes tahab anonüümselt lugeda, peab saama; kes tahab anonüümselt paroole läbi proovida, mitte. Ja see oskab teatada õnnestunud sisselogimisest nimekirjas olevalt aadressilt kui kahtlusjuhtumist. Mõlema jaoks on vaja nimekirja seal, kus sisselogimine toimub.

Hindamine kõhutunde asemel

Aadress, mis on korra küsinud /wp-login.php, on midagi muud kui see, mis on kahel päeval viie erineva mustriga kolmes domeenis ringi käinud. Web RBL arvutab selle hindeks vahemikus 0 kuni 100 — sellest, mida ta ise näinud on, ilma välise teenuseta ja ilma päringuta väljapoole.

Üks kirje: 99 tabamust, hinne 84, ja põhjendus selges keeles — raskeim muster, viis erinevat tõsist mustrit, kaks kahtlast päeva, üle kahekümne tabamuse.

Hinne otsustab kahe asja üle. Seadistatavast väärtusest alates on sisselogimine keelatud — veebileht jääb loetavaks, kuid kes on juba pääsuandmeid otsinud, ei saa võimalust leitud andmeid proovida. Ja hindega aadressilt õnnestunud sisselogimisest teatatakse: siis ei ole keegi enam lihtsalt arvanud, vaid teadnud. Kas õigustatud kasutaja oli liikvel või pääsuandmed on kadunud — moodul ei otsusta seda, vaid esitab selle kellelegi, kes saab järele küsida. Parooli ennast ei puututa seejuures kusagil.

Blokeerimisnimekiri, filtreeritud hindega alates 40: tabamuste arv, kahtlased päevad, mõjutatud domeenid ja iga aadressi viimane tee.

Mida Web RBL kaitseb — kaitsemõju üksikasjalikult

1. Pääsuandmed jäävad avastamata

Suurim mõõdetud ründeklass ei otsi Odoo nõrkusi, vaid maha jäänud saladusi. Seitsmeteistkümne päeva jooksul:

• 57.721 päringut .env-failidele — seal asuvad andmebaasiparoolid, API-võtmed ja sessiooni saladused
• 5.535 päringut konfiguratsioonifailidele
• 4.388 päringut pilve pääsuandmetele: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 päringut .git-kataloogidele — kes sellise leiab, laadib alla kogu lähtekoodi koos ajalooga
• 1.907 päringut ehitusjuhistele nagu .github/workflows/deploy.yml või .gitlab-ci.yml, kus on kirjas registrid ja võtmete nimed

Otsustav pole seejuures päringute arv, vaid erinevate aadresside arv: /credentials.json tuli 98 aadressilt, /.git-credentials 92-lt. See ei ole üksik skanner, vaid standardrepertuaar, mis töötab kogu maailmas korraga.

2. Sisselogimiskatsed jooksevad tühjalt — püsivalt

Odoo-l on endal piduri paroolide läbiproovimise vastu. Sellel on kolm piiri, mis on dokumenteeritud Odoo lähtekoodis endas: loendur asub töötlusprotsessi mälus ja nullitakse iga taaskäivitusega, see ainult viivitab, mitte ei blokeeri, ja see loeb ainult katseid, mis jõuavad paroolikontrollini.

Web RBL alustab samadest kohtadest, kuid kirjutab andmebaasi. Seega kehtib:

• Seis elab üle iga taaskäivituse ja kehtib kõigis töötlusprotsessides
• Arvesse võetakse mõlemad teed: sisselogimisvorm /web/login ning liidesed /xmlrpc/2/common ja /jsonrpc
• Arvesse võetakse ka katsed, mis ei jõua kunagi paroolikontrollini — näiteks sisselogimised ilma kehtiva sessioonitunnuseta
• Ebaõnnestunud juurdepääs andmebaasihalduril loetakse kaasa; see on kõige tõsisem sisselogimiskatse üldse

Sisselogimiste lävi on seatud kümnele ja põhjuseks on mõõtmine: üheksast seitsmeteistkümne päeva jooksul ebaõnnestunud sisselogimisest pärines enamik klientidelt, kes seadistasid endale ligipääsu ise teisel seadmel ja sisestasid seejuures vale domeeni — ühel juhul oma enda, ainult punkti asemel sidekriipsuga. Blokeering esimese ebaõnnestunud katse järel ei oleks seega tabanud ründajaid, vaid kliente seadistamise ajal.

Kes seevastu jätkab koputamist, kuigi server on juba vastanud „palun oota hetk“, blokeeritakse kohe. Seda teadet loeb inimene ja ootab; kes seda ignoreerib, on programm. Oma muster läveväärtusega null püüab täpselt selle juhu kinni ja see ei saa tabada kolleegi: sinna jõuab ainult see, kellel on juba kümme ebaõnnestunud katset selja taga ja kes seejärel jätkab.

3. Rünnak ei maksa serverile enam midagi

Sond sellisele teele nagu /@fs/../../.env oli enne moodulit kallis: Odoo otsib vealehte, renderdab selle, komistab aadressi koostamisel punktisegmentide otsa ja ebaõnnestub seejärel ka vealehe vealehega. Kaks stackitrace'i sondi kohta. Seitsmeteistkümne päeva jooksul mõõdeti 28.401 sellist viga, lisaks 9.467 järelviga.

Web RBL sekkub funktsiooni ir.http._match, ehk enne marsruudi leidmist. Vastus antakse ilma mallita, ilma andmebaasipöördumiseta väljaspool blokeerimiskontrolli ja ilma logirea. Kontroll lubatud nimekirja, ohunimekirjade ja riigireeglite vastu toimub vahemälust sorteeritud aadressivahemike kaudu — mõni mikrosekund, isegi üle kolmekümne tuhande vahemiku korral.

4. Tulemüür viskab ründaja välja, enne kui ta kohale jõuab

Blokeerimisnimekiri avaldatakse RBL-nimekirjana, mida HAProxy ja OPNsense otse loevad. Ründaja ei jõua seega enam veebiserverini — ega ühegi teise teenuseni samas hostis. Üks kord pahatahtlikuks tunnistatud juurdepääs kaitseb nii ta tagasiulatuvalt kogu masinat.

Kolm taset: blokeeri, loe, teata

Mitte iga tühja pöördumine ei ole rünne. Web RBL eristab seetõttu kolme taset ja taset saab mustri kaupa ümber seadistada, koodi puutumata.

Tase	Käivitav päring	Tagajärg aadressile
blokeeri	lükatakse tagasi	blokeeritud 24 tunniks, kolme kahtlase päeva järel püsivalt
loe	läheb läbi	ainult arvele võetud, blokeeringut pole
teata	läheb läbi	arvele võetud tuvastustekstiga, mitte kunagi ei blokeerita

Ohunimekirjade ja riikide jaoks on neljas tase: sisselogimisele ligipääsu pole. Veebileht jääb loetavaks, sisselogimisvorm ja liidesed on suletud. See on kesktee kõige jaoks, mis on kahtlane, kuid ei pea olema pahatahtlik — Tor, üks andmekeskuse vahemik, klientideta riik.

Milliseid rünnakuid tuvastatakse

Kõik mustrid on kontrollitud tegeliku liiklusega. Erinevate aadresside arv on teadlikult kõrval — see näitab, kas muster tabab üksikut skannerit või levinud tegutsemisviisi.

Ründeklass	Päringud	Aadressid
.env-i väljaimemine	57.721	223
PHP-sondid	12.237	256
Tee läbimine (path traversal) väärt sihtmärgiga	10.046	64
Konfiguratsioonifailid	5.535	114
Pilve pääsuvõtmed	4.388	152
WordPressi sondid	3.366	385
.git-i väljaimemine	2.811	255
Odoo luure (andmebaasihaldur, versioonipäring)	2.500	213
Tehisintellekti tööriistaahelad ja käskude täitmine (/mcp, /api/fs/exec)	2.450	74
Ehitusjuhised (CI/CD)	1.907	88
GraphQL-i lõpp-punktid	1.878	71

Tähelepanuväärne on kõige uuem klass. /api/fs/exec sai 369 päringut 54 erinevalt aadressilt — see ei ole lugemispöördumine, vaid katse käske täita. Selliseid sihtmärke ei olnud kaks aastat tagasi; need pärinevad uute tehisintellekti tööriistade liidestest ja ülesandejärjekordadest. Kes oma kaitse ainult WordPressile ja PHP-le suunab, ei näe sellest midagi. Hindamisel kaalub see klass vastavalt raskelt.

Ohunimekirjad ja päritoluriik

Neli nimekirja, 32.851 aadressivahemikku, kõik seadel „ainult teata“. Iga lisanimekiri on üks aadress ja üks tase.

Võõras nimekiri on väide, mille keegi teine esitab põhjustel, mida me ei tea, liikluse kohta, mida me kunagi näinud ei ole. See võib olla vale, aegunud või mõeldud muuks otstarbeks: blocklist.de kogub peamiselt aadresse, mis on mujal SSH-sisselogimisi läbi proovinud, ja see ütleb veebiserveri kohta vähe. Seetõttu hoiab Web RBL võõraid nimekirju eraldi oma blokeerimisnimekirjast ja seetõttu on vaikeväärtus teata. Ja oma lubatud nimekiri võidab alati: klient, keda me tunneme, kaalub rohkem kui kolmanda osapoole hinnang.

Päritoluriik on iga tabamuse ja aadressi juures. Hindamisel on see asendamatu — sisselogimiskatse oma riigist kell kümme hommikul on midagi muud kui katse riigist, kus meil pole ainsatki klienti. Üldiseks välistamiseks on see vähe sobiv, ja seda ütlevad meie enda arvud: ründajad meie nimekirjas tulid peamiselt pilvevahemikest Belgias, Soomes ja Hollandis. Blokeering kõigele väljaspool saksakeelset ruumi ei oleks neid tabanud — küll aga oma töötajaid puhkusel ja kliente ärireisil.

Riigireeglid tarnitakse tühjana ja vaade ütleb, miks.

Valekonfiguratsioonidest teatada, mitte neid blokeerida

Kõige sagedasem juhtum tegelikus liikluses ei ole ei rünne ega külastaja, vaid defektne tarkvara, mis peab veebiserverit millekski muuks:

• 1.367 pöördumist QNAP-i NAS-i veebiliidesele — sünkroonimiskliendile, mille siht ei ole enam õige. Üks ainus ühendus koputas 962 korda.
• 65 Autodiscover-päringut — Outlook, mis peab veebidomeeni oma Exchange'iks

Selliseid aadresse ei blokeerita kunagi. Blokeering ei kõrvalda defekti, vaid peidab selle — ja tabab seda, kelle seade on niigi valesti seadistatud. Selle asemel tekib kirje tuvastusteksti ja mõjutatud domeenidega, millest soovi korral tekib automaatselt pilet: aadressi kohta täpselt üks, ja kui see suletakse ning aadress satub uuesti silma, avatakse sama pilet uuesti, mitte ei teki teist.

Tuvastatakse QNAP, Synology, Exchange Autodiscover, ActiveSync ning WebDAV-, CalDAV- ja CardDAV-kliendid. Mustrid nimetavad seejuures täpseid failinimesid ja katalooge, mitte kunagi pelgalt laiendeid: Samas kataloogis /cgi-bin/ asuvad kahjutud sünkroonimispöördumised otse klassikaliste sondide nagu printenv.pl kõrval.

Lubatud nimekiri: aadressid, mida kunagi ei blokeerita

Eksimuse hind ei ole kõigi aadresside puhul sama. Andmekeskusest pärineva skanneri puhul ei maksa valehäire midagi. Asukohatunneli vastuspoole puhul maksab see terve asukoha.

Seetõttu on olemas teine nimekiri, mis seisab esimese ees: aadressid ja võrgud, mida ei blokeerita kunagi. See ei vaigista midagi — kes seal on, seda kontrollitakse ja arvestatakse edasi, ainult tagajärg jääb ära. See on erinevus tulemüüri erandist: viimane teeb pimedaks, see teeb ainult kannatlikuks.

See täidetakse iga päev kahest allikast: tulemüürist endast koos kõigi VPN-i vastuspooltega, et äsja seadistatud tunnel ei sõltuks sellest, et keegi blokeerimisnimekirja peale mõtleb — ja Google'i ja Microsofti avaldatud aadressivahemikest nende indekseerijate jaoks. Ainult nii saab päris Googlebot'i eristada skannerist, kes end nii nimetab. Otsingumootoreid ei tohi kunagi blokeerida; kes need välja lukustab, võtab oma lehe indekseerimisest tagasitee puudumisel maha.

Seejuures kehtib reegel, mis on olulisem kui võrdlus: Tühi vastus ei kustuta kunagi. Kui allikas ei vasta, vastab tühjalt või arusaamatult, jääb nimekiri muutmata. Lubatud nimekiri, mis tühjendab end häire korral ise, võtab kõige halvemal mõeldaval hetkel kõik tunnelid kaasa.

Kui lubatud nimekirja kirjel on klient, seostatakse iga tema võrgust pärinev tabamus temaga. Valekonfiguratsioonil on seega kohe kontaktisik, ilma et keegi peaks aadresse üles otsima.

Kohustuslikud andmed ja automatiseeritud andmekogujad

Impressum ei ole tavaline leht. See peab inimestele kättesaadavaks jääma, sest sellele blokeeringu seadmine loob just selle rikkumise, mida kogu ja otsib. Samal ajal on see leht, kus on nimi ja aadress — ja seega masinliku koristamise sihtmärk.

Austria hoiatuskirjade laine ajal, mis tulenes sisseehitatud Google'i fontidest, näitasid logid, et kirjad ei pärinenud üksikutest külastustest, vaid automatiseeritud massilisest läbikammimisest: erinevad, omavahel mitteseotud hostid millisekundiliste vahedega.

Web RBL lahendab selle madalamale tasemele viimisega erandi asemel. Kanooniline tee /impressum ei satu ühegi mustri alla ja jääb alati kättesaadavaks. Võõrad kirjapildid nagu /impressum.php — mida Odoo lehel ei saa olemas olla — märgitakse teatamisele ja kes ei soovi masinlikku koristamist taluda, muudab ühe parameetri. sitemap ja robots on sellest välja arvatud ja põhimõtteliselt blokeerimatud: need ei sisalda isikuandmeid ja nende hankimine on iga otsingumootori indekseerija ülesanne.

Domeen ja tunnus: mis ligipääsulogist puudub

werkzeug'i ligipääsulogi ei kirjuta üles ei nimetatud hosti ega päringu tegija tunnust. Odoo saab mõlemad loomulikult — ilma hostita ei saaks ta mitme veebilehe korral õiget üldse valida. Kuid hiljem ei saa seda enam järele vaadata.

Web RBL salvestab mõlemad iga tabamuse kohta. See vastab kahele küsimusele, mida muidu ei saa vastata: milline veebileht valekonfiguratsiooniga pöördub — ja seega, kellele domeen kuulub — ning kas aadress külastab ühte lehte või kõiki. Mitu omavahel mitteseotud domeeni samalt aadressilt on massilise läbikammimise tunnus ja need tõstavad hinnet.

Kui palju tunnus loeb, näitas analüüs ühel meie veebilehtedest: üle seitsmekümne protsendi kogu liiklusest langes seal ühele ainsale päringu tegijale, jaotatuna enam kui sajale aadressile. Ilma tunnuseta oleks see näinud välja nagu hajutatud skraper. Tegemist oli GPTBot'iga, OpenAI indekseerijaga — ta küsis ikka ja jälle robots.txt-i ning käitus täiesti korrektselt.

Turvaaspektid üksikasjalikult

1. Proxy tuvastamine — üldse kõige ohtlikum koht

Kui Odoo töötab pöördvaheserveri taga ja proxy_mode on valesti seatud, näeb moodul iga päringu puhul sama aadressi: proxy aadressi. Blokeering lukustaks siis kõik külastajad korraga välja.

Seetõttu kontrollib Web RBL enne iga blokeeringut, kas aadressi määramine on usaldusväärne. See nõuab proxy_mode-i koos edastuspäisega, keeldub töötamast, kui edastus saabub ilma proxy_mode-ita, ja keeldub samamoodi enam kui ühe vahepealse proxy korral. Kahtluse korral ei blokeerita.

2. Oma võrgud mitte kunagi

Privaatsed aadressivahemikud, loopback, link-local ja CGNAT on kindlalt välja arvatud. Need ei saa mingil juhul nimekirja sattuda, ka mitte käsitsi. Sama kehtib võõraste nimekirjade kohta: privaatsed ja reserveeritud vahemikud ning absurdselt suured võrgud lükatakse sisselugemisel tagasi.

3. Oma viga ei tohi veebilehte kaasa viia

Kogu kontroll toimub kaitsekihis, mis püüab kinni iga vea. Mis siin untsu läheb, logitakse ja päring jätkab muutumatult. Kaitsemoodul, mis oma vea korral veebilehe kaasa viib, on halvem kui mitte ühtegi. Kõik päringud päringuteel töötavad lisaks ilma külastaja brauserikeeleta ja ilma tõlgitud väljade järgi sorteerimiseta — külastaja, kelle keel ei ole paigaldatud, ei tohi kontrolli luhtumist põhjustada.

4. Jälgi enne blokeerimist

Pärast paigaldust on nimekirjas olevate aadresside blokeerimine tavapäringute puhul välja lülitatud. Sondid lükatakse tagasi ja arvestatakse, kõik muu läheb läbi. Nii saab paar päeva jälgida, kes tegelikult nimekirja satub, enne kui keegi välja lukustatakse. Sama kehtib käitumise tuvastamise, ohunimekirjade ja riigireeglite kohta: kõigepealt teata, blokeeri pärast vaatlemist.

5. Kitsad mustrid laiade võrkude asemel

Valesti tuvastatud külastaja on kallim kui märkamata jäänud sond. Iga muster kannab seetõttu oma taset ja seda saab mustri kaupa ümber seadistada. Ainuüksi faililaiendist harva piisab: .php korral on 14.012 tõelist sondi vastu käputäis vanu linke, .asp korral on suhe vastupidine. Selliseid otsuseid tuleb mõõta, mitte hinnata.

6. Käsitsi tehtud vabastus jääb kehtima

Kes aadressi vabastab, tegi seda põhjusega. Järgmine tabamus ei tühista seda otsust vaikselt.

7. Nimekiri on kaitstud, kuid mitte saladus

Lõpp-punkt nõuab tokenit ja vastab ilma kehtiva tokenita koodiga 404, mitte 403 — aadressi olemasolu ei kinnitata seega üldse. Võrdlus toimub konstantse ajaga. Nimekiri ise ei sisalda midagi konfidentsiaalset: see koosneb aadressidest, mis on ise meie uksele koputanud.

8. Mitte mingeid saladusi raamatupidamises

Ebaõnnestunud sisselogimiste puhul märgitakse üles proovitud kasutajanimi, mitte kunagi parool. Andmebaasihalduri puhul ei loeta edastatud väärtustest üldse midagi: seal on esimesel kohal peaparool ja blokeerimisnimekirja kirje rändab iga andmebaasi varukoopiasse. GeoLite2 litsentsivõti on ainult süsteemiparameetris ja mitte üheski logireas.

9. Peibutis ei reeda midagi kasutatavat

Valikuliselt vastab Web RBL sondidele väljamõeldud sisuga, milles on ühemõtteline kanaarilinnu väärtus. Kes selle väärtuse hiljem välja küsib, on võltsvastust lugenud ja selle põhjal tegutsenud — valehäire on seejuures välistatud. Peibutised ei sisalda kasutatavaid andmeid, mitte ühtegi tõelist teed ega kehtivaid pääsuandmeid. Seda funktsiooni tarnitakse välja lülitatuna, sest see muudab väljapoole nähtavat käitumist.

Mida moodul ei suuda

See ei asenda tulemüüri ega veebirakenduse tulemüüri (Web Application Firewall). See tuvastab teadaolevaid sondeerimismustreid teedes, ebaõnnestunud sisselogimisi ja kahtlast käitumist — mitte rünnakuid vormide vastu, mitte parameetritesse sisse smugeldamise katseid.

Lisaks näeb see ainult seda, mis HTTP kaudu tagasi tuleb. Mida ründaja saadud andmebaasi- või postkastipääsudega teeb, jääb nähtamatuks — ja just seepärast on kanaarilinnu väärtused teed ja mitte pääsuandmed.

Ja see ei asenda hoolsust: moodul, mis .env-sonde tagasi lükkab, ei muuda kogemata väljastatud .env-faili ohutuks.

Saadavus

Web RBL on AGPL-3 all avalikult kättesaadav ja töötab meil toodangus viiel veebilehel:

github.com/Alex0176/odoo-web-rbl

Moodul eeldab Odoo 19 Community'd ja sellel ei ole sõltuvusi peale base ja web. Piletiühendus on valikuline ega vaja kindlat piletisüsteemi; ilma sellise süsteemita ei juhtu lihtsalt midagi. Päritoluriik vajab MaxMindi tasuta GeoLite2 andmebaasi; kui see puudub, jääb väli tühjaks ja kõik muu töötab muutumatult.

Edasiseks lugemiseks: Kuidas Web RBL sobib täielikku turvaarhitektuuri -- koos tulemüüri, kaheastmelise autentimise ja õigustega, sealhulgas samm-sammuline juhend: Odoo 19 turvaarhitektuuri õige kombineerimine.

Küsimusi, märkusi ja veateateid võtame hea meelega vastu — kõige meelsamini Issue'na GitHubis.