Odoo 19 Community: Web RBL – blokeerimisloend oma veebisaitidele suunatud ründeliikluse tõkestamiseks

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 artikkel tutvustab Web RBL-i, avatud lähtekoodiga moodulit Odoo 19 Community jaoks, mis sellise liikluse tuvastab, hindab, registreerib ja tõrjub ning avaldab blokeerimisloendi RBL-loendina ehk vormingus, mida tulemüürid ja pöördproksid saavad otse lugeda. Kõik arvud pärinevad tegelikust kasutusest.

Mida moodul suudab — funktsioonide ülevaade

Funktsioon	Mida see teeb	Vaikeseadistus
Mustrituvastus	Tuvastab tee ja faililaiendi põhjal kompimiskatseid: .env, .git, konfiguratsioonifailid, pilveteenuste võtmed, CI/CD ehitusjuhised, WordPress, PHP, kataloogipuus liikumise katsed, andmebaasihaldurid, GraphQL, käskude käivitamine /api/fs/exec ja sarnaste liideste kaudu	blokeeri
Kolm taset iga mustri jaoks	blokeeri, loenda või teavita — iga mustri jaoks muudetav ilma koodi muutmata	mustri kaupa
Lävendid	Sama mustri tabamuste arv, mille järel rakendub blokeering; sisselogimiste puhul kümme	sisselogimisel 10
Kaitse sisselogimisrünnete eest	Ebaõnnestunud sisselogimised vormi ja XML-RPC/JSON-RPC kaudu, ebaõnnestunud seansikontrollid, pöördumised andmebaasihalduri poole — salvestatakse andmebaasi, mitte muutmällu	sees
Bottide tuvastamine sisselogimisel	Kes eirab kümne ebaõnnestunud katse järel kuvatud ootesõnumit ja jätkab proovimist, blokeeritakse kohe	blokeeri
Käitumise tuvastamine	Aadressid, mille päringud annavad viie minuti jooksul kakskümmend vealehte ja peaaegu mitte ühtegi toimivat lehte — seega proovitakse aadresse huupi, selle asemel et lehti lugeda	teavita
Riskiskoor 0–100	Kui kindel on, et aadressi taga on ründaja? Hinnang põhineb mustri tõsidusel, erinevate mustrite arvul, kahtlase tegevusega päevadel, puudutatud domeenidel ja tabamuste arvul ning sisaldab selges keeles põhjendust	sees
Sisselogimise blokeerimine riskiskoori alusel	Seadistatavast riskiskoorist alates on sisselogimine keelatud, kuid veebisaiti saab endiselt lugeda	alates 40-st
Varastatud sisselogimisandmete kahtlus	Kahtlaselt aadressilt toimunud edukast sisselogimisest teavitatakse ja soovi korral määratakse see kellelegi ülesandeks — üks kord aadressi kohta päevas	sees
Ohuloendid	Tori väljumissõlmed, Spamhaus DROP, FireHOL Level 1 ja blocklist.de on eelseadistatud; mis tahes muu RBL-loendi saab lisada selle aadressi kaudu, loendeid sünkroonitakse iga päev ja igal loendil on oma tase	teavita
Sisselogimisele juurdepääs keelatud	Neljas tase loendite ja riikide jaoks: veebisaiti saab lugeda, kuid sisselogimisvorm ja liidesed on suletud — sobiv lahendus Tori puhul	Valikuline
Päritoluriik	Iga tabamuse ja aadressi riik määratakse GeoLite2 abil; moodul hoiab andmebaasi tasuta litsentsivõtme abil ise ajakohasena	kuva
Riigipõhised reeglid	Blokeerimine, sisselogimisele juurdepääsu keelamine, teavitamine või selgesõnaline lubamine — iga riigi jaoks eraldi, teadlikult ilma vaikeseadistuseta	puuduvad
Seadistusvead	QNAP, Synology, Exchange-Autodiscover, ActiveSync ja WebDAV/CalDAV/CardDAV tuvastatakse, neid ei blokeerita kunagi ning need lisatakse koos leiu ja puudutatud domeeniga tööloendisse	teavita
Üks tugipilet aadressi kohta	Leiu põhjal luuakse soovi korral tugipilet — täpselt üks iga aadressi kohta; suletud pilet avatakse uuesti, selle asemel et luua duplikaat	väljas
Kohustuslikud lehed ja andmekogujad	Veebilehe haldaja andmete lehe kanooniline tee jääb alati kättesaadavaks; muude kirjapiltide automaatne läbiproovimine tuvastatakse ja soovi korral blokeeritakse	teavita
Lubatud aadresside loend	Aadressid ja võrgud, mida kunagi ei blokeerita; loendit täiendatakse iga päev tulemüüri andmete (VPN-i vastaspunktid) ning Googleboti ja Bingboti avaldatud aadressivahemike põhjal	sees
Kliendiga seostamine	Kliendi võrgust tulnud tabamus seostatakse selle kliendiga — lubatud aadresside loendi põhjal, mitte kunagi käsitsi oletades	sees
Domeen ja tunnus iga tabamuse juures	Millise veebisaidi poole pöörduti ja millise User-Agent päisega — mõlemad puuduvad juurdepääsulogist	sees
Analüüs	Kõigi tabamuste diagramm ja risttabel: mustri, päeva, domeeni, riigi ja aadressi kaupa	sees
Peibutised	Kompimispäringutele antakse väljamõeldud vastused, mis sisaldavad peibutusväärtust; kes seda hiljem pärib, on vastuseid lugenud	väljas
RBL-loendi avaldamine	Blokeerimisloend lihtsa aadressiloendina või JSON-vormingus eraldi, pääsmikuga kaitstud aadressil — HAProxy, OPNsense'i ja kõigi URL-loendeid lugevate tulemüüride jaoks	sees

Kõik, mille vaikeseadistus on teavita, väljas või Valikuline, on nii teadlikult: blokeering tuleks sisse lülitada pärast seda, kui on mõne päeva jooksul jälgitud, kes selle alla satub, mitte seepärast, et vaikeseadistus nii ette nägi.

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

RBL-loendid: standardne viis blokeeringute jagamiseks

RBL tähendab Real-time Blackhole List. Mõiste pärineb e-posti maailmast, kus Spamhaus ja teised on alates üheksakümnendatest avaldanud pahatahtlike saatjate aadresside loendeid. Põhimõte on väga lihtne ja just seetõttu nii levinud: üks aadress real, kättesaadav HTTP kaudu, laaditakse korrapäraselt uuesti. Pole vormingut, mida tuleks esmalt parsida, ega liidest, mille kasutamiseks oleks vaja eraldi tööriista.

Peaaegu iga tulemüür ja pöördproksi saab sellise loendi sisse lugeda ning selle põhjal reegleid luua. Tootjad kasutavad erinevaid nimetusi, kuid toimimispõhimõte on kõikjal sama:

• OPNsense ja pfSense — URL Table Alias: aadressiloend laaditakse HTTP kaudu, seda kasutatakse tulemüürireeglites aliasena ning uuendatakse iga tunni või päeva järel
• HAProxy — ACL-failid ja Maps: src -f sperrliste.txt reeglis http-request deny, uuesti laaditav käitusaja API kaudu ilma taaskäivitamiseta
• nginx — moodul geo koos kaasatud aadressifailiga või deny-direktiivid genereeritud include-failist
• Fortinet FortiGate — External Block List või Threat Feed: URL, millelt tulemüür hangib IP-aadresside loendi ja kasutab seda reeglites
• Palo Alto Networks — External Dynamic List (EDL): sama põhimõte, eraldi objektitüübina turbereeglites
• Check Point — Custom Intelligence Feeds ja IP Block Lists URL-i kaudu
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds oma loendiallikatega
• Sophos Firewall — Third-Party Threat Feeds: URL-ilt saadavad aadressiloendid blokeerimisreeglite allikana
• Juniper SRX — Dynamic Address Entries voogudest
• MikroTik RouterOS — Address Lists, täidetakse URL-ilt skripti ja fetch abil
• CrowdSec — oma loendid tõrjekomponentide andmeallikana kõigis toetatud süsteemides

Just selles vormingus avaldab Web RBL oma blokeerimisloendi. Tulemüür hülgab paketid enne, kui need veebiserverini jõuavad, ning tõrjub ühtlasi kõik muud samalt aadressilt tulevad katsed, näiteks meiliserveri või VPN-lüüsi vastu.

Mõlemas suunas, kuid õiges kohas

See toimib ka vastupidi: Web RBL-i saab lisada mis tahes RBL-loendi — URL, tase ja valmis. Tori väljumissõlmed, Spamhaus DROP, FireHOL ja blocklist.de on eelseadistatud, ülejäänud saab lisada kolme klõpsuga. Moodul jaotab iga loendi aadressivahemikeks ning kontrollib iga päringut nende vastu mõne mikrosekundiga.

Siiski on mõistlikum kasutada teiste koostatud loendeid serveri ees olevas tulemüüris. Selleks on kolm põhjust. Tulemüür näeb kõiki teenuseid, mitte ainult HTTP-d — Spamhausi loendis olev aadress tuleks tõrjuda ka meiliserveri ja VPN-i juures. See hülgab liikluse pakettide tasemel juba enne ühenduse loomist ega koorma seega rakendusserverit. Pealegi hallatakse selliseid loendeid niigi tulemüüris; teine koopia rakenduses tähendab veel üht kohta, kus andmed võivad aeguda.

Milleks siis loendeid veel moodulis vaja on? Selleks, mida tulemüür teha ei saa. Tulemüür ei tunne sisselogimisvormi. Web RBL saab Tori loendis olevale aadressile keelata juurdepääsu sisselogimisele, kuid lubada veebisaiti endiselt lugeda — kes soovib anonüümselt lugeda, võib seda teha; kes soovib anonüümselt paroole läbi proovida, ei või. Samuti saab moodul teatada loendis olevalt aadressilt toimunud edukast sisselogimisest kui kahtlasest juhtumist. Mõlemaks on loendit vaja seal, kus sisselogimine toimub.

Kõhutunde asemel riskiskoor

Aadress, millelt on kord küsitud /wp-login.php, on midagi muud kui aadress, millelt on kahel päeval proovitud viit erinevat mustrit kolmel domeenil. Web RBL arvutab selle põhjal riskiskoori 0–100, kasutades üksnes enda nähtut, ilma välise teenuse ja väljapoole tehtavate päringuteta.

Üks kirje: 99 tabamust, riskiskoor 84 ja selges keeles põhjendus — kõige raskem ohumuster, viis erinevat tõsist ohumustrit, kaks kahtlase tegevusega päeva, üle kahekümne tabamuse.

Riskiskoor määrab kaks asja. Seadistatavast väärtusest alates on sisselogimine keelatud — veebisaiti saab endiselt lugeda, kuid kes on juba sisselogimisandmeid otsinud, ei saa võimalust leitud andmeid proovida. Samuti teavitatakse riskiskooriga aadressilt toimunud edukast sisselogimisest: sel juhul ei arvanud keegi enam huupi, vaid teadis. Kas õigustatud kasutaja oli liikvel või on sisselogimisandmed võõrastesse kätesse sattunud — moodul seda ei otsusta, vaid annab juhtumi üle inimesele, kes saab asja uurida. Parooli ennast ei puudutata selle käigus kusagil.

Blokeerimisloend, filtreeritud riskiskoori järgi alates 40-st: iga aadressi tabamuste arv, kahtlase tegevusega päevad, puudutatud domeenid ja viimane tee.

Mida Web RBL kaitseb — kaitse üksikasjalikumalt

1. Sisselogimisandmed jäävad leidmata

Suurim mõõdetud rünnakuliik ei otsi Odoo turvaauke, vaid ripakile 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

Määrav pole siin päringute arv, vaid erinevate aadresside arv: /credentials.json küsiti 98 aadressilt, /.git-credentials 92 aadressilt. See pole üksik skanner, vaid standardne võtete kogum, mida kasutatakse korraga kogu maailmas.

2. Sisselogimiskatsed jäävad tulemusteta — püsivalt

Odoo sisaldab oma kaitsemehhanismi paroolide läbiproovimise aeglustamiseks. Sellel on kolm piirangut, mis on dokumenteeritud Odoo lähtekoodis endas: loendur asub tööprotsessi muutmälus ja nullitakse igal taaskäivitamisel, see üksnes viivitab, mitte ei blokeeri, ning loendab ainult katseid, mis jõuavad paroolikontrollini.

Web RBL sekkub samades kohtades, kuid salvestab andmed andmebaasi. See tähendab järgmist:

• Loenduri seis säilib igal taaskäivitamisel ja on kõigile tööprotsessidele ühine
• Arvesse lähevad mõlemad võimalused: sisselogimisvorm /web/login ning liidesed /xmlrpc/2/common ja /jsonrpc
• Arvesse lähevad ka katsed, mis ei jõua kunagi paroolikontrollini, näiteks sisselogimised ilma kehtiva seansitunnuseta
• Ka ebaõnnestunud juurdepääsukatse andmebaasihaldurile läheb arvesse; see on kõige tõsisem sisselogimiskatse

Sisselogimiste lävendiks on määratud kümme ja selle aluseks on mõõtmistulemus: seitsmeteistkümne päeva üheksast ebaõnnestunud sisselogimisest pärines enamik klientidelt, kes seadistasid endale ligipääsu veel ühes seadmes ja sisestasid vale domeeni — ühel juhul oma domeeni, kuid punkti asemel sidekriipsuga. Juba esimese ebaõnnestunud katse järel rakenduv blokeering oleks seega tabanud ründajate asemel seadistamisega tegelevaid kliente.

Kes aga jätkab proovimist pärast seda, kui server on juba vastanud „palun oodake veidi”, blokeeritakse kohe. Inimene loeb seda sõnumit ja ootab; kes seda eirab, on programm. Just selle juhtumi püüab kinni eraldi muster lävendiga null ning see ei saa tabada ühtegi kolleegi: selleni jõuab vaid see, kellel on juba kümme ebaõnnestunud katset seljataga ja kes seejärel jätkab.

3. Rünnak ei koorma enam serverit

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 meetodis ir.http._match, seega enne marsruutimist. Vastus tagastatakse ilma mallita, ilma blokeeringukontrollile lisanduvate andmebaasipäringuteta ja ilma logikirjeta. Lubatud aadresside loendi, ohuloendite ja riigireeglite kontroll toimub vahemälus sorditud aadressivahemike põhjal — mõne mikrosekundiga ka siis, kui vahemikke on üle kolmekümne tuhande.

4. Tulemüür tõrjub ründaja juba enne tema kohalejõudmist

Blokeerimisloend avaldatakse RBL-loendina, mida HAProxy ja OPNsense saavad otse lugeda. Ründaja ei jõua seega enam veebiserverini ega ühegi muu samas hostis töötava teenuseni. Üks kord pahatahtlikuks tunnistatud pöördumine kaitseb nii tagantjärele kogu masinat.

Kolm taset: blokeeri, loenda, teavita

Mitte iga olematule lehele tehtud päring pole rünnak. Seetõttu eristab Web RBL kolme taset ning iga mustri taset saab muuta koodi puutumata.

Tase	Käivitav päring	Tagajärg aadressile
blokeeri	lükatakse tagasi	blokeeritakse 24 tunniks, pärast kolme kahtlase tegevusega päeva püsivalt
loenda	lubatakse läbi	ainult registreeritakse, ei blokeerita
teavita	lubatakse läbi	registreeritakse koos tuvastatu kirjeldusega, ei blokeerita kunagi

Ohuloendite ja riikide jaoks on ka neljas võimalus: sisselogimine pole lubatud. Veebileht jääb loetavaks, kuid sisselogimisvorm ja liidesed on suletud. See on kesktee kõige jaoks, mis on kahtlane, kuid ei pruugi olla pahatahtlik — Tor, andmekeskuse aadressivahemik või riik, kus pole kliente.

Milliseid ründeid tuvastatakse

Kõiki mustreid on kontrollitud tegeliku liikluse põhjal. Eri aadresside arv on teadlikult kõrval välja toodud — see näitab, kas muster tabab üksikut skannerit või laialt levinud tegutsemisviisi.

Ründeliik	Päringud	Aadressid
.env-faili andmete hankimine	57.721	223
PHP sondeerimised	12.237	256
Väärtuslikule sihtmärgile suunatud kataloogist väljumise rünne	10.046	64
Konfiguratsioonifailid	5.535	114
Pilveteenuste pääsuvõtmed	4.388	152
WordPressi sondeerimised	3.366	385
.git-andmete hankimine	2.811	255
Odoo luure (andmebaasihaldur, versioonipäring)	2.500	213
Tehisintellekti tööriistaahelad ja käskude käivitamine (/mcp, /api/fs/exec)	2.450	74
Järkamisjuhised (CI/CD)	1.907	88
GraphQL-i lõpp-punktid	1.878	71

Tähelepanu väärib uusim ründeliik. Aadressile /api/fs/exec tehti 369 päringut 54 eri aadressilt — see pole lugemispäring, vaid katse käivitada käske. Kaks aastat tagasi selliseid sihtmärke veel polnud; need pärinevad uute tehisintellekti tööriistade ja ülesandejärjekordade liidestest. Kes suunab oma kaitse ainult WordPressi ja PHP vastu, ei märka neid üldse. Seetõttu on sellel ründeliigil hinnangus ka suur kaal.

Ohuloendid ja päritoluriik

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

Väline loend on kellegi teise väide, mis põhineb meile teadmata põhjustel ja liiklusel, mida me pole kunagi näinud. See võib olla ekslik, aegunud või mõeldud teiseks otstarbeks: blocklist.de kogub eelkõige aadresse, millelt on mujal SSH kaudu sisselogimist katsetatud, ning see ütleb veebiserveri kohta vähe. Seepärast hoiab Web RBL väliseid loendeid oma blokeerimisloendist eraldi ja vaikeseadistus on teavita. Oma lubatud aadresside loend on aga alati ülimuslik: klient, keda tunneme, kaalub üles kolmanda osapoole hinnangu.

Päritoluriik on näha iga tabamuse ja aadressi juures. Hindamisel on see asendamatu — sisselogimiskatse oma riigist kell kümme hommikul erineb katsest riigist, kus pole ühtki klienti. Üldiseks blokeerimisaluseks sobib see halvasti ja seda kinnitavad meie enda arvud: meie loendis olevad ründajad tulid peamiselt Belgia, Soome ja Madalmaade pilveteenuste aadressivahemikest. Kõige saksakeelsest piirkonnast väljapoole jääva blokeerimine poleks neid tabanud — küll aga meie puhkusel viibivaid töötajaid ja tööreisil olevaid kliente.

Riigireeglite loend on algselt tühi ja vaates on selgitatud, miks.

Vigastest seadistustest teavitamine blokeerimise asemel

Tegelikus liikluses pole kõige sagedamini tegemist ei ründe ega külastajaga, vaid hoopis vigase tarkvaraga, mis peab veebiserverit millekski muuks:

• 1367 päringut QNAP NAS-i veebiliidesele — sünkroonimisklient, mille sihtaadress enam ei klapi. Üheltainsalt ühenduselt tehti 962 pöördumist.
• 65 Autodiscoveri päringut — Outlook, mis peab veebidomeeni oma Exchange'i serveriks

Selliseid aadresse ei blokeerita kunagi. Blokeerimine ei paranda viga, vaid peidab selle — ja tabab inimest, kelle seade on niigi valesti seadistatud. Selle asemel luuakse kirje tuvastatu kirjelduse ja asjaomaste domeenidega. Soovi korral luuakse sellest automaatselt tugipilet: iga aadressi kohta täpselt üks. Kui pilet suletakse ja aadress uuesti silma jääb, avatakse sama pilet uuesti, selle asemel et luua teine.

Tuvastatakse QNAP, Synology, Exchange-Autodiscover, ActiveSync ning WebDAV-i, CalDAV-i ja CardDAV-i kliendid. Mustrid sisaldavad seejuures täpseid failinimesid ja katalooge, mitte kunagi pelgalt faililaiendeid: samas kataloogis /cgi-bin/ asuvad kahjutud sünkroonimispäringud kõrvuti klassikaliste sondeerimiste sihtmärkidega, nagu printenv.pl.

Lubatud aadresside loend: aadressid, mida ei blokeerita kunagi

Eksimuse hind pole kõigi aadresside puhul sama. Andmekeskusest pärit skanneri puhul ei maksa valehäire midagi. Tegevuskohta ühendava tunneli vastasotspunkti puhul tähendab see kogu tegevuskoha ühenduse kaotust.

Seepärast on olemas teine loend, mis on esimesest ülimuslik: aadressid ja võrgud, mida ei blokeerita kunagi. Seejuures ei vaigista see midagi — loendis olijaid kontrollitakse ja registreeritakse endiselt, ära jääb vaid blokeerimine. Selles seisneb erinevus tulemüüri erandist: too teeb pimedaks, see üksnes kannatlikuks.

Loendit täiendatakse iga päev kahest allikast: tulemüürist endast kõigi VPN-i vastasotspunktidega, et äsja loodud tunneli toimimine ei sõltuks sellest, kas keegi blokeerimisloendile mõtleb, ning Google'i ja Microsofti avaldatud aadressivahemikega, mida nende veebiroomajad kasutavad. Ainult nii saab eristada päris Googleboti skannerist, mis end selleks nimetab. Otsingumootoreid ei tohi kunagi blokeerida; kes neile ligipääsu sulgeb, eemaldab oma veebilehe pöördumatult otsinguindeksist.

Seejuures kehtib reegel, mis on võrdlemisest tähtsam: tühi vastus ei kustuta kunagi midagi. Kui allikas ei vasta või vastus on tühi või arusaamatu, jääb loend muutmata. Lubatud aadresside loend, mis end tõrke korral tühjendab, katkestab kõik tunnelid kõige halvemal võimalikul hetkel.

Kui lubatud aadresside loendi kirje on seotud kliendiga, seostatakse iga tema võrgust pärit tabamus selle kliendiga. Nii on vigase seadistuse korral kohe teada, kellega ühendust võtta, ilma et keegi peaks aadresse eraldi otsima.

Kohustuslikud andmed ja automaatsed andmekogujad

Veebisaidi juriidiliste andmete leht pole tavaline leht. See peab jääma inimestele kättesaadavaks, sest selle blokeerimine tekitaks just selle rikkumise, mida andmekoguja otsib. Samas on see leht, kus asuvad nimi ja aadress — ning seega ka automaatse andmekorje sihtmärk.

Kui Austrias levis veebilehtedele lisatud Google'i fontidega seotud nõudekirjade laine, näitasid logid, et kirjad ei põhinenud üksikkülastustel, vaid automaatsel lauskontrollil: eri omavahel seostamata hostide poole pöörduti millisekundiliste vahedega.

Web RBL lahendab selle erandi tegemise asemel taseme alandamisega. Kanooniline tee /impressum ei vasta ühelegi mustrile ja jääb alati kättesaadavaks. Muud variandid, nagu /impressum.php — mida Odoo veebilehel olla ei saa — registreeritakse teavitusena. Kes ei soovi automaatse andmekorjega leppida, muudab üht parameetrit. sitemap ja robots on sellest välja jäetud ning neid ei saa üldse blokeerida: need ei sisalda isikuandmeid ja nende pärimine kuulub iga otsingumootori veebiroomaja ülesannete hulka.

Domeen ja tunnus: mis juurdepääsulogist puudub

werkzeugi juurdepääsulogi ei salvesta sihthosti ega päringu tegija tunnust. Odoo saab loomulikult mõlemad — ilma hostita ei saaks see mitme veebisaidi korral õiget valida. Hiljem neid andmeid logist aga lugeda ei saa.

Web RBL salvestab mõlemad iga tabamuse juures. See vastab kahele küsimusele, millele muidu vastust ei saaks: millise veebisaidi poole vigase seadistusega tarkvara pöördub — ja seega, millisele kliendile domeen kuulub — ning kas aadress külastab üht veebisaiti või kõiki. Ühelt aadressilt mitme omavahel seostamata domeeni poole pöördumine viitab lauskontrollile ja tõstab riskihinnangut.

Tunnuse tähtsust näitas ühe meie veebisaidi analüüs: üle seitsmekümne protsendi kogu liiklusest pärines üheltainsalt päringu tegijalt, kes kasutas enam kui sadat aadressi. Ilma tunnuseta oleks see paistnud hajutatud andmekorjerobotina. Tegemist oli OpenAI veebiroomajaga GPTBot — see päris korduvalt faili robots.txt ja käitus täiesti korrektselt.

Turvakaalutlused lähemalt

1. Puhverserveri tuvastamine — kõige ohtlikum koht

Kui Odoo töötab pöördpuhverserveri taga ja proxy_mode on valesti seadistatud, näeb moodul iga päringu puhul sama aadressi: puhverserveri oma. Selle blokeerimine sulgeks ligipääsu korraga kõigile külastajatele.

Seepärast kontrollib Web RBL enne iga blokeerimist, kas aadressi määramine on usaldusväärne. See nõuab proxy_mode kasutamist koos edastuspäisega, keeldub töötamast, kui edastatud päring saabub ilma proxy_mode seadistuseta, ning keeldub ka siis, kui vahel on rohkem kui üks puhverserver. Kahtluse korral ei blokeerita.

2. Oma võrke ei blokeerita kunagi

Privaatsed aadressivahemikud, tagasisilmusaadressid, lingikohalikud aadressid ja CGNAT on alati välistatud. Need ei saa mingil juhul loendisse sattuda, ka käsitsi lisades. Sama kehtib väliste loendite kohta: privaatsed ja reserveeritud vahemikud ning ebamõistlikult suured võrgud jäetakse importimisel kõrvale.

3. Mooduli enda viga ei tohi veebisaiti rivist välja viia

Kogu kontroll toimub kaitsemehhanismi sees, mis püüab kinni kõik vead. Siin tekkiv viga logitakse ja päringu töötlemine jätkub muutmata kujul. Kaitsemoodul, mis oma vea tõttu veebisaidi rivist välja viib, on hullem kui kaitsemooduli puudumine. Lisaks tehakse kõik päringu töötlemise käigus vajalikud andmepäringud külastaja brauseri keelt kasutamata ja tõlgitud väljade järgi sortimata — külastaja, kelle keel pole paigaldatud, ei tohi kontrolli nurjata.

4. Enne jälgimine, siis blokeerimine

Pärast paigaldamist on loendis olevate aadresside blokeerimine tavaliste päringute korral välja lülitatud. Sondeerimised tõrjutakse ja registreeritakse, kõik muu lastakse läbi. Nii saab mõne päeva jooksul jälgida, kes tegelikult loendisse satub, enne kui kellelegi ligipääs suletakse. Sama kehtib käitumise tuvastamise, ohuloendite ja riigireeglite kohta: esmalt teavitamine, pärast ülevaatamist blokeerimine.

5. Täpsed mustrid laia võrgu 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 antud luba jääb kehtima

Kui keegi on aadressi lubanud, oli tal selleks põhjus. Uus tabamus ei tühista seda otsust vaikimisi.

7. Loend on kaitstud, kuid pole saladus

Lõpp-punkt nõuab pääsutõendit ja vastab kehtiva pääsutõendi puudumisel koodiga 404, mitte 403 — nii ei kinnitata isegi aadressi olemasolu. Võrdlemine toimub konstantse ajaga. Loend ise ei sisalda midagi konfidentsiaalset: see koosneb aadressidest, mis on ise meie poole pöördunud.

8. Arvestusse ei kuulu saladused

Nurjunud sisselogimiste korral märgitakse üles proovitud kasutajanimi, mitte kunagi parool. Andmebaasihalduris ei loeta edastatud väärtustest mitte midagi: seal on esikohal peaparool ja blokeerimisloendi kirje jõuab igasse andmebaasi varukoopiasse. GeoLite2 litsentsivõti asub ainult süsteemiparameetris ega satu ühelegi logireale.

9. Peibutis ei avalda midagi kasutuskõlblikku

Soovi korral vastab Web RBL sondeerimistele väljamõeldud sisuga, mis sisaldab kordumatut peibutusväärtust. Kes seda väärtust hiljem pärib, on võltsvastust lugenud ja selle põhjal tegutsenud — valehäire on sel juhul välistatud. Peibutised ei sisalda kasutuskõlblikke andmeid, tegelikke teid ega kehtivaid sisselogimisandmeid. Vaikimisi on see funktsioon välja lülitatud, sest see muudab väljapoole nähtavat käitumist.

Mida moodul ei suuda

See ei asenda tulemüüri ega veebirakenduse tulemüüri. See tuvastab teadaolevaid sondeerimismustreid päringuteedes, nurjunud sisselogimisi ja kahtlast käitumist, kuid mitte vormide vastu suunatud ründeid ega parameetrite kaudu tehtavaid süstimiskatseid.

Lisaks näeb see ainult seda, mis tuleb tagasi HTTP kaudu. Ründaja tegevus varastatud andmebaasi- või postkastipääsudega jääb nähtamatuks — just seetõttu on peibutusväärtused teed, mitte sisselogimisandmed.

Samuti ei asenda see hoolsust: moodul, mis tõrjub .env-sondeerimisi, ei muuda kogemata avalikuks tehtud .env-faili ohutuks.

Kättesaadavus

Web RBL on avalikult saadaval litsentsi AGPL-3 alusel ja töötab meie viiel veebisaidil tootmiskeskkonnas:

github.com/Alex0176/odoo-web-rbl

Moodul eeldab Odoo 19 Community kasutamist ning sõltub ainult moodulitest base ja web. Tugipiletite liidestus on valikuline ega nõua kindlat piletisüsteemi; selle puudumisel ei juhtu lihtsalt midagi. Päritoluriigi määramiseks on vaja MaxMindi tasuta GeoLite2 andmebaasi; selle puudumisel jääb väli tühjaks ja kõik muu töötab endistviisi.

Lisalugemist: kuidas sobitub Web RBL terviklikku turbearhitektuuri koos tulemüüri, kaheastmelise autentimise ja õigustega, sealhulgas üksikasjalik juhend: Odoo 19 turbearhitektuuri osade õige kombineerimine.

Ootame küsimusi, tähelepanekuid ja veateateid — kõige parem on esitada need GitHubis Issue'na.