Odoo 19 Community: Web RBL – listë bllokimi për trafikun sulmues në faqet tona të internetit

Kodi burimor: github.com/Alex0176/odoo-web-rbl — AGPL-3, i lirë për përdorim.

Kush operon një server Odoo në internet, merr vizita. Jo vetëm herë pas here, por pa pushim. Gjatë shtatëmbëdhjetë ditëve kemi regjistruar dhe vlerësuar në pesë faqet tona të internetit 731.297 kërkesa. 110.511 prej tyre nuk ishin vizitorë, por kërkim i automatizuar për dobësi, të dhëna hyrjeje dhe skedarë konfigurimi.

Ky artikull përshkruan Web RBL, një modul me burim të hapur për Odoo 19 Community, që e njeh, e vlerëson, e regjistron dhe e refuzon këtë trafik — dhe që e publikon listën e bllokimit si listë RBL, pra në formatin që firewall-et dhe reverse proxy-t e lexojnë drejtpërdrejt. Të gjitha shifrat vijnë nga operimi real.

Çfarë mund të bëjë moduli — funksionet përmbledhtazi

Funksioni	Çfarë bën	Gjendja në dorëzim
Njohja e modeleve	Njeh sondimet nga shtegu dhe prapashtesa: .env, .git, skedarë konfigurimi, çelësa cloud, udhëzime CI/CD të ndërtimit, WordPress, PHP, path traversal, menaxherë të bazave të të dhënave, GraphQL, ekzekutim komandash përmes /api/fs/exec dhe ndërfaqeve të ngjashme	blloko
Tre nivele për çdo model	blloko, numëro ose raporto — i ndërrueshëm për çdo model, pa kod	për çdo model
Pragjet	Aq përputhje të të njëjtit model përpara se të bllokohet; për identifikimet dhjetë	10 te identifikimi
Mbrojtja e identifikimit	Identifikime të dështuara përmes formularit dhe XML-RPC/JSON-RPC, kontrolle të dështuara sesioni, qasje te menaxheri i bazave të të dhënave — në bazën e të dhënave, jo në memorien operative	aktiv
Njohja e boteve te identifikimi	Kush e injoron mesazhin e pritjes pas dhjetë përpjekjeve të dështuara dhe vazhdon të trokasë, bllokohet menjëherë	blloko
Njohja e sjelljes	Adresa që në pesë minuta krijojnë njëzet faqe të gabuara dhe pothuajse asnjë faqe të gjetur — pra hamendësojnë në vend që të lexojnë	raporto
Vlerësimi 0–100	Sa e sigurt është që pas adresës qëndron një sulmues? Nga ashpërsia e modelit, numri i modeleve të ndryshme, ditët e dyshimta, domenet e prekura dhe numri i përputhjeve — me arsyetim në tekst të qartë	aktiv
Bllokimi i identifikimit sipas vlerësimit	Nga një vlerësim i rregullueshëm e tutje identifikimi ndalohet, faqja e internetit mbetet e lexueshme	nga 40
Dyshim për të dhëna hyrjeje të vjedhura	Një hyrje e suksesshme nga një adresë e dyshimtë raportohet dhe, sipas dëshirës, caktohet si detyrë — një herë për adresë në ditë	aktiv
Listat e kërcënimeve	nyjet dalëse të Tor, Spamhaus DROP, FireHOL Level 1, blocklist.de të para-konfiguruara; çdo listë tjetër RBL mund të shtohet me adresë, krahasim i përditshëm, nivel i veçantë për çdo listë	raporto
Pa qasje në hyrje	Niveli i katërt për listat dhe vendet: faqja mund të lexohet, formulari i hyrjes dhe ndërfaqet janë të mbyllura — përgjigjja e duhur ndaj Tor	Opsion
Vendi i origjinës	Vendi për çdo përputhje dhe adresë nëpërmjet GeoLite2; modulin e përditëson vetë bazën e të dhënave me një çelës licence falas	shfaq
Rregullat e vendeve	Blloko, pa qasje në hyrje, raporto ose shprehimisht i lirë — për çdo vend, qëllimisht pa vlerë të paracaktuar	asnjë
Konfigurime të gabuara	QNAP, Synology, Exchange-Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV njihen, kurrë nuk bllokohen dhe vendosen në një listë pune me gjetjen dhe domenin e prekur	raporto
Tiketë për çdo adresë	Nga një gjetje, sipas dëshirës, krijohet një tiketë — saktësisht një për çdo adresë; një tiketë e mbyllur rihapet në vend që të dyfishohet	joaktiv
Faqet e detyrueshme dhe mbledhësit	Shtegu kanonik i Impressum-it mbetet gjithmonë i arritshëm; provuarja automatike i shkrimeve të huaja njihet dhe, sipas dëshirës, bllokohet	raporto
Lista e lirë	Adresa dhe rrjete që nuk bllokohen kurrë; mbushet çdo ditë nga firewall-i (skajet e VPN-së) dhe nga diapazonet e adresave të publikuara të Googlebot dhe Bingbot	aktiv
Caktimi te klienti	Një përputhje nga rrjeti i një klienti i caktohet atij — nga lista e lirë, kurrë e hamendësuar me dorë	aktiv
Domeni dhe identifikuesi për çdo përputhje	Cila faqe u thirr dhe me cilin User-Agent — të dyja mungojnë në regjistrin e qasjeve	aktiv
Analiza	Diagram dhe pivot mbi të gjitha përputhjet: sipas modelit, ditës, domenit, vendit, adresës	aktiv
Karremi	Sondat marrin përgjigje të shpikura me një vlerë kanarini; kush e thërret më vonë, i ka lexuar ato	joaktiv
Shpërndarja RBL	Lista e bllokimit si listë e thjeshtë adresash ose JSON në një adresë të veçantë, të mbrojtur me token — për HAProxy, OPNsense dhe çdo firewall që lexon lista URL-sh	aktiv

Gjithçka që jepet me raporto, joaktiv ose opsion është qëllimisht e tillë: kush aktivizon një bllokim, duhet ta bëjë sepse ka vëzhguar disa ditë se kush bie në të — jo sepse e kërkonte vlera e paracaktuar.

Analiza: përputhjet sipas modelit gjatë shtatë ditëve. Shtylla më e lartë është kërkimi i skedarëve .env.

Listat RBL: një mënyrë e standardizuar për të shpërndarë bllokimet

RBL do të thotë Real-time Blackhole List. Termi vjen nga bota e postës elektronike, ku Spamhaus dhe të tjerë që nga vitet nëntëdhjetë publikojnë lista adresash dërguesish me qëllim të keq. Parimi është shumë i thjeshtë dhe pikërisht për këtë aq i përhapur: një adresë në çdo rresht, e marrshme nëpërmjet HTTP, e ringarkuar rregullisht. Pa format që duhet analizuar fillimisht, pa ndërfaqe për të cilën duhet një mjet.

Praktikisht çdo firewall dhe çdo reverse proxy mund ta lexojë një listë të tillë dhe të ndërtojë rregulla prej saj. Prodhuesit e quajnë ndryshe, mekanizmi është kudo i njëjtë:

• OPNsense dhe pfSense — URL Table Alias: ngarkohet lista e adresave nëpërmjet HTTP, përdoret si alias në rregullat e firewall-it, përditësimi në ritëm orësh ose ditësh
• HAProxy — skedarë ACL dhe Maps: src -f sperrliste.txt në një rregull http-request deny, i ringarkueshëm nëpërmjet API-t të kohës së ekzekutimit pa rinisje
• nginx — moduli geo me skedar adresash të përfshirë, ose udhëzime deny nga një skedar include i gjeneruar
• Fortinet FortiGate — External Block List ose Threat Feed: një URL nga e cila firewall-i merr një listë IP-sh dhe e përdor në politika
• Palo Alto Networks — External Dynamic List (EDL): i njëjti parim, si lloj i veçantë objekti në politikat e sigurisë
• Check Point — Custom Intelligence Feeds dhe IP Block Lists nëpërmjet një URL-je
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds me burime të veta listash
• Sophos Firewall — Third-Party Threat Feeds: lista adresash nga një URL si burim për rregullat e bllokimit
• Juniper SRX — Dynamic Address Entries nga feed-e
• MikroTik RouterOS — Address Lists, të mbushura nga një URL me skript dhe fetch
• CrowdSec — lista të veta si burim për bouncer-ët në çdo sistem të mbështetur

Pikërisht në këtë format e shpërndan Web RBL listën e vet të bllokimit. Firewall-i hedh poshtë paketat para se të arrijnë te serveri i uebit — dhe bashkë me to çdo tentativë tjetër nga e njëjta adresë, për shembull ndaj serverit të postës ose portës së VPN-së.

Të dyja drejtimet, por në vendin e duhur

Rruga funksionon edhe në drejtim të kundërt: në Web RBL mund të regjistrohet çdo listë RBL e dëshiruar — një URL, një nivel, gati. Tor-Ausgangsknoten, Spamhaus DROP, FireHOL dhe blocklist.de janë të para-konfiguruara, të tjera shtohen me tre klikime. Moduli e ndan çdo listë në diapazone adresash dhe e krahason çdo kërkesë me to, brenda disa mikrosekondave.

Megjithatë: është më e arsyeshme që listat e huaja të përdoren në firewall-in para tij. Për tre arsye. Firewall-i sheh të gjitha shërbimet, jo vetëm HTTP — një adresë nga lista e Spamhaus duhet të dështojë edhe te serveri i postës dhe te VPN-ja. Ai hedh poshtë në nivel paketash, përpara se të krijohet fare një lidhje, dhe kështu nuk i kushton asgjë serverit të aplikacionit. Dhe është vendi ku këto lista mirëmbahen gjithsesi; një kopje e dytë në aplikacion është një vend i dytë që mund të vjetrohet.

Për çfarë janë atëherë të mira listat në modul: për atë që një firewall nuk e di të bëjë. Ai nuk e njeh formularin e hyrjes. Web RBL mund t’i mohojë një adrese nga lista Tor qasjen në hyrje dhe prapë ta shërbejë faqen — kush dëshiron të lexojë në mënyrë anonime, lejohet; kush dëshiron të provojë fjalëkalime në mënyrë anonime, jo. Dhe mund të raportojë një hyrje të suksesshme nga një adresë e listuar si rast i dyshimtë. Të dyja kërkojnë listën aty ku bëhet hyrja.

Vlerësim në vend të ndjesisë

Një adresë që ka pyetur një herë për /wp-login.php është diçka tjetër nga një që në dy ditë ka kaluar me pesë modele të ndryshme nëpër tre domene. Web RBL e kthen këtë në një vlerësim nga 0 deri në 100 — nga ajo që ka parë vetë, pa shërbim të huaj dhe pa pyetje jashtë.

Një regjistrim: 99 përputhje, vlerësim 84, dhe arsyetimi në tekst të qartë — modeli më i rëndë, pesë modele të ndryshme serioze, dy ditë të dyshimta, mbi njëzet përputhje.

Vlerësimi vendos për dy gjëra. Nga një vlerë e rregullueshme e tutje hyrja ndalohet — faqja mbetet e lexueshme, por kush ka kërkuar tashmë të dhëna hyrjeje, nuk merr mundësi t’i provojë ato që gjeti. Dhe një hyrje e suksesshme nga një adresë me vlerësim raportohet: atëherë njëri nuk ka hamendësuar më, por ka ditur. Ose përdoruesi i autorizuar ishte në udhëtim, ose të dhënat e hyrjes kanë humbur — moduli nuk e vendos këtë, ia paraqet njërit që mund të pyesë. Fjalëkalimi vetë nuk preket askund.

Lista e bllokimit, e filtruar sipas vlerësimit nga 40: numri i përputhjeve, dita të dyshimta, domenet e prekura dhe shtegu i fundit për çdo adresë.

Çfarë mbron Web RBL — efekti mbrojtës në detaje

1. Të dhënat e hyrjes mbeten të pazbuluara

Klasa më e madhe e matur e sulmeve nuk kërkon dobësi në Odoo, por sekrete të harruara. Gjatë shtatëmbëdhjetë ditëve:

• 57.721 kërkesa për skedarë .env — aty ndodhen fjalëkalime bazash të dhënash, çelësa API dhe sekrete sesionesh
• 5.535 kërkesa për skedarë konfigurimi
• 4.388 kërkesa për të dhëna hyrjeje në re: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 kërkesa për drejtori .git — kush gjen një të tillë, shkarkon kodin e plotë burimor së bashku me historikun
• 1.907 kërkesa për udhëzime ndërtimi si .github/workflows/deploy.yml ose .gitlab-ci.yml, ku ndodhen regjistrat dhe emrat e çelësave

Vendimtar nuk është numri i kërkesave, por numri i adresave të ndryshme: /credentials.json erdhi nga 98 adresa, /.git-credentials nga 92. Ky nuk është një skaner i vetëm, por një repertor standard që funksionon në mbarë botën njëkohësisht.

2. Tentativat e hyrjes shkojnë në boshllëk — përgjithmonë

Odoo ka një frenë të vetën kundër provimit të fjalëkalimeve. Ajo ka tri kufij, të dokumentuar në vetë kodin burimor të Odoo-s: numruesi ndodhet në kujtesën e procesit të punës dhe rivendoset me çdo rinisje, ai vetëm vonon në vend që të bllokojë, dhe numëron vetëm tentativat që arrijnë deri te kontrolli i fjalëkalimit.

Web RBL fillon në të njëjtat pika, por shkruan në bazën e të dhënave. Kështu vlen:

• Gjendja mbijeton çdo rinisje dhe vlen për të gjitha proceset e punës
• Regjistrohen të dyja rrugët: formulari i hyrjes /web/login dhe ndërfaqet /xmlrpc/2/common dhe /jsonrpc
• Regjistrohen edhe tentativat që nuk arrijnë kurrë deri te kontrolli i fjalëkalimit — për shembull hyrje pa shenjë të vlefshme sesioni
• Një qasje e dështuar te menaxheri i bazës së të dhënave numërohet gjithashtu; kjo është tentativa më e rëndë e hyrjes në përgjithësi

Pragu për hyrjet është dhjetë, dhe arsyeja është një matje: nga nëntë hyrjet e dështuara në shtatëmbëdhjetë ditë, shumica i përkisnin klientëve, të cilët vetë e vendosën qasjen në një pajisje tjetër dhe futën domenin e gabuar — në një rast të vetin, vetëm me vizë në vend të pikës. Një bllokim në tentativën e parë të dështuar nuk do të kishte goditur sulmuesit, por klientët gjatë vendosjes.

Kush, përkundrazi, vazhdon të trokasë ndonëse serveri ka dhënë tashmë përgjigjen „ju lutem prisni pak“, bllokohet menjëherë. Këtë mesazh e lexon një njeri dhe pret; kush e injoron, është një program. Një model i veçantë me prag zero kap pikërisht këtë rast, dhe nuk mund të godasë një koleg: atje arrin vetëm kush ka tashmë dhjetë tentativa të dështuara pas vetes dhe më pas vazhdon.

3. Sulmi nuk i kushton më asgjë serverit

Një sondë për një shteg si /@fs/../../.env ishte para modulit e kushtueshme: Odoo kërkon faqen e gabimit, e renderon, pengohet në ndërtimin e adresës te segmentet me pika dhe dështon pastaj edhe te faqja e gabimit të faqes së gabimit. Dy protokolle stivash për çdo sondë. U matën 28.401 gabime të tilla në shtatëmbëdhjetë ditë, plus 9.467 gabime pasuese.

Web RBL ndërhyn në ir.http._match, pra para gjetjes së rrugës. Përgjigjja jepet pa shabllon, pa qasje në bazën e të dhënave përtej kontrollit të bllokimit dhe pa rresht protokolli. Kontrolli kundrejt listës së lirë, listave të kërcënimeve dhe rregullave të vendeve kryhet nga kujtesa e ndërmjetme mbi diapazone adresash të renditura — disa mikrosekonda, edhe me mbi tridhjetë mijë diapazone.

4. Firewall-i e hedh sulmuesin jashtë para se të arrijë

Lista e bllokimit publikohet si listë RBL, të cilën HAProxy dhe OPNsense e lexojnë drejtpërdrejt. Sulmuesi nuk e arrin më fare serverin e uebit — dhe as ndonjë shërbim tjetër në një host të njëjtë. Një qasje e njohur një herë si e keqe mbron kështu me efekt prapaveprues të gjithë makinën.

Tri nivele: blloko, numëro, raporto

Jo çdo kërkesë në boshllëk është sulm. Prandaj Web RBL dallon tri nivele, dhe niveli mund të ndërrohet për çdo model, pa u prekur kodi.

Niveli	Kërkesa shkaktuese	Pasoja për adresën
blloko	refuzohet	e bllokuar 24 orë, pas tri ditësh të dyshimta përgjithmonë
numëro	kalon	vetëm regjistrohet, pa bllokim
raporto	kalon	regjistrohet me tekst gjetjeje, kurrë nuk bllokohet

Për listat e kërcënimeve dhe vendet ka një të katërt: pa qasje në hyrje. Faqja mbetet e lexueshme, formulari i hyrjes dhe ndërfaqet janë të mbyllura. Ky është kompromisi për çdo gjë që është e dyshimtë, por nuk ka pse të jetë me qëllim të keq — Tor, një diapazon qendre të dhënash, një vend pa klientë.

Cilat sulme njihen

Të gjitha modelet janë provuar me trafik real. Numri i adresave të ndryshme qëndron qëllimisht pranë — ai tregon nëse një model godet një skaner të vetëm apo një mënyrë veprimi të përhapur.

Klasa e sulmit	Kërkesa	Adresa
Mbledhja e .env	57.721	223
Sonda PHP	12.237	256
Path traversal me objektiv të vlefshëm	10.046	64
Skedarë konfigurimi	5.535	114
Çelësa qasjeje në re	4.388	152
Sonda WordPress	3.366	385
Mbledhja e .git	2.811	255
Zbulim i Odoo-s (menaxheri i bazës së të dhënave, pyetje versioni)	2.500	213
Zinxhirë mjetesh të inteligjencës artificiale dhe ekzekutim komandash (/mcp, /api/fs/exec)	2.450	74
Udhëzime ndërtimi (CI/CD)	1.907	88
Pika fundore GraphQL	1.878	71

E dukshme është klasa më e re. /api/fs/exec u kërkua 369 herë nga 54 adresa të ndryshme — ky nuk është një qasje leximi, por një tentativë për të ekzekutuar komanda. Objektiva si këta nuk ekzistonin dy vjet më parë; ato vijnë nga ndërfaqet e mjeteve të reja të inteligjencës artificiale dhe radhëve të detyrave. Kush e orienton mbrojtjen e vet vetëm në WordPress dhe PHP, nuk sheh asgjë nga kjo. Në vlerësim kjo klasë peshon me të drejtë rëndë.

Listat e kërcënimeve dhe vendi i origjinës

Katër lista, 32.851 diapazone adresash, të gjitha në „vetëm raporto“. Çdo listë tjetër është një adresë dhe një nivel.

Një listë e huaj është një pohim që e bën dikush tjetër, nga arsye që nuk i njohim, për një trafik që nuk e kemi parë kurrë. Mund të jetë e gabuar, e vjetruar ose e menduar për një qëllim tjetër: blocklist.de mbledh kryesisht adresa që diku tjetër kanë provuar hyrje SSH, dhe kjo thotë pak për një server uebi. Prandaj Web RBL i mban listat e huaja të ndara nga lista e vet e bllokimit, dhe prandaj vlera e paracaktuar është raporto. Dhe lista e lirë e jonë fiton gjithmonë: një klient që e njohim peshon më shumë se vlerësimi i një të treti.

Vendi i origjinës shfaqet te çdo përputhje dhe çdo adresë. Për vlerësim është i pazëvendësueshëm — një tentativë hyrjeje nga vendi ynë në orën dhjetë të paradites është diçka tjetër nga një nga një vend pa asnjë klient. Për bllokim të përgjithshëm vlen pak, dhe këtë e thonë shifrat tona: sulmuesit në listën tonë vinin kryesisht nga diapazone resh në Belgjikë, Finlandë dhe Holandë. Një bllokim për gjithçka jashtë zonës gjermanishtfolëse nuk do t’i kishte goditur — por do të kishte goditur punonjës tanë në pushim dhe klientë në udhëtim pune.

Rregullat e vendeve shpërndahen bosh, dhe pamja e thotë pse.

Konfigurimet e gabuara raportohen në vend që të bllokohen

Rasti më i shpeshtë në trafikun real nuk është as sulm, as vizitor, por softuer i prishur që e ngatërron serverin e uebit me diçka tjetër:

• 1.367 thirrje të ndërfaqes së uebit të një QNAP-NAS — një klient sinkronizimi, objektivi i të cilit nuk është më i saktë. Një port i vetëm trokiti 962 herë.
• 65 pyetje Autodiscover — një Outlook që e merr domenin e uebit për Exchange-in e vet

Adresa të tilla nuk bllokohen kurrë. Një bllokim nuk e zgjidh defektin, e fsheh — dhe godet atë që pajisja e tij është tashmë e konfiguruar gabim. Në vend të kësaj krijohet një regjistrim me tekst gjetjeje dhe domenet e prekura, nga i cili, sipas dëshirës, krijohet automatikisht një tiketë: për çdo adresë saktësisht një, dhe nëse mbyllet dhe adresa bie sërish në sy, rihapet e njëjta tiketë, në vend që të krijohet një e dytë.

Njihen QNAP, Synology, Exchange-Autodiscover, ActiveSync dhe klientët WebDAV, CalDAV dhe CardDAV. Modelet përmendin emra të saktë skedarësh dhe drejtori, kurrë prapashtesa të thjeshta: Në të njëjtën drejtori /cgi-bin/ thirrjet e padëmshme sinkronizimi ndodhen drejtpërdrejt pranë sondave klasike si printenv.pl.

Lista e lirë: adresa që nuk bllokohen kurrë

Çmimi i një gabimi nuk është i njëjtë për të gjitha adresat. Te një skaner nga një qendër të dhënash, një alarm i rremë nuk kushton asgjë. Te skaji i largët i një tuneli lokacioni, i kushton lokacionin.

Prandaj ekziston një listë e dytë, që qëndron para të parës: adresa dhe rrjete që nuk bllokohen kurrë. Ajo nuk e vë asgjë në heshtje — kush është në të, vazhdon të kontrollohet dhe regjistrohet, vetëm pasoja bie. Kjo është dallimi nga një përjashtim në firewall: ai të verbon, kjo të bën vetëm të durueshëm.

Mbushet çdo ditë nga dy burime: nga vetë firewall-i me të gjitha skajet e VPN-së, që një tunel i sapovendosur të mos varet nga fakti që dikush mendon për listën e bllokimit — dhe nga diapazonet e adresave të publikuara të Google-it dhe Microsoft-it për crawler-ët e tyre. Vetëm kështu mund të dallohet një Googlebot i vërtetë nga një skaner që e quan veten kështu. Motorët e kërkimit nuk duhet të bllokohen kurrë; kush i përjashton, e heq faqen e vet nga indeksimi pa mundësi kthimi.

Këtu vlen një rregull që është më i rëndësishëm se krahasimi: Një përgjigje e zbrazët nuk fshin kurrë. Nëse burimi nuk përgjigjet, kthen të zbrazët ose të pakuptueshme, lista mbetet e pandryshuar. Një listë e lirë që zbrazet vetë gjatë një defekti, merr me vete në çastin më të keq të mundshëm të gjithë tunelet.

Nëse një regjistrim i listës së lirë mban një klient, çdo përputhje nga rrjeti i tij i caktohet atij. Një konfigurim i gabuar ka kështu menjëherë një person kontakti, pa pasur nevojë që dikush të kërkojë adresa.

Të dhëna të detyrueshme dhe mbledhës të automatizuar të dhënash

Impressum nuk është faqe e zakonshme. Duhet të mbetet e arritshme për njerëzit, sepse një bllokim mbi të krijon pikërisht shkeljen që kërkon një mbledhës. Njëkohësisht është faqja ku ndodhen emri dhe adresa — dhe kështu objektivi i korrjes automatike.

Në valën austriake të njoftimeve paralajmëruese për shkak të shkronjave të Google-it të integruara, protokollet treguan se letrat nuk vinin nga vizita të veçanta, por nga një sulm i automatizuar i gjerë: hoste të ndryshëm, të palidhur mes tyre, në distancë milisekondash.

Web RBL e zgjidh këtë me ulje niveli në vend të përjashtimit. Shtegu kanonik /impressum nuk përputhet me asnjë model dhe mbetet gjithmonë i arritshëm. Shkrimet e huaja si /impressum.php — të cilat në një faqe Odoo nuk mund të ekzistojnë — raportohen, dhe kush nuk dëshiron ta pranojë korrjen automatike, ndryshon një parametër. sitemap dhe robots përjashtohen nga kjo dhe në parim nuk mund të bllokohen: ato nuk përmbajnë asnjë të dhënë personale, dhe marrja e tyre është detyra e çdo crawler-i të motorëve të kërkimit.

Domeni dhe identifikuesi: çfarë mungon në regjistrin e qasjeve

Regjistri i qasjeve i werkzeug nuk shkruan as hostin e thirrur, as identifikuesin e thirrësit. Odoo i merr natyrisht të dyja — pa hostin nuk mund të zgjidhte dot faqen e duhur kur ka disa faqe. Por pas faktit nuk mund të lexohet.

Web RBL i ruan të dyja për çdo përputhje. Kjo u përgjigjet dy pyetjeve që nuk mund t’u përgjigjemi ndryshe: cila faqe i referohet një konfigurimi të gabuar — dhe kështu cilit klient i përket domeni — dhe nëse një adresë viziton një faqe apo të gjitha. Disa domene të palidhura të së njëjtës adresë janë shenja e sulmit të gjerë, dhe ato e rrisin vlerësimin.

Sa shumë peshon identifikuesi, e tregoi një analizë në një nga faqet tona: mbi shtatëdhjetë përqind e të gjithë trafikut iu përkiste atje një thirrësi të vetëm, i shpërndarë në më shumë se njëqind adresa. Pa identifikuesin kjo do të kishte dukur si një scraper i shpërndarë. Ishte GPTBot, crawler-i i OpenAI — pyeste vazhdimisht për robots.txt dhe sillej plotësisht korrekt.

Aspektet e sigurisë në detaje

1. Njohja e proxy-t — vendi më i rrezikshëm në përgjithësi

Nëse Odoo funksionon pas një reverse proxy dhe proxy_mode është vendosur gabim, moduli sheh në çdo kërkesë të njëjtën adresë: ajo e proxy-t. Një bllokim do të përjashtonte atëherë të gjithë vizitorët njëkohësisht.

Prandaj Web RBL kontrollon para çdo bllokimi nëse përcaktimi i adresës është i besueshëm. Kërkon proxy_mode së bashku me një kokë përcjellëse, refuzon të punojë nëse arrin një përcjellje pa proxy_mode, dhe e refuzon gjithashtu kur ka më shumë se një proxy të ndërmjetëm. Në dyshim nuk bllokohet.

2. Rrjetet e veta asnjëherë

Diapazonet e adresave private, loopback, link-local dhe CGNAT janë të përjashtuara përgjithmonë. Ato nuk mund të përfundojnë në asnjë rrethanë në listë, as me dorë. E njëjta vlen për listat e huaja: diapazonet private dhe diapazonet e rezervuara, si dhe rrjetet absurdisht të mëdha, hidhen poshtë gjatë leximit.

3. Një gabim i vetë moduli nuk duhet ta marrë faqen me vete

I gjithë kontrolli kryhet në një mbrojtje që kap çdo gabim. Çfarë shkon keq këtu, protokollohet, dhe kërkesa vazhdon e pandryshuar. Një modul mbrojtës që, gjatë një gabimi të vetin, e merr faqen me vete, është më keq se aspak. Të gjitha pyetjet në rrugën e kërkesës kryhen përveç kësaj pa gjuhën e shfletuesit të vizitorit dhe pa renditje sipas fushave të përkthyera — një vizitor me një gjuhë të paintaluar nuk duhet ta bëjë kontrollin të dështojë.

4. Vëzhgo para se të bllokosh

Pas instalimit, bllokimi i adresave të listuara në kërkesa të zakonshme është i çaktivizuar. Sondat refuzohen dhe regjistrohen, gjithçka tjetër kalon. Kështu mund të lexohet për disa ditë kush përfundon realisht në listë, para se dikush t’i përjashtohet. E njëjta vlen për njohjen e sjelljes, listat e kërcënimeve dhe rregullat e vendeve: fillimisht raporto, blloko pas vlerësimit.

5. Modele të ngushta në vend të rrjeteve të gjera

Një vizitor i njohur gabimisht është më i kushtueshëm se një sondë e anashkaluar. Çdo model mban prandaj nivelin e vet, dhe ai mund të ndërrohet për çdo model. Një prapashtesë skedari vetëm rrallë mjafton: te .php qëndrojnë 14.012 sonda të vërteta kundër një grushti lidhjesh të vjetra, te .asp raporti është i kundërt. Vendime si këto duhen matur, jo vlerësuar.

6. Një çlirim me dorë mbetet në fuqi

Kush çliron një adresë, kishte një arsye. Një përputhje tjetër nuk e anulon në heshtje këtë vendim.

7. Lista është e mbrojtur, por nuk është sekret

Pika fundore kërkon një token dhe pa token të vlefshëm përgjigjet me 404, jo me 403 — ekzistenca e adresës nuk konfirmohet kështu fare. Krahasimi kryhet në kohë konstante. Vetë lista nuk përmban asgjë konfidenciale: Ajo përbëhet nga adresa që kanë trokitur vetë te ne.

8. Pa sekrete në kontabilitet

Në hyrjet e dështuara shënohet emri i përdoruesit i provuar, kurrë fjalëkalimi. Te menaxheri i bazës së të dhënave nga vlerat e dorëzuara nuk lexohet fare asgjë: Aty në vendin e parë qëndron fjalëkalimi kryesor, dhe një regjistrim në një listë bllokimi shkon në çdo kopje rezervë të bazës së të dhënave. Çelësi i licencës për GeoLite2 gjendet vetëm në parametrin e sistemit dhe në asnjë rresht protokolli.

9. Karremi nuk zbulon asgjë të përdorshme

Opsionalisht Web RBL u përgjigjet sondave me përmbajtje të shpikur që përmban një vlerë të qartë kanarini. Kush e thërret më vonë këtë vlerë, ka lexuar përgjigjen e falsifikuar dhe ka vepruar në bazë të saj — një alarm i rremë këtu përjashtohet. Karremat nuk përmbajnë asnjë të dhënë të përdorshme, asnjë shteg të vërtetë dhe asnjë të dhënë hyrjeje të vlefshme. Ky funksion jepet i çaktivizuar, sepse ndryshon sjelljen e dukshme nga jashtë.

Çfarë nuk mund të bëjë moduli

Nuk zëvendëson as firewall as Web Application Firewall. Njeh modele të njohura sondimi në shtigje, hyrje të dështuara dhe sjellje të dyshimtë — jo sulme ndaj formularëve, jo tentativa injektimi në parametra.

Përveç kësaj sheh vetëm atë që kthehet nëpërmjet HTTP. Çfarë bën një sulmues me qasje të vjedhura në baza të dhënash ose kuti postare, mbetet e padukshme — dhe pikërisht për këtë vlerat e kanarinit janë shtigje dhe jo të dhëna hyrjeje.

Dhe nuk zëvendëson kujdesin: Një modul që refuzon sondat .env nuk e bën të padëmshëm një skedar .env të shërbyer gabimisht.

Disponueshmëria

Web RBL është i disponueshëm publikisht nën AGPL-3 dhe funksionon te ne në prodhim në pesë faqe:

github.com/Alex0176/odoo-web-rbl

Moduli kërkon Odoo 19 Community dhe nuk ka varësi përveç base dhe web. Lidhja me tiketat është opsionale dhe nuk kërkon ndonjë sistem tiketash të caktuar; pa të, thjesht nuk ndodh asgjë. Vendi i origjinës kërkon bazën e të dhënave falas GeoLite2 të MaxMind; nëse mungon, fusha mbetet bosh dhe gjithçka tjetër funksionon e pandryshuar.

Vazhdim: Si përshtatet Web RBL në një arkitekturë të plotë sigurie -- së bashku me firewall, vërtetim dyfaktorësh dhe të drejta, përfshirë udhëzimin hap pas hapi: Si të kombinohet drejt arkitektura e sigurisë së Odoo 19.

Pyetjet, vërejtjet dhe raportet e gabimeve i pranojmë me kënaqësi — mundësisht si Issue në GitHub.