Código fuente: github.com/Alex0176/odoo-web-rbl — AGPL-3, de libre uso.
Quien tiene un servidor Odoo en Internet recibe visitas. No de vez en cuando, sino sin parar. Durante diecisiete días registramos y analizamos 731.297 solicitudes en nuestros cinco sitios web. 110.511 de ellas no procedían de visitantes, sino de búsquedas automatizadas de vulnerabilidades, credenciales de acceso y archivos de configuración.
Este artículo presenta Web RBL, un módulo de código abierto para Odoo 19 Community que detecta, evalúa, registra y rechaza ese tráfico, y publica la lista de bloqueo como una lista RBL, en un formato que los cortafuegos y proxies inversos pueden leer directamente. Todas las cifras proceden del funcionamiento en producción.
Qué puede hacer el módulo: resumen de funciones
| Función | Qué hace | Configuración de fábrica |
|---|---|---|
| Detección de patrones | Detecta sondeos por la ruta y la extensión: .env, .git, archivos de configuración, claves de servicios en la nube, instrucciones de compilación CI/CD, WordPress, PHP, recorrido de directorios, gestores de bases de datos, GraphQL, ejecución de comandos mediante /api/fs/exec e interfaces similares | bloquear |
| Tres modos por patrón | bloquear, contar o notificar: configurable para cada patrón sin tocar el código | por patrón |
| Umbrales | Número de coincidencias de un mismo patrón necesario para bloquear; diez para los inicios de sesión | 10 para el inicio de sesión |
| Protección del inicio de sesión | Intentos fallidos de inicio de sesión mediante el formulario y XML-RPC/JSON-RPC, comprobaciones de sesión fallidas y accesos al gestor de bases de datos: registrados en la base de datos, no en la memoria RAM | activado |
| Detección de bots en el inicio de sesión | Quien ignora el aviso de espera tras diez intentos fallidos y sigue intentándolo queda bloqueado de inmediato | bloquear |
| Detección por comportamiento | Direcciones que generan veinte páginas de error en cinco minutos y apenas acceden a páginas válidas: prueban rutas al azar en lugar de leer | notificar |
| Puntuación de 0 a 100 | ¿Qué certeza hay de que detrás de la dirección se encuentra un atacante? Se calcula a partir de la gravedad del patrón, la cantidad de patrones distintos, los días con actividad sospechosa, los dominios afectados y el número de coincidencias, con una justificación en lenguaje claro | activado |
| Bloqueo del inicio de sesión según la puntuación | A partir de una puntuación configurable se impide iniciar sesión, pero el sitio web sigue siendo accesible para su lectura | a partir de 40 |
| Sospecha de robo de credenciales | Un inicio de sesión correcto desde una dirección sospechosa se notifica y, si se desea, se asigna como tarea: una vez por dirección y día | activado |
| Listas de amenazas | Nodos de salida de Tor, Spamhaus DROP, FireHOL Level 1 y blocklist.de preconfigurados; se puede añadir cualquier otra lista RBL mediante su dirección, con actualización diaria y un modo propio para cada lista | notificar |
| Sin acceso al inicio de sesión | El cuarto modo para listas y países: se puede leer el sitio web, pero el formulario de inicio de sesión y las interfaces quedan cerrados; una respuesta adecuada para Tor | Opcional |
| País de origen | País de cada coincidencia y dirección mediante GeoLite2; el módulo actualiza la base de datos automáticamente con una clave de licencia gratuita | mostrar |
| Reglas por país | Bloquear, impedir el acceso al inicio de sesión, notificar o permitir expresamente: configurable por país, sin opción predeterminada de forma deliberada | ninguna |
| Errores de configuración | Se detectan QNAP, Synology, Exchange-Autodiscover y ActiveSync, WebDAV/CalDAV/CardDAV; nunca se bloquean y se añaden a una lista de trabajo con el problema detectado y el dominio afectado | notificar |
| Un ticket por dirección | Si se desea, un problema detectado genera un ticket: solo uno por dirección; si ya hay uno cerrado, se reabre en lugar de crear un duplicado | desactivado |
| Páginas legales y recolectores | La ruta canónica del aviso legal permanece siempre accesible; se detectan los intentos automatizados de probar otras variantes del nombre y, si se desea, se bloquean | notificar |
| Lista de permitidos | Direcciones y redes que nunca se bloquean; se actualiza a diario a partir del cortafuegos (extremos remotos de VPN) y de los rangos de direcciones publicados por Googlebot y Bingbot | activado |
| Asignación al cliente | Una coincidencia procedente de la red de un cliente se le asigna a ese cliente según la lista de permitidos, nunca mediante suposiciones manuales | activado |
| Dominio e identificador por coincidencia | A qué sitio web se ha accedido y con qué User-Agent: ninguno de los dos datos figura en el registro de acceso | activado |
| Análisis | Gráfico y tabla dinámica de todas las coincidencias: por patrón, día, dominio, país y dirección | activado |
| Señuelos | Los sondeos reciben respuestas inventadas con un valor canario; quien lo solicita después ha leído esas respuestas | desactivado |
| Publicación de la RBL | La lista de bloqueo como lista simple de direcciones o en JSON, disponible en una dirección propia protegida con un token: para HAProxy, OPNsense y cualquier cortafuegos que lea listas desde una URL | activado |
Todo lo que viene configurado como notificar, desactivado u Opcional está así por una razón: quien active un bloqueo debe hacerlo después de observar durante unos días a quién afectaría, no porque venga así de fábrica.
El análisis: coincidencias por patrón durante siete días. La barra más alta corresponde a la búsqueda de archivos .env.
Listas RBL: una forma estandarizada de distribuir bloqueos
RBL significa Real-time Blackhole List. El término procede del mundo del correo, donde Spamhaus y otros publican desde los años noventa listas de direcciones de remitentes maliciosos. El principio es sencillísimo y precisamente por eso está tan extendido: una dirección por línea, accesible por HTTP, recargada con regularidad. Sin un formato que haya que analizar primero, sin una interfaz para la que se necesite una herramienta.
Prácticamente cualquier cortafuegos o proxy inverso puede leer una lista de este tipo y generar reglas a partir de ella. Cada fabricante lo llama de una manera, pero el mecanismo es el mismo:
- OPNsense y pfSense — URL Table Alias: cargar una lista de direcciones mediante HTTP, utilizarla como alias en las reglas del cortafuegos y actualizarla cada hora o cada día
- HAProxy — archivos ACL y Maps:
src -f sperrliste.txten una reglahttp-request deny, recargable mediante la API de ejecución sin reiniciar - nginx — módulo geo con un archivo de direcciones incluido, o directivas
denydesde un archivoincludegenerado - Fortinet FortiGate — External Block List o Threat Feed: una URL de la que el cortafuegos obtiene una lista de IP para utilizarla en sus políticas
- Palo Alto Networks — External Dynamic List (EDL): el mismo principio, como un tipo de objeto propio dentro de las políticas de seguridad
- Check Point — Custom Intelligence Feeds e IP Block Lists mediante una URL
- Cisco Secure Firewall (Firepower) — Security Intelligence Feeds con fuentes de listas propias
- Sophos Firewall — Third-Party Threat Feeds: listas de direcciones obtenidas de una URL como fuente para las reglas de bloqueo
- Juniper SRX — Dynamic Address Entries a partir de fuentes de datos
- MikroTik RouterOS — Address Lists, alimentadas desde una URL mediante un script y
fetch - CrowdSec — listas propias como fuente para los bouncers en cualquier sistema compatible
Web RBL ofrece su lista de bloqueo precisamente en este formato. El cortafuegos descarta los paquetes antes de que lleguen al servidor web y, con ellos, cualquier otro intento desde la misma dirección, por ejemplo, contra el servidor de correo o la pasarela VPN.
En ambos sentidos, pero en el lugar adecuado
También funciona a la inversa: en Web RBL se puede añadir cualquier lista RBL: una URL, un nivel y listo. Los nodos de salida de Tor, Spamhaus DROP, FireHOL y blocklist.de vienen preconfigurados; añadir otras listas solo requiere tres clics. El módulo descompone cada lista en rangos de direcciones y comprueba cada solicitud frente a ellos en unos pocos microsegundos.
Aun así, tiene más sentido utilizar las listas de terceros en el cortafuegos situado delante del servidor. Por tres razones. El cortafuegos ve todos los servicios, no solo HTTP: una dirección de la lista de Spamhaus tampoco debería poder acceder al servidor de correo ni a la VPN. Descarta los paquetes antes incluso de que se establezca una conexión, sin consumir recursos del servidor de aplicaciones. Y es donde ya se mantienen estas listas; una segunda copia en la aplicación supone otro lugar en el que pueden quedar desactualizadas.
Entonces, ¿para qué sirven las listas dentro del módulo? Para lo que un cortafuegos no puede hacer. El cortafuegos no entiende de formularios de inicio de sesión. Web RBL puede denegar el acceso al inicio de sesión a una dirección de la lista de Tor y seguir mostrando la página web: quien quiera leer de forma anónima debe poder hacerlo; quien quiera probar contraseñas de forma anónima, no. También puede notificar como sospechoso un inicio de sesión correcto desde una dirección incluida en una lista. Ambas funciones necesitan que la lista esté allí donde se inicia la sesión.
Puntuaciones en lugar de intuiciones
Una dirección que ha solicitado /wp-login.php una vez no es lo mismo que otra que, durante dos días, ha recorrido tres dominios con cinco patrones distintos. Web RBL lo convierte en una puntuación de 0 a 100, a partir de lo que ha observado por sí mismo, sin servicios de terceros ni consultas externas.
Una entrada: 99 coincidencias, una puntuación de 84 y la justificación en lenguaje claro: patrón de máxima gravedad, cinco patrones graves distintos, dos días con actividad sospechosa y más de veinte coincidencias.
La puntuación determina dos cosas. A partir de un valor configurable, se prohíbe iniciar sesión: la página web sigue siendo accesible para su lectura, pero quien ya ha buscado credenciales no tiene ocasión de probar las que haya encontrado. Además, se notifica cualquier inicio de sesión correcto desde una dirección con puntuación: en ese caso, alguien ha dejado de adivinar y ha demostrado que conocía las credenciales. Puede que el usuario legítimo estuviera de viaje o que las credenciales hayan caído en otras manos. El módulo no lo decide: lo pone en conocimiento de alguien que pueda preguntar. La contraseña en sí no se toca en ningún momento.
La lista de bloqueo, filtrada por puntuaciones de 40 o más: número de coincidencias, días con actividad sospechosa, dominios afectados y última ruta por dirección.
Qué protege Web RBL: su protección en detalle
1. Las credenciales no quedan al descubierto
La categoría de ataques más numerosa de las medidas no busca vulnerabilidades en Odoo, sino datos secretos olvidados. En diecisiete días:
- 57.721 solicitudes de archivos
.env, que contienen contraseñas de bases de datos, claves de API y secretos de sesión - 5.535 solicitudes de archivos de configuración
- 4.388 solicitudes de credenciales de la nube:
credentials.json,service-account.json,firebase-adminsdk.json,rclone.conf,.git-credentials - 2.811 solicitudes de directorios
.git— quien encuentra uno descarga el código fuente completo con todo su historial - 1.907 solicitudes de instrucciones de compilación como
.github/workflows/deploy.ymlo.gitlab-ci.yml, que contienen registros y nombres de claves
Lo decisivo no es el número de solicitudes, sino el de direcciones distintas: las solicitudes de /credentials.json procedían de 98 direcciones; las de /.git-credentials, de 92. No se trata de un único escáner, sino de un repertorio estándar que se ejecuta simultáneamente en todo el mundo.
2. Los intentos de inicio de sesión quedan en nada, de forma permanente
Odoo incorpora su propio mecanismo para frenar los intentos sucesivos de adivinar contraseñas. Tiene tres limitaciones documentadas en el propio código fuente de Odoo: el contador se guarda en la memoria RAM del proceso de trabajo y se reinicia cada vez que este arranca; solo introduce una demora, sin bloquear; y únicamente cuenta los intentos que llegan a la comprobación de la contraseña.
Web RBL interviene en los mismos puntos, pero guarda los datos en la base de datos. Así:
- El recuento se conserva tras cada reinicio y es común a todos los procesos de trabajo
- Se registran ambas vías: el formulario de inicio de sesión
/web/loginy las interfaces/xmlrpc/2/commony/jsonrpc - También se registran los intentos que nunca llegan a la comprobación de la contraseña, como los inicios de sesión sin un identificador de sesión válido
- También se contabilizan los accesos fallidos al gestor de bases de datos, el intento de inicio de sesión más grave de todos
El umbral para los inicios de sesión está fijado en diez, y la razón se basa en una medición: de los nueve inicios de sesión fallidos registrados en diecisiete días, la mayoría procedían de clientes que estaban configurando el acceso en otro dispositivo y habían introducido un dominio incorrecto; en un caso, el suyo propio, pero con un guion en lugar de un punto. Bloquear al primer intento fallido no habría afectado a atacantes, sino a clientes durante la configuración.
En cambio, quien sigue insistiendo después de que el servidor haya respondido «espere un momento» queda bloqueado de inmediato. Una persona lee ese mensaje y espera; quien lo ignora es un programa. Un patrón específico con umbral cero detecta precisamente este caso y no puede afectar a ningún compañero: solo llega a ese punto quien ya ha acumulado diez intentos fallidos y sigue insistiendo.
3. El ataque deja de consumir recursos del servidor
Antes de instalar el módulo, un sondeo de una ruta como /@fs/../../.env resultaba costoso: Odoo busca la página de error, la renderiza, tropieza con los segmentos de puntos al construir la dirección y vuelve a fallar al generar la página de error de la propia página de error. Dos trazas de pila por sondeo. En diecisiete días se registraron 28.401 errores de este tipo, además de 9.467 errores derivados.
Web RBL interviene en ir.http._match, es decir, antes del enrutamiento. La respuesta se genera sin plantilla, sin accesos a la base de datos más allá de la comprobación de bloqueo y sin ninguna línea de registro. La comprobación frente a la lista de permitidos, las listas de amenazas y las reglas por país se realiza desde la caché mediante rangos de direcciones ordenados: unos pocos microsegundos, incluso con más de treinta mil rangos.
4. El cortafuegos expulsa al atacante antes de que llegue
La lista de bloqueo se publica como lista RBL que HAProxy y OPNsense leen directamente. Así, el atacante ya no llega siquiera al servidor web — ni a ningún otro servicio del mismo host. Un acceso detectado una vez como malicioso protege así retroactivamente a toda la máquina.
Tres niveles: bloquear, contabilizar y notificar
No toda solicitud a un recurso inexistente es un ataque. Por eso, Web RBL distingue tres niveles que se pueden cambiar para cada patrón sin tocar el código.
| Nivel | Solicitud que lo activa | Consecuencia para la dirección |
|---|---|---|
| bloquear | se rechaza | bloqueada durante 24 horas; de forma permanente tras tres días con actividad sospechosa |
| contabilizar | se permite | solo se registra, sin bloqueo |
| notificar | se permite | se registra con una descripción del hallazgo; nunca se bloquea |
Para las listas de amenazas y los países existe un cuarto nivel: sin acceso al inicio de sesión. La página web sigue siendo accesible para su lectura, pero el formulario de inicio de sesión y las interfaces quedan cerrados. Es el término medio para todo lo que resulta sospechoso sin ser necesariamente malicioso: Tor, un rango de un centro de datos o un país en el que no hay clientes.
Qué ataques se detectan
Todos los patrones se han comprobado con tráfico real. El número de direcciones distintas se muestra al lado de forma deliberada: permite ver si un patrón detecta un único escáner o una práctica extendida.
| Categoría de ataque | Solicitudes | Direcciones |
|---|---|---|
Extracción de archivos .env | 57.721 | 223 |
| Sondeos de PHP | 12.237 | 256 |
| Recorrido de directorios con un objetivo de valor | 10.046 | 64 |
| Archivos de configuración | 5.535 | 114 |
| Claves de acceso a la nube | 4.388 | 152 |
| Sondeos de WordPress | 3.366 | 385 |
Extracción de .git | 2.811 | 255 |
| Reconocimiento de Odoo (gestor de bases de datos, consulta de versión) | 2.500 | 213 |
Cadenas de herramientas de IA y ejecución de comandos (/mcp, /api/fs/exec) | 2.450 | 74 |
| Instrucciones de compilación (CI/CD) | 1.907 | 88 |
| Puntos de acceso GraphQL | 1.878 | 71 |
La categoría más reciente merece especial atención. Se solicitó /api/fs/exec 369 veces desde 54 direcciones distintas: no se trata de un acceso de lectura, sino de un intento de ejecutar comandos. Estos objetivos no existían hace dos años; proceden de interfaces de nuevas herramientas de IA y colas de tareas. Quien centre su defensa únicamente en WordPress y PHP no detectará nada de esto. Por eso, esta categoría tiene un peso elevado en la puntuación.
Listas de amenazas y país de origen
Cuatro listas, 32.851 rangos de direcciones, todas en modo «solo notificar». Para añadir otra lista basta con una dirección y un nivel.
Una lista de terceros es una afirmación que hace otra persona, por motivos que desconocemos, sobre un tráfico que nunca hemos visto. Puede ser incorrecta, estar desactualizada o haberse concebido para otro fin: blocklist.de recopila principalmente direcciones que han intentado adivinar credenciales de SSH en otros sistemas, y eso dice poco sobre un servidor web. Por eso, Web RBL mantiene las listas de terceros separadas de su propia lista de bloqueo, y por eso el valor predeterminado es notificar. Además, la lista de permitidos propia siempre tiene prioridad: un cliente al que conocemos pesa más que la valoración de un tercero.
El país de origen figura en cada coincidencia y en cada dirección. Es indispensable para evaluar la actividad: un intento de inicio de sesión desde el propio país a las diez de la mañana no es lo mismo que otro desde un país sin un solo cliente. Sirve de poco para aplicar bloqueos indiscriminados, como demuestran nuestros propios datos: los atacantes de nuestra lista procedían principalmente de rangos de la nube en Bélgica, Finlandia y los Países Bajos. Un bloqueo de todo lo que quedara fuera del ámbito germanohablante no les habría afectado; en cambio, sí habría afectado a empleados de vacaciones y a clientes en viajes de negocios.
Las reglas por país se entregan vacías y la vista explica el motivo.
Notificar las configuraciones incorrectas en lugar de bloquear
El caso más frecuente en el tráfico real no es un ataque ni un visitante, sino software que funciona mal y confunde el servidor web con otro servicio:
- 1.367 solicitudes a la interfaz web de un NAS QNAP: un cliente de sincronización cuyo destino ya no es correcto. Una sola conexión de origen lo intentó 962 veces.
- 65 consultas de Autodiscover: una instancia de Outlook que confunde el dominio web con su servidor Exchange
Estas direcciones nunca se bloquean. Un bloqueo no soluciona el fallo, sino que lo oculta y perjudica a quien ya tiene su dispositivo mal configurado. En su lugar, se crea una entrada con una descripción del hallazgo y los dominios afectados, que puede convertirse automáticamente en un ticket si se desea: exactamente uno por dirección. Si se cierra y la dirección vuelve a mostrar actividad sospechosa, se reabre el mismo ticket en lugar de crear otro.
Se detectan QNAP, Synology, Exchange-Autodiscover, ActiveSync y clientes WebDAV, CalDAV y CardDAV. Los patrones especifican nombres de archivo y directorios exactos, nunca simples extensiones: en el mismo directorio /cgi-bin/, las solicitudes de sincronización inofensivas conviven con sondeos clásicos como printenv.pl.
La lista de permitidos: direcciones que nunca se bloquean
El coste de un error no es el mismo para todas las direcciones. En el caso de un escáner de un centro de datos, un falso positivo no cuesta nada. En el extremo remoto de un túnel entre sedes, cuesta la conexión de toda una sede.
Por eso existe una segunda lista que tiene prioridad sobre la primera: direcciones y redes que nunca se bloquean. Esto no silencia nada: las direcciones de esa lista se siguen comprobando y registrando; solo se elimina la consecuencia. Esa es la diferencia respecto a una excepción en el cortafuegos: aquella impide ver; esta solo aporta paciencia.
Se actualiza a diario a partir de dos fuentes: el propio cortafuegos, con todos los extremos remotos de las VPN, para que un túnel recién configurado no dependa de que alguien se acuerde de la lista de bloqueo; y los rangos de direcciones publicados por Google y Microsoft para sus rastreadores. Solo así se puede distinguir un Googlebot auténtico de un escáner que se hace pasar por él. Los motores de búsqueda nunca deben bloquearse: quien les cierra el paso retira su página de la indexación sin vuelta atrás.
Se aplica una regla más importante que la propia comparación: una respuesta vacía nunca borra nada. Si la fuente no responde, devuelve una respuesta vacía o resulta incomprensible, la lista permanece intacta. Una lista de permitidos que se vacía sola ante un fallo deja fuera de servicio todos los túneles en el peor momento posible.
Si una entrada de la lista de permitidos tiene un cliente asociado, cada coincidencia procedente de su red se le atribuye a ese cliente. Así, una configuración incorrecta tiene de inmediato una persona de contacto, sin que nadie tenga que buscar a quién pertenecen las direcciones.
Información legal obligatoria y recopiladores automatizados de datos
El aviso legal no es una página cualquiera. Debe seguir siendo accesible para las personas, porque bloquearlo provoca precisamente el incumplimiento que busca un recopilador. Al mismo tiempo, es la página que contiene el nombre y la dirección y, por tanto, el objetivo de la recopilación automatizada.
Durante la oleada de requerimientos legales en Austria por el uso de fuentes de Google integradas, los registros mostraron que las reclamaciones no procedían de visitas individuales, sino de un barrido automatizado: distintos hosts sin relación entre sí, visitados con milisegundos de diferencia.
Web RBL lo resuelve reduciendo el nivel en lugar de crear una excepción. La ruta canónica /impressum no coincide con ningún patrón y siempre permanece accesible. Las variantes ajenas, como /impressum.php, que no pueden existir en una web de Odoo, se notifican; quien no quiera aceptar la recopilación automatizada puede cambiar un parámetro. sitemap y robots quedan excluidos y no se pueden bloquear en ningún caso: no contienen datos personales y obtenerlos forma parte del trabajo de cualquier rastreador de motores de búsqueda.
Dominio e identificador: lo que falta en el registro de accesos
El registro de accesos de werkzeug no guarda ni el host al que se dirige la solicitud ni el identificador del cliente que la realiza. Odoo recibe ambos, por supuesto: sin el host no podría seleccionar la web correcta cuando aloja varias. Sin embargo, después no es posible consultarlos.
Web RBL guarda ambos datos en cada coincidencia. Esto responde a dos preguntas que, de otro modo, quedarían sin respuesta: a qué web se dirige una configuración incorrecta y, por tanto, a qué cliente pertenece el dominio; y si una dirección visita una web o todas. El acceso a varios dominios sin relación entre sí desde una misma dirección es la señal de un barrido indiscriminado y aumenta la puntuación.
Un análisis de una de nuestras webs demostró la importancia del identificador: más del setenta por ciento de todo el tráfico procedía de un único cliente automatizado, distribuido entre más de cien direcciones. Sin el identificador habría parecido un extractor de datos distribuido. Era GPTBot, el rastreador de OpenAI: solicitaba repetidamente robots.txt y se comportaba de forma totalmente correcta.
Los aspectos de seguridad en detalle
1. La detección del proxy: el punto más peligroso
Si Odoo se ejecuta detrás de un proxy inverso y proxy_mode está mal configurado, el módulo ve la misma dirección en todas las solicitudes: la del proxy. Un bloqueo dejaría entonces sin acceso a todos los visitantes a la vez.
Por eso, antes de cada bloqueo, Web RBL comprueba si la identificación de la dirección es fiable. Exige proxy_mode junto con una cabecera de reenvío, se niega a actuar si llega una solicitud reenviada sin proxy_mode y hace lo mismo cuando hay más de un proxy intermedio. En caso de duda, no se bloquea.
2. Las redes propias, nunca
Los rangos de direcciones privadas, loopback, link-local y CGNAT quedan excluidos de forma permanente. No pueden acabar en la lista bajo ninguna circunstancia, ni siquiera de forma manual. Lo mismo se aplica a las listas de terceros: los rangos privados y reservados, así como las redes desmesuradamente grandes, se descartan al importarlos.
3. Un fallo del módulo no debe hacer caer la web
Toda la comprobación se ejecuta dentro de un mecanismo de protección que captura cualquier error. Si algo falla, se registra y la solicitud continúa sin cambios. Un módulo de protección que hace caer la web por un fallo propio es peor que no tener ninguno. Además, todas las consultas realizadas durante el procesamiento de la solicitud se ejecutan sin utilizar el idioma del navegador del visitante ni ordenar por campos traducidos: un visitante cuyo idioma no esté instalado no debe provocar que falle la comprobación.
4. Observar antes de bloquear
Tras la instalación, el bloqueo de las direcciones incluidas en la lista para las solicitudes normales está desactivado. Los sondeos se rechazan y se registran; todo lo demás se permite. Así se puede observar durante unos días quién acaba realmente en la lista antes de bloquear a nadie. Lo mismo se aplica a la detección de comportamiento, las listas de amenazas y las reglas por país: primero notificar; bloquear después de revisar.
5. Patrones precisos en lugar de filtros amplios
Un visitante clasificado por error sale más caro que un sondeo que pasa desapercibido. Por eso, cada patrón tiene su propio nivel, que se puede cambiar individualmente. Una extensión de archivo rara vez basta: para .php hay 14.012 sondeos reales frente a un puñado de enlaces antiguos; para .asp, la proporción es la contraria. Estas decisiones deben basarse en mediciones, no en estimaciones.
6. Una autorización manual se mantiene
Quien autoriza una dirección tiene sus motivos. Una nueva coincidencia no anula esa decisión de forma silenciosa.
7. La lista está protegida, pero no es secreta
El punto de acceso exige un token y, si no recibe uno válido, responde con 404, no con 403, para no confirmar siquiera la existencia de la dirección. La comparación se realiza en tiempo constante. La lista en sí no contiene información confidencial: se compone de direcciones que han contactado con nosotros por iniciativa propia.
8. Ningún secreto en los registros
En los inicios de sesión fallidos se anota el nombre de usuario utilizado, nunca la contraseña. En el gestor de bases de datos no se lee ninguno de los valores enviados: el primero es la contraseña maestra, y una entrada en una lista de bloqueo acaba en cada copia de seguridad de la base de datos. La clave de licencia de GeoLite2 solo se guarda en el parámetro del sistema y no aparece en ninguna línea de registro.
9. El señuelo no revela información aprovechable
Opcionalmente, Web RBL responde a los sondeos con contenido inventado que incluye un valor canario único. Quien solicita ese valor más adelante ha leído la respuesta falsa y ha actuado en consecuencia; en ese caso, queda descartada una falsa alarma. Los señuelos no contienen información aprovechable, rutas reales ni credenciales válidas. Esta función viene desactivada de fábrica, porque cambia el comportamiento del sistema de forma visible desde el exterior.
Qué no puede hacer el módulo
No sustituye a un cortafuegos ni a un cortafuegos de aplicaciones web. Detecta patrones conocidos de sondeo en las rutas, intentos fallidos de inicio de sesión y comportamientos sospechosos, pero no ataques a formularios ni intentos de inyección en parámetros.
Además, solo ve lo que vuelve a través de HTTP. Lo que haga un atacante con credenciales robadas de bases de datos o buzones queda fuera de su alcance; precisamente por eso, los valores canario son rutas y no credenciales.
Tampoco sustituye a una gestión cuidadosa: que un módulo rechace los sondeos de .env no hace que un archivo .env expuesto por error deje de ser peligroso.
Disponibilidad
Web RBL está disponible públicamente bajo la licencia AGPL-3 y lo utilizamos en producción en cinco sitios web:
github.com/Alex0176/odoo-web-rbl
El módulo requiere Odoo 19 Community y no tiene más dependencias que base y web. La integración con un sistema de tickets es opcional y no exige ningún sistema concreto; si no hay ninguno, simplemente no se realiza ninguna acción. Para determinar el país de origen se necesita la base de datos gratuita GeoLite2 de MaxMind; si no está disponible, el campo queda vacío y todo lo demás sigue funcionando igual.
Para saber más: Cómo encaja Web RBL en una arquitectura de seguridad completa, junto con el cortafuegos, la autenticación de dos factores y los permisos, con una guía paso a paso: Cómo combinar correctamente las capas de seguridad de Odoo 19.
Estaremos encantados de recibir preguntas, comentarios e informes de errores, preferiblemente mediante una incidencia en GitHub.