Odoo 19 Community: Web RBL – listă de blocare pentru traficul de atac pe propriile site-uri

Cod sursă: github.com/Alex0176/odoo-web-rbl — AGPL-3, utilizabil liber.

Cine operează un server Odoo pe internet primește vizite. Nu ocazional, ci neîntrerupt. Pe parcursul a șaptesprezece zile am înregistrat și evaluat pe cele cinci site-uri ale noastre 731.297 de cereri. 110.511 dintre ele nu au fost vizitatori, ci căutare automatizată de vulnerabilități, date de acces și fișiere de configurare.

Acest articol descrie Web RBL, un modul open source pentru Odoo 19 Community, care recunoaște, evaluează, înregistrează și respinge acest trafic — și care publică lista de blocare ca listă RBL, adică în formatul pe care firewall-urile și reverse proxy-urile îl citesc direct. Toate cifrele provin din funcționarea reală.

Ce poate modulul — funcțiile în privire de ansamblu

Funcție	Ce face	Livrare
Recunoașterea tiparelor	Recunoaște sondările după cale și extensie: .env, .git, fișiere de configurare, chei cloud, instrucțiuni de build CI/CD, WordPress, PHP, path traversal, administratori de baze de date, GraphQL, execuție de comenzi prin /api/fs/exec și interfețe similare	blocare
Trei niveluri pentru fiecare tipar	blocare, numărare sau raportare — modificabile pentru fiecare tipar, fără cod	pentru fiecare tipar
Praguri	Atâtea potriviri ale aceluiași tipar înainte de blocare; pentru autentificări zece	10 la autentificare
Apărare la autentificare	Autentificări eșuate prin formular și XML-RPC/JSON-RPC, verificări de sesiune eșuate, accesări ale administratorului de baze de date — în baza de date, nu în memoria de lucru	activ
Recunoașterea boților la autentificare	Cine ignoră mesajul de așteptare după zece încercări eșuate și continuă să bată la ușă este blocat imediat	blocare
Recunoașterea comportamentului	Adrese care produc în cinci minute douăzeci de pagini inexistente și aproape nicio pagină găsită — deci ghicesc în loc să citească	raportare
Evaluare 0–100	Cât de sigur este că în spatele adresei se află un atacator? Din gravitatea tiparului, numărul de tipare diferite, zile remarcabile, domenii afectate și numărul de potriviri — cu justificare în text clar	activ
Blocarea autentificării după evaluare	De la o evaluare configurabilă, autentificarea este interzisă, site-ul rămâne lizibil	de la 40
Suspiciune de date de acces furate	O autentificare reușită de la o adresă suspectă este raportată și, la cerere, atribuită ca sarcină — o singură dată pe adresă și pe zi	activ
Liste de amenințări	Noduri de ieșire Tor, Spamhaus DROP, FireHOL Level 1, blocklist.de preconfigurate; orice altă listă RBL poate fi adăugată prin adresă, comparare zilnică, nivel propriu pentru fiecare listă	raportare
Fără acces la autentificare	Al patrulea nivel pentru liste și țări: site-ul rămâne lizibil, formularul de autentificare și interfețele sunt închise — răspunsul potrivit pentru Tor	Opțiune
Țara de origine	Țara pentru fiecare detecție și adresă prin GeoLite2; modulul își actualizează singur baza de date cu o cheie de licență gratuită	afișare
Reguli pe țări	Blocare, fără acces la autentificare, raportare sau explicit liber — pentru fiecare țară, în mod deliberat fără valoare implicită	niciuna
Configurări greșite	QNAP, Synology, Exchange Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV sunt recunoscute, niciodată blocate și introduse într-o listă de lucru cu constatarea și domeniul afectat	raportare
Tichet pe adresă	Dintr-o constatare se creează, la cerere, un tichet — exact unul pe adresă; unul închis este redeschis în loc să fie dublat	dezactivat
Pagini obligatorii și colectori	Calea canonică a paginii de mențiuni legale rămâne mereu accesibilă; încercarea automată a unor variante străine de scriere este detectată și, la cerere, blocată	raportare
Lista albă	Adrese și rețele care nu sunt niciodată blocate; se completează zilnic din firewall (stațiile VPN la distanță) și din intervalele de adrese publicate ale Googlebot și Bingbot	activ
Atribuirea către client	O detecție din rețeaua unui client îi este atribuită lui — pe baza listei albe, niciodată presupusă manual	activ
Domeniu și identificator pentru fiecare detecție	Ce site a fost accesat, cu ce User-Agent — ambele lipsesc din jurnalul de acces	activ
Analiză	Diagramă și pivot pentru toate detecțiile: pe model, zi, domeniu, țară, adresă	activ
Momeală	Sondele primesc răspunsuri inventate cu o valoare-canar; cine o accesează ulterior le-a citit	dezactivat
Livrarea RBL	Lista de blocare ca simplă listă de adrese sau JSON, la o adresă proprie protejată cu token — pentru HAProxy, OPNsense și orice firewall care citește liste de URL-uri	activ

Tot ce este livrat cu raportare, dezactivat sau opțiune este astfel în mod deliberat: cine activează o blocare ar trebui s-o facă pentru că a observat câteva zile cine cade în ea — nu pentru că valoarea implicită a cerut-o.

Analiza: detecții pe model în decurs de șapte zile. Cea mai înaltă bară este căutarea fișierelor .env.

Liste RBL: o modalitate standardizată de a livra blocări

RBL înseamnă Real-time Blackhole List. Termenul provine din lumea e-mailului, unde Spamhaus și alții publică din anii nouăzeci liste de adrese de expeditori rău intenționați. Principiul este atât de simplu și tocmai de aceea atât de răspândit: o adresă pe fiecare rând, accesibilă prin HTTP, reîncărcată periodic. Fără un format pe care trebuie să-l analizezi mai întâi, fără o interfață pentru care ai nevoie de un instrument.

Practic orice firewall și orice reverse proxy poate citi o astfel de listă și construi reguli pe baza ei. Producătorii o numesc diferit, dar mecanismul este peste tot același:

• OPNsense și pfSense — URL Table Alias: încărcarea listei de adrese prin HTTP, utilizarea ca alias în regulile firewall, actualizare orară sau zilnică
• HAProxy — fișiere ACL și Maps: src -f sperrliste.txt într-o regulă http-request deny, reîncărcabilă prin API-ul de execuție fără repornire
• nginx — modulul geo cu fișier de adrese inclus, sau instrucțiuni deny dintr-un fișier include generat
• Fortinet FortiGate — External Block List respectiv Threat Feed: un URL din care firewall-ul preia o listă de IP-uri și o folosește în politici
• Palo Alto Networks — External Dynamic List (EDL): același principiu, ca tip de obiect separat în politicile de securitate
• Check Point — Custom Intelligence Feeds și IP Block Lists printr-un URL
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds cu surse proprii de liste
• Sophos Firewall — Third-Party Threat Feeds: liste de adrese de la un URL ca sursă pentru regulile de blocare
• Juniper SRX — Dynamic Address Entries din feed-uri
• MikroTik RouterOS — Address Lists, completate printr-un script și fetch dintr-un URL
• CrowdSec — liste proprii ca sursă pentru bouncere pe orice sistem acceptat

Exact în acest format livrează Web RBL lista sa de blocare. Firewall-ul respinge pachetele înainte ca acestea să ajungă la serverul web — și odată cu ele orice altă încercare de la aceeași adresă, de exemplu spre serverul de e-mail sau gateway-ul VPN.

Ambele sensuri, dar la locul potrivit

Calea funcționează și invers: în Web RBL se poate adăuga orice listă RBL — un URL, un nivel, gata. Nodurile de ieșire Tor, Spamhaus DROP, FireHOL și blocklist.de sunt preconfigurate, altele se adaugă în trei clicuri. Modulul descompune fiecare listă în intervale de adrese și verifică fiecare cerere în raport cu ele, în câteva microsecunde.

Și totuși: este mai potrivit să folosiți listele externe pe firewall, înaintea aplicației. Din trei motive. Firewall-ul vede toate serviciile, nu doar HTTP — o adresă din lista Spamhaus trebuie să eșueze și la serverul de e-mail și la VPN. El respinge la nivel de pachet, înainte ca o conexiune să se stabilească, și astfel nu costă nimic serverul de aplicații. Și el este locul unde astfel de liste sunt oricum întreținute; o a doua copie în aplicație este un al doilea loc care se poate perima.

La ce mai servesc atunci listele din modul: pentru ceea ce un firewall nu poate. El nu cunoaște formularul de autentificare. Web RBL poate refuza accesul la autentificare unei adrese din lista Tor și totuși livra site-ul — cine vrea să citească anonim trebuie să poată; cine vrea să încerce anonim parole, nu. Și poate raporta ca suspiciune o autentificare reușită de la o adresă listată. Ambele necesită lista chiar acolo unde are loc autentificarea.

Evaluare în loc de intuiție

O adresă care a cerut o singură dată /wp-login.php este altceva decât una care, în două zile, a trecut cu cinci modele diferite prin trei domenii. Web RBL transformă asta într-o evaluare de la 0 la 100 — pe baza a ceea ce a văzut chiar el, fără serviciu extern și fără interogări către exterior.

O intrare: 99 de detecții, evaluarea 84, și motivarea în text clar — cel mai grav model, cinci modele serioase diferite, două zile suspecte, peste douăzeci de detecții.

Evaluarea decide asupra a două lucruri. De la o valoare reglabilă, autentificarea este interzisă — site-ul rămâne lizibil, dar cine a căutat deja date de acces nu primește ocazia de a încerca ce a găsit. Iar o autentificare reușită de la o adresă cu evaluare este raportată: atunci cineva nu a mai ghicit, ci a știut. Fie utilizatorul îndreptățit era în deplasare, fie datele de acces s-au pierdut — modulul nu decide asta, ci o prezintă unei persoane care poate întreba. Parola în sine nu este atinsă nicăieri.

Lista de blocare, filtrată după evaluare de la 40: numărul de detecții, zilele suspecte, domeniile afectate și ultima cale pentru fiecare adresă.

Ce protejează Web RBL — efectul de protecție în detaliu

1. Datele de acces rămân nedescoperite

Cea mai mare clasă de atacuri măsurată nu caută breșe în Odoo, ci secrete lăsate nepăzite. Pe parcursul a șaptesprezece zile:

• 57.721 de cereri pentru fișiere .env — acolo se află parole de baze de date, chei API și secrete de sesiune
• 5.535 de cereri pentru fișiere de configurare
• 4.388 de cereri pentru date de acces cloud: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 de cereri pentru directoare .git — cine găsește unul descarcă întregul cod sursă împreună cu istoricul
• 1.907 de cereri pentru instrucțiuni de build precum .github/workflows/deploy.yml sau .gitlab-ci.yml, în care sunt înscrise registrele și numele cheilor

Decisiv nu este numărul de cereri, ci numărul de adrese diferite: /credentials.json a venit de la 98 de adrese, /.git-credentials de la 92. Nu este un singur scaner, ci un repertoriu standard care rulează simultan în întreaga lume.

2. Încercările de autentificare se pierd în gol — permanent

Odoo vine cu o frână proprie împotriva încercării succesive a parolelor. Ea are trei limite, documentate chiar în codul sursă Odoo: Contorul se află în memoria de lucru a procesului de lucru și este resetat la fiecare repornire, el doar întârzie în loc să blocheze, și numără exclusiv încercările care ajung până la verificarea parolei.

Web RBL intervine în aceleași puncte, dar scrie în baza de date. Astfel:

• Starea supraviețuiește oricărei reporniri și este valabilă pentru toate procesele de lucru
• Sunt înregistrate ambele căi: formularul de autentificare /web/login și interfețele /xmlrpc/2/common și /jsonrpc
• Sunt înregistrate și încercările care nu ajung niciodată la verificarea parolei — de exemplu autentificările fără un marcaj de sesiune valid
• Un acces eșuat la managerul bazelor de date este numărat; aceasta este cea mai gravă încercare de autentificare

Pragul pentru autentificări este setat la zece, iar motivul este o măsurătoare: Din nouă autentificări eșuate în șaptesprezece zile, majoritatea proveneau de la clienți care și-au configurat singuri accesul pe un alt dispozitiv și au introdus domeniul greșit — într-un caz pe al lor, doar cu cratimă în loc de punct. O blocare la prima încercare eșuată nu ar fi lovit atacatorii, ci clienții în timpul configurării.

Cine, în schimb, continuă să bată la ușă deși serverul a răspuns deja „așteptați puțin”, este blocat imediat. Acest mesaj îl citește un om și așteaptă; cine îl ignoră este un program. Un model propriu cu prag zero prinde exact acest caz și nu poate lovi un coleg: Acolo ajunge doar cine are deja zece încercări eșuate în urmă și apoi continuă.

3. Atacul nu mai costă nimic serverul

O sondă către o cale precum /@fs/../../.env era costisitoare înainte de modul: Odoo caută pagina de eroare, o randează, se împiedică la construirea adresei de segmentele cu puncte și eșuează apoi și la pagina de eroare a paginii de eroare. Două stack trace-uri pe sondă. S-au măsurat 28.401 astfel de erori în șaptesprezece zile, plus 9.467 de erori subsecvente.

Web RBL intervine în ir.http._match, deci înainte de găsirea rutei. Răspunsul se dă fără șablon, fără acces la baza de date dincolo de verificarea blocării și fără linie de jurnal. Verificarea în raport cu lista albă, listele de amenințări și regulile pe țări rulează din cache prin intervale de adrese sortate — câteva microsecunde, chiar și la peste treizeci de mii de intervale.

4. Firewall-ul îl alungă pe atacator înainte să ajungă

Lista de blocare este publicată ca listă RBL pe care HAProxy și OPNsense o citesc direct. Atacatorul nu mai ajunge astfel deloc la serverul web — și nici la vreun alt serviciu de pe același host. Un acces recunoscut o dată ca rău intenționat protejează astfel retroactiv întregul sistem.

Trei niveluri: blocare, numărare, raportare

Nu orice cerere în gol este un atac. De aceea Web RBL distinge trei niveluri, iar nivelul poate fi schimbat pentru fiecare model, fără a atinge codul.

Nivel	Cererea declanșatoare	Consecința pentru adresă
blocare	este respinsă	blocată 24 de ore, definitiv după trei zile suspecte
numărare	trece mai departe	doar înregistrată, fără blocare
raportare	trece mai departe	înregistrată cu text de constatare, niciodată blocată

Pentru listele de amenințări și țări există un al patrulea: fără acces la autentificare. Site-ul rămâne lizibil, formularul de autentificare și interfețele sunt închise. Este calea de mijloc pentru tot ce este suspect, dar nu trebuie să fie rău intenționat — Tor, un interval de centru de date, o țară fără clienți.

Ce atacuri sunt recunoscute

Toate modelele sunt verificate pe trafic real. Numărul de adrese diferite este afișat în mod deliberat alături — arată dacă un model lovește un singur scaner sau un mod de acțiune răspândit.

Clasa de atac	Cereri	Adrese
Extragere .env	57.721	223
Sonde PHP	12.237	256
Path traversal cu țintă valoroasă	10.046	64
Fișiere de configurare	5.535	114
Chei de acces cloud	4.388	152
Sonde WordPress	3.366	385
Extragere .git	2.811	255
Explorare Odoo (manager de baze de date, interogare de versiune)	2.500	213
Lanțuri de instrumente AI și execuție de comenzi (/mcp, /api/fs/exec)	2.450	74
Instrucțiuni de build (CI/CD)	1.907	88
Endpoint-uri GraphQL	1.878	71

Remarcabilă este cea mai recentă clasă. /api/fs/exec a fost solicitat de 369 de ori de la 54 de adrese diferite — nu este un acces de citire, ci o încercare de a executa comenzi. Astfel de ținte nu existau acum doi ani; provin din interfețele noilor instrumente AI și ale cozilor de sarcini. Cine își orientează apărarea doar spre WordPress și PHP nu vede nimic din toate acestea. În evaluare, această clasă cântărește corespunzător de greu.

Liste de amenințări și țara de origine

Patru liste, 32.851 de intervale de adrese, toate pe „doar raportare”. Fiecare altă listă este o adresă și un nivel.

O listă externă este o afirmație pe care o face altcineva, din motive pe care nu le cunoaștem, despre un trafic pe care nu l-am văzut niciodată. Poate fi greșită, depășită sau gândită pentru un alt scop: blocklist.de colectează în principal adrese care au încercat în altă parte autentificări SSH, iar acest lucru spune puțin despre un server web. De aceea Web RBL ține listele externe separat de lista proprie de blocare, și de aceea valoarea implicită este raportare. Iar propria listă albă câștigă întotdeauna: Un client pe care îl cunoaștem cântărește mai mult decât părerea unui terț.

Țara de origine este afișată la fiecare detecție și adresă. Pentru evaluare este de neînlocuit — o încercare de autentificare din propria țară la zece dimineața este altceva decât una dintr-o tară fără niciun client. Pentru blocări în bloc nu este prea potrivită, iar cifrele noastre o spun: Atacatorii din lista noastră veneau în mare parte din zone cloud din Belgia, Finlanda și Țările de Jos. O blocare a tot ce este în afara spațiului vorbitor de limba germană nu i-ar fi lovit — dar ar fi lovit propriii angajați în concediu și clienții în călătorii de afaceri.

Regulile pe țări sunt livrate goale, iar vizualizarea spune de ce.

Raportarea configurărilor greșite în loc de blocare

Cazul cel mai frecvent în traficul real nu este nici atac, nici vizitator, ci software defect care confundă serverul web cu altceva:

• 1.367 de accesări ale interfeței web a unui NAS QNAP — un client de sincronizare a cărui țintă nu mai este corectă. Un singur punct de acces a bătut la ușă de 962 de ori.
• 65 de interogări Autodiscover — un Outlook care consideră domeniul web ca fiind Exchange-ul său

Astfel de adrese nu sunt niciodată blocate. O blocare nu remediază defectul, ci îl ascunde — și îl lovește pe cel al cărui dispozitiv este oricum deja configurat greșit. În schimb se creează o intrare cu text de constatare și domeniile afectate, din care, la cerere, se face automat un tichet: exact unul pe adresă, iar dacă este închis și adresa reapare, același tichet se redeschide, în loc să apară un al doilea.

Sunt recunoscute QNAP, Synology, Exchange Autodiscover, ActiveSync precum și clienți WebDAV, CalDAV și CardDAV. Modelele menționează nume exacte de fișiere și directoare, niciodată simple extensii: În același director /cgi-bin/ se află apelurile inofensive de sincronizare chiar lângă sonde clasice precum printenv.pl.

Lista albă: adrese care nu sunt niciodată blocate

Prețul unei greșeli nu este același pentru toate adresele. La un scaner dintr-un centru de date, o alarmă falsă nu costă nimic. La stația la distanță a unui tunel de locație, costă locația.

De aceea există o a doua listă, care stă înaintea primei: adrese și rețele care nu sunt niciodată blocate. Ea nu reduce la tăcere nimic — cine se află pe ea este în continuare verificat și înregistrat, doar consecința dispare. Aceasta este diferența față de o excepție în firewall: Aceea te face orb, aceasta te face doar răbdător.

Se completează zilnic din două surse: din firewall-ul însuși cu toate stațiile VPN la distanță, pentru ca un tunel nou configurat să nu depindă de faptul că cineva se gândește la lista de blocare — și din intervalele de adrese publicate de Google și Microsoft pentru crawlerele lor. Numai așa se poate distinge un adevărat Googlebot de un scaner care se dă drept el. Motoarele de căutare nu trebuie blocate niciodată; cine le blochează, își scoate site-ul din indexare fără cale de întoarcere.

Se aplică aici o regulă mai importantă decât comparația: Un răspuns gol nu șterge niciodată. Dacă sursa nu răspunde, răspunde gol sau neinteligibil, lista rămâne neschimbată. O listă albă care se golește singură în caz de defecțiune ia cu ea, în cel mai rău moment posibil, toate tunelurile.

Dacă o intrare din lista albă poartă un client, fiecare detecție din rețeaua lui îi este atribuită. O configurare greșită are astfel imediat un interlocutor, fără ca cineva să trebuiască să caute adrese.

Informații obligatorii și colectori automatizați de date

Pagina de mențiuni legale nu este o pagină obișnuită. Trebuie să rămână accesibilă oamenilor, deoarece o blocare pe ea creează exact încălcarea pe care o caută un colector. În același timp este pagina pe care se află numele și adresa — și astfel ținta recoltării automate.

În valul austriac de somații privind fonturile Google încorporate, jurnalele au arătat că scrisorile nu proveneau din vizite izolate, ci dintr-o acțiune automatizată de amploare: host-uri diferite, fără legătură între ele, la intervale de milisecunde.

Web RBL rezolvă aceasta prin retrogradare în loc de excepție. Calea canonică /impressum nu corespunde niciunui model și rămâne mereu accesibilă. Variante străine de scriere precum /impressum.php — care nu pot exista pe o pagină Odoo — sunt raportate, iar cine nu vrea să accepte recolta automată, schimbă un parametru. sitemap și robots sunt exceptate și în principiu nu pot fi blocate: Ele nu conțin nicio informație personală, iar preluarea lor este sarcina oricărui crawler al motoarelor de căutare.

Domeniu și identificator: ce lipsește din jurnalul de acces

Jurnalul de acces al werkzeug nu înregistrează nici host-ul accesat, nici identificatorul apelantului. Odoo primește ambele, bineînțeles — fără host nu ar putea alege, în cazul mai multor site-uri, pe cel potrivit. Dar ulterior nu se mai poate verifica.

Web RBL reține ambele pentru fiecare detecție. Aceasta răspunde la două întrebări care altfel nu pot fi lămurite: ce site vizează o configurare greșită — și, prin urmare, cărui client îi aparține domeniul — și dacă o adresă vizitează o singură pagină sau toate. Mai multe domenii fără legătură între ele de la aceeași adresă sunt semnul acțiunii de amploare și măresc evaluarea.

Cât de mult contează identificatorul a arătat o analiză pe una dintre site-urile noastre: Peste șaptezeci la sută din întregul trafic provenea acolo de la un singur apelant, distribuit pe mai mult de o sută de adrese. Fără identificator ar fi părut un scraper distribuit. Era GPTBot, crawlerul OpenAI — care cerea mereu robots.txt și se comporta absolut corect.

Aspectele de securitate în detaliu

1. Detectarea proxy-ului — cel mai periculos punct

Dacă Odoo rulează în spatele unui reverse proxy și proxy_mode este setat greșit, modulul vede la fiecare cerere aceeași adresă: cea a proxy-ului. O blocare ar exclude atunci toți vizitatorii simultan.

De aceea Web RBL verifică înainte de orice blocare dacă determinarea adresei este fiabilă. Cere proxy_mode împreună cu o linie de antet de redirecționare, refuză să lucreze dacă ajunge o redirecționare fără proxy_mode și refuză la fel dacă există mai mult de un proxy intermediar. În caz de îndoială nu se blochează.

2. Niciodată propriile rețele

Intervalele de adrese private, loopback, link-local și CGNAT sunt exceptate definitiv. Ele nu pot ajunge în niciun caz pe listă, nici manual. Același lucru este valabil pentru listele externe: Intervalele private și rezervate, precum și rețelele absurd de mari, sunt respinse la citire.

3. O eroare proprie nu are voie să ia site-ul cu ea

Întreaga verificare rulează într-o protecție care prinde orice eroare. Ce nu merge aici este înregistrat în jurnal, iar cererea continuă neschimbată. Un modul de protecție care, la o eroare proprie, ia site-ul cu el, este mai rău decât niciunul. Toate interogările din calea cererii rulează, de asemenea, fără limba browserului a vizitatorului și fără sortare după câmpuri traduse — un vizitator cu o limbă neinstalată nu are voie să facă verificarea să eșueze.

4. Observare înainte de blocare

După instalare, blocarea adreselor listate la cereri obișnuite este dezactivată. Sondele sunt respinse și înregistrate, restul trece. Astfel se poate urmări câteva zile cine ajunge efectiv pe listă, înainte ca cineva să fie exclus. Același lucru este valabil pentru detectarea comportamentului, listele de amenințări și regulile pe țări: mai întâi raportare, blocare după evaluare.

5. Modele înguste în loc de rețele largi

Un vizitator recunoscut greșit este mai costisitor decât o sondă scăpată. Fiecare model poartă de aceea nivelul său, care poate fi schimbat pentru fiecare model. O extensie de fișier singură rareori este suficientă: La .php stau 14.012 sonde reale față de o mână de linkuri vechi, la .asp raportul este invers. Astfel de decizii trebuie măsurate, nu estimate.

6. O deblocare manuală rămâne în vigoare

Cine deblochează o adresă a avut un motiv. O altă detecție nu anulează în tăcere această decizie.

7. Lista este protejată, dar nu este un secret

Endpoint-ul cere un token și răspunde fără token valid cu 404, nu cu 403 — existența adresei nu este astfel nici măcar confirmată. Comparația rulează în timp constant. Lista în sine nu conține nimic confidențial: Ea constă din adrese care au bătut din proprie inițiativă la ușa noastră.

8. Fără secrete în evidență

La autentificările eșuate este consemnat numele de utilizator încercat, niciodată parola. La managerul bazelor de date nu se citește nimic din valorile transmise: Acolo se află pe primul loc parola principală, iar o intrare într-o listă de blocare ajunge în fiecare copie de siguranță a bazei de date. Cheia de licență pentru GeoLite2 se află doar în parametrul de sistem și în nicio linie de jurnal.

9. Momeala nu dezvăluie nimic utilizabil

Opțional, Web RBL răspunde la sonde cu conținut inventat care conține o valoare-canar unică. Cine accesează ulterior această valoare a citit răspunsul fals și a acționat în consecință — o alarmă falsă este astfel exclusă. Momelile nu conțin informații utilizabile, nici căi reale, nici date de acces valide. Această funcție este livrată dezactivată, deoarece modifică comportamentul vizibil din exterior.

Ce nu poate face modulul

Nu înlocuiește un firewall și nici un Web Application Firewall. El recunoaște modele cunoscute de sondare în căi, autentificări eșuate și comportament suspect — nu atacuri asupra formularelor, nu încercări de injectare în parametri.

De asemenea, vede doar ceea ce revine prin HTTP. Ce face un atacator cu accesuri furate la baza de date sau la căsuța poștală rămâne invizibil — și tocmai de aceea valorile-canar sunt căi și nu date de acces.

Și nu înlocuiește grija: Un modul care respinge sondele .env nu face inofensiv un fișier .env livrat din greșeală.

Disponibilitate

Web RBL este disponibil public sub AGPL-3 și rulează la noi în producție pe cinci site-uri:

github.com/Alex0176/odoo-web-rbl

Modulul presupune Odoo 19 Community și nu are dependențe în afară de base și web. Conectarea la tichete este opțională și nu necesită un anumit sistem de tichete; fără unul, pur și simplu nu se întâmplă nimic. Țara de origine necesită baza de date gratuită GeoLite2 de la MaxMind; dacă lipsește, câmpul rămâne gol și tot restul funcționează neschimbat.

Pentru aprofundare: Cum se integrează Web RBL într-o arhitectură de securitate completă -- împreună cu firewall, autentificare în doi pași și permisiuni, inclusiv ghid pas cu pas: Combinarea corectă a arhitecturii de securitate Odoo 19.

Primim cu plăcere întrebări, observații și rapoarte de erori — cel mai bine ca issue pe GitHub.