Arquitetura de segurança do Odoo 19: combinar corretamente firewall, 2FA, permissões e Web RBL

Nos nossos cinco sítios web, o Odoo é acessível a partir da Internet aberta, e isso não é uma exceção, mas o caso normal: quem gere uma oferta, uma loja ou um início de sessão de clientes tem um servidor público. Basta uma única palavra-passe vulnerável, um ficheiro de configuração esquecido ou uma permissão demasiado generosa para que um servidor público se torne um servidor aberto.

Este artigo mostra como pode proteger corretamente o Odoo 19 — não com uma única medida, mas com várias camadas que se complementam: firewall e proxy inverso, o nosso módulo de código aberto Web RBL, autenticação de dois fatores, política de palavras-passe e permissões — e que tentativas de ataque cada uma delas realmente trava. No final há umas instruções passo a passo, com as quais qualquer instalação própria do Odoo pode ser atualizada.

Defesa em profundidade: porque uma medida nunca chega

Cada medida de segurança, por si só, tem uma lacuna. Uma firewall não vê o que se passa num formulário de início de sessão do Odoo. Uma palavra-passe forte não protege se já tiver sido roubada noutro lado. Uma estrutura de permissões de nada serve contra um atacante que ainda nem sequer iniciou sessão. O princípio que fecha estas lacunas chama-se defesa em profundidade (defense in depth): várias camadas independentes, cada uma das quais, por si só, poderia ser contornada — mas todas em conjunto, não.

Connosco são quatro camadas, cada uma com uma função diferente:

• Firewall / proxy inverso — mantém afastado o que é manifestamente malicioso, antes de chegar sequer ao servidor
• Web RBL — liga os dois lados: o Odoo aprende, a partir do seu próprio registo da aplicação, aquilo que a firewall não consegue ver, e devolve-lho
• O próprio Odoo — autenticação de dois fatores, política de palavras-passe, permissões, gestão de sessões
• Base de dados & operação — cópia de segurança, proteção de acesso à gestão, segredos fora de qualquer registo

As secções seguintes percorrem cada camada em separado.

Camada 1: firewall e proxy inverso

A firewall é a primeira instância a ver um pedido, e a única que consegue manter um atacante afastado de todos os serviços do servidor — não só do sítio web, mas também do servidor de correio, do acesso VPN e da própria interface de gestão. O que faz sentido ativar neste ponto depende do fabricante, mas os componentes são os mesmos em OPNsense, pfSense, HAProxy, FortiGate, Sophos ou Check Point:

Listas RBL: o caminho normalizado pelo qual a reputação é distribuída

RBL significa Real-time Blackhole List, um termo do mundo do correio eletrónico: um endereço por linha, acessível por HTTP, recarregado regularmente. Praticamente qualquer firewall consegue ler uma lista destas e criar regras a partir dela — OPNsense e pfSense como URL Table Alias, HAProxy como ficheiro ACL, FortiGate como External Block List, Palo Alto como External Dynamic List, Cisco, Sophos, Juniper e MikroTik com nomes próprios para o mesmo princípio.

É precisamente aqui que o nosso próprio módulo entra em ação — e é precisamente aqui que começa a segunda camada.

Camada 2: Web RBL — a ponte entre a aplicação e a firewall

Uma firewall vê pacotes, não lógica de aplicação. Não sabe que um pedido a /xmlrpc/2/common é uma tentativa de início de sessão, que vinte caminhos diferentes em catorze segundos são um scanner, ou que um endereço acabou de adivinhar com êxito uma palavra-passe. Tudo isso só o próprio Odoo sabe. Web RBL, o nosso próprio módulo de código aberto (AGPL-3), torna esse conhecimento utilizável — para o próprio Odoo e, entregue como lista RBL, também para a firewall que está à frente.

Listas de ameaças continuamente comparadas, cada uma com o seu próprio nível.

Resumindo, o que está descrito em pormenor no artigo anterior:

• Reconhecimento de padrões em caminhos: ficheiros .env, diretórios .git, ficheiros de configuração, sondas WordPress e PHP, path traversal, execução de comandos através de novas interfaces de IA
• Defesa de inícios de sessão que conta ao longo de reinícios — ao contrário do contador do próprio Odoo, que vive na memória
• Pontuação de cada endereço de 0 a 100, com fundamentação em texto simples
• Configurações incorretas (QNAP, Autodiscover, Synology) são reconhecidas e nunca bloqueadas, porque um bloqueio não corrige o defeito, apenas o esconde
• Listas de ameaças de terceiros como Spamhaus, FireHOL e nós de saída Tor, continuamente comparadas
• Lista de exceções para endereços que nunca devem ser bloqueados

Para este artigo, duas características são particularmente importantes, porque estão diretamente ligadas à firewall e ao início de sessão.

Uma lista inerte é uma lista em que se pode confiar

A lista de exceções — endereços que nunca são bloqueados, por exemplo as ligações das nossas próprias sedes — muda, por regra, raramente. É precisamente esse o seu valor, não a sua falha: quando uma lista tranquila quase não se move ao longo de dias, qualquer alteração rara salta de imediato à vista. A atualização automática diária não existe porque mude muita coisa, mas para que a alteração rara não tenha de ser registada à mão — e é justamente nesse ponto que nos esquecemos. Uma das nossas próprias configurações incorretas no mês passado foi detetada exatamente assim: não por muitos eventos, mas pelo único que ninguém conhecia, até a API web QNAP de um cliente ser bloqueada por engano. Desde então, o QNAP consta da lista das configurações incorretas que nunca são bloqueadas, apenas comunicadas.

O início de sessão é o lugar que uma firewall não vê

Uma firewall pode bloquear um endereço. Não pode saber se um início de sessão foi bem-sucedido, e muito menos se veio de um endereço que pouco antes ainda andava à procura de credenciais. O Web RBL sabe: uma pontuação a partir de um limiar configurável proíbe totalmente o início de sessão, e um início de sessão bem-sucedido a partir de um endereço suspeito é comunicado — é o elo de ligação com a camada seguinte.

Camada 3: proteger o próprio Odoo

Autenticação de dois fatores: um segundo segredo que não é reutilizável

O maior problema das palavras-passe não é a sua qualidade, mas a sua reutilização. Uma palavra-passe roubada noutro serviço funciona connosco da mesma forma, desde que seja a mesma. A autenticação de dois fatores (2FA, também chamada TOTP) contrapõe-lhe um segundo segredo: um código de seis dígitos que muda a cada trinta segundos e é calculado a partir de um segredo que só o próprio smartphone conhece. Uma palavra-passe roubada, por si só, já não chega.

O Odoo 19 Community traz isto incorporado — como módulo instalável Two-Factor Authentication (TOTP), complementado por uma opção de recurso por e-mail. Cada utilizador configura-o por si, através de código QR, com qualquer aplicação de autenticação habitual:

A configuração: ler o código QR, confirmar uma vez o código de seis dígitos, pronto.

Isto, por si só, só ajuda quem o configura por iniciativa própria — e a experiência mostra que, sem obrigação, esses continuam a ser a minoria. Por isso o Odoo tem uma política de imposição: ou apenas para colaboradores (utilizadores internos) ou para todos, incluindo utilizadores do portal. Sem um segundo segredo configurado, ninguém passa do formulário de início de sessão sem, pelo menos, o confirmar por código enviado por e-mail.

Política de palavras-passe: um comprimento mínimo não é uma evidência

Sem módulo adicional, o Odoo Community não impõe qualquer comprimento mínimo às palavras-passe — um utilizador pode definir uma palavra-passe de três caracteres se ninguém o impedir. O módulo Password Policy fecha precisamente esta lacuna: um comprimento mínimo imposto no servidor, e não apenas sugerido no navegador. Quem quiser mais — um prazo de validade obrigatório, um histórico contra a reutilização — precisa para isso de um módulo OCA ou de terceiros; na versão Community isto é deliberadamente mantido enxuto.

Permissões: só quem precisa tem acesso

O Odoo separa, de origem, três níveis: utilizadores do portal (apenas o próprio portal de clientes ou de fornecedores), utilizadores internos (o backend, com direitos por aplicação) e administradores (acesso ilimitado, incluindo as definições técnicas). O erro mais frequente não é uma palavra-passe demasiado fraca, mas uma função de administrador atribuída de forma demasiado generosa: quem só deve criar faturas não precisa de acesso às definições do sistema.

Dois princípios suportam a maior parte da carga:

Ambos podem ser verificados na mesma vista em que também se configura a autenticação de dois fatores:

Uma vista geral, quatro alavancas: palavra-passe, segundo fator, chaves de API, dispositivos com sessão iniciada.

Sessões e dispositivos: quem tem sessão iniciada neste momento

A mesma vista mostra também a partir de que dispositivos uma conta tem sessão iniciada neste momento — e permite terminar a sessão de um só ou de todos de uma vez. Após a perda de um portátil ou a suspeita de uma palavra-passe comprometida, este é o passo eficaz mais rápido: a sessão termina de imediato, independentemente de a palavra-passe já ter sido alterada ou não.

Camada 4: base de dados e operação

A quarta camada é a menos visível e, ao mesmo tempo, a mais imperdoável, porque um erro aqui pode deitar por terra tudo o que foi construído antes.

• Cópias de segurança regulares e verificadas, guardadas separadamente do próprio servidor. Uma cópia de segurança que nunca foi restaurada é uma suposição, não uma cópia de segurança.
• Os segredos não pertencem a nenhum ficheiro de registo. Palavras-passe, chaves de API, dados de licença — quem escreve extensões próprias deve tratá-los como a própria palavra-passe mestra: não os registar em lado nenhum, nem “só para depurar”.
• Manter os módulos atualizados, também e sobretudo os de terceiros. Os módulos adicionais livres (OCA e outros) ficam naturalmente para trás em relação às novas versões do Odoo; antes de cada instalação vale a pena ver que dependências vêm automaticamente.

O caminho do início de sessão no seu conjunto

As quatro camadas não atuam sucessivamente em salas separadas, mas sobre o mesmo pedido, passo a passo. O exemplo de um início de sessão torna isso mais evidente:

Cinco pontos em que um pedido malicioso pode terminar antes de chegar ao verdadeiro alvo — e apenas um em que um utilizador legítimo passa por todos.

Cenários de ataque e a respetiva defesa

A vista geral seguinte associa padrões de ataque reais às camadas que efetivamente os travam. Vários deles não são teoria, mas observações nossas ao longo de dezassete dias de tráfego real nos nossos cinco sítios web.

Passo a passo: proteger a própria instalação do Odoo

A ordem seguinte é aquela em que nós próprios procederíamos — do maior efeito à regulação mais fina.

1. Impor a autenticação de dois fatores

1. Se ainda não estiver instalado: abrir Aplicações, procurar “Two-Factor Authentication” e instalar (com vários sítios web, recomenda-se adicionalmente “Two-Factor Authentication by Mail” como opção de recurso).
2. Abrir Definições → Definições gerais → Permissões.
3. Ativar “Impor autenticação de dois fatores”.
4. Escolher a política: “Apenas colaboradores” para utilizadores internos, “Todos os utilizadores” se também os utilizadores do portal (clientes com acesso) devem ser incluídos.
5. Guardar. A partir da tentativa de início de sessão seguinte, o Odoo exige a todos os utilizadores sem segundo segredo configurado, no mínimo, o código por e-mail, até configurarem a aplicação de autenticação.

2. Definir um comprimento mínimo para as palavras-passe

1. Abrir Aplicações, procurar “Password Policy” e instalar.
2. Abrir Definições → Definições gerais → Permissões.
3. Definir “Comprimento mínimo da palavra-passe” — doze caracteres são um valor de partida razoável.
4. Guardar. A regra aplica-se de imediato a toda a atribuição ou alteração de palavra-passe, mas não retroativamente às palavras-passe existentes.

3. Rever as permissões

1. Abrir Definições → Utilizadores & empresas → Utilizadores.
2. Abrir cada utilizador individualmente e verificar o separador com os direitos de acesso por aplicação: esta pessoa precisa mesmo de “Gestor” ou “Administrador”, ou basta “Utilizador”?
3. Verificar em especial: quem tem acesso às próprias “Definições”? Deve ser um grupo muito pequeno.
4. Para cada ligação externa (contabilidade, scripts próprios, registo de tempo), criar no separador “Segurança da conta” do respetivo utilizador técnico uma chave de API própria, em vez de transmitir a palavra-passe do utilizador.

4. Instalar o Web RBL e observar antes de ativar

1. Colocar o módulo de github.com/Alex0176/odoo-web-rbl no caminho de addons e instalar.
2. Observar durante alguns dias: o menu Web RBL → Análise mostra que padrões efetivamente atuam.
3. Só depois ligar web_rbl.sperren_aktiv (Definições → Técnico → Parâmetros do sistema) — a partir daqui, as sondas reconhecidas são efetivamente rejeitadas.
4. Integrar na firewall a lista de bloqueio, no endereço protegido por token indicado no módulo, como lista RBL (no OPNsense/pfSense como URL Table Alias, no HAProxy como ficheiro ACL).

5. Proteger a própria firewall

1. Tornar a interface de gestão da firewall acessível exclusivamente a partir da rede interna, nunca pelo mesmo endereço público que o sítio web.
2. Ativar as atualizações de segurança automáticas do software da firewall, desde que o fabricante as ofereça.
3. Verificar a configuração TLS: apenas versões de protocolo atuais, desativar os métodos de cifragem desatualizados.
4. Se disponível: integrar diretamente na firewall uma lista de reputação conhecida (por exemplo, Spamhaus DROP) — independentemente do Web RBL, pois assim a firewall vê também o tráfego para serviços que o Odoo nunca alcança.

6. Fechar a gestão da base de dados

1. Verificar se /web/database/manager é acessível do exterior — se sim, definir list_db = False na configuração do Odoo ou bloquear o caminho ao nível da firewall.
2. Definir a palavra-passe mestra da gestão da base de dados longa e aleatória, e não a anotar em nenhum local que mais alguém possa ler.

7. Verificar a cópia de segurança, não apenas configurá-la

1. Configurar uma cópia de segurança automática e regular, guardada separadamente do servidor Odoo.
2. Restaurá-la efetivamente pelo menos uma vez e verificar se a recuperação funciona — uma cópia de segurança não verificada é uma suposição.

Nenhum destes passos substitui outro. Quem aplica apenas um, reforçou uma porta e deixou todas as outras abertas — quem aplica os sete, tem uma defesa que se mantém mesmo quando uma camada falha.

O que esta arquitetura não substitui

Nenhuma das medidas descritas torna o cuidado supérfluo. Um módulo que rejeita sondas .env não torna inofensivo um ficheiro .env publicado por engano. A autenticação de dois fatores não protege contra um utilizador que lê o seu código a alguém ao telefone. E uma firewall não substitui a decisão sobre quem realmente precisa de que permissão. A arquitetura de segurança cria as condições em que um erro isolado não se torna logo num incidente — não dispensa ninguém do cuidado.

Perguntas frequentes

Basta uma palavra-passe forte para proteger o Odoo 19?

Não. Uma palavra-passe pode ser roubada noutro lado, independentemente da sua qualidade, e funciona então em qualquer serviço que aceite a mesma palavra-passe. Só a combinação com autenticação de dois fatores, uma firewall à frente e uma estrutura de permissões sensata resulta numa proteção que se mantém mesmo depois de uma palavra-passe roubada.

Como ativo a autenticação de dois fatores no Odoo 19?

Instalar o módulo “Two-Factor Authentication (TOTP)” através da gestão de aplicações, depois ativar a imposição em Definições → Definições gerais → Permissões e escolher entre “Apenas colaboradores” e “Todos os utilizadores”. Cada utilizador configura então o seu próprio segundo fator através de código QR.

O que é uma lista RBL e porque precisa o Odoo de uma?

RBL (Real-time Blackhole List) é uma lista de endereços acessível por HTTP que praticamente qualquer firewall consegue ler. O próprio Odoo não inclui nenhuma lista deste tipo — o nosso módulo Web RBL fecha esta lacuna, reconhecendo tráfego de ataque a partir do próprio registo da aplicação e devolvendo-o, como lista RBL, à firewall que está à frente.

O Odoo 19 Community está suficientemente protegido sem módulos adicionais?

Não por completo. Sem o módulo Password Policy não há comprimento mínimo para as palavras-passe, sem Two-Factor Authentication não há segundo fator, e sem um módulo como o Web RBL o Odoo não reconhece nem tentativas de sondagem nem tentativas de início de sessão repetidas ao longo de um reinício. Os quatro podem ser acrescentados gratuitamente.

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

A descrição completa das funcionalidades, com todos os padrões, a pontuação e as listas de ameaças, encontra-se no artigo anterior: Web RBL – lista de bloqueio para tráfego de ataque nos próprios sítios web.

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