Architettura di sicurezza Odoo 19: combinare correttamente firewall, 2FA, permessi e Web RBL

Sui nostri cinque siti web Odoo è raggiungibile dalla rete pubblica, e questa non è un'eccezione, ma la norma: chi gestisce un'offerta, un negozio o un accesso clienti ha un server pubblico. Basta una sola password vulnerabile, un file di configurazione dimenticato o un permesso troppo generoso perché un server pubblico diventi un server aperto.

Questo articolo mostra come mettere in sicurezza Odoo 19 nel modo giusto — non con una singola misura, ma con più livelli che si completano a vicenda: firewall e reverse proxy, il nostro modulo open source Web RBL, autenticazione a due fattori, policy delle password e permessi — e quali tentativi di attacco ciascuno di essi intercetta davvero. In chiusura trovate una guida passo passo con cui è possibile replicare il tutto su qualsiasi installazione Odoo.

Difesa in profondità: perché una sola misura non basta mai

Ogni singola misura di sicurezza ha una lacuna. Un firewall non vede ciò che accade in una maschera di accesso di Odoo. Una password robusta non protegge se è già stata rubata altrove. Una struttura di permessi non serve a nulla contro un aggressore che non ha ancora effettuato alcun accesso. Il principio che colma queste lacune si chiama difesa in profondità (defense in depth): più livelli indipendenti, ciascuno dei quali preso da solo sarebbe aggirabile — ma tutti insieme no.

Da noi i livelli sono quattro, ciascuno con un compito diverso:

• Firewall / reverse proxy — tiene lontano ciò che è palesemente malevolo prima ancora che raggiunga il server
• Web RBL — collega i due lati: Odoo impara dal proprio registro applicativo ciò che il firewall non può affatto vedere, e glielo restituisce
• Odoo stesso — autenticazione a due fattori, policy delle password, permessi, gestione delle sessioni
• Database & esercizio — backup, protezione dell'accesso all'amministrazione, segreti fuori da ogni registro

Le sezioni seguenti esaminano ogni livello singolarmente.

Livello 1: firewall e reverse proxy

Il firewall è la prima istanza che vede una richiesta e l'unica in grado di tenere lontano un aggressore da ogni servizio sul server — non solo dal sito web, ma anche dal server di posta, dall'accesso VPN e dalla propria interfaccia di amministrazione. Ciò che in questo punto conviene attivare dipende dal produttore, ma le forme costruttive sono le stesse con OPNsense, pfSense, HAProxy, FortiGate, Sophos o Check Point:

Liste RBL: la via standard con cui viene distribuita la reputazione

RBL sta per Real-time Blackhole List, un termine del mondo della posta elettronica: un indirizzo per riga, consultabile via HTTP, ricaricato regolarmente. Praticamente ogni firewall può leggere una tale lista e ricavarne regole — OPNsense e pfSense come URL Table Alias, HAProxy come file ACL, FortiGate come External Block List, Palo Alto come External Dynamic List, Cisco, Sophos, Juniper e MikroTik con nomi propri per lo stesso principio.

È proprio qui che interviene il nostro modulo — ed è proprio qui che inizia il secondo livello.

Livello 2: Web RBL — il ponte tra applicazione e firewall

Un firewall vede pacchetti, non logica applicativa. Non sa che una richiesta verso /xmlrpc/2/common è un tentativo di accesso, che venti percorsi diversi in quattordici secondi sono uno scanner, o che un indirizzo ha appena indovinato con successo una password. Tutto questo lo sa solo Odoo stesso. Web RBL, il nostro modulo open source (AGPL-3), rende utilizzabile questa conoscenza — per Odoo stesso e, distribuito come lista RBL, anche per il firewall a monte.

Liste di minacce confrontate di continuo, ciascuna con un proprio livello.

In breve, ciò che è descritto in dettaglio nell'articolo precedente:

• Riconoscimento di modelli nei percorsi: file .env, directory .git, file di configurazione, sonde WordPress e PHP, path traversal, esecuzione di comandi tramite le nuove interfacce di IA
• Difesa degli accessi che conta attraverso i riavvii — a differenza del contatore di Odoo, che vive nella memoria di lavoro
• Valutazione di ogni indirizzo da 0 a 100, con motivazione in linguaggio semplice
• Configurazioni errate (QNAP, Autodiscover, Synology) vengono riconosciute e mai bloccate, perché un blocco non risolve il difetto, ma lo nasconde soltanto
• Liste di minacce di terzi come Spamhaus, FireHOL e nodi di uscita Tor, confrontate di continuo
• Lista consentita per indirizzi che non devono mai essere bloccati

Per questo articolo due caratteristiche sono particolarmente importanti, perché sono direttamente collegate al firewall e all'accesso.

Una lista lenta è una lista di cui ci si può fidare

La lista consentita — indirizzi che non vengono mai bloccati, ad esempio i collegamenti delle proprie sedi — di regola cambia raramente. È proprio questo il suo valore, non il suo difetto: se una lista tranquilla per giorni si muove appena, ogni rara modifica salta subito all'occhio. L'aggiornamento automatico giornaliero non esiste perché cambierebbe molto, ma affinché la rara modifica non debba essere inserita a mano — ed è proprio il punto in cui ci si dimentica. Una delle nostre stesse configurazioni errate nel mese scorso è stata notata esattamente così: non per i molti eventi, ma per quell'unico che nessuno conosceva, finché l'API web QNAP di un cliente non è stata bloccata per errore. Da allora QNAP figura nell'elenco delle configurazioni errate che non vengono mai bloccate, ma solo segnalate.

L'accesso è il luogo che un firewall non vede

Un firewall può bloccare un indirizzo. Non può sapere se un accesso sia riuscito, e tanto meno se provenisse da un indirizzo che poco prima cercava ancora credenziali. Web RBL sì: una valutazione oltre una soglia impostabile vieta del tutto l'accesso, e un accesso riuscito da un indirizzo sospetto viene segnalato — è l'anello di collegamento con il livello successivo.

Livello 3: mettere in sicurezza Odoo stesso

Autenticazione a due fattori: un secondo segreto che non è riutilizzabile

Il problema più grande delle password non è la loro qualità, ma il loro riutilizzo. Una password rubata presso un altro servizio funziona da noi esattamente allo stesso modo, finché è la stessa. L'autenticazione a due fattori (2FA, detta anche TOTP) vi oppone un secondo segreto: un codice a sei cifre che cambia ogni trenta secondi e viene calcolato a partire da un segreto noto solo al proprio smartphone. Una password rubata da sola non basta più.

Odoo 19 Community lo include di serie — come modulo installabile Two-Factor Authentication (TOTP), integrato da un'opzione di ripiego via e-mail. Ogni utente lo configura da sé, tramite codice QR, con qualsiasi comune app di autenticazione:

La configurazione: scansionare il codice QR, confermare una volta il codice a sei cifre, fatto.

Questo da solo, però, aiuta solo chi lo configura di propria iniziativa — e l'esperienza mostra che senza obbligo resta una minoranza. Odoo prevede perciò una policy di obbligatorietà: o solo per i collaboratori (utenti interni) o per tutti, utenti del portale inclusi. Senza un secondo segreto configurato nessuno supera più la maschera di accesso senza almeno confermarlo con un codice via e-mail.

Policy delle password: una lunghezza minima non è scontata

Senza modulo aggiuntivo Odoo Community non impone alcuna lunghezza minima per le password — un utente può assegnare una password di tre caratteri se nessuno glielo impedisce. Il modulo Password Policy colma esattamente questa lacuna: una lunghezza minima imposta lato server, non soltanto suggerita nel browser. Chi vuole di più — una scadenza obbligatoria, una cronologia contro il riutilizzo — ha bisogno per questo di un modulo OCA o di terzi; nella versione Community ciò è volutamente tenuto snello.

Permessi: accede solo chi ne ha bisogno

Odoo separa di serie tre livelli: utenti del portale (solo il proprio portale clienti o fornitori), utenti interni (il backend, con diritti per applicazione) e amministratori (accesso illimitato comprese le impostazioni tecniche). L'errore più frequente non è una password troppo debole, ma un ruolo di amministratore assegnato in modo troppo generoso: chi deve solo emettere fatture non ha bisogno di accedere alle impostazioni di sistema.

Due principi reggono la maggior parte del carico:

Entrambe le cose si possono verificare nella stessa vista in cui si configura anche l'autenticazione a due fattori:

Una panoramica, quattro leve: password, secondo fattore, chiavi API, dispositivi connessi.

Sessioni e dispositivi: chi è connesso in questo momento

La stessa vista mostra anche da quali dispositivi un account è attualmente connesso — e consente di disconnetterne uno solo o tutti in una volta. Dopo la perdita di un portatile o il sospetto di una password compromessa, è il passo efficace più rapido: la sessione termina subito, indipendentemente dal fatto che la password sia già stata cambiata.

Livello 4: database ed esercizio

Il quarto livello è il meno visibile e al tempo stesso il più imperdonabile, perché un errore qui può vanificare tutto ciò che è stato costruito prima.

• Backup regolari e verificati, conservati separatamente dal server stesso. Un backup che non è mai stato ripristinato è un'ipotesi, non un backup.
• I segreti non vanno in alcun file di log. Password, chiavi API, dati di licenza — chi scrive estensioni proprie dovrebbe trattarli come la password principale stessa: non registrarli da nessuna parte, nemmeno «solo per il debug».
• Tenere aggiornati i moduli, e soprattutto quelli di terzi. I moduli aggiuntivi liberi (OCA e altri) sono per natura in ritardo rispetto alle nuove versioni di Odoo; prima di ogni installazione vale la pena controllare quali dipendenze vengono installate automaticamente.

Il percorso di accesso nel suo insieme

I quattro livelli non agiscono uno dopo l'altro in stanze separate, ma sulla stessa richiesta, livello per livello. L'esempio di un accesso lo rende più chiaro:

Cinque punti in cui una richiesta malevola può fermarsi prima di arrivare al vero obiettivo — e uno solo in cui un utente legittimo li supera tutti.

Scenari di attacco e relative contromisure

La panoramica seguente associa modelli di attacco reali ai livelli che li fermano davvero. Molti di essi non sono teoria, ma osservazioni nostre di diciassette giorni di traffico reale sui nostri cinque siti web.

Passo passo: mettere in sicurezza la propria installazione Odoo

L'ordine seguente è quello in cui procederemmo noi stessi — dall'effetto maggiore all'impostazione più fine.

1. Rendere obbligatoria l'autenticazione a due fattori

1. Se non ancora installato: aprire App, cercare «Two-Factor Authentication» e installare (con più siti web si consiglia inoltre «Two-Factor Authentication by Mail» come opzione di ripiego).
2. Aprire Impostazioni → Impostazioni generali → Permessi.
3. Attivare «Rendi obbligatoria l'autenticazione a due fattori».
4. Scegliere la policy: «Solo collaboratori» per gli utenti interni, «Tutti gli utenti» se si vogliono includere anche gli utenti del portale (clienti con accesso).
5. Salvare. Dal prossimo tentativo di accesso Odoo richiede a ogni utente senza un secondo segreto configurato almeno il codice via e-mail, finché non ha configurato l'app di autenticazione.

2. Stabilire una lunghezza minima per le password

1. Aprire App, cercare «Password Policy» e installare.
2. Aprire Impostazioni → Impostazioni generali → Permessi.
3. Impostare «Lunghezza minima della password» — dodici caratteri sono un valore di partenza ragionevole.
4. Salvare. La regola vale da subito per ogni nuova o modificata assegnazione di password, non retroattivamente per le password esistenti.

3. Rivedere i permessi

1. Aprire Impostazioni → Utenti & Aziende → Utenti.
2. Aprire ogni utente singolarmente e controllare la scheda con i diritti di accesso per applicazione: questa persona ha davvero bisogno di «Manager» o «Amministratore», oppure basta «Utente»?
3. Controllare in modo particolare: chi ha accesso alle «Impostazioni» stesse? Dovrebbe essere un gruppo molto piccolo.
4. Per ogni collegamento esterno (contabilità, script propri, rilevazione dei tempi) creare nella scheda «Sicurezza dell'account» dell'utente tecnico corrispondente una chiave API propria, anziché comunicare la password dell'utente.

4. Installare Web RBL e osservare prima di attivare i blocchi

1. Copiare il modulo da github.com/Alex0176/odoo-web-rbl nel percorso degli addon e installarlo.
2. Osservare per alcuni giorni: il menu Web RBL → Analisi mostra quali modelli intervengono realmente.
3. Solo dopo attivare web_rbl.sperren_aktiv (Impostazioni → Tecnico → Parametri di sistema) — da qui in poi le sonde riconosciute vengono effettivamente respinte.
4. Integrare l'elenco di blocco nel firewall come lista RBL, all'indirizzo indicato nel modulo e protetto da token (con OPNsense/pfSense come URL Table Alias, con HAProxy come file ACL).

5. Mettere in sicurezza il firewall stesso

1. Rendere l'interfaccia di amministrazione del firewall raggiungibile esclusivamente dalla rete interna, mai tramite lo stesso indirizzo pubblico del sito web.
2. Attivare gli aggiornamenti di sicurezza automatici per il software del firewall, se il produttore li offre.
3. Verificare la configurazione TLS: solo versioni di protocollo aggiornate, disattivare gli algoritmi di cifratura obsoleti.
4. Se disponibile: integrare direttamente sul firewall una lista di reputazione nota (ad esempio Spamhaus DROP) — indipendentemente da Web RBL, perché così il firewall vede anche il traffico verso servizi che Odoo non raggiunge mai.

6. Chiudere l'amministrazione del database

1. Verificare se /web/database/manager è raggiungibile dall'esterno — in caso affermativo, impostare nella configurazione di Odoo list_db = False o bloccare il percorso a livello di firewall.
2. Impostare la password principale dell'amministrazione del database lunga e casuale e non annotarla in alcun luogo leggibile da altri.

7. Verificare il backup, non solo configurarlo

1. Configurare un backup automatico e regolare, conservato separatamente dal server Odoo.
2. Ripristinarlo realmente almeno una volta e verificare che il ripristino funzioni — un backup non verificato è un'ipotesi.

Nessuno di questi passi sostituisce un altro. Chi ne attua uno solo ha rinforzato una porta e lasciato aperte tutte le altre — chi li attua tutti e sette ha una difesa che tiene anche quando un singolo livello cede.

Ciò che questa architettura non sostituisce

Nessuna delle misure descritte rende superflua la diligenza. Un modulo che respinge le sonde .env non rende innocuo un file .env pubblicato per errore. L'autenticazione a due fattori non protegge da un utente che legge il proprio codice a un chiamante al telefono. E un firewall non sostituisce una decisione su chi abbia realmente bisogno di quale permesso. L'architettura di sicurezza crea le condizioni in cui un singolo errore non diventa subito un incidente — non esonera nessuno dalla diligenza.

Domande frequenti

Basta una password robusta per mettere in sicurezza Odoo 19?

No. Una password può essere rubata altrove, del tutto indipendentemente dalla sua qualità, e funziona allora presso ogni servizio che accetta la stessa password. Solo la combinazione con l'autenticazione a due fattori, un firewall a monte e una struttura di permessi sensata dà una protezione che regge anche dopo il furto di una password.

Come si attiva l'autenticazione a due fattori in Odoo 19?

Installare il modulo «Two-Factor Authentication (TOTP)» tramite la gestione delle App, quindi in Impostazioni → Impostazioni generali → Permessi attivare l'obbligatorietà e scegliere tra «Solo collaboratori» e «Tutti gli utenti». Ogni utente configura poi il proprio secondo fattore tramite codice QR.

Che cos'è una lista RBL, e perché Odoo ne ha bisogno?

RBL (Real-time Blackhole List) è una lista di indirizzi consultabile via HTTP, che praticamente ogni firewall può leggere. Odoo stesso non include una tale lista — il nostro modulo Web RBL colma questa lacuna riconoscendo il traffico di attacco dal proprio registro applicativo e restituendolo come lista RBL al firewall a monte.

Odoo 19 Community è sufficientemente protetto senza moduli aggiuntivi?

Non completamente. Senza il modulo Password Policy non esiste una lunghezza minima per le password, senza Two-Factor Authentication non c'è un secondo fattore, e senza un modulo come Web RBL Odoo non riconosce né i tentativi di sondaggio né i ripetuti tentativi di accesso attraverso un riavvio. Tutti e quattro si possono aggiungere gratuitamente.

Disponibilità

Web RBL è disponibile pubblicamente sotto AGPL-3 e da noi è in produzione su cinque siti web:

github.com/Alex0176/odoo-web-rbl

La descrizione completa delle funzioni con tutti i modelli, la valutazione e le liste di minacce si trova nell'articolo precedente: Web RBL – elenco di blocco per il traffico di attacco sui propri siti web.

Domande, osservazioni e segnalazioni di errori sono benvenute — preferibilmente come issue su GitHub.