Odoo 19 Community: Web RBL – lista de bloqueio para tráfego de ataque nos próprios sites

Código-fonte: github.com/Alex0176/odoo-web-rbl — AGPL-3, de utilização livre.

Quem opera um servidor Odoo na Internet recebe visitas. Não ocasionalmente, mas sem interrupção. Ao longo de dezassete dias, registámos e avaliámos nos nossos cinco sites 731.297 pedidos. 110.511 destes não eram visitantes, mas pesquisas automatizadas de vulnerabilidades, credenciais de acesso e ficheiros de configuração.

Esta publicação descreve o Web RBL, um módulo open source para o Odoo 19 Community, que deteta, avalia, regista e rejeita este tráfego — e que publica a lista de bloqueio como lista RBL, ou seja, no formato que firewalls e reverse proxies lêem diretamente. Todos os números provêm de operação real.

O que o módulo faz — as funções em resumo

Função	O que faz	Predefinição
Deteção de padrões	Deteta sondagens por caminho e extensão: .env, .git, ficheiros de configuração, chaves cloud, instruções de compilação CI/CD, WordPress, PHP, path traversal, gestores de bases de dados, GraphQL, execução de comandos através de /api/fs/exec e interfaces semelhantes	bloquear
Três níveis por padrão	bloquear, contar ou reportar — configurável por padrão, sem código	por padrão
Limiares	Quantas ocorrências do mesmo padrão antes de bloquear; para inícios de sessão, dez	10 no início de sessão
Defesa de início de sessão	Inícios de sessão falhados através do formulário e de XML-RPC/JSON-RPC, verificações de sessão falhadas, acessos ao gestor de bases de dados — na base de dados, não na memória principal	ativo
Deteção de bots no início de sessão	Quem ignora a mensagem de espera após dez tentativas falhadas e continua a bater à porta é bloqueado de imediato	bloquear
Deteção de comportamento	Endereços que, em cinco minutos, geram vinte páginas de erro e quase nenhuma página válida — ou seja, adivinham em vez de ler	reportar
Pontuação 0–100	Qual é a certeza de que, por trás do endereço, está um atacante? Com base na gravidade do padrão, no número de padrões distintos, em dias invulgares, nos domínios afetados e no número de ocorrências — com justificação em linguagem clara	ativo
Bloqueio de início de sessão por pontuação	A partir de uma pontuação configurável, o início de sessão fica proibido, o site continua legível	a partir de 40
Suspeita de credenciais de acesso roubadas	Um início de sessão bem-sucedido a partir de um endereço suspeito é comunicado e, se desejado, atribuído como tarefa — uma vez por endereço e por dia	ativo
Listas de ameaças	Nós de saída Tor, Spamhaus DROP, FireHOL Level 1 e blocklist.de pré-configurados; qualquer outra lista RBL pode ser registada através do seu endereço, comparação diária, nível próprio por lista	reportar
Sem acesso ao início de sessão	O quarto nível para listas e países: o sítio web continua legível, o formulário de início de sessão e as interfaces ficam fechados — a resposta certa para o Tor	Opção
País de origem	País por ocorrência e endereço através do GeoLite2; o módulo mantém a base de dados atualizada por si, com uma chave de licença gratuita	mostrar
Regras por país	Bloquear, sem acesso ao início de sessão, comunicar ou expressamente liberado — por país, deliberadamente sem predefinição	nenhuma
Configurações incorretas	QNAP, Synology, Exchange Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV são reconhecidos, nunca bloqueados e colocados numa lista de trabalho com o diagnóstico e o domínio afetado	reportar
Pedido de assistência por endereço	De um diagnóstico nasce, se desejado, um pedido de assistência — exatamente um por endereço; um pedido fechado é reaberto em vez de duplicado	desligado
Páginas obrigatórias e recolhedores	O caminho canónico do aviso legal permanece sempre acessível; a tentativa automática de grafias alheias é detetada e, se desejado, bloqueada	reportar
Lista de exceções	Endereços e redes que nunca são bloqueados; preenche-se diariamente a partir da firewall (extremidades de VPN) e dos intervalos de endereços publicados do Googlebot e do Bingbot	ativo
Atribuição ao cliente	Uma ocorrência proveniente da rede de um cliente é-lhe atribuída — a partir da lista de exceções, nunca adivinhada à mão	ativo
Domínio e identificação por ocorrência	Que sítio web foi acedido e com que User-Agent — ambos faltam no registo de acessos	ativo
Análise	Gráfico e tabela dinâmica sobre todas as ocorrências: por padrão, dia, domínio, país, endereço	ativo
Isco	As sondas recebem respostas inventadas com um valor-canário; quem o consultar mais tarde, leu-as	desligado
Disponibilização da RBL	A lista de bloqueio como simples lista de endereços ou JSON, num endereço próprio protegido por token — para HAProxy, OPNsense e qualquer firewall que leia listas de URL	ativo

Tudo o que é entregue como comunicar, desligado ou opção é assim de propósito: quem ativa um bloqueio deve fazê-lo porque observou durante alguns dias quem é apanhado — não porque a predefinição assim o quis.

A análise: ocorrências por padrão ao longo de sete dias. A barra mais alta é a procura de ficheiros .env.

Listas RBL: uma forma normalizada de distribuir bloqueios

RBL significa Real-time Blackhole List. O termo vem do mundo do correio eletrónico, onde a Spamhaus e outros publicam, desde os anos noventa, listas de endereços de remetentes maliciosos. O princípio é extremamente simples e é precisamente por isso que está tão difundido: um endereço por linha, acessível por HTTP, recarregado regularmente. Nenhum formato que seja preciso primeiro analisar, nenhuma interface para a qual seja necessária uma ferramenta.

Praticamente qualquer firewall e qualquer proxy inverso consegue ler uma lista destas e criar regras a partir dela. Os fabricantes dão-lhe nomes diferentes, mas o mecanismo é o mesmo em todo o lado:

• OPNsense e pfSense — URL Table Alias: carregar a lista de endereços por HTTP, usá-la como alias nas regras da firewall, atualização de hora a hora ou diária
• HAProxy — ficheiros ACL e Maps: src -f sperrliste.txt numa regra http-request deny, recarregável em execução através da API de runtime, sem reinício
• nginx — módulo geo com ficheiro de endereços incluído, ou instruções deny a partir de um ficheiro include gerado
• Fortinet FortiGate — External Block List ou Threat Feed: um URL a partir do qual a firewall obtém uma lista de IP e a utiliza nas políticas
• Palo Alto Networks — External Dynamic List (EDL): o mesmo princípio, como tipo de objeto próprio nas políticas de segurança
• Check Point — Custom Intelligence Feeds e IP Block Lists através de um URL
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds com fontes de listas próprias
• Sophos Firewall — Third-Party Threat Feeds: listas de endereços a partir de um URL como fonte para regras de bloqueio
• Juniper SRX — Dynamic Address Entries a partir de feeds
• MikroTik RouterOS — Address Lists, preenchidas por script e fetch a partir de um URL
• CrowdSec — listas próprias como fonte para os bouncers em qualquer sistema suportado

É exatamente neste formato que o Web RBL disponibiliza a sua lista de bloqueio. A firewall descarta os pacotes antes de chegarem ao servidor web — e, com eles, qualquer outra tentativa do mesmo endereço, por exemplo ao servidor de correio ou ao gateway VPN.

Nos dois sentidos, mas no sítio certo

O caminho funciona também no sentido inverso: no Web RBL é possível registar qualquer lista RBL — um URL, um nível, e está feito. Nós de saída Tor, Spamhaus DROP, FireHOL e blocklist.de vêm pré-configurados, outras juntam-se com três cliques. O módulo decompõe cada lista em intervalos de endereços e verifica cada pedido em relação a eles, em poucos microssegundos.

E, no entanto: é mais sensato utilizar listas de terceiros na firewall que está à frente. Por três razões. A firewall vê todos os serviços, não só HTTP — um endereço da lista Spamhaus deve também falhar no servidor de correio e na VPN. Ela descarta ao nível do pacote, antes sequer de se estabelecer uma ligação, e assim não custa nada ao servidor de aplicações. E é o local onde, de qualquer forma, estas listas são mantidas; uma segunda cópia na aplicação é um segundo sítio que pode ficar desatualizado.

Para que servem então as listas no módulo: para aquilo que uma firewall não consegue. Ela não conhece nenhum formulário de início de sessão. O Web RBL pode recusar o acesso ao início de sessão a um endereço da lista Tor e, mesmo assim, entregar o sítio web — quem quer ler anonimamente, pode fazê-lo; quem quer experimentar palavras-passe de forma anónima, não. E pode comunicar como caso suspeito um início de sessão bem-sucedido a partir de um endereço listado. Ambos precisam da lista no local onde o início de sessão acontece.

Avaliação em vez de intuição

Um endereço que perguntou uma vez por /wp-login.php é diferente de um que, ao longo de dois dias, passou com cinco padrões diferentes por três domínios. O Web RBL converte isso numa pontuação de 0 a 100 — a partir do que ele próprio observou, sem serviço externo e sem consultas ao exterior.

Uma entrada: 99 ocorrências, pontuação 84, e a fundamentação em texto simples — padrão mais grave, cinco padrões graves diferentes, dois dias suspeitos, mais de vinte ocorrências.

A pontuação decide duas coisas. A partir de um valor configurável, o início de sessão fica proibido — o sítio web continua legível, mas quem já andou à procura de credenciais não recebe a oportunidade de experimentar as que encontrou. E um início de sessão bem-sucedido a partir de um endereço com pontuação é comunicado: então alguém deixou de adivinhar e passou a saber. Ou o utilizador legítimo estava em viagem, ou as credenciais foram extraviadas — o módulo não decide isso, apresenta o caso a alguém que possa perguntar. A palavra-passe em si nunca é tocada.

A lista de bloqueio, filtrada por pontuação a partir de 40: número de ocorrências, dias suspeitos, domínios afetados e o último caminho por endereço.

O que o Web RBL protege — o efeito de proteção em pormenor

1. As credenciais permanecem por descobrir

A maior classe de ataques medida não procura falhas no Odoo, mas sim segredos esquecidos. Ao longo de dezassete dias:

• 57.721 pedidos de ficheiros .env — aí estão palavras-passe de bases de dados, chaves de API e segredos de sessão
• 5.535 pedidos de ficheiros de configuração
• 4.388 pedidos de credenciais de cloud: credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 pedidos de diretórios .git — quem encontra um, descarrega o código-fonte completo com o histórico
• 1.907 pedidos de instruções de compilação como .github/workflows/deploy.yml ou .gitlab-ci.yml, onde constam registos e nomes de chaves

O decisivo não é o número de pedidos, mas o número de endereços diferentes: /credentials.json veio de 98 endereços, /.git-credentials de 92. Isto não é um scanner isolado, mas um repertório-padrão que corre em todo o mundo ao mesmo tempo.

2. As tentativas de início de sessão caem no vazio — de forma permanente

O Odoo traz um travão próprio contra a tentativa sistemática de palavras-passe. Tem três limites, documentados no próprio código-fonte do Odoo: o contador está na memória do processo de trabalho e é reposto a cada reinício, apenas atrasa em vez de bloquear, e conta exclusivamente tentativas que chegam até à verificação da palavra-passe.

O Web RBL atua nos mesmos pontos, mas escreve na base de dados. Assim:

• O estado sobrevive a qualquer reinício e vale para todos os processos de trabalho
• São registados ambos os caminhos: o formulário de início de sessão /web/login e as interfaces /xmlrpc/2/common e /jsonrpc
• São também registadas tentativas que nunca chegam à verificação da palavra-passe — por exemplo inícios de sessão sem identificador de sessão válido
• Um acesso falhado ao gestor de bases de dados é contabilizado; é a tentativa de início de sessão mais grave de todas

O limiar para inícios de sessão está em dez, e a razão é uma medição: de nove inícios de sessão falhados em dezassete dias, a maioria era de clientes que configuraram o acesso sozinhos num outro dispositivo e introduziram o domínio errado — num caso o próprio, só com hífen em vez de ponto. Um bloqueio na primeira tentativa falhada não teria atingido atacantes, mas sim clientes durante a configuração.

Quem, pelo contrário, continua a bater à porta apesar de o servidor já ter respondido “aguarde um momento”, é bloqueado de imediato. Essa mensagem é lida por uma pessoa, que espera; quem a ignora, é um programa. Um padrão próprio com limiar zero apanha precisamente este caso, e não pode atingir um colega: só lá chega quem já tem dez tentativas falhadas e continua a seguir.

3. O ataque já não custa nada ao servidor

Uma sonda a um caminho como /@fs/../../.env era cara antes do módulo: o Odoo procura a página de erro, renderiza-a, tropeça na construção do endereço nos segmentos de ponto e falha então também na página de erro da página de erro. Dois registos de pilha por sonda. Foram medidos 28.401 destes erros em dezassete dias, mais 9.467 erros subsequentes.

O Web RBL intervém em ir.http._match, ou seja, antes da determinação da rota. A resposta é dada sem modelo, sem acesso à base de dados além da verificação de bloqueio e sem linha de registo. A verificação em relação à lista de exceções, às listas de ameaças e às regras por país corre a partir da memória intermédia, sobre intervalos de endereços ordenados — poucos microssegundos, mesmo com mais de trinta mil intervalos.

4. A firewall expulsa o atacante antes de ele chegar

A lista de bloqueio é publicada como lista RBL, que o HAProxy e a OPNsense leem diretamente. O atacante já não chega ao servidor web — nem a qualquer outro serviço no mesmo anfitrião. Um acesso, uma vez reconhecido como malicioso, protege assim retroativamente toda a máquina.

Três níveis: bloquear, contar, comunicar

Nem todo o pedido que cai no vazio é um ataque. O Web RBL distingue por isso três níveis, e o nível pode ser alterado por padrão, sem mexer no código.

Nível	O pedido que o desencadeia	Consequência para o endereço
bloquear	é rejeitado	bloqueado 24 horas, de forma permanente após três dias suspeitos
contar	passa	apenas registado, sem bloqueio
comunicar	passa	registado com texto de diagnóstico, nunca bloqueado

Para listas de ameaças e países há um quarto: sem acesso ao início de sessão. O sítio web continua legível, o formulário de início de sessão e as interfaces ficam fechados. É o meio-termo para tudo o que é suspeito, mas não tem de ser malicioso — Tor, um intervalo de centro de dados, um país sem clientes.

Que ataques são detetados

Todos os padrões foram testados com tráfego real. O número de endereços diferentes está lá de propósito — mostra se um padrão atinge um scanner isolado ou uma prática difundida.

Classe de ataque	Pedidos	Endereços
Recolha de .env	57.721	223
Sondas PHP	12.237	256
Path traversal com alvo compensador	10.046	64
Ficheiros de configuração	5.535	114
Chaves de acesso à cloud	4.388	152
Sondas WordPress	3.366	385
Recolha de .git	2.811	255
Reconhecimento do Odoo (gestor de bases de dados, consulta de versão)	2.500	213
Cadeias de ferramentas de IA e execução de comandos (/mcp, /api/fs/exec)	2.450	74
Instruções de compilação (CI/CD)	1.907	88
Pontos de acesso GraphQL	1.878	71

Digna de nota é a classe mais recente. /api/fs/exec foi pedido 369 vezes por 54 endereços diferentes — isto não é um acesso de leitura, mas a tentativa de executar comandos. Alvos destes não existiam há dois anos; provêm de interfaces de novas ferramentas de IA e filas de tarefas. Quem orienta a sua defesa apenas para WordPress e PHP, não vê nada disto. Na pontuação, esta classe pesa em conformidade.

Listas de ameaças e país de origem

Quatro listas, 32.851 intervalos de endereços, todas em “apenas comunicar”. Cada lista adicional é um endereço e um nível.

Uma lista de terceiros é uma afirmação que outra pessoa faz, por razões que desconhecemos, sobre tráfego que nunca vimos. Pode estar errada, desatualizada ou pensada para outro fim: o blocklist.de reúne sobretudo endereços que noutros sítios tentaram inícios de sessão SSH por tentativa e erro, e isso diz pouco sobre um servidor web. Por isso o Web RBL mantém as listas de terceiros separadas da lista de bloqueio própria, e por isso a predefinição é comunicar. E a lista de exceções própria ganha sempre: um cliente que conhecemos pesa mais do que a avaliação de um terceiro.

O país de origem consta em cada ocorrência e em cada endereço. Para avaliar, é insubstituível — uma tentativa de início de sessão do própio país às dez da manhã é diferente de uma proveniente de um país sem um único cliente. Para bloqueios generalizados serve pouco, e dizem-no os nossos próprios números: os atacantes na nossa lista vinham sobretudo de zonas de cloud na Bélgica, Finlândia e Países Baixos. Um bloqueio a tudo o que está fora do espaço germanófono não os teria atingido — mas teria atingido colaboradores nossos de férias e clientes em viagem de negócios.

As regras por país são entregues vazias, e a vista explica porquê.

Comunicar configurações incorretas em vez de bloquear

O caso mais frequente no tráfego real não é nem ataque nem visitante, mas sim software avariado que confunde o servidor web com outra coisa:

• 1.367 acessos à interface web de um NAS QNAP — um cliente de sincronização cujo destino já não está correto. Uma única ligação bateu à porta 962 vezes.
• 65 consultas Autodiscover — um Outlook que confunde o domínio web com o seu Exchange

Tais endereços nunca são bloqueados. Um bloqueio não corrige o defeito, esconde-o — e atinge quem tem o dispositivo já mal configurado. Em vez disso, surge uma entrada com texto de diagnóstico e os domínios afetados, da qual, se desejado, se gera automaticamente um pedido de assistência: exatamente um por endereço, e se for fechado e o endereço voltar a dar nas vistas, o mesmo pedido reabre-se em vez de surgir um segundo.

São detetados QNAP, Synology, Exchange Autodiscover, ActiveSync e ainda clientes WebDAV, CalDAV e CardDAV. Os padrões indicam nomes de ficheiros e diretórios exatos, nunca meras extensões: no mesmo diretório /cgi-bin/ encontram-se as chamadas de sincronização inofensivas mesmo ao lado de sondas clássicas como printenv.pl.

A lista de exceções: endereços que nunca são bloqueados

O preço de um erro não é igual para todos os endereços. Com um scanner de um centro de dados, um falso alarme não custa nada. Com a extremidade de um túnel entre sedes, custa a própria sede.

Por isso existe uma segunda lista, que vem antes da primeira: endereços e redes que nunca são bloqueados. Não silencia nada — quem consta dela continua a ser verificado e registado, apenas a consequência não se aplica. Essa é a diferença para uma exceção na firewall: esta deixa cego, aquela só torna paciente.

É preenchida diariamente a partir de duas fontes: da própria firewall com todas as extremidades de VPN, para que um túnel acabado de configurar não dependa de alguém se lembrar da lista de bloqueio — e dos intervalos de endereços publicados pela Google e pela Microsoft para os seus crawlers. Só assim se consegue distinguir um verdadeiro Googlebot de um scanner que assim se apresenta. Os motores de busca nunca devem ser bloqueados; quem os bloqueia, retira o seu sítio da indexação sem caminho de volta.

Aplica-se aí uma regra mais importante do que a comparação: uma resposta vazia nunca apaga. Se a fonte não responder, responder vazio ou de forma incompreensível, a lista mantém-se inalterada. Uma lista de exceções que se esvazia sozinha numa falha leva consigo todos os túneis no pior momento imaginável.

Se uma entrada da lista de exceções tiver um cliente associado, cada ocorrência a partir da sua rede é-lhe atribuída. Uma configuração incorreta tem assim logo um interlocutor, sem que ninguém tenha de consultar endereços.

Informações obrigatórias e recolhedores automatizados de dados

O aviso legal não é uma página comum. Tem de permanecer acessível às pessoas, pois um bloqueio nele cria precisamente a infração que um recolhedor procura. Ao mesmo tempo, é a página onde constam o nome e o endereço — e, portanto, o alvo da colheita automática.

Na vaga austríaca de notificações por causa de fontes Google incorporadas, os registos mostraram que as cartas não provinham de visitas isoladas, mas de uma varredura automatizada: vários anfitriões sem relação entre si, com intervalos de milissegundos.

O Web RBL resolve isto com despromoção em vez de exceção. O caminho canónico /impressum não corresponde a nenhum padrão e permanece sempre acessível. Grafias alheias como /impressum.php — que não podem existir numa página Odoo — são comunicadas, e quem não quiser aceitar a colheita automática, altera um parâmetro. sitemap e robots estão excluídos e, por princípio, não são bloqueáveis: não contêm dados pessoais, e obtê-los é a tarefa de qualquer crawler de motor de busca.

Domínio e identificação: o que falta no registo de acessos

O registo de acessos do werkzeug não escreve nem o anfitrião acedido nem a identificação de quem chama. O Odoo recebe ambos, naturalmente — sem o anfitrião, nem conseguiria, com vários sítios web, escolher o correto. Mas não é possível consultá-los depois.

O Web RBL guarda ambos por ocorrência. Isso responde a duas perguntas que de outra forma não têm resposta: que sítio web uma configuração incorreta acede — e, com isso, a que cliente pertence o domínio — e se um endereço visita uma página ou todas. Vários domínios sem relação entre si do mesmo endereço são o sinal da varredura, e aumentam a pontuação.

O peso que a identificação tem mostrou-o uma análise num dos nossos sítios web: mais de setenta por cento de todo o tráfego cabia aí a um único autor de chamadas, distribuído por mais de cem endereços. Sem a identificação, teria parecido um scraper distribuído. Era o GPTBot, o crawler da OpenAI — que pedia vezes sem conta o robots.txt e se comportava de forma totalmente correta.

Os aspetos de segurança em pormenor

1. A deteção de proxy — o ponto mais perigoso de todos

Se o Odoo correr atrás de um proxy inverso e o proxy_mode estiver mal definido, o módulo vê em cada pedido o mesmo endereço: o do proxy. Um bloqueio deixaria então todos os visitantes à porta ao mesmo tempo.

Por isso o Web RBL verifica, antes de cada bloqueio, se a determinação do endereço é fiável. Exige proxy_mode em conjunto com um cabeçalho de reencaminhamento, recusa-se a trabalhar se chegar um reencaminhamento sem proxy_mode, e recusa-se igualmente perante mais de um proxy intermédio. Na dúvida, não se bloqueia.

2. Redes próprias, nunca

Intervalos de endereços privados, loopback, link-local e CGNAT estão excluídos de forma fixa. Não podem, em circunstância alguma, ir parar à lista, nem sequer à mão. O mesmo vale para listas de terceiros: intervalos privados e reservados, bem como redes absurdamente grandes, são descartados na leitura.

3. Um erro próprio não pode arrastar consigo o sítio web

Toda a verificação corre dentro de uma proteção que apanha qualquer erro. O que aqui falhar é registado, e o pedido segue sem alterações. Um módulo de proteção que, perante um erro seu, arrasta consigo o sítio web é pior do que nenhum. Todas as consultas no caminho do pedido correm ainda sem o idioma do navegador do visitante e sem ordenação por campos traduzidos — um visitante com um idioma não instalado não pode fazer falhar a verificação.

4. Observar antes de bloquear

Após a instalação, o bloqueio de endereços listados em pedidos normais está desligado. As sondas são rejeitadas e registadas, tudo o resto passa. Assim é possível acompanhar durante alguns dias quem realmente vai parar à lista, antes de alguém ficar bloqueado. O mesmo vale para a deteção de comportamento, listas de ameaças e regras por país: primeiro comunicar, bloquear depois de ver.

5. Padrões estreitos em vez de redes largas

Um visitante mal identificado é mais caro do que uma sonda ignorada. Cada padrão leva por isso o seu nível, que pode ser alterado por padrão. Uma extensão de ficheiro sozinha raramente basta: com .php há 14.012 sondas verdadeiras contra um punhado de ligações antigas, com .asp a proporção é inversa. Decisões destas devem ser medidas, não estimadas.

6. Uma libertação manual permanece

Quem liberta um endereço tinha uma razão. Uma nova ocorrência não anula silenciosamente essa decisão.

7. A lista está protegida, mas não é um segredo

O ponto de acesso exige um token e, sem token válido, responde com 404, não com 403 — a existência do endereço nem sequer é assim confirmada. A comparação é feita em tempo constante. A própria lista não contém nada confidencial: consiste em endereços que bateram à nossa porta por iniciativa própria.

8. Nenhum segredo nos registos

Nos inícios de sessão falhados é anotado o nome de utilizador tentado, nunca a palavra-passe. No gestor de bases de dados, dos valores transmitidos não se lê absolutamente nada: aí figura em primeiro lugar a palavra-passe mestra, e uma entrada numa lista de bloqueio vai parar a cada cópia de segurança da base de dados. A chave de licença do GeoLite2 consta apenas no parâmetro de sistema e em nenhuma linha de registo.

9. O isco não revela nada aproveitável

Opcionalmente, o Web RBL responde às sondas com conteúdo inventado que contém um valor-canário inequívoco. Quem consultar esse valor mais tarde, leu a resposta falsificada e agiu em conformidade — um falso alarme fica assim excluído. Os iscos não contêm dados aproveitáveis, nem caminhos reais, nem credenciais válidas. Esta função é entregue desligada, pois altera o comportamento de forma visível para o exterior.

O que o módulo não consegue fazer

Não substitui uma firewall nem uma Web Application Firewall. Deteta padrões de sondagem conhecidos em caminhos, inícios de sessão falhados e comportamento suspeito — não ataques a formulários, nem tentativas de injeção em parâmetros.

Além disso, só vê o que regressa por HTTP. O que um atacante faz com acessos furtados a bases de dados ou caixas de correio, permanece invisível — e é precisamente por isso que os valores-canário são caminhos e não credenciais.

E não substitui o cuidado: um módulo que rejeita sondas de .env não torna inofensivo um ficheiro .env entregue por engano.

Disponibilidade

O Web RBL está publicamente disponível sob a licença AGPL-3 e corre em produção, connosco, em cinco sítios web:

github.com/Alex0176/odoo-web-rbl

O módulo pressupõe o Odoo 19 Community e não tem dependências além de base e web. A ligação ao sistema de pedidos de assistência é opcional e não requer nenhum sistema específico; sem ele, simplesmente nada acontece. O país de origem requer a base de dados gratuita GeoLite2 da MaxMind; se faltar, o campo fica vazio e tudo o resto funciona sem alterações.

Para saber mais: Como o Web RBL se integra numa arquitetura de segurança completa -- em conjunto com firewall, autenticação de dois fatores e permissões, incluindo instruções passo a passo: Combinar corretamente a arquitetura de segurança do Odoo 19.

Aceitamos com gosto perguntas, comentários e relatórios de erros — de preferência como issue no GitHub.