Arquitectura de seguridade de Odoo 19: combinar correctamente firewall, 2FA, permisos e Web RBL

Odoo é accesible desde Internet aberta nas nosas cinco páxinas web, e iso non é unha excepción, senón o caso normal: quen ofrece un catálogo, unha tenda ou un acceso de clientes ten un servidor público. Basta un único contrasinal vulnerable, un ficheiro de configuración esquecido ou un permiso demasiado xeneroso para que un servidor público pase a ser un servidor aberto.

Esta publicación mostra como protexer Odoo 19 correctamente — non cunha única medida, senón con varias capas que se complementan entre si: firewall e proxy inverso, o noso módulo de código aberto Web RBL, autenticación de dous factores, política de contrasinais e permisos — e que intentos de ataque detén realmente cada unha. Ao final hai unha guía paso a paso coa que se pode aplicar a mesma configuración a calquera instalación propia de Odoo.

Defensa en profundidade: por que unha medida nunca basta

Cada medida de seguridade por si soa ten unha lagoa. Un firewall non ve o que sucede nun formulario de acceso de Odoo. Un contrasinal forte non protexe se xa foi roubado noutro lugar. Unha estrutura de permisos non serve de nada contra un atacante que aínda nin sequera iniciou sesión. O principio que pecha estas lagoas chámase defensa en profundidade (defense in depth): varias capas independentes, cada unha das cales, tomada por separado, sería evitable — pero todas xuntas, non.

Na nosa configuración son catro capas, cada unha cunha función distinta:

• Firewall / proxy inverso — mantén lonxe o que é evidentemente malicioso antes de que chegue sequera ao servidor
• Web RBL — une ambos os lados: Odoo aprende do seu propio rexistro de aplicación o que o firewall non pode ver en absoluto, e devólveselo
• Odoo en si — autenticación de dous factores, política de contrasinais, permisos, xestión de sesións
• Base de datos & operación — copias de seguridade, protección de acceso á administración, segredos fóra de calquera rexistro

As seguintes seccións repasan cada capa por separado.

Capa 1: firewall e proxy inverso

O firewall é a primeira instancia que ve unha solicitude e a única que pode manter un atacante lonxe de todos os servizos do servidor — non só da páxina web, senón tamén do servidor de correo, do acceso VPN e da propia interface de administración. O que se activa con sentido neste punto depende do fabricante, pero as formas de construción son as mesmas en OPNsense, pfSense, HAProxy, FortiGate, Sophos ou Check Point:

Listas RBL: o camiño estándar polo que se entrega a reputación

RBL significa Real-time Blackhole List, un termo do mundo do correo: un enderezo por liña, accesible por HTTP, recargado con regularidade. Practicamente calquera firewall pode ler unha lista así e crear 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 con nomes propios para o mesmo principio.

Xusto aquí actúa o noso propio módulo — e xusto aquí comeza a segunda capa.

Capa 2: Web RBL — a ponte entre a aplicación e o firewall

Un firewall ve paquetes, non lóxica de aplicación. Non sabe que unha solicitude a /xmlrpc/2/common é un intento de inicio de sesión, que vinte rutas diferentes en catorce segundos son un escáner, nin que un enderezo acaba de adiviñar con éxito un contrasinal. Todo iso só o sabe Odoo en si. Web RBL, o noso propio módulo de código aberto (AGPL-3), fai utilizable ese coñecemento — para Odoo en si e, entregado como lista RBL, tamén para o firewall que ten diante.

Listas de ameazas comparadas continuamente, cada unha co seu propio nivel.

Breve resumo do que se describe con detalle na publicación anterior:

• Recoñecemento de patróns en rutas: ficheiros .env, directorios .git, ficheiros de configuración, sondas de WordPress e PHP, path traversal, execución de comandos a través das novas interfaces de IA
• Defensa dos inicios de sesión que conta a través dos reinicios — a diferenza do contador propio de Odoo, que vive na memoria
• Puntuación de cada enderezo de 0 a 100, con xustificación en texto claro
• As configuracións erróneas (QNAP, Autodiscover, Synology) detéctanse e nunca se bloquean, porque un bloqueo non soluciona o defecto, só o oculta
• Listas de ameazas alleas como Spamhaus, FireHOL e nodos de saída de Tor, comparadas continuamente
• Lista de exclusións para enderezos que nunca deben bloquearse

Para esta publicación, dúas características son especialmente importantes, porque están directamente relacionadas co firewall e co inicio de sesión.

Unha lista inerte é unha lista na que se pode confiar

A lista de exclusións — enderezos que nunca se bloquean, por exemplo as conexións das propias sedes — cambia, por regra xeral, poucas veces. Precisamente iso é o seu valor, non a súa carencia: cando unha lista tranquila apenas se move durante días, calquera cambio raro destaca de inmediato. A actualización automática diaria non existe porque fosen cambiar moitas cousas, senón para que o cambio raro non teña que engadirse a man — e é xusto ese o momento no que un se esquece. Unha das nosas propias configuracións erróneas do mes pasado detectouse exactamente así: non por moitos eventos, senón polo único que ninguén coñecía ata que a API web de QNAP dun cliente se bloqueou por erro. Desde entón, QNAP figura na lista de configuracións erróneas que nunca se bloquean, só se comunican.

O inicio de sesión é o lugar que un firewall non ve

Un firewall pode bloquear un enderezo. Non pode saber se un inicio de sesión tivo éxito, e menos aínda se procedía dun enderezo que pouco antes buscaba datos de acceso. Web RBL, en cambio, si: unha puntuación a partir dun límite axustable prohibe por completo o inicio de sesión, e un inicio de sesión correcto desde un enderezo sospeitoso comunícase — iso é o elo coa seguinte capa.

Capa 3: protexer Odoo en si

Autenticación de dous factores: un segundo segredo que non se pode reutilizar

O maior problema dos contrasinais non é a súa calidade, senón a súa reutilización. Un contrasinal roubado noutro servizo funciona connosco exactamente igual, sempre que sexa o mesmo. A autenticación de dous factores (2FA, tamén chamada TOTP) opón a isto un segundo segredo: un código de seis díxitos que cambia cada trinta segundos e se calcula a partir dun segredo que só coñece o propio smartphone. Un contrasinal roubado, só, xa non chega.

Odoo 19 Community inclúeo de serie — como módulo instalable Two-Factor Authentication (TOTP), completado cunha opción alternativa por correo electrónico. Cada usuario configúrao por si mesmo, mediante código QR, con calquera aplicación de autenticación habitual:

A configuración: escanear o código QR, confirmar unha vez o código de seis díxitos, e listo.

Pero isto só axuda a quen o configura por si mesmo — e a experiencia mostra que, sen obrigatoriedade, queda como minoría. Por iso Odoo ten unha política de obrigatoriedade: ben só para empregados (usuarios internos), ben para todos, incluídos os usuarios do portal. Sen un segundo segredo configurado, ninguén pasa xa do formulario de acceso sen confirmalo polo menos mediante un código por correo electrónico.

Política de contrasinais: unha lonxitude mínima non é algo evidente

Sen un módulo adicional, Odoo Community non esixe ningunha lonxitude mínima para os contrasinais — un usuario pode asignar un contrasinal de tres caracteres se ninguén llo impide. O propio módulo Password Policy pecha exactamente esa lagoa: unha lonxitude mínima que se impón no servidor, non só se suxire no navegador. Quen queira máis — un prazo de caducidade obrigatorio, un historial contra a reutilización — precisa para iso un módulo da OCA ou de terceiros; na versión Community mantense deliberadamente sinxela.

Permisos: só quen o necesita obtén acceso

Odoo separa de serie tres niveis: usuarios do portal (só o propio portal de clientes ou de provedores), usuarios internos (o backend, con dereitos por aplicación) e administradores (acceso sen restricións, incluídos os axustes técnicos). O erro máis frecuente non é un contrasinal demasiado feble, senón un rol de administrador concedido con demasiada xenerosidade: quen só debe crear facturas non precisa acceso aos axustes do sistema.

Dous principios soportan a maior parte da carga:

Ambas cousas pódense comprobar na mesma vista na que tamén se configura a autenticación de dous factores:

Unha vista xeral, catro alavancas: contrasinal, segundo factor, chaves de API, dispositivos con sesión iniciada.

Sesións e dispositivos: quen ten a sesión iniciada neste momento

A mesma vista mostra tamén desde que dispositivos ten unha conta a sesión iniciada neste momento — e permite pechar a sesión dun só ou de todos á vez. Tras a perda dun portátil ou a sospeita dun contrasinal comprometido, é o paso eficaz máis rápido: a sesión remata de inmediato, independentemente de se o contrasinal xa se cambiou.

Capa 4: base de datos e operación

A cuarta capa é a menos visible e á vez a máis imperdoable, porque un erro aquí pode botar a perder todo o construído antes.

• Copias de seguridade regulares e comprobadas, gardadas separadamente do propio servidor. Unha copia que nunca se restaurou é unha suposición, non unha copia de seguridade.
• Os segredos non pertencen a ningún ficheiro de rexistro. Contrasinais, chaves de API, datos de licenza — quen escribe extensións propias debería tratalos como o propio contrasinal mestre: non rexistralos en ningures, nin sequera «só para depurar».
• Manter os módulos actualizados, tamén e precisamente os de terceiros. Os módulos adicionais libres (OCA e outros) quedan por natureza por detrás das novas versións de Odoo; antes de cada instalación compensa ver que dependencias veñen incluídas automaticamente.

O camiño do inicio de sesión no seu conxunto

As catro capas non actúan unha tras outra en salas separadas, senón sobre a mesma solicitude, paso a paso. Vese con máis claridade co exemplo dun inicio de sesión:

Cinco puntos nos que pode acabar unha solicitude maliciosa antes de chegar ao verdadeiro obxectivo — e un só no que un usuario lexítimo os supera todos.

Escenarios de ataque e a súa defensa

A seguinte vista xeral asigna patróns de ataque reais ás capas que realmente os deteñen. Varios deles non son teoría, senón observacións propias de dezasete días de tráfico real nas nosas cinco páxinas web.

Paso a paso: protexer a propia instalación de Odoo

A seguinte orde é a que seguiriamos nós mesmos — do maior efecto ao axuste máis fino.

1. Impoñer a autenticación de dous factores

1. Se aínda non está instalado: abrir Apps, buscar «Two-Factor Authentication» e instalalo (con varias páxinas web, recoméndase ademais «Two-Factor Authentication by Mail» como opción alternativa).
2. Abrir Axustes → Axustes xerais → Permisos.
3. Activar «Impoñer a autenticación de dous factores».
4. Escoller a política: «Só empregados» para usuarios internos, «Todos os usuarios» se tamén se quere incluír os usuarios do portal (clientes con acceso).
5. Gardar. A partir do seguinte intento de inicio de sesión, Odoo esixe a todo usuario sen un segundo segredo configurado, como mínimo, o código por correo electrónico, ata que configure a aplicación de autenticación.

2. Fixar unha lonxitude mínima para os contrasinais

1. Abrir Apps, buscar «Password Policy» e instalalo.
2. Abrir Axustes → Axustes xerais → Permisos.
3. Fixar «Lonxitude mínima do contrasinal» — doce caracteres son un valor inicial razoable.
4. Gardar. A regra vale desde agora para cada asignación ou cambio de contrasinal novo, non retroactivamente para os contrasinais existentes.

3. Revisar os permisos

1. Abrir Axustes → Usuarios & empresas → Usuarios.
2. Abrir cada usuario individualmente e comprobar a lapela cos dereitos de acceso por aplicación: esta persoa necesita realmente «Xestor» ou «Administrador», ou chega con «Usuario»?
3. Comprobar especialmente: quen ten acceso aos propios «Axustes»? Debería ser un grupo moi pequeno.
4. Para cada conexión externa (contabilidade, scripts propios, rexistro de tempos), crear na lapela «Seguridade da conta» do usuario técnico correspondente unha chave de API propia, en vez de transmitir o contrasinal do usuario.

4. Instalar Web RBL e observar antes de activar o bloqueo

1. Colocar o módulo de github.com/Alex0176/odoo-web-rbl no camiño de addons e instalalo.
2. Observar durante uns días: o menú Web RBL → Análise mostra que patróns actúan realmente.
3. Só despois activar web_rbl.sperren_aktiv (Axustes → Técnico → Parámetros do sistema) — a partir de aquí as sondas detectadas rexéitanse de verdade.
4. Integrar no firewall a lista de bloqueo como lista RBL, no enderezo protexido por token indicado no módulo (en OPNsense/pfSense como URL Table Alias, en HAProxy como ficheiro ACL).

5. Protexer o propio firewall

1. Facer que a interface de administración do firewall sexa accesible exclusivamente desde a rede interna, nunca polo mesmo enderezo público ca a páxina web.
2. Activar as actualizacións de seguridade automáticas para o software do firewall, sempre que o fabricante as ofreza.
3. Revisar a configuración de TLS: só versións de protocolo actuais, desactivar os métodos de cifrado obsoletos.
4. Se está dispoñible: integrar directamente no firewall unha lista de reputación coñecida (por exemplo Spamhaus DROP) — independentemente de Web RBL, pois así o firewall ve tamén o tráfico cara a servizos aos que Odoo nunca chega.

6. Pechar a xestión da base de datos

1. Comprobar se /web/database/manager é accesible desde fóra — se o é, fixar list_db = False na configuración de Odoo ou bloquear a ruta a nivel de firewall.
2. Fixar o contrasinal mestre da xestión da base de datos longo e aleatorio, e non anotalo en ningún lugar que poida ler outra persoa.

7. Comprobar a copia de seguridade, non só configurala

1. Configurar unha copia de seguridade automática e regular, gardada separadamente do servidor de Odoo.
2. Restaurala realmente polo menos unha vez e comprobar se a recuperación funciona — unha copia sen comprobar é unha suposición.

Ningún destes pasos substitúe a outro. Quen só aplica un deles reforzou unha porta e deixou abertas todas as demais — quen aplica os sete ten unha defensa que aínda aguanta cando falla unha capa individual.

O que esta arquitectura non substitúe

Ningunha das medidas descritas fai innecesario o coidado. Un módulo que rexeita sondas .env non fai inofensivo un ficheiro .env publicado por descoido. A autenticación de dous factores non protexe dun usuario que le o seu código a quen chama por teléfono. E un firewall non substitúe a decisión sobre quen necesita realmente que permiso. A arquitectura de seguridade crea as condicións nas que un erro illado non se converte de inmediato nun incidente — pero non exime a ninguén do coidado.

Preguntas frecuentes

Chega un contrasinal forte para protexer Odoo 19?

Non. Un contrasinal pode ser roubado noutro lugar, con independencia da súa calidade, e funciona entón en todo servizo que acepte ese mesmo contrasinal. Só a combinación coa autenticación de dous factores, un firewall diante e unha estrutura de permisos sensata dá unha protección que aguanta mesmo despois dun contrasinal roubado.

Como activo a autenticación de dous factores en Odoo 19?

Instalar o módulo «Two-Factor Authentication (TOTP)» mediante a xestión de Apps, despois activar a obrigatoriedade en Axustes → Axustes xerais → Permisos e escoller entre «Só empregados» e «Todos os usuarios». Cada usuario configura despois o seu propio segundo factor mediante código QR.

Que é unha lista RBL e por que a necesita Odoo?

RBL (Real-time Blackhole List) é unha lista de enderezos accesible por HTTP que practicamente calquera firewall pode ler. Odoo en si non inclúe ningunha lista así — o noso módulo Web RBL pecha esa lagoa recoñecendo o tráfico de ataque no propio rexistro da aplicación e devolvéndoo como lista RBL ao firewall que ten diante.

Está Odoo 19 Community suficientemente protexido sen módulos adicionais?

Non por completo. Sen o módulo Password Policy non hai lonxitude mínima para os contrasinais, sen Two-Factor Authentication non hai segundo factor, e sen un módulo como Web RBL Odoo non detecta nin intentos de sondaxe nin intentos repetidos de inicio de sesión a través dun reinicio. Os catro pódense engadir gratuitamente.

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

A descrición completa das funcións con todos os patróns, a puntuación e as listas de ameazas está na publicación anterior: Web RBL – lista de bloqueo para o tráfico de ataque nas propias páxinas web.

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