Arquitectura de seguretat d'Odoo 19: combinar correctament tallafoc, 2FA, permisos i Web RBL

Odoo és accessible des d'Internet obert als nostres cinc llocs web, i això no és una excepció, sinó el cas normal: qui ofereix un producte, una botiga o un inici de sessió de clients, té un servidor públic. Una sola contrasenya vulnerable, un fitxer de configuració oblidat o un permís massa generós n'hi ha prou perquè un servidor públic passi a ser un servidor obert.

Aquesta entrada mostra com protegir Odoo 19 correctament — no amb una única mesura, sinó amb diverses capes que es complementen entre elles: tallafoc i servidor intermediari invers, el nostre mòdul de codi obert Web RBL, autenticació de dos factors, política de contrasenyes i permisos — i quins intents d'atac atura realment cadascuna. Al final hi ha unes instruccions pas a pas amb les quals es pot replicar qualsevol instal·lació pròpia d'Odoo.

Defensa en profunditat: per què una sola mesura mai no n'hi ha prou

Cada mesura de seguretat té una bretxa. Un tallafoc no veu què passa en un formulari d'inici de sessió d'Odoo. Una contrasenya forta no protegeix si ja ha estat robada en un altre lloc. Una estructura de permisos no serveix de res contra un atacant que encara ni tan sols ha iniciat sessió. El principi que tanca aquestes bretxes s'anomena defensa en profunditat (defense in depth): diverses capes independents, cadascuna de les quals, per si sola, es podria esquivar — però no pas totes juntes.

Són quatre capes les que tenim, cadascuna amb una funció diferent:

• Tallafoc / servidor intermediari invers — manté lluny el que és evidentment maliciós abans que arribi ni tan sols al servidor
• Web RBL — uneix les dues bandes: Odoo aprèn del seu propi registre d'aplicació el que el tallafoc no pot veure en absolut, i li ho retorna
• Odoo mateix — autenticació de dos factors, política de contrasenyes, permisos, gestió de sessions
• Base de dades & operació — còpia de seguretat, protecció d'accés a l'administració, secrets fora de qualsevol registre

Les seccions següents repassen cada capa per separat.

Capa 1: tallafoc i servidor intermediari invers

El tallafoc és la primera instància que veu una sol·licitud, i l'única que pot mantenir un atacant lluny de qualsevol servei del servidor — no només del web, sinó també del servidor de correu, de l'accés VPN i de la pròpia interfície d'administració. El que s'hi activa de manera útil depèn del fabricant, però les formes bàsiques són les mateixes a OPNsense, pfSense, HAProxy, FortiGate, Sophos o Check Point:

Llistes RBL: la via estàndard per lliurar reputació

RBL significa Real-time Blackhole List, un terme del món del correu: una adreça per línia, accessible per HTTP i recarregada de manera regular. Pràcticament qualsevol tallafoc pot llegir una llista així i construir-ne regles — OPNsense i pfSense com a URL Table Alias, HAProxy com a fitxer ACL, FortiGate com a External Block List, Palo Alto com a External Dynamic List, Cisco, Sophos, Juniper i MikroTik amb noms propis per al mateix principi.

És exactament aquí on intervé el nostre mòdul — i és exactament aquí on comença la segona capa.

Capa 2: Web RBL — el pont entre l'aplicació i el tallafoc

Un tallafoc veu paquets, no lògica d'aplicació. No sap que una sol·licitud a /xmlrpc/2/common és un intent d'inici de sessió, que vint rutes diferents en catorze segons són un escàner, ni que una adreça acaba d'endevinar amb èxit una contrasenya. Tot això només ho sap Odoo mateix. Web RBL, el nostre propi mòdul de codi obert (AGPL-3), fa aprofitable aquest coneixement — per a Odoo mateix i, lliurat com a llista RBL, també per al tallafoc que hi ha al davant.

Llistes d'amenaces comparades de manera contínua, cadascuna amb un nivell propi.

Resum breu del que es descriu amb detall a l'entrada anterior:

• Detecció de patrons en rutes: fitxers .env, directoris .git, fitxers de configuració, sondes de WordPress i PHP, path traversal, execució d'ordres mitjançant les noves interfícies d'IA
• Defensa d'inici de sessió que compta a través dels reinicis — a diferència del comptador propi d'Odoo, que viu a la memòria principal
• Puntuació de cada adreça de 0 a 100, amb justificació en text clar
• Configuracions errònies (QNAP, Autodiscover, Synology) es detecten i mai es bloquegen, perquè un bloqueig no soluciona el defecte, només l'amaga
• Llistes d'amenaces alienes com Spamhaus, FireHOL i nodes de sortida de Tor, comparades de manera contínua
• Llista d'excepcions per a adreces que no s'han de bloquejar mai

Per a aquesta entrada dues propietats són especialment importants, perquè estan directament relacionades amb el tallafoc i amb l'inici de sessió.

Una llista inert és una llista de la qual et pots fiar

La llista d'excepcions — adreces que no es bloquegen mai, per exemple les connexions de les pròpies seus — canvia, en general, poques vegades. Això és precisament el seu valor, no el seu defecte: quan una llista tranquil·la gairebé no es mou durant dies, qualsevol canvi poc freqüent crida l'atenció de seguida. L'actualització automàtica diària no existeix perquè hi hagi molts canvis, sinó perquè el canvi poc freqüent no s'hagi d'afegir a mà — i aquest és precisament el punt en què s'oblida. Una de les nostres pròpies configuracions errònies el mes passat es va detectar exactament així: no per molts esdeveniments, sinó per l'únic que ningú no coneixia, fins que l'API web QNAP d'un client va ser bloquejada per error. Des d'aleshores QNAP figura a la llista de configuracions errònies que no es bloquegen mai, sinó que només es notifiquen.

L'inici de sessió és el lloc que un tallafoc no veu

Un tallafoc pot bloquejar una adreça. No pot saber si un inici de sessió ha estat reeixit, i molt menys si provenia d'una adreça que poc abans encara buscava dades d'accés. Web RBL sí: una puntuació a partir d'un llindar ajustable prohibeix l'inici de sessió del tot, i un inici de sessió reeixit des d'una adreça sospitosa es notifica — aquest és l'element d'unió amb la capa següent.

Capa 3: protegir Odoo mateix

Autenticació de dos factors: un segon secret que no es pot reutilitzar

El problema més gran de les contrasenyes no és la seva qualitat, sinó la seva reutilització. Una contrasenya robada en un altre servei funciona exactament igual amb nosaltres, mentre sigui la mateixa. L'autenticació de dos factors (2FA, també anomenada TOTP) hi oposa un segon secret: un codi de sis xifres que canvia cada trenta segons i es calcula a partir d'un secret que només coneix el propi telèfon intel·ligent. Una contrasenya robada ja no n'hi ha prou per si sola.

Odoo 19 Community ho incorpora de sèrie — com a mòdul instal·lable Two-Factor Authentication (TOTP), completat amb una opció alternativa per correu electrònic. Cada usuari ho configura per si mateix, mitjançant un codi QR, amb qualsevol aplicació d'autenticació habitual:

La configuració: escanejar el codi QR, confirmar una vegada el codi de sis xifres, i llestos.

Però només això ajuda únicament els qui ho configuren per si mateixos — i l'experiència demostra que, sense obligació, aquests continuen sent la minoria. Per això Odoo disposa d'una política d'obligatorietat: o bé només per als empleats (usuaris interns) o bé per a tothom, inclosos els usuaris del portal. Sense un segon secret configurat, ningú no passa ja del formulari d'inici de sessió sense confirmar-ho almenys mitjançant un codi per correu electrònic.

Política de contrasenyes: una longitud mínima no és una obvietat

Sense mòdul addicional, Odoo Community no exigeix cap longitud mínima per a les contrasenyes — un usuari pot assignar una contrasenya de tres caràcters si ningú ho impedeix. El mòdul propi Password Policy tanca precisament aquesta bretxa: una longitud mínima que s'imposa al servidor, no només se suggereix al navegador. Qui en vol més — un termini de caducitat obligatori, un historial contra la reutilització — necessita per a això un mòdul d'OCA o de tercers; a la versió Community s'ha mantingut deliberadament lleuger.

Permisos: només qui ho necessita obté accés

Odoo separa de sèrie tres nivells: usuaris del portal (només el propi portal de clients o proveïdors), usuaris interns (el backend, amb drets per aplicació) i administradors (accés il·limitat, inclosa la configuració tècnica). L'error més freqüent no és una contrasenya massa feble, sinó un rol d'administrador assignat amb massa generositat: qui només ha de crear factures no necessita accés a la configuració del sistema.

Dos principis suporten la major part de la càrrega:

Totes dues coses es poden comprovar a la mateixa vista on també es configura l'autenticació de dos factors:

Una vista general, quatre palanques: contrasenya, segon factor, claus d'API, dispositius connectats.

Sessions i dispositius: qui està connectat ara

La mateixa vista mostra també des de quins dispositius hi ha un compte connectat en aquest moment — i permet tancar la sessió d'un sol dispositiu o de tots alhora. Després d'un portàtil perdut o davant la sospita d'una contrasenya compromesa, aquest és el pas eficaç més ràpid: la sessió acaba a l'instant, independentment que la contrasenya ja s'hagi canviat o no.

Capa 4: base de dades i operació

La quarta capa és la menys visible i alhora la més imperdonable, perquè un error aquí pot anul·lar tot el que s'ha construït abans.

• Còpies de seguretat regulars i verificades, emmagatzemades separadament del servidor mateix. Una còpia de seguretat que mai no s'ha restaurat és una suposició, no una còpia de seguretat.
• Els secrets no pertanyen a cap fitxer de registre. Contrasenyes, claus d'API, dades de llicència — qui escriu extensions pròpies, les hauria de tractar com la contrasenya mestra mateixa: no registrar-les enlloc, ni tan sols «només per depurar».
• Mantenir els mòduls actualitzats, també i precisament els de tercers. Els mòduls addicionals lliures (OCA i altres) van, per naturalesa, per darrere de les noves versions d'Odoo; abans de cada instal·lació val la pena mirar quines dependències s'hi afegeixen automàticament.

El camí d'inici de sessió en conjunt

Les quatre capes no actuen una darrere l'altra en espais separats, sinó sobre la mateixa sol·licitud, nivell per nivell. L'exemple d'un inici de sessió ho fa més evident:

Cinc punts on una sol·licitud maliciosa pot acabar abans d'arribar al seu objectiu real — i un de sol on un usuari legítim els supera tots.

Escenaris d'atac i la seva defensa

La vista general següent assigna patrons d'atac reals a les capes que realment els aturen. Diversos d'ells no són teoria, sinó observacions pròpies de disset dies de trànsit real als nostres cinc llocs web.

Pas a pas: protegir la pròpia instal·lació d'Odoo

L'ordre següent és el que seguiríem nosaltres mateixos — de l'efecte més gran al paràmetre més fi.

1. Imposar l'autenticació de dos factors

1. Si encara no està instal·lat: obrir Apps, cercar «Two-Factor Authentication» i instal·lar-lo (amb diversos llocs web es recomana, a més, «Two-Factor Authentication by Mail» com a opció alternativa).
2. Obrir Configuració → Configuració general → Permisos.
3. Activar «Imposar l'autenticació de dos factors».
4. Triar la política: «Només empleats» per als usuaris interns, «Tots els usuaris» si també s'hi han d'incloure els usuaris del portal (clients amb accés).
5. Desar. A partir del proper intent d'inici de sessió, Odoo exigeix a cada usuari sense un segon secret configurat almenys el codi per correu electrònic, fins que hagi configurat l'aplicació d'autenticació.

2. Establir una longitud mínima per a les contrasenyes

1. Obrir Apps, cercar «Password Policy» i instal·lar-lo.
2. Obrir Configuració → Configuració general → Permisos.
3. Establir «Longitud mínima de la contrasenya» — dotze caràcters són un valor inicial raonable.
4. Desar. La regla val a partir d'ara per a qualsevol assignació de contrasenya nova o modificada, però no retroactivament per a les contrasenyes existents.

3. Revisar els permisos

1. Obrir Configuració → Usuaris & empreses → Usuaris.
2. Obrir cada usuari individualment i comprovar la pestanya amb els drets d'accés per aplicació: aquesta persona necessita realment «Gestor» o «Administrador», o n'hi ha prou amb «Usuari»?
3. Comprovar especialment: qui té accés a la «Configuració» mateixa? Hauria de ser un grup molt reduït.
4. Per a cada connexió externa (comptabilitat, scripts propis, registre d'hores), crear a la pestanya «Seguretat del compte» de l'usuari tècnic corresponent una clau d'API pròpia, en lloc de facilitar la contrasenya de l'usuari.

4. Instal·lar Web RBL i observar abans d'activar-lo de debò

1. Col·locar el mòdul de github.com/Alex0176/odoo-web-rbl a la ruta d'addons i instal·lar-lo.
2. Observar uns dies: el menú Web RBL → Anàlisi mostra quins patrons actuen realment.
3. Només després activar web_rbl.sperren_aktiv (Configuració → Tècnic → Paràmetres del sistema) — a partir d'aquí les sondes detectades es rebutgen realment.
4. Integrar la llista de bloqueig, mitjançant l'adreça protegida amb token indicada al mòdul, al tallafoc com a llista RBL (a OPNsense/pfSense com a URL Table Alias, a HAProxy com a fitxer ACL).

5. Protegir el tallafoc mateix

1. Fer que la interfície d'administració del tallafoc sigui accessible exclusivament des de la xarxa interna, mai per la mateixa adreça pública que el web.
2. Activar les actualitzacions de seguretat automàtiques del programari del tallafoc, sempre que el fabricant les ofereixi.
3. Revisar la configuració de TLS: només versions de protocol actuals, desactivar els mètodes de xifratge obsolets.
4. Si és possible: integrar directament al tallafoc una llista de reputació coneguda (per exemple, Spamhaus DROP) — independentment de Web RBL, perquè així el tallafoc veu també el trànsit cap a serveis que Odoo no arriba a veure mai.

6. Tancar l'administració de bases de dades

1. Comprovar si /web/database/manager és accessible des de l'exterior — si ho és, establir list_db = False a la configuració d'Odoo o bloquejar la ruta a nivell de tallafoc.
2. Establir una contrasenya mestra de l'administració de bases de dades llarga i aleatòria, i no anotar-la en cap lloc que algú altre pugui llegir.

7. Verificar la còpia de seguretat, no només configurar-la

1. Configurar una còpia de seguretat automàtica i regular, emmagatzemada separadament del servidor d'Odoo.
2. Restaurar-la realment almenys una vegada i comprovar si la recuperació funciona — una còpia de seguretat no verificada és una suposició.

Cap d'aquests passos no en substitueix cap altre. Qui n'aplica només un, ha reforçat una porta i n'ha deixat totes les altres obertes — qui els aplica tots set, té una defensa que resisteix fins i tot quan una sola capa falla.

El que aquesta arquitectura no substitueix

Cap de les mesures descrites fa superflua la diligència. Un mòdul que rebutja les sondes de .env no fa inofensiu un fitxer .env publicat per descuit. L'autenticació de dos factors no protegeix d'un usuari que llegeix el seu codi a algú que el truca per telèfon. I un tallafoc no substitueix una decisió sobre qui necessita realment quin permís. L'arquitectura de seguretat crea les condicions en què un sol error no esdevé de seguida un incident — no eximeix ningú de la diligència.

Preguntes freqüents

N'hi ha prou amb una contrasenya forta per protegir Odoo 19?

No. Una contrasenya es pot robar en un altre lloc, independentment de la seva qualitat, i aleshores funciona a qualsevol servei que accepti la mateixa contrasenya. Només la combinació amb l'autenticació de dos factors, un tallafoc al davant i una estructura de permisos assenyada dona una protecció que resisteix fins i tot després d'una contrasenya robada.

Com activo l'autenticació de dos factors a Odoo 19?

Instal·lar el mòdul «Two-Factor Authentication (TOTP)» mitjançant la gestió d'Apps, després activar l'obligatorietat a Configuració → Configuració general → Permisos i triar entre «Només empleats» i «Tots els usuaris». Cada usuari configura després el seu propi segon factor mitjançant un codi QR.

Què és una llista RBL, i per què Odoo en necessita una?

RBL (Real-time Blackhole List) és una llista d'adreces accessible per HTTP que pràcticament qualsevol tallafoc pot llegir. Odoo mateix no inclou cap llista així — el nostre mòdul Web RBL tanca aquesta bretxa detectant el trànsit d'atac al propi registre d'aplicació i retornant-lo com a llista RBL al tallafoc situat al davant.

Odoo 19 Community està prou protegit sense mòduls addicionals?

No del tot. Sense el mòdul Password Policy no hi ha longitud mínima per a les contrasenyes, sense Two-Factor Authentication no hi ha segon factor, i sense un mòdul com Web RBL, Odoo no detecta ni els intents de sondeig ni els intents d'inici de sessió repetits a través d'un reinici. Els quatre es poden afegir gratuïtament.

Disponibilitat

Web RBL és de disponibilitat pública sota l'AGPL-3 i funciona en producció a casa nostra en cinc llocs web:

github.com/Alex0176/odoo-web-rbl

La descripció completa de les funcions, amb tots els patrons, la puntuació i les llistes d'amenaces, és a l'entrada anterior: Web RBL – llista de bloqueig per al trànsit d'atac als propis llocs web.

Rebem de bon grat preguntes, comentaris i informes d'errors — preferiblement com a issue a GitHub.