Odoo 19 Community: Web RBL – lista di blocco per il traffico di attacco sui propri siti web

Codice sorgente: github.com/Alex0176/odoo-web-rbl — AGPL-3, liberamente utilizzabile.

Chi gestisce un server Odoo su Internet riceve visite. Non occasionalmente, ma di continuo. In diciassette giorni abbiamo registrato e analizzato sui nostri cinque siti web 731.297 richieste. 110.511 di queste non erano visitatori, ma ricerche automatizzate di vulnerabilità, credenziali di accesso e file di configurazione.

Questo articolo descrive Web RBL, un modulo open source per Odoo 19 Community che riconosce, valuta, registra e respinge questo traffico — e che pubblica la lista di blocco come lista RBL, cioè nel formato che firewall e reverse proxy leggono direttamente. Tutti i numeri provengono dall'esercizio reale.

Cosa sa fare il modulo — le funzioni in sintesi

Funzione	Cosa fa	Distribuzione
Riconoscimento dei pattern	Riconosce i tentativi di sondaggio da percorso ed estensione: .env, .git, file di configurazione, chiavi cloud, istruzioni di build CI/CD, WordPress, PHP, path traversal, gestori di database, GraphQL, esecuzione di comandi tramite /api/fs/exec e interfacce simili	bloccare
Tre livelli per pattern	bloccare, contare o segnalare — modificabile per ogni pattern, senza codice	per pattern
Soglie	Quanti riscontri dello stesso pattern prima del blocco; per i login dieci	10 per il login
Difesa dei login	Login falliti tramite maschera e XML-RPC/JSON-RPC, verifiche di sessione fallite, accessi al gestore di database — nel database, non nella memoria di lavoro	attiva
Rilevamento bot al login	Chi ignora il messaggio di attesa dopo dieci tentativi falliti e continua a bussare viene bloccato immediatamente	bloccare
Rilevamento del comportamento	Indirizzi che in cinque minuti generano venti pagine inesistenti e quasi nessuna pagina valida — cioè che tirano a indovinare invece di leggere	segnalare
Valutazione 0–100	Quanto è probabile che dietro l'indirizzo ci sia un aggressore? In base alla gravità del pattern, al numero di pattern diversi, ai giorni anomali, ai domini interessati e al numero di riscontri — con motivazione in chiaro	attiva
Blocco del login in base alla valutazione	A partire da una valutazione impostabile il login è vietato, il sito web resta leggibile	da 40
Sospetto di credenziali di accesso rubate	Un accesso riuscito da un indirizzo sospetto viene segnalato e, su richiesta, assegnato come attività — una volta per indirizzo e per giorno	attiva
Liste di minacce	Nodi di uscita Tor, Spamhaus DROP, FireHOL Level 1, blocklist.de preconfigurati; qualsiasi altra lista RBL è registrabile tramite indirizzo, confronto giornaliero, livello proprio per ogni lista	segnalare
Nessun accesso al login	Il quarto livello per liste e Paesi: sito web leggibile, maschera di accesso e interfacce chiuse — la risposta giusta a Tor	Opzione
Paese di origine	Paese per ogni riscontro e indirizzo tramite GeoLite2; il modulo aggiorna da sé il database con una chiave di licenza gratuita	mostra
Regole per Paese	Bloccare, nessun accesso al login, segnalare o esplicitamente libero — per ogni Paese, volutamente senza impostazione predefinita	nessuna
Configurazioni errate	QNAP, Synology, Exchange Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV vengono riconosciuti, mai bloccati e inseriti in un elenco di lavoro con esito e dominio interessato	segnalare
Ticket per indirizzo	Da un esito nasce, su richiesta, un ticket — esattamente uno per indirizzo; un ticket chiuso viene riaperto invece di essere duplicato	off
Pagine obbligatorie e raccoglitori	Il percorso canonico del colophon resta sempre raggiungibile; i tentativi automatizzati con grafie estranee vengono riconosciuti e, su richiesta, bloccati	segnalare
Lista consentita	Indirizzi e reti che non vengono mai bloccati; si riempie ogni giorno dal firewall (controparti VPN) e dagli intervalli di indirizzi pubblicati di Googlebot e Bingbot	attiva
Assegnazione al cliente	Un riscontro proveniente dalla rete di un cliente gli viene assegnato — dalla lista consentita, mai a intuito	attiva
Dominio e identificativo per riscontro	Quale sito web è stato contattato, con quale user agent — entrambi mancano nel registro degli accessi	attiva
Analisi	Grafico e pivot su tutti i riscontri: per modello, giorno, dominio, Paese, indirizzo	attiva
Esca	Le sonde ricevono risposte inventate con un valore canarino; chi lo richiama in seguito le ha lette	off
Distribuzione RBL	L'elenco di blocco come semplice lista di indirizzi o JSON a un indirizzo dedicato, protetto da token — per HAProxy, OPNsense e ogni firewall che legge liste di URL	attiva

Tutto ciò che viene fornito con segnala, off o opzione è così per scelta: chi attiva un blocco deve farlo perché ha osservato per qualche giorno chi ci finisce dentro, non perché l'impostazione predefinita lo voleva.

L'analisi: riscontri per modello nell'arco di sette giorni. La barra più alta è la ricerca di file .env.

Liste RBL: un modo standardizzato per distribuire i blocchi

RBL sta per Real-time Blackhole List. Il termine proviene dal mondo della posta elettronica, dove Spamhaus e altri pubblicano dagli anni Novanta liste di indirizzi di mittenti malevoli. Il principio è semplicissimo e proprio per questo così diffuso: un indirizzo per riga, consultabile via HTTP, ricaricato regolarmente. Nessun formato da analizzare prima, nessuna interfaccia per cui serva uno strumento.

Praticamente ogni firewall e ogni reverse proxy può leggere una tale lista e ricavarne regole. I produttori la chiamano in modi diversi, il meccanismo è ovunque lo stesso:

• OPNsense e pfSense — URL Table Alias: caricare la lista di indirizzi via HTTP, usarla come alias nelle regole del firewall, aggiornamento a cadenza oraria o giornaliera
• HAProxy — file ACL e Map: src -f sperrliste.txt in una regola http-request deny, ricaricabile tramite l'API di runtime senza riavvio
• nginx — modulo geo con file di indirizzi incluso, oppure istruzioni deny da un file include generato
• Fortinet FortiGate — External Block List ovvero Threat Feed: un URL da cui il firewall ricava un elenco di IP e lo usa nelle policy
• Palo Alto Networks — External Dynamic List (EDL): lo stesso principio, come tipo di oggetto a sé nelle policy di sicurezza
• Check Point — Custom Intelligence Feeds e IP Block Lists tramite un URL
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds con fonti di liste proprie
• Sophos Firewall — Third-Party Threat Feeds: liste di indirizzi da un URL come fonte per le regole di blocco
• Juniper SRX — Dynamic Address Entries da feed
• MikroTik RouterOS — Address Lists, popolate da un URL tramite script e fetch
• CrowdSec — liste proprie come fonte per i bouncer su ogni sistema supportato

È esattamente in questo formato che Web RBL distribuisce il suo elenco di blocco. Il firewall scarta i pacchetti prima che raggiungano il server web — e con essi ogni altro tentativo dello stesso indirizzo, ad esempio verso il server di posta o il gateway VPN.

Entrambe le direzioni, ma nel punto giusto

Il percorso funziona anche al contrario: in Web RBL si può registrare qualsiasi lista RBL — un URL, un livello, fatto. Nodi di uscita Tor, Spamhaus DROP, FireHOL e blocklist.de sono preconfigurati, altre si aggiungono con tre clic. Il modulo scompone ogni lista in intervalli di indirizzi e controlla ogni richiesta rispetto a essi, in pochi microsecondi.

E tuttavia: è più sensato usare le liste di terzi sul firewall a monte. Per tre motivi. Il firewall vede tutti i servizi, non solo HTTP — un indirizzo della lista Spamhaus deve fallire anche sul server di posta e sulla VPN. Esso scarta a livello di pacchetto, prima ancora che si stabilisca una connessione, e non costa quindi nulla al server applicativo. Ed è il luogo in cui tali liste vengono comunque mantenute; una seconda copia nell'applicazione è un secondo punto che può diventare obsoleto.

A cosa servono dunque le liste nel modulo: a ciò che un firewall non sa fare. Non conosce alcuna maschera di accesso. Web RBL può negare a un indirizzo della lista Tor l'accesso al login e comunque servire il sito web — chi vuole leggere in anonimo deve poterlo fare; chi vuole provare password in modo anonimo, no. E può segnalare come caso sospetto un accesso riuscito da un indirizzo in lista. Entrambe le cose richiedono la lista lì dove avviene l'accesso.

Valutazione anziché intuito

Un indirizzo che ha chiesto una volta /wp-login.php è diverso da uno che in due giorni è passato con cinque modelli diversi su tre domini. Web RBL lo converte in una valutazione da 0 a 100 — a partire da ciò che ha visto direttamente, senza servizi esterni e senza interrogazioni verso l'esterno.

Una voce: 99 riscontri, valutazione 84, e la motivazione in linguaggio semplice — modello più grave, cinque diversi modelli seri, due giorni sospetti, oltre venti riscontri.

La valutazione decide due cose. A partire da un valore impostabile il login è vietato — il sito web resta leggibile, ma chi ha già cercato credenziali di accesso non ha modo di provare quelle trovate. E un accesso riuscito da un indirizzo con valutazione viene segnalato: allora qualcuno non ha più tirato a indovinare, ma sapeva. O l'utente legittimo era in viaggio, oppure le credenziali sono andate perse — il modulo non lo decide, lo sottopone a qualcuno che può chiedere chiarimenti. La password stessa non viene toccata in nessun punto.

L'elenco di blocco, filtrato per valutazione da 40: numero di riscontri, giorni sospetti, domini interessati e ultimo percorso per indirizzo.

Che cosa protegge Web RBL — l'effetto protettivo nel dettaglio

1. Le credenziali restano non scoperte

La più grande classe di attacchi misurata non cerca falle in Odoo, ma segreti dimenticati. In diciassette giorni:

• 57.721 richieste di file .env — lì si trovano password di database, chiavi API e segreti di sessione
• 5.535 richieste di file di configurazione
• 4.388 richieste di credenziali cloud: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 richieste di directory .git — chi ne trova una scarica l'intero codice sorgente con tutta la cronologia
• 1.907 richieste di istruzioni di build come .github/workflows/deploy.yml o .gitlab-ci.yml, in cui compaiono registry e nomi di chiavi

Decisivo non è il numero di richieste, ma il numero di indirizzi diversi: /credentials.json è arrivato da 98 indirizzi, /.git-credentials da 92. Non si tratta di un singolo scanner, ma di un repertorio standard che gira in tutto il mondo contemporaneamente.

2. I tentativi di accesso cadono nel vuoto — in modo permanente

Odoo ha già un proprio freno contro i tentativi a raffica di password. Ha tre limiti, documentati nel codice sorgente di Odoo stesso: il contatore risiede nella memoria di lavoro del processo di lavoro e viene azzerato a ogni riavvio, esso ritarda soltanto invece di bloccare, e conta esclusivamente i tentativi che arrivano fino al controllo della password.

Web RBL interviene negli stessi punti, ma scrive nel database. Ne consegue:

• Lo stato sopravvive a ogni riavvio e vale per tutti i processi di lavoro
• Vengono rilevati entrambi i percorsi: la maschera di accesso /web/login e le interfacce /xmlrpc/2/common e /jsonrpc
• Vengono rilevati anche i tentativi che non arrivano mai al controllo della password — ad esempio accessi senza un valido contrassegno di sessione
• Un accesso fallito al gestore dei database viene conteggiato; è il tentativo di accesso più grave in assoluto

La soglia per gli accessi è fissata a dieci, e il motivo è una misurazione: dei nove accessi falliti in diciassette giorni, la maggior parte proveniva da clienti che si stavano configurando l'accesso da soli su un altro dispositivo e inserivano il dominio sbagliato — in un caso il proprio, solo con un trattino al posto del punto. Un blocco al primo tentativo fallito non avrebbe quindi colpito gli aggressori, ma i clienti durante la configurazione.

Chi invece continua a bussare, benché il server abbia già risposto «attendere un momento», viene bloccato subito. Questo messaggio lo legge una persona e attende; chi lo ignora è un programma. Un modello proprio con soglia zero intercetta esattamente questo caso e non può colpire un collega: ci arriva solo chi ha già alle spalle dieci tentativi falliti e poi continua.

3. L'attacco non costa più nulla al server

Una sonda verso un percorso come /@fs/../../.env era costosa prima del modulo: Odoo cerca la pagina di errore, la renderizza, inciampa nella costruzione dell'indirizzo sui segmenti di punti e fallisce quindi anche con la pagina di errore della pagina di errore. Due stack trace per sonda. Sono stati misurati 28.401 di questi errori in diciassette giorni, più 9.467 errori consequenziali.

Web RBL interviene su ir.http._match, quindi prima del routing. La risposta avviene senza template, senza accessi al database oltre il controllo del blocco e senza riga di log. Il controllo rispetto a lista consentita, liste di minacce e regole per Paese viene eseguito dalla cache su intervalli di indirizzi ordinati — pochi microsecondi, anche con oltre trentamila intervalli.

4. Il firewall getta fuori l'aggressore prima che arrivi

L'elenco di blocco viene pubblicato come lista RBL che HAProxy e OPNsense leggono direttamente. L'aggressore non raggiunge più il server web e nemmeno alcun altro servizio sullo stesso host. Un accesso riconosciuto una volta come malevolo protegge così retroattivamente l'intera macchina.

Tre livelli: bloccare, contare, segnalare

Non ogni richiesta nel vuoto è un attacco. Web RBL distingue perciò tre livelli, e il livello può essere modificato per ogni modello, senza toccare il codice.

Livello	La richiesta scatenante	Conseguenza per l'indirizzo
bloccare	viene respinta	bloccato per 24 ore, in modo permanente dopo tre giorni sospetti
contare	passa	solo registrata, nessun blocco
segnalare	passa	registrata con testo di esito, mai bloccata

Per liste di minacce e Paesi ce n'è un quarto: nessun accesso al login. Il sito web resta leggibile, maschera di accesso e interfacce sono chiuse. È la via di mezzo per tutto ciò che è sospetto ma non deve essere necessariamente malevolo — Tor, un intervallo di data center, un Paese senza clienti.

Quali attacchi vengono riconosciuti

Tutti i modelli sono verificati su traffico reale. Il numero di indirizzi diversi è volutamente accanto — mostra se un modello colpisce un singolo scanner o una pratica diffusa.

Classe di attacco	Richieste	Indirizzi
Prelievo di .env	57.721	223
Sonde PHP	12.237	256
Path traversal con obiettivo redditizio	10.046	64
File di configurazione	5.535	114
Chiavi di accesso cloud	4.388	152
Sonde WordPress	3.366	385
Prelievo di .git	2.811	255
Esplorazione di Odoo (gestore dei database, richiesta di versione)	2.500	213
Toolchain di IA ed esecuzione di comandi (/mcp, /api/fs/exec)	2.450	74
Istruzioni di build (CI/CD)	1.907	88
Endpoint GraphQL	1.878	71

Degna di nota è la classe più recente. /api/fs/exec è stato richiesto 369 volte da 54 indirizzi diversi — non è un accesso in lettura, ma il tentativo di eseguire comandi. Obiettivi simili due anni fa non esistevano; provengono dalle interfacce dei nuovi strumenti di IA e delle code di attività. Chi orienta la propria difesa solo su WordPress e PHP, di tutto ciò non vede nulla. Nella valutazione questa classe pesa di conseguenza.

Liste di minacce e Paese di origine

Quattro liste, 32.851 intervalli di indirizzi, tutti su «solo segnalare». Ogni ulteriore lista è un indirizzo e un livello.

Una lista di terzi è un'affermazione che qualcun altro formula, per motivi che non conosciamo, su traffico che non abbiamo mai visto. Può essere sbagliata, superata o pensata per un altro scopo: blocklist.de raccoglie soprattutto indirizzi che altrove hanno provato accessi SSH, e ciò dice poco su un server web. Per questo Web RBL tiene le liste di terzi separate dal proprio elenco di blocco, e per questo l'impostazione predefinita è segnalare. E la propria lista consentita vince sempre: un cliente che conosciamo pesa più della valutazione di un terzo.

Il Paese di origine compare su ogni riscontro e ogni indirizzo. Per valutare è insostituibile — un tentativo di accesso dal proprio Paese alle dieci del mattino è una cosa diversa da uno proveniente da un Paese senza un solo cliente. Per un blocco generalizzato serve poco, e lo dicono i nostri stessi numeri: gli aggressori nella nostra lista provenivano per lo più da aree cloud in Belgio, Finlandia e Paesi Bassi. Un blocco per tutto ciò che è al di fuori dell'area di lingua tedesca non li avrebbe colpiti — ma avrebbe colpito i nostri collaboratori in ferie e i clienti in viaggio d'affari.

Le regole per Paese vengono fornite vuote, e la vista spiega perché.

Segnalare le configurazioni errate anziché bloccarle

Il caso più frequente nel traffico reale non è né un attacco né un visitatore, ma un software difettoso che scambia il server web per qualcos'altro:

• 1.367 accessi all'interfaccia web di un NAS QNAP — un client di sincronizzazione la cui destinazione non è più corretta. Una sola connessione ha bussato 962 volte.
• 65 richieste Autodiscover — un Outlook che scambia il dominio web per il proprio Exchange

Tali indirizzi non vengono mai bloccati. Un blocco non risolve il difetto, lo nasconde — e colpisce proprio chi ha già un dispositivo configurato male. Nasce invece una voce con testo di esito e i domini interessati, dalla quale su richiesta si genera automaticamente un ticket: esattamente uno per indirizzo, e se viene chiuso e l'indirizzo si ripresenta, si riapre lo stesso ticket invece di crearne un secondo.

Vengono riconosciuti QNAP, Synology, Exchange Autodiscover, ActiveSync nonché client WebDAV, CalDAV e CardDAV. I modelli indicano nomi di file e directory esatti, mai semplici estensioni: nella stessa directory /cgi-bin/ le innocue chiamate di sincronizzazione si trovano accanto a classiche sonde come printenv.pl.

La lista consentita: indirizzi che non vengono mai bloccati

Il prezzo di un errore non è uguale per tutti gli indirizzi. Con uno scanner proveniente da un data center un falso allarme non costa nulla. Con la controparte di un tunnel tra sedi costa la sede.

Per questo esiste una seconda lista, che precede la prima: indirizzi e reti che non vengono mai bloccati. Non mette però a tacere nulla — chi vi figura continua a essere controllato e registrato, viene solo meno la conseguenza. È la differenza rispetto a un'eccezione nel firewall: questa rende ciechi, quella rende solo pazienti.

Viene riempita ogni giorno da due fonti: dal firewall stesso con tutte le controparti VPN, in modo che un tunnel appena configurato non dipenda dal fatto che qualcuno pensi all'elenco di blocco — e dagli intervalli di indirizzi pubblicati da Google e Microsoft per i loro crawler. Solo così si può distinguere un vero Googlebot da uno scanner che si spaccia per tale. I motori di ricerca non devono mai essere bloccati; chi li esclude toglie il proprio sito dall'indicizzazione senza via di ritorno.

Vale inoltre una regola più importante del confronto: una risposta vuota non cancella mai. Se la fonte non risponde, risponde in modo vuoto o incomprensibile, la lista resta invariata. Una lista consentita che si svuota da sola in caso di guasto si porta via, nel peggior momento immaginabile, tutti i tunnel.

Se una voce della lista consentita riporta un cliente, ogni riscontro dalla sua rete gli viene assegnato. Una configurazione errata ha così subito un interlocutore, senza che qualcuno debba cercare gli indirizzi.

Informazioni obbligatorie e raccoglitori automatizzati di dati

Il colophon non è una pagina qualsiasi. Deve restare raggiungibile per le persone, poiché un blocco su di essa crea proprio la violazione che un raccoglitore cerca. Al tempo stesso è la pagina in cui compaiono nome e indirizzo — e quindi l'obiettivo della raccolta automatizzata.

Nell'ondata austriaca di diffide per i Google Fonts incorporati, i registri hanno mostrato che le lettere non provenivano da singole visite, ma da un'azione a tappeto automatizzata: host diversi e non collegati tra loro a distanza di millisecondi.

Web RBL lo risolve con il declassamento anziché l'eccezione. Il percorso canonico /impressum non corrisponde ad alcun modello e resta sempre raggiungibile. Grafie estranee come /impressum.php — che non può esistere su una pagina Odoo — vengono segnalate, e chi non vuole accettare la raccolta automatizzata modifica un parametro. sitemap e robots ne sono esclusi e in linea di principio non sono bloccabili: non contengono alcun dato personale, e recuperarli è il compito di ogni crawler dei motori di ricerca.

Dominio e identificativo: ciò che manca nel registro degli accessi

Il registro degli accessi di werkzeug non scrive né l'host contattato né l'identificativo del chiamante. Odoo riceve naturalmente entrambi — senza l'host non potrebbe, con più siti web, scegliere quello giusto. Ma in seguito non è possibile consultarli.

Web RBL registra entrambi per ogni riscontro. Ciò risponde a due domande che altrimenti non troverebbero risposta: quale sito web una configurazione errata sta contattando — e quindi a quale cliente appartiene il dominio — e se un indirizzo visita una pagina o tutte. Più domini non collegati tra loro provenienti dallo stesso indirizzo sono il segno distintivo dell'azione a tappeto, e aumentano la valutazione.

Quanto conti l'identificativo lo ha mostrato un'analisi su uno dei nostri siti web: oltre il settanta per cento di tutto il traffico era attribuibile a un unico chiamante, distribuito su più di cento indirizzi. Senza l'identificativo sarebbe sembrato uno scraper distribuito. Era GPTBot, il crawler di OpenAI — chiedeva continuamente robots.txt e si comportava in modo del tutto corretto.

Gli aspetti di sicurezza nel dettaglio

1. Il rilevamento del proxy — il punto più pericoloso in assoluto

Se Odoo gira dietro un reverse proxy e proxy_mode è impostato in modo errato, il modulo vede a ogni richiesta lo stesso indirizzo: quello del proxy. Un blocco escluderebbe allora tutti i visitatori contemporaneamente.

Per questo Web RBL verifica prima di ogni blocco se la determinazione dell'indirizzo è affidabile. Richiede proxy_mode insieme a un'intestazione di inoltro, rifiuta di lavorare se arriva un inoltro senza proxy_mode, e lo rifiuta altrettanto in presenza di più di un proxy intermedio. Nel dubbio non si blocca.

2. Mai le proprie reti

Intervalli di indirizzi privati, loopback, link-local e CGNAT sono esclusi in modo fisso. Non possono in nessuna circostanza finire nella lista, nemmeno a mano. Lo stesso vale per le liste di terzi: gli intervalli privati e riservati nonché le reti assurdamente grandi vengono scartati in fase di lettura.

3. Un errore proprio non deve trascinare con sé il sito web

L'intero controllo viene eseguito in una protezione che intercetta ogni errore. Ciò che qui va storto viene registrato, e la richiesta prosegue invariata. Un modulo di protezione che, in caso di errore proprio, trascina con sé il sito web è peggio di nessuno. Tutte le interrogazioni nel percorso della richiesta avvengono inoltre senza la lingua del browser del visitatore e senza ordinamento per campi tradotti — un visitatore con una lingua non installata non deve far fallire il controllo.

4. Osservare prima di bloccare

Dopo l'installazione il blocco degli indirizzi in lista per le richieste ordinarie è disattivato. Le sonde vengono respinte e registrate, tutto il resto passa. Così si può osservare per alcuni giorni chi finisce effettivamente nella lista, prima che qualcuno venga escluso. Lo stesso vale per il rilevamento comportamentale, le liste di minacce e le regole per Paese: prima segnalare, bloccare dopo aver valutato.

5. Modelli stretti anziché reti ampie

Un visitatore riconosciuto per errore costa più di una sonda sfuggita. Ogni modello porta perciò il proprio livello, che è modificabile per ogni modello. Un'estensione di file da sola raramente basta: con .php ci sono 14.012 vere sonde contro una manciata di vecchi link, con .asp il rapporto è inverso. Tali decisioni vanno misurate, non stimate.

6. Uno sblocco manuale resta valido

Chi sblocca un indirizzo aveva un motivo. Un ulteriore riscontro non annulla in silenzio questa decisione.

7. La lista è protetta, ma non è un segreto

L'endpoint richiede un token e, senza token valido, risponde con 404, non con 403 — l'esistenza dell'indirizzo non viene così nemmeno confermata. Il confronto avviene a tempo costante. La lista stessa non contiene nulla di riservato: è composta da indirizzi che hanno bussato di propria iniziativa alla nostra porta.

8. Nessun segreto nella contabilità

Per gli accessi falliti viene annotato il nome utente tentato, mai la password. Per il gestore dei database dai valori trasmessi non si legge nulla: lì al primo posto compare la password principale, e una voce in un elenco di blocco finisce in ogni backup del database. La chiave di licenza per GeoLite2 compare solo nel parametro di sistema e in nessuna riga di log.

9. L'esca non rivela nulla di sfruttabile

Facoltativamente Web RBL risponde alle sonde con un contenuto inventato che contiene un inequivocabile valore canarino. Chi richiama in seguito questo valore ha letto la risposta falsificata e ha agito di conseguenza — un falso allarme è così escluso. Le esche non contengono informazioni sfruttabili, nessun percorso reale e nessuna credenziale valida. Questa funzione viene fornita disattivata, perché modifica il comportamento in modo visibile verso l'esterno.

Ciò che il modulo non sa fare

Non sostituisce né un firewall né un Web Application Firewall. Riconosce modelli di sondaggio noti nei percorsi, accessi falliti e comportamenti sospetti — non attacchi ai moduli, non tentativi di iniezione nei parametri.

Vede inoltre solo ciò che ritorna via HTTP. Ciò che un aggressore fa con accessi a database o caselle di posta carpiti, resta invisibile — ed è proprio per questo che i valori canarino sono percorsi e non credenziali.

E non sostituisce la diligenza: un modulo che respinge le sonde .env non rende innocuo un file .env consegnato per errore.

Disponibilità

Web RBL è disponibile pubblicamente sotto AGPL-3 e da noi è in produzione su cinque siti web:

github.com/Alex0176/odoo-web-rbl

Il modulo presuppone Odoo 19 Community e non ha dipendenze oltre a base e web. Il collegamento ai ticket è facoltativo e non richiede alcun sistema di ticket specifico; senza di esso semplicemente non accade nulla. Il Paese di origine richiede il database gratuito GeoLite2 di MaxMind; se manca, il campo resta vuoto e tutto il resto funziona invariato.

Approfondimenti: come Web RBL si inserisce in un'architettura di sicurezza completa -- insieme a firewall, autenticazione a due fattori e permessi, con guida passo passo: Combinare correttamente l'architettura di sicurezza di Odoo 19.

Domande, osservazioni e segnalazioni di errori sono benvenute — preferibilmente come issue su GitHub.