Odoo 19 Community: Web RBL – Llista de bloqueig del trànsit d'atac als nostres llocs web

Codi font: github.com/Alex0176/odoo-web-rbl — AGPL-3, d’ús lliure.

Qui té un servidor Odoo a Internet rep visites. No de tant en tant, sinó contínuament. Durant disset dies hem registrat i analitzat 731.297 peticions als nostres cinc llocs web. 110.511 no corresponien a visitants, sinó a cerques automatitzades de vulnerabilitats, credencials i fitxers de configuració.

Aquest article presenta Web RBL, un mòdul de codi obert per a Odoo 19 Community que detecta, avalua, registra i rebutja aquest trànsit, i que publica la llista de bloqueig com a llista RBL, és a dir, en el format que els tallafocs i els servidors intermediaris inversos poden llegir directament. Totes les xifres provenen de l’ús en producció.

Què pot fer el mòdul: resum de funcions

Funció	Què fa	Lliurament
Detecció de patrons	Detecta intents d’exploració pel camí i l’extensió: .env, .git, fitxers de configuració, claus del núvol, instruccions de compilació de CI/CD, WordPress, PHP, recorregut de directoris, gestors de bases de dades, GraphQL, execució d’ordres mitjançant /api/fs/exec i interfícies semblants	bloquejar
Tres nivells per patró	bloquejar, comptar o notificar: configurable per a cada patró, sense codi	per patró
Llindars	Nombre de coincidències amb un mateix patró abans d’aplicar el bloqueig; deu per als inicis de sessió	10 per a l’inici de sessió
Protecció de l’inici de sessió	Inicis de sessió fallits mitjançant el formulari i XML-RPC/JSON-RPC, comprovacions de sessió fallides, accessos al gestor de bases de dades: registrats a la base de dades, no a la memòria RAM	activat
Detecció de bots a l’inici de sessió	Qui ignora el missatge d’espera després de deu intents fallits i ho continua intentant queda bloquejat immediatament	bloquejar
Detecció de comportaments	Adreces que en cinc minuts generen vint pàgines d’error i gairebé cap pàgina vàlida: proven d’endevinar adreces en lloc de llegir contingut	notificar
Puntuació de 0 a 100	Quin grau de certesa hi ha que darrere de l’adreça hi hagi un atacant? Es calcula a partir de la gravetat del patró, el nombre de patrons diferents, els dies amb activitat sospitosa, els dominis afectats i el nombre de coincidències, amb una justificació en llenguatge clar	activat
Bloqueig de l’inici de sessió segons la puntuació	A partir d’una puntuació configurable es prohibeix iniciar sessió, però el lloc web es pot continuar llegint	a partir de 40
Sospita de robatori de credencials	Es notifica qualsevol inici de sessió reeixit des d’una adreça sospitosa i, si es vol, s’assigna com a tasca: un cop per adreça i dia	activat
Llistes d’amenaces	Nodes de sortida de Tor, Spamhaus DROP, FireHOL Level 1 i blocklist.de preconfigurats; es pot afegir qualsevol altra llista RBL mitjançant la seva adreça, amb sincronització diària i un nivell propi per a cada llista	notificar
Sense accés a l’inici de sessió	El quart nivell per a llistes i països: el lloc web es pot llegir, però el formulari d’inici de sessió i les interfícies queden tancats; la resposta adequada per a Tor	Opcional
País d’origen	Identifica el país de cada coincidència i adreça mitjançant GeoLite2; el mòdul manté la base de dades actualitzada amb una clau de llicència gratuïta	mostrar
Regles per país	Bloquejar, denegar l’accés a l’inici de sessió, notificar o permetre explícitament: per a cada país i, expressament, sense cap opció predefinida	cap
Errors de configuració	Es detecten QNAP, Synology, Exchange-Autodiscover, ActiveSync i WebDAV/CalDAV/CardDAV, mai no es bloquegen i s’afegeixen a una llista de treball amb el resultat de la detecció i el domini afectat	notificar
Un tiquet per adreça	Si es vol, una detecció es converteix en un tiquet: exactament un per adreça; si ja està tancat, es torna a obrir en lloc de duplicar-lo	desactivat
Pàgines obligatòries i recol·lectors	El camí canònic de l’avís legal sempre és accessible; es detecten els intents automatitzats de provar altres variants del nom i, si es vol, es bloquegen	notificar
Llista de permesos	Adreces i xarxes que no es bloquegen mai; s’actualitza diàriament a partir del tallafoc (extrems remots de VPN) i dels intervals d’adreces publicats de Googlebot i Bingbot	activat
Assignació al client	Una coincidència procedent de la xarxa d’un client se li assigna a partir de la llista de permesos, mai per una suposició manual	activat
Domini i identificador per coincidència	A quin lloc web s’ha accedit i amb quin User-Agent: dues dades que falten al registre d’accessos	activat
Anàlisi	Gràfic i taula dinàmica de totes les coincidències: per patró, dia, domini, país i adreça	activat
Esquers	Els intents d’exploració reben respostes inventades amb un valor testimoni; qui el consulta més endavant demostra que les ha llegit	desactivat
Publicació de la llista RBL	La llista de bloqueig com a llista simple d’adreces o en JSON, en una adreça pròpia protegida amb un testimoni d’accés: per a HAProxy, OPNsense i qualsevol tallafoc que llegeixi llistes des d’un URL	activat

Tot el que es distribueix amb la configuració notificar, desactivat o Opcional és així expressament: qui activa un bloqueig ho ha de fer perquè ha observat durant uns dies qui hi queda afectat, no perquè ho dicti la configuració predeterminada.

L’anàlisi: coincidències per patró durant set dies. La barra més alta correspon a la cerca de fitxers .env.

Llistes RBL: una manera estandarditzada de distribuir bloquejos

RBL significa Real-time Blackhole List. El terme prové del món del correu electrònic, on Spamhaus i altres publiquen llistes d’adreces de remitents maliciosos des dels anys noranta. El principi és ben senzill i precisament per això està tan estès: una adreça per línia, accessible per HTTP i recarregada periòdicament. Cap format que calgui analitzar primer, cap interfície que requereixi una eina.

Pràcticament qualsevol tallafoc i servidor intermediari invers pot llegir una llista d’aquest tipus i generar-ne regles. Cada fabricant ho anomena d’una manera, però el mecanisme és el mateix a tot arreu:

• OPNsense i pfSense — URL Table Alias: carregar una llista d’adreces per HTTP, utilitzar-la com a àlies en les regles del tallafoc i actualitzar-la cada hora o cada dia
• HAProxy — fitxers ACL i Maps: src -f sperrliste.txt en una regla http-request deny, recarregable mitjançant l’API d’execució sense reiniciar
• nginx — mòdul geo amb un fitxer d’adreces inclòs, o directives deny procedents d’un fitxer include generat
• Fortinet FortiGate — External Block List o Threat Feed: un URL del qual el tallafoc obté una llista d’IP que utilitza en les polítiques
• Palo Alto Networks — External Dynamic List (EDL): el mateix principi, com a tipus d’objecte propi dins de les polítiques de seguretat
• Check Point — Custom Intelligence Feeds i IP Block Lists mitjançant un URL
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds amb fonts de llistes pròpies
• Sophos Firewall — Third-Party Threat Feeds: llistes d’adreces obtingudes d’un URL com a font per a regles de bloqueig
• Juniper SRX — Dynamic Address Entries procedents de fonts de dades
• MikroTik RouterOS — Address Lists, emplenades des d’un URL mitjançant un script i fetch
• CrowdSec — llistes pròpies com a font per als Bouncer en qualsevol sistema compatible

Web RBL publica la seva llista de bloqueig exactament en aquest format. El tallafoc descarta els paquets abans que arribin al servidor web, i també qualsevol altre intent de la mateixa adreça, per exemple contra el servidor de correu o la passarel·la VPN.

En tots dos sentits, però al lloc adequat

També funciona a la inversa: a Web RBL es pot afegir qualsevol llista RBL: un URL, un nivell i llestos. Els nodes de sortida de Tor, Spamhaus DROP, FireHOL i blocklist.de ja estan preconfigurats; se’n poden afegir d’altres amb tres clics. El mòdul desglossa cada llista en intervals d’adreces i hi contrasta cada petició en pocs microsegons.

Tot i això, és més convenient utilitzar les llistes de tercers al tallafoc situat al davant. Per tres motius. El tallafoc veu tots els serveis, no només HTTP: una adreça de la llista de Spamhaus també ha de quedar bloquejada al servidor de correu i a la VPN. Descarta el trànsit a nivell de paquet, abans que s’arribi a establir cap connexió, de manera que no consumeix recursos del servidor d’aplicacions. I és el lloc on ja es mantenen aquestes llistes; una segona còpia a l’aplicació és un segon lloc on poden quedar desactualitzades.

Per a què serveixen, doncs, les llistes dins del mòdul? Per fer allò que un tallafoc no pot fer. El tallafoc no coneix el formulari d’inici de sessió. Web RBL pot denegar a una adreça de la llista de Tor l’accés a l’inici de sessió i continuar servint-li el lloc web: qui vulgui llegir de manera anònima ho ha de poder fer; qui vulgui provar contrasenyes de manera anònima, no. I pot notificar com a sospitós un inici de sessió reeixit des d’una adreça inclosa en una llista. Totes dues funcions necessiten la llista allà on s’inicia la sessió.

Puntuació en lloc d’intuïció

Una adreça que ha demanat /wp-login.php una vegada no és el mateix que una que ha recorregut tres dominis durant dos dies amb cinc patrons diferents. Web RBL ho converteix en una puntuació de 0 a 100, a partir del que ha observat directament, sense serveis de tercers ni consultes externes.

Una entrada: 99 coincidències, una puntuació de 84 i la justificació en llenguatge clar: patró de gravetat màxima, cinc patrons greus diferents, dos dies amb activitat sospitosa i més de vint coincidències.

La puntuació determina dues coses. A partir d’un valor configurable, es prohibeix iniciar sessió: el lloc web es pot continuar llegint, però qui ja ha buscat credencials no té l’oportunitat de provar les que hagi trobat. I es notifica qualsevol inici de sessió reeixit des d’una adreça amb puntuació: en aquest cas, algú ja no ha provat d’endevinar les credencials, sinó que les sabia. O bé l’usuari autoritzat es connectava des d’un altre lloc, o bé les credencials han caigut en mans alienes. El mòdul no ho decideix: ho presenta a algú que pot demanar explicacions. Durant aquest procés no es manipula la contrasenya en cap moment.

La llista de bloqueig, filtrada per puntuacions a partir de 40: nombre de coincidències, dies amb activitat sospitosa, dominis afectats i últim camí per a cada adreça.

Què protegeix Web RBL: la protecció al detall

1. Les credencials no es descobreixen

La categoria d’atacs més nombrosa que hem mesurat no busca vulnerabilitats d’Odoo, sinó secrets que han quedat exposats. Durant disset dies:

• 57.721 peticions de fitxers .env: contenen contrasenyes de bases de dades, claus d’API i secrets de sessió
• 5.535 peticions de fitxers de configuració
• 4.388 peticions de credencials del núvol: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 peticions de directoris .git: qui en troba un es descarrega tot el codi font amb l’historial complet
• 1.907 peticions d’instruccions de compilació com ara .github/workflows/deploy.yml o .gitlab-ci.yml, que contenen registres i noms de claus

La dada decisiva no és el nombre de peticions, sinó el nombre d’adreces diferents: les peticions de /credentials.json provenien de 98 adreces, i les de /.git-credentials, de 92. No es tracta d’un únic escàner, sinó d’un repertori estàndard que s’executa simultàniament arreu del món.

2. Els intents d’inici de sessió queden en no res, de manera permanent

Odoo incorpora un mecanisme propi per frenar els intents d’endevinar contrasenyes. Té tres limitacions documentades al mateix codi font d’Odoo: el comptador és a la memòria RAM del procés de treball i es reinicia cada vegada que aquest torna a arrencar, només introdueix un retard en lloc de bloquejar i compta exclusivament els intents que arriben a la comprovació de la contrasenya.

Web RBL actua als mateixos punts, però escriu a la base de dades. Això vol dir que:

• El recompte es conserva després de qualsevol reinici i és compartit per tots els processos de treball
• Es registren totes dues vies: el formulari d’inici de sessió /web/login i les interfícies /xmlrpc/2/common i /jsonrpc
• També es registren els intents que no arriben mai a la comprovació de la contrasenya, com ara els inicis de sessió sense un identificador de sessió vàlid
• També es compta qualsevol accés fallit al gestor de bases de dades; és l’intent d’inici de sessió més greu de tots

El llindar per als inicis de sessió està fixat en deu, i el motiu és una observació: dels nou inicis de sessió fallits en disset dies, la majoria provenien de clients que es configuraven l’accés en un altre dispositiu i hi introduïen un domini incorrecte; en un cas, el seu, però amb un guionet en lloc d’un punt. Per tant, un bloqueig al primer intent fallit no hauria afectat els atacants, sinó els clients durant la configuració.

En canvi, qui ho continua intentant després que el servidor ja hagi respost «espereu un moment, si us plau» queda bloquejat immediatament. Una persona llegeix aquest missatge i espera; qui l’ignora és un programa. Un patró específic amb un llindar de zero detecta exactament aquest cas i no pot afectar cap company: només hi arriba qui ja acumula deu intents fallits i encara continua.

3. L’atac deixa de consumir recursos del servidor

Abans d'instal·lar el mòdul, un sondeig d'una ruta com /@fs/../../.env tenia un cost elevat: Odoo busca la pàgina d'error, la renderitza, ensopega amb els segments de punts en construir l'adreça i, tot seguit, també falla en generar la pàgina d'error de la pàgina d'error. Dues traces de pila per sondeig. Es van comptabilitzar 28.401 errors d'aquest tipus en disset dies, a més de 9.467 errors derivats.

Web RBL intervé a ir.http._match, és a dir, abans de l'encaminament. La resposta es genera sense plantilles, sense accedir a la base de dades més enllà de la comprovació del bloqueig i sense cap línia de registre. La comprovació de la llista d'adreces permeses, les llistes d'amenaces i les regles per país es fa des de la memòria cau sobre intervals d'adreces ordenats: uns quants microsegons, fins i tot amb més de trenta mil intervals.

4. El tallafoc expulsa l'atacant abans que arribi

La llista de bloqueig es publica com a llista RBL, que HAProxy i OPNsense llegeixen directament. Així, l'atacant ja no arriba al servidor web — ni a cap altre servei del mateix amfitrió. Un accés detectat un cop com a maliciós protegeix així retroactivament tota la màquina.

Tres nivells: bloquejar, comptar, notificar

No totes les peticions a recursos inexistents són atacs. Per això, Web RBL distingeix tres nivells, que es poden canviar per a cada patró sense tocar el codi.

Nivell	La petició que l'activa	Conseqüència per a l'adreça
bloquejar	es rebutja	bloquejada durant 24 hores; després de tres dies amb activitat sospitosa, permanentment
comptar	es deixa passar	només es comptabilitza, sense bloqueig
notificar	es deixa passar	es registra amb una descripció del problema i mai no es bloqueja

Per a les llistes d'amenaces i els països hi ha un quart nivell: sense accés a l'inici de sessió. El lloc web es pot continuar consultant, però el formulari d'inici de sessió i les interfícies queden tancats. És la via intermèdia per a tot allò que és sospitós però no necessàriament maliciós: Tor, un interval d'adreces d'un centre de dades, un país on no tenim clients.

Quins atacs es detecten

Tots els patrons s'han comprovat amb trànsit real. Al costat s'hi indica expressament el nombre d'adreces diferents: mostra si un patró detecta un únic escàner o una pràctica estesa.

Tipus d'atac	Peticions	Adreces
Extracció de .env	57.721	223
Sondejos de PHP	12.237	256
Travessia de directoris amb un objectiu de valor	10.046	64
Fitxers de configuració	5.535	114
Claus d'accés al núvol	4.388	152
Sondejos de WordPress	3.366	385
Extracció de .git	2.811	255
Exploració d'Odoo (gestor de bases de dades, consulta de la versió)	2.500	213
Cadenes d'eines d'IA i execució d'ordres (/mcp, /api/fs/exec)	2.450	74
Instruccions de construcció (CI/CD)	1.907	88
Punts d'accés de GraphQL	1.878	71

La categoria més recent és especialment remarcable. Es van fer 369 peticions a /api/fs/exec des de 54 adreces diferents: no és un accés de lectura, sinó un intent d'executar ordres. Fa dos anys, aquests objectius no existien; provenen de les interfícies de noves eines d'IA i de cues de tasques. Qui orienta la defensa només a WordPress i PHP no en detecta res. Per això, aquesta categoria té un pes considerable en la valoració.

Llistes d'amenaces i país d'origen

Quatre llistes, 32.851 intervals d'adreces, totes en mode «només notificar». Per afegir-hi una altra llista, només cal una adreça i un nivell.

Una llista externa és una afirmació que fa algú altre, per motius que desconeixem, sobre trànsit que no hem vist mai. Pot ser errònia, estar desactualitzada o haver estat concebuda per a una altra finalitat: blocklist.de recull sobretot adreces que han provat repetidament d'iniciar sessió per SSH en altres sistemes, i això diu ben poca cosa sobre un servidor web. Per això, Web RBL manté les llistes externes separades de la seva pròpia llista de bloqueig, i per això l'opció predeterminada és notificar. I la llista pròpia d'adreces permeses sempre té prioritat: un client que coneixem pesa més que la valoració d'un tercer.

El país d'origen consta a cada detecció i a cada adreça. És insubstituïble per valorar-les: un intent d'iniciar sessió des del nostre país a les deu del matí no és el mateix que un intent des d'un país on no tenim cap client. En canvi, serveix de ben poc per bloquejar indiscriminadament, i les nostres pròpies xifres ho demostren: els atacants de la nostra llista provenien majoritàriament d'intervals d'adreces del núvol de Bèlgica, Finlàndia i els Països Baixos. Un bloqueig de tot el que vingués de fora de l'àmbit de parla alemanya no els hauria afectat, però sí els nostres empleats de vacances i els clients en viatge de negocis.

Les regles per país es lliuren buides, i la vista n'explica el motiu.

Notificar les configuracions incorrectes en lloc de bloquejar

El cas més habitual en el trànsit real no és ni un atac ni un visitant, sinó programari que funciona malament i confon el servidor web amb una altra cosa:

• 1.367 peticions a la interfície web d'un NAS QNAP: un client de sincronització que ja no apunta a la destinació correcta. Una sola connexió va fer 962 intents.
• 65 consultes Autodiscover: un Outlook que confon el domini web amb el seu servidor Exchange

Aquestes adreces no es bloquegen mai. Un bloqueig no resol el problema, sinó que l'amaga i perjudica algú que ja té el dispositiu mal configurat. En lloc d'això, es crea una entrada amb una descripció del problema i els dominis afectats, a partir de la qual, si es vol, es genera automàticament un tiquet: exactament un per adreça. Si es tanca i l'adreça torna a presentar activitat sospitosa, es reobre el mateix tiquet en lloc de crear-ne un altre.

Es detecten QNAP, Synology, Exchange-Autodiscover, ActiveSync i clients WebDAV, CalDAV i CardDAV. Els patrons especifiquen noms exactes de fitxers i directoris, mai simples extensions: dins del mateix directori /cgi-bin/, les peticions de sincronització inofensives conviuen amb sondejos clàssics com printenv.pl.

La llista d'adreces permeses: adreces que no es bloquegen mai

El cost d'un error no és el mateix per a totes les adreces. En el cas d'un escàner d'un centre de dades, un fals positiu no costa res. En el cas de l'extrem remot d'un túnel d'una seu, costa la connexió de tota la seu.

Per això hi ha una segona llista que té prioritat sobre la primera: adreces i xarxes que no es bloquegen mai. Això no silencia res: les adreces que hi figuren es continuen comprovant i registrant; només se n'omet la conseqüència. Aquesta és la diferència respecte d'una excepció al tallafoc: aquella ens deixa a cegues; aquesta només ens fa més pacients.

S'actualitza diàriament a partir de dues fonts: el mateix tallafoc, amb tots els extrems remots de VPN, perquè un túnel acabat de configurar no depengui que algú es recordi de la llista de bloqueig, i els intervals d'adreces publicats per Google i Microsoft per als seus rastrejadors. Només així es pot distingir un Googlebot autèntic d'un escàner que es fa passar per ell. Els cercadors no s'han de bloquejar mai; qui els barra el pas treu el seu lloc de la indexació sense possibilitat de tornar enrere.

Aquí s'aplica una regla més important que la mateixa comprovació: una resposta buida no esborra mai res. Si la font no respon, respon sense contingut o retorna una resposta incomprensible, la llista es manté intacta. Una llista d'adreces permeses que es buida sola quan hi ha una incidència deixa fora de servei tots els túnels en el pitjor moment possible.

Si una entrada de la llista d'adreces permeses té un client associat, cada detecció procedent de la seva xarxa se li atribueix. Així, una configuració incorrecta té immediatament una persona de contacte, sense que ningú hagi de buscar a qui pertanyen les adreces.

Informació legal obligatòria i recol·lectors automatitzats de dades

L'avís legal no és una pàgina qualsevol. Ha de continuar sent accessible per a les persones, perquè bloquejar-lo crea precisament l'incompliment que busca un recol·lector. Alhora, és la pàgina on consten el nom i l'adreça i, per tant, un objectiu de la recol·lecció automatitzada.

Durant l'onada de requeriments legals a Àustria per l'ús de fonts de Google incrustades, els registres van mostrar que els escrits no provenien de visites individuals, sinó d'una campanya automatitzada massiva: diversos amfitrions sense relació entre ells, visitats amb mil·lisegons de diferència.

Web RBL ho resol rebaixant el nivell en lloc de crear una excepció. La ruta canònica /impressum no coincideix amb cap patró i continua sent sempre accessible. Les variants alienes, com ara /impressum.php, que no poden existir en un lloc d'Odoo, es notifiquen; qui no vulgui tolerar la recol·lecció automatitzada només ha de canviar un paràmetre. sitemap i robots en queden exclosos i no es poden bloquejar en cap cas: no contenen dades personals, i consultar-los és la feina de qualsevol rastrejador de cercadors.

Domini i identificador: què falta al registre d'accessos

El registre d'accessos de werkzeug no desa ni l'amfitrió de destinació ni l'identificador de qui fa la petició. Odoo, naturalment, rep totes dues dades: sense l'amfitrió, no podria triar el lloc correcte quan n'hi ha diversos. Però després no es poden consultar.

Web RBL desa totes dues dades per a cada detecció. Això respon dues preguntes que, altrament, quedarien sense resposta: a quin lloc web s'adreça una configuració incorrecta i, per tant, a quin client pertany el domini, i si una adreça visita un sol lloc o tots. L'accés a diversos dominis sense relació entre ells des d'una mateixa adreça és el senyal d'una campanya massiva i fa augmentar la puntuació.

Una anàlisi d'un dels nostres llocs web va mostrar fins a quin punt és important l'identificador: més del setanta per cent de tot el trànsit provenia d'un únic agent, repartit entre més de cent adreces. Sense l'identificador, hauria semblat un extractor de dades distribuït. Era GPTBot, el rastrejador d'OpenAI: consultava repetidament robots.txt i es comportava de manera del tot correcta.

Els aspectes de seguretat, en detall

1. La detecció del servidor intermediari: el punt més perillós de tots

Si Odoo funciona darrere d'un servidor intermediari invers i proxy_mode està mal configurat, el mòdul veu la mateixa adreça en totes les peticions: la del servidor intermediari. En aquest cas, un bloqueig barraria el pas a tots els visitants alhora.

Per això, abans de cada bloqueig, Web RBL comprova si la determinació de l'adreça és fiable. Exigeix proxy_mode juntament amb una capçalera de reenviament, es nega a actuar si arriba un reenviament sense proxy_mode i també si hi ha més d'un servidor intermediari al mig. En cas de dubte, no es bloqueja.

2. Les xarxes pròpies, mai

Els intervals d'adreces privades, les adreces de bucle local, les d'enllaç local i les de CGNAT queden exclosos de manera fixa. No poden acabar a la llista sota cap circumstància, ni tan sols manualment. El mateix s'aplica a les llistes externes: els intervals privats i reservats, així com les xarxes desmesuradament grans, es descarten durant la importació.

3. Un error propi no ha de fer caure el lloc web

Tota la comprovació s'executa dins d'un mecanisme de protecció que captura qualsevol error. Si alguna cosa falla, es registra i la petició continua sense canvis. Un mòdul de protecció que fa caure el lloc web per un error propi és pitjor que no tenir-ne cap. A més, totes les consultes fetes durant el processament de la petició s'executen sense fer servir l'idioma del navegador del visitant ni ordenar per camps traduïts: un visitant amb un idioma no instal·lat no ha de poder fer fallar la comprovació.

4. Observar abans de bloquejar

Després de la instal·lació, el bloqueig d'adreces de la llista per a peticions ordinàries està desactivat. Els sondejos es rebutgen i es registren; tota la resta es deixa passar. Això permet observar durant uns quants dies qui acaba realment a la llista abans de barrar el pas a ningú. El mateix s'aplica a la detecció de comportaments, les llistes d'amenaces i les regles per país: primer notificar, després revisar i bloquejar.

5. Patrons precisos en lloc de filtres massa amplis

Un visitant classificat erròniament surt més car que un sondeig no detectat. Per això, cada patró té el seu nivell, que es pot canviar individualment. Una extensió de fitxer per si sola rarament és suficient: en el cas de .php, hi ha 14.012 sondejos reals davant d'un grapat d'enllaços antics; amb .asp, la proporció és la inversa. Aquestes decisions s'han de basar en mesures, no en estimacions.

6. Una autorització manual es manté

Qui autoritza una adreça té un motiu per fer-ho. Una nova detecció no anul·la aquesta decisió de manera silenciosa.

7. La llista està protegida, però no és secreta

El punt d'accés exigeix un testimoni i, si no és vàlid, respon amb 404, no amb 403: així ni tan sols es confirma que l'adreça existeixi. La comparació es fa en temps constant. La llista en si no conté res de confidencial: està formada per adreces que han contactat amb nosaltres per iniciativa pròpia.

8. Cap secret als registres

En els intents fallits d'iniciar sessió es registra el nom d'usuari utilitzat, mai la contrasenya. En el gestor de bases de dades no es llegeix absolutament cap dels valors enviats: el primer és la contrasenya mestra, i una entrada de la llista de bloqueig acaba a totes les còpies de seguretat de la base de dades. La clau de llicència de GeoLite2 només consta al paràmetre del sistema i en cap línia de registre.

9. L'esquer no revela res d'aprofitable

Opcionalment, Web RBL respon als sondejos amb contingut inventat que conté un valor esquer únic. Qui més endavant fa una petició amb aquest valor ha llegit la resposta falsa i ha actuat en conseqüència: en aquest cas, queda descartat un fals positiu. Els esquers no contenen informació aprofitable, ni rutes reals ni credencials vàlides. Aquesta funció es lliura desactivada, perquè canvia el comportament de manera visible des de l'exterior.

Què no pot fer el mòdul

No substitueix un tallafoc ni un tallafoc d'aplicacions web. Detecta patrons de sondeig coneguts en les rutes, intents fallits d'iniciar sessió i comportaments sospitosos, però no atacs contra formularis ni intents d'injecció en paràmetres.

A més, només veu allò que torna a arribar per HTTP. El que faci un atacant amb credencials robades de bases de dades o de bústies de correu queda fora del seu abast, i precisament per això els valors esquer són rutes i no credencials.

Tampoc no substitueix la cura necessària: un mòdul que rebutja sondejos de .env no fa que un fitxer .env exposat per error deixi de ser perillós.

Disponibilitat

Web RBL està disponible públicament sota la llicència AGPL-3 i el fem servir en producció en cinc llocs web:

github.com/Alex0176/odoo-web-rbl

El mòdul requereix Odoo 19 Community i no té cap dependència més enllà de base i web. La integració amb tiquets és opcional i no requereix cap sistema de tiquets concret; si no n'hi ha cap, simplement no fa res. El país d'origen necessita la base de dades gratuïta GeoLite2 de MaxMind; si no hi és, el camp queda buit i tota la resta continua funcionant igual.

Per saber-ne més: Com encaixa Web RBL en una arquitectura de seguretat completa, juntament amb el tallafoc, l'autenticació de dos factors i els permisos, amb una guia pas a pas: Com combinar correctament els elements de l'arquitectura de seguretat d'Odoo 19.

Agraïm les preguntes, els comentaris i els informes d'errors, preferiblement com a incidència a GitHub.