Odoo 19 Community: Web RBL – lista de bloqueo para tráfico de ataque nas propias webs

Código fonte: github.com/Alex0176/odoo-web-rbl — AGPL-3, de uso libre.

Quen opera un servidor Odoo en Internet recibe visitas. Non de vez en cando, senón sen interrupción. Durante dezasete días rexistramos e avaliamos nas nosas cinco webs 731.297 solicitudes. 110.511 delas non eran visitantes, senón busca automatizada de vulnerabilidades, datos de acceso e ficheiros de configuración.

Esta publicación describe Web RBL, un módulo de código aberto para Odoo 19 Community que detecta, avalía, rexistra e rexeita este tráfico — e que publica a lista de bloqueo como lista RBL, é dicir, no formato que os firewalls e os proxys inversos len directamente. Todas as cifras proceden da operación real.

O que sabe facer o módulo — as funcións nunha ollada

Función	O que fai	Entrega
Recoñecemento de patróns	Detecta sondaxes por ruta e extensión: .env, .git, ficheiros de configuración, claves de nube, instrucións de construción CI/CD, WordPress, PHP, path traversal, xestores de bases de datos, GraphQL, execución de comandos a través de /api/fs/exec e interfaces semellantes	bloquear
Tres niveis por patrón	bloquear, contar ou informar — modificable por patrón, sen código	por patrón
Limiares	Cantos acertos do mesmo patrón antes de bloquear; para inicios de sesión, dez	10 no inicio de sesión
Defensa de inicio de sesión	Inicios de sesión fallidos a través do formulario e XML-RPC/JSON-RPC, comprobacións de sesión fallidas, accesos ao xestor de bases de datos — na base de datos, non na memoria principal	activado
Detección de bots no inicio de sesión	Quen ignora a mensaxe de espera despois de dez intentos fallidos e segue chamando é bloqueado de inmediato	bloquear
Detección do comportamento	Enderezos que en cinco minutos xeran vinte páxinas de erro e case ningunha páxina atopada — é dicir, adiviñan en vez de ler	informar
Avaliación 0–100	Que seguro é que detrás do enderezo hai un atacante? A partir da gravidade do patrón, o número de patróns distintos, días chamativos, dominios afectados e número de acertos — con xustificación en texto claro	activado
Bloqueo do inicio de sesión segundo a avaliación	A partir dunha avaliación axustable, o inicio de sesión está prohibido, a web segue sendo lexible	desde 40
Sospeita de datos de acceso roubados	Un inicio de sesión correcto desde un enderezo sospeitoso comunícase e, se se desexa, asígnase como tarefa — unha vez por enderezo e día	activado
Listas de ameazas	Nodos de saída de Tor, Spamhaus DROP, FireHOL Level 1 e blocklist.de preconfigurados; calquera outra lista RBL pódese engadir polo seu enderezo, comparación diaria, cada lista co seu propio nivel	informar
Sen acceso ao inicio de sesión	O cuarto nivel para listas e países: a páxina web pódese ler, pero o formulario de acceso e as interfaces quedan pechados — a resposta axeitada para Tor	Opción
País de orixe	País por cada acerto e enderezo mediante GeoLite2; o módulo mantén a base de datos actualizada por si mesmo cunha clave de licenza gratuíta	mostrar
Regras por país	Bloquear, sen acceso ao inicio de sesión, comunicar ou expresamente libre — por país, deliberadamente sen valor predeterminado	ningunha
Configuracións erróneas	QNAP, Synology, Exchange Autodiscover, ActiveSync e WebDAV/CalDAV/CardDAV detéctanse, nunca se bloquean e pásanse a unha lista de traballo co diagnóstico e o dominio afectado	informar
Tícket por enderezo	Dun diagnóstico sae, se se desexa, un tícket — exactamente un por enderezo; un tícket pechado reábrese en vez de duplicarse	desactivado
Páxinas obrigatorias e colectores	A ruta canónica do aviso legal sempre permanece accesible; detéctase o tanteo automático de grafías alleas e, se se desexa, bloquéase	informar
Lista de exclusións	Enderezos e redes que nunca se bloquean; énchese a diario desde o firewall (extremos de VPN) e desde os intervalos de enderezos publicados de Googlebot e Bingbot	activado
Asignación a clientes	Un acerto procedente da rede dun cliente asígnaselle a el — a partir da lista de exclusións, nunca adiviñado a man	activado
Dominio e identificador por acerto	Que páxina web se solicitou e con que User-Agent — ambos faltan no rexistro de accesos	activado
Análise	Gráfico e táboa dinámica sobre todos os acertos: por patrón, día, dominio, país e enderezo	activado
Cebos	As sondas reciben respostas inventadas cun valor canario; quen o consulte despois leuas	desactivado
Entrega de RBL	A lista de bloqueo como simple lista de enderezos ou JSON nun enderezo propio protexido por token — para HAProxy, OPNsense e calquera firewall que lea listas de URL	activado

Todo o que se entrega con comunicar, desactivado ou opción é así deliberadamente: quen activa un bloqueo debe facelo porque observou durante uns días quen cae nel — non porque o valor predeterminado así o quixese.

A análise: acertos por patrón durante sete días. A barra máis alta é a busca de ficheiros .env.

Listas RBL: unha forma estandarizada de entregar bloqueos

RBL significa Real-time Blackhole List. O termo procede do mundo do correo, onde Spamhaus e outros publican desde os anos noventa listas de enderezos de remitentes maliciosos. O principio é moi sinxelo e precisamente por iso está tan difundido: un enderezo por liña, accesible por HTTP, recargado con regularidade. Sen un formato que haxa que analizar primeiro, sen unha interface para a que faga falta unha ferramenta.

Practicamente calquera firewall e calquera proxy inverso pode ler unha lista destas e crear regras a partir dela. Os fabricantes chámanlle distinto, pero o mecanismo é o mesmo en todas partes:

• OPNsense e pfSense — URL Table Alias: cargar a lista de enderezos por HTTP, usala como alias nas regras do firewall, actualización cada hora ou cada día
• HAProxy — ficheiros ACL e Maps: src -f sperrliste.txt nunha regra http-request deny, recargable a través da API en tempo de execución sen reiniciar
• nginx — módulo geo cun ficheiro de enderezos incluído, ou instrucións deny procedentes dun ficheiro include xerado
• Fortinet FortiGate — External Block List ou Threat Feed: unha URL da que o firewall obtén unha lista de IP e a usa nas políticas
• Palo Alto Networks — External Dynamic List (EDL): o mesmo principio, como tipo de obxecto propio nas políticas de seguridade
• Check Point — Custom Intelligence Feeds e IP Block Lists a través dunha URL
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds con fontes de listas propias
• Sophos Firewall — Third-Party Threat Feeds: listas de enderezos desde unha URL como fonte para regras de bloqueo
• Juniper SRX — Dynamic Address Entries a partir de feeds
• MikroTik RouterOS — Address Lists, énchense mediante script e fetch desde unha URL
• CrowdSec — listas propias como fonte para os bouncers en calquera sistema compatible

Web RBL entrega a súa lista de bloqueo exactamente neste formato. O firewall descarta os paquetes antes de que cheguen ao servidor web — e con eles calquera outro intento do mesmo enderezo, por exemplo contra o servidor de correo ou a pasarela VPN.

Nos dous sentidos, pero no lugar axeitado

O camiño tamén funciona ao revés: en Web RBL pódese engadir calquera lista RBL — unha URL, un nivel e listo. Os nodos de saída de Tor, Spamhaus DROP, FireHOL e blocklist.de veñen preconfigurados; outras engádense con tres clics. O módulo descompón cada lista en intervalos de enderezos e comproba cada solicitude contra eles, en poucos microsegundos.

Aínda así: é máis razoable usar listas alleas no firewall que vai por diante. Por tres motivos. O firewall ve todos os servizos, non só HTTP — un enderezo da lista de Spamhaus tamén debe fracasar no servidor de correo e na VPN. Descarta ao nivel de paquete, antes de que se estableza sequera unha conexión, e así non lle custa nada ao servidor de aplicacións. E é o lugar onde estas listas se manteñen de todos modos; unha segunda copia na aplicación é un segundo punto que pode quedar obsoleto.

Para que serven entón as listas no módulo: para o que un firewall non pode facer. Non coñece ningún formulario de acceso. Web RBL pode denegarlle o acceso ao inicio de sesión a un enderezo da lista de Tor e, aínda así, entregar a páxina web — quen quere ler de forma anónima debe poder facelo; quen quere probar contrasinais de forma anónima, non. E pode comunicar como caso sospeitoso un inicio de sesión correcto desde un enderezo listado. Ambas cousas precisan a lista alí onde ten lugar o inicio de sesión.

Avaliación en vez de intuición

Un enderezo que preguntou unha soa vez por /wp-login.php é algo distinto doutro que, en dous días, tentou cinco patróns diferentes en tres dominios. Web RBL convérteo nunha puntuación de 0 a 100 — a partir do que viu por si mesmo, sen servizos externos e sen consultas ao exterior.

Unha entrada: 99 acertos, puntuación 84 e a xustificación en texto claro — patrón máis grave, cinco patróns graves diferentes, dous días sospeitosos, máis de vinte acertos.

A puntuación decide dúas cousas. A partir dun valor ajustable, o inicio de sesión está prohibido — a páxina web segue legible, pero quen xa buscou datos de acceso non recibe a oportunidade de probar os que atopou. E un inicio de sesión correcto desde un enderezo con puntuación comunícase: entón alguén xa non adiviñou, senón que sabía. Ou o usuario lexítimo estaba de viaxe, ou os datos de acceso extraviáronse — o módulo non o decide, preséntallo a alguén que poida preguntar. O contrasinal en si non se toca en ningún momento.

A lista de bloqueo, filtrada por puntuación a partir de 40: número de acertos, días sospeitosos, dominios afectados e a última ruta por enderezo.

Que protexe Web RBL — o efecto protector en detalle

1. Os datos de acceso permanecen sen descubrir

A clase de ataque máis grande medida non busca fallos en Odoo, senón segredos esquecidos. Durante dezasete días:

• 57.721 solicitudes de ficheiros .env — aí están os contrasinais das bases de datos, as claves de API e os segredos de sesión
• 5.535 solicitudes de ficheiros de configuración
• 4.388 solicitudes de credenciais na nube: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 solicitudes de directorios .git — quen atopa un descarga o código fonte completo co historial
• 1.907 solicitudes de instrucións de compilación como .github/workflows/deploy.yml ou .gitlab-ci.yml, nas que figuran rexistros e nomes de claves

O decisivo non é o número de solicitudes, senón o número de enderezos diferentes: /credentials.json veu de 98 enderezos e /.git-credentials de 92. Non é un único escáner, senón un repertorio estándar que funciona en todo o mundo ao mesmo tempo.

2. Os intentos de inicio de sesión non levan a ningures — de forma permanente

Odoo incorpora un freo propio contra o tanteo de contrasinais. Ten tres límites, documentados no propio código fonte de Odoo: o contador está na memoria do proceso de traballo e reiníciase en cada reinicio, só atrasa en vez de bloquear, e conta exclusivamente os intentos que chegan ata a comprobación do contrasinal.

Web RBL actúa nos mesmos puntos, pero escribe na base de datos. Con isto, cúmprese que:

• O estado sobrevive a cada reinicio e vale para todos os procesos de traballo
• Rexístranse ambas as vías: o formulario de acceso /web/login e as interfaces /xmlrpc/2/common e /jsonrpc
• Tamén se rexistran os intentos que nunca chegan á comprobación do contrasinal — por exemplo, inicios de sesión sen un identificador de sesión válido
• Un acceso fallido ao xestor de bases de datos tamén se contabiliza; é o intento de inicio de sesión máis grave de todos

O límite para os inicios de sesión está en dez, e o motivo é unha medición: de nove inicios de sesión fallidos en dezasete días, a maioría eran de clientes que configuraban eles mesmos o acceso nun outro dispositivo e introducían o dominio equivocado — nun caso, o seu propio, só que cun guión en vez de punto. Un bloqueo ao primeiro intento fallido non tería afectado a atacantes, senón a clientes durante a configuración.

Quen, en cambio, segue petando aínda que o servidor xa respondese «agarde un momento», bloquéase de inmediato. Esa mensaxe lea unha persoa e agarda; quen a ignora é un programa. Un patrón propio con límite cero detecta exactamente este caso, e non pode afectar a un compañeiro: alí só chega quen xa leva dez intentos fallidos e despois segue.

3. O ataque xa non lle custa nada ao servidor

Unha sonda a unha ruta como /@fs/../../.env era cara antes do módulo: Odoo busca a páxina de erro, renderízaa, tropeza ao construír o enderezo cos segmentos de puntos e fracasa entón tamén coa páxina de erro da páxina de erro. Dous rexistros de pila por sonda. Mediuse 28.401 erros destes en dezasete días, ademais de 9.467 erros derivados.

Web RBL actúa en ir.http._match, é dicir, antes de encontrar a ruta. A resposta dáse sen modelo, sen acceso á base de datos alén da comprobación de bloqueo e sen liña de rexistro. A comprobación contra a lista de exclusións, as listas de ameazas e as regras por país execútase desde a caché sobre intervalos de enderezos ordenados — poucos microsegundos, mesmo con máis de trinta mil intervalos.

4. O firewall bota ao atacante antes de que chegue

A lista de bloqueo publícase como lista RBL, que HAProxy e OPNsense len directamente. Así, o atacante xa non chega ao servidor web — nin a ningún outro servizo do mesmo host. Un acceso recoñecido unha vez como malicioso protexe así retroactivamente toda a máquina.

Tres niveis: bloquear, contar, comunicar

Non todas as solicitudes ao baleiro son un ataque. Por iso Web RBL distingue tres niveis, e o nivel pódese cambiar por patrón sen tocar o código.

Nivel	A solicitude que o activa	Consecuencia para o enderezo
bloquear	rexéitase	bloqueado 24 horas, de forma permanente tras tres días sospeitosos
contar	pasa	só se rexistra, sen bloqueo
comunicar	pasa	rexístrase co texto do diagnóstico, nunca se bloquea

Para as listas de ameazas e os países hai un cuarto: sen acceso ao inicio de sesión. A páxina web segue legible, o formulario de acceso e as interfaces quedan pechados. É o termo medio para todo o que é sospeitoso, pero non ten por que ser malicioso — Tor, un intervalo de centro de datos, un país sen clientes.

Que ataques se detectan

Todos os patróns están comprobados contra tráfico real. O número de enderezos diferentes figura ao lado deliberadamente — mostra se un patrón afecta a un único escáner ou a unha práctica estendida.

Clase de ataque	Solicitudes	Enderezos
Captura de .env	57.721	223
Sondas PHP	12.237	256
Path traversal cun obxectivo valioso	10.046	64
Ficheiros de configuración	5.535	114
Claves de acceso á nube	4.388	152
Sondas de WordPress	3.366	385
Captura de .git	2.811	255
Exploración de Odoo (xestor de bases de datos, consulta de versión)	2.500	213
Cadeas de ferramentas de IA e execución de comandos (/mcp, /api/fs/exec)	2.450	74
Instrucións de compilación (CI/CD)	1.907	88
Puntos finais de GraphQL	1.878	71

A clase máis recente é digna de mención. /api/fs/exec solicitouse 369 veces desde 54 enderezos diferentes — non é un acceso de lectura, senón un intento de executar comandos. Tales obxectivos non existían hai dous anos; proceden das interfaces de novas ferramentas de IA e de colas de tarefas. Quen oriente a súa defensa só cara a WordPress e PHP non ve nada disto. Na puntuación, esta clase pesa en consecuencia moito.

Listas de ameazas e país de orixe

Catro listas, 32.851 intervalos de enderezos, todas en «só comunicar». Cada outra lista é un enderezo e un nivel.

Unha lista allea é unha afirmación que fai outra persoa, por motivos que non coñecemos, sobre un tráfico que nunca vimos. Pode ser falsa, estar obsoleta ou estar pensada para outro fin: blocklist.de recolle sobre todo enderezos que noutros lugares tentaron adiviñar inicios de sesión SSH, e iso di pouco sobre un servidor web. Por iso Web RBL mantén as listas alleas separadas da súa propia lista de bloqueo, e por iso o valor predeterminado é comunicar. E a propia lista de exclusións gaña sempre: un cliente que coñecemos pesa máis ca a valoración dun terceiro.

O país de orixe figura en cada acerto e en cada enderezo. Para avaliar é insubstituíble — un intento de inicio de sesión desde o propio país ás dez da mañá é algo distinto doutro desde un país sen un só cliente. Para bloquear en bloque serve pouco, e iso din as nosas propias cifras: os atacantes da nosa lista procedían sobre todo de intervalos de nube en Bélxica, Finlandia e os Países Baixos. Un bloqueo de todo o que quede fóra do espazo de fala alemá non os tería afectado — pero si a empregados propios de vacacións e a clientes de viaxe de negocios.

As regras por país entréganse baleiras, e a vista di por que.

Comunicar as configuracións erróneas en vez de bloquear

O caso máis frecuente no tráfico real non é nin un ataque nin un visitante, senón un software defectuoso que confunde o servidor web con outra cousa:

• 1.367 accesos á interface web dun NAS QNAP — un cliente de sincronización cuxo destino xa non é correcto. Un só enderezo petou 962 veces.
• 65 consultas de Autodiscover — un Outlook que toma o dominio web polo seu Exchange

Tales enderezos nunca se bloquean. Un bloqueo non soluciona o defecto, ocúltao — e afecta a quen tén o dispositivo mal configurado de todos modos. No seu lugar, créase unha entrada co texto do diagnóstico e os dominios afectados, da que, se se desexa, se xera automaticamente un tícket: exactamente un por enderezo, e se se pecha e o enderezo volve chamar a atención, reábrese o mesmo tícket en vez de crear un segundo.

Detéctanse QNAP, Synology, Exchange Autodiscover, ActiveSync e clientes WebDAV, CalDAV e CardDAV. Os patróns citan nomes de ficheiro e directorios exactos, nunca simples extensións: no mesmo directorio /cgi-bin/ as chamadas de sincronización inofensivas están ao carón de sondas clásicas como printenv.pl.

A lista de exclusións: enderezos que nunca se bloquean

O prezo dun erro non é igual para todos os enderezos. Cun escáner dun centro de datos, unha falsa alarma non custa nada. Co extremo dun túnel de sede, custa a sede.

Por iso hai unha segunda lista, que vai antes da primeira: enderezos e redes que nunca se bloquean. Non silencia nada — quen figura nela segue sendo comprobado e rexistrado, só se omite a consecuencia. Esa é a diferenza cunha excepción no firewall: aquela cega, esta só fai paciente.

Énchese a diario desde dúas fontes: desde o propio firewall con todos os extremos de VPN, para que un túnel recén configurado non dependa de que alguén se lembre da lista de bloqueo — e desde os intervalos de enderezos publicados por Google e Microsoft para os seus rastrexadores. Só así se pode distinguir un Googlebot real dun escáner que se fai pasar por tal. Os buscadores nunca deben bloquearse; quen os excluíu deixa o seu sitio sen camiño de volta á indexación.

Aquí vale unha regra máis importante ca a comparación: unha resposta baleira nunca borra. Se a fonte non responde, responde baleira ou de forma ininteligible, a lista permanece sen cambios. Unha lista de exclusións que se baleira a si mesma ante unha avaría leva consigo, no peor momento imaxinable, todos os túneles.

Se unha entrada da lista de exclusións leva un cliente, cada acerto procedente da súa rede asígnaselle a el. Así, unha configuración errónea ten de inmediato unha persoa de contacto, sen que ninguén teña que buscar enderezos.

Datos obrigatorios e colectores automatizados de datos

O aviso legal non é unha páxina calquera. Debe seguir accesible para as persoas, pois un bloqueo nela crea precisamente a infracción que busca un colector. Ao mesmo tempo, é a páxina na que figuran o nome e o enderezo — e, por tanto, o obxectivo da colleita automática.

Durante a onda austríaca de avisos por tipos de letra de Google incorporados, os rexistros mostraron que as cartas non procedían de visitas illadas, senón dun barrido automatizado: hosts distintos e sen relación entre si con milisegundos de diferenza.

Web RBL resólveo con rebaixa de nivel en vez de excepción. A ruta canónica /impressum non coincide con ningún patrón e sempre permanece accesible. As grafías alleas como /impressum.php — que non poden existir nunha páxina de Odoo — comunícanse, e quen non queira aceptar a colleita automática cambia un parámetro. sitemap e robots están exceptuados e, por principio, non se poden bloquear: non conteñen ningún dato persoal, e obtelos é a tarefa de calquera rastrexador de buscadores.

Dominio e identificador: o que falta no rexistro de accesos

O rexistro de accesos de werkzeug non anota nin o host solicitado nin o identificador de quen chama. Odoo recibe ambos, por suposto — sen o host non podería, con varias páxinas web, escoller a correcta. Pero despois non se pode consultar.

Web RBL rexistra ambas as cousas por acerto. Iso responde a dúas preguntas que doutro modo non se poden responder: que páxina web atopa unha configuración errónea — e, con iso, a que cliente pertence o dominio — e se un enderezo visita unha páxina ou todas. Varios dominios sen relación entre si do mesmo enderezo son o sinal do barrido, e aumentan a puntuación.

Canto importa o identificador mostrouno unha análise nunha as nosas páxinas web: máis do setenta por cento de todo o tráfico correspondía alí a un único chamador, repartido en máis de cen enderezos. Sen o identificador, aquilo tería parecido un scraper distribuído. Era GPTBot, o rastrexador de OpenAI — que preguntaba unha e outra vez por robots.txt e comportábase de forma totalmente correcta.

Os aspectos de seguridade en detalle

1. A detección do proxy — o punto máis perigoso de todos

Se Odoo funciona detrás dun proxy inverso e proxy_mode está mal configurado, o módulo ve en cada solicitude o mesmo enderezo: o do proxy. Un bloqueo excluiría entón a todos os visitantes ao mesmo tempo.

Por iso Web RBL comproba antes de cada bloqueo se a determinación do enderezo é fiable. Esixe proxy_mode xunto con unha cabeceira de reenvío, négase a traballar se chega unha solicitude reenviada sen proxy_mode e négase igualmente se hai máis dun proxy intermedio. Na dúbida, non se bloquea.

2. Nunca as redes propias

Os intervalos de enderezos privados, loopback, link-local e CGNAT están excluídos de forma fixa. En ningún caso poden acabar na lista, nin sequera a man. O mesmo vale para as listas alleas: os intervalos privados e reservados, así como as redes absurdamente grandes, descártanse ao importalas.

3. Un erro propio non debe levar consigo a páxina web

Toda a comprobación execútase dentro dunha protección que captura calquera erro. O que saia mal aquí rexístrase, e a solicitude segue o seu curso sen cambios. Un módulo de protección que, ante un erro propio, leva consigo a páxina web é peor ca ningún. Ademais, todas as consultas na ruta da solicitude execútanse sen o idioma do navegador do visitante e sen ordenar por campos traducidos — un visitante cun idioma non instalado non pode facer fracasar a comprobación.

4. Observar antes de bloquear

Tras a instalación, o bloqueo de enderezos listados nas solicitudes ordinarias está desactivado. As sondas rexéitanse e rexístranse, todo o demais pasa. Así pódese ver durante uns días quen acaba realmente na lista antes de que alguén sexa excluído. O mesmo vale para a detección de comportamento, as listas de ameazas e as regras por país: primeiro comunicar, bloquear despois de observar.

5. Patróns estreitos en vez de redes amplas

Un visitante recoñecido por erro é máis caro ca unha sonda pasada por alto. Por iso cada patrón leva o seu nivel, e é modificable por patrón. Unha extensión de ficheiro soa raramente chega: con .php hai 14.012 sondas reais fronte a un puñado de ligazóns antigas, con .asp a proporción é á inversa. Estas decisións deben medirse, non estimarse.

6. Unha liberación feita a man permanece

Quen libera un enderezo tiña un motivo. Outro acerto non anula esa decisión en silencio.

7. A lista está protexida, pero non é un segredo

O punto final esixe un token e, sen token válido, responde con 404, non con 403 — así nin sequera se confirma a existencia do enderezo. A comparación execútase en tempo constante. A lista en si non contén nada confidencial: consiste en enderezos que viñeron petar á nosa porta por si mesmos.

8. Sen segredos no rexistro

Nos inicios de sesión fallidos anótase o nome de usuario intentado, nunca o contrasinal. No xestor de bases de datos, dos valores transmitidos non se le nada: alí o contrasinal mestre figura en primeiro lugar, e unha entrada nunha lista de bloqueo acaba en cada copia de seguridade da base de datos. A clave de licenza de GeoLite2 figura só no parámetro do sistema e en ningunha liña de rexistro.

9. O cebo non revela nada aproveitable

Opcionalmente, Web RBL responde ás sondas con contido inventado que contén un valor canario inequívoco. Quen consulte despois ese valor leu a resposta falsificada e actuou en consecuencia — unha falsa alarma queda así excluída. Os cebos non conteñen datos aproveitables, nin rutas reais, nin datos de acceso válidos. Esta función entrégase desactivada, porque cambia o comportamento de xeito visible desde o exterior.

O que o módulo non pode facer

Non substitúe un firewall nin un Web Application Firewall. Detecta patróns de sondaxe coñecidos en rutas, inicios de sesión fallidos e comportamento sospeitoso — non ataques a formularios nin intentos de inxección en parámetros.

Ademais, só ve o que volve por HTTP. O que un atacante faga con accesos roubados a bases de datos ou a caixas de correo permanece invisible — e precisamente por iso os valores canario son rutas e non datos de acceso.

E non substitúe o coidado: un módulo que rexeita sondas .env non fai inofensivo un ficheiro .env entregado por descoido.

Dispoñibilidade

Web RBL está dispoñible publicamente baixo a AGPL-3 e funciona en produción connosco en cinco páxinas web:

github.com/Alex0176/odoo-web-rbl

O módulo require Odoo 19 Community e non ten dependencias aparte de base e web. A conexión con tícketes é opcional e non precisa ningún sistema de tícketes concreto; sen un, simplemente non pasa nada. O país de orixe precisa a base de datos gratuíta GeoLite2 de MaxMind; se falta, o campo queda baleiro e todo o demais funciona sen cambios.

Para saber máis: como Web RBL encaixa nunha arquitectura de seguridade completa -- xunto con firewall, autenticación de dous factores e permisos, incluída unha guía paso a paso: Combinar correctamente a arquitectura de seguridade de Odoo 19.

Estaremos encantados de recibir preguntas, comentarios e informes de erros — preferiblemente como issue en GitHub.