Configurare Mail Protection di Sophos Firewall in Legacy mode

In Legacy mode, Sophos Firewall funziona come proxy di posta trasparente. Il mail server interno rimane l’endpoint SMTP effettivo; il firewall inoltra il traffico attraverso le regole firewall e NAT esistenti e nel frattempo lo controlla per spam, malware, tipi di file o corrispondenze Data Control.

Questo comportamento è sostanzialmente diverso dal MTA mode. Il firewall non diventa un Mail Transfer Agent, non assume la consegna dei messaggi per i domini protetti e non fornisce un MTA mail spool per questo percorso. Un test positivo della porta SMTP non dimostra quindi né la scansione proxy né l’applicazione della policy corretta.

⚠️ La modifica dello SMTP Deployment Mode è un cambiamento globale del percorso di protezione della posta. Prima di commutare devono essere documentati il backup, le policy esistenti, le regole firewall e NAT e un percorso di ripristino testato. Un problema MTA non è un motivo per passare al Legacy mode senza pianificazione.

Legacy mode in nove passaggi

1. Documentare il percorso SMTP in entrata e in uscita esistente con indirizzi IP, porte, NAT e Firewall Rule IDs.
2. Verificare se il proxy trasparente è davvero più adatto del MTA mode.
3. Assicurare un backup della configurazione e un accesso di gestione indipendente.
4. In Email > General settings, selezionare Switch to legacy mode.
5. Definire il limite di dimensione SMTP, l’azione per i messaggi sovradimensionati, IP Reputation, i limiti DoS e il comportamento TLS.
6. Creare solo le policy SMTP malware e SMTP spam necessarie oppure verificarne l’ordine.
7. Limitare i percorsi DNAT in entrata e SNAT in uscita al mail server effettivo.
8. Attivare Scan SMTP o Scan SMTPS nelle regole firewall che vengono realmente applicate.
9. Verificare i messaggi di test in entrata e in uscita mediante Rule ID, risultato della policy, certificato e log del proxy Legacy.

Scegliere Legacy mode o MTA mode

Legacy mode è adatto soprattutto agli ambienti esistenti in cui il mail server interno è già pubblicato direttamente tramite NAT e questo percorso deve essere mantenuto. SFOS si colloca in modo trasparente tra il peer remoto e il server. Destinazione MX, accettazione SMTP e logica di consegna rimangono parte del design del mail server esistente.

MTA mode è invece la scelta più adatta quando il firewall deve accettare direttamente i messaggi, instradarli per dominio protetto, inoltrarli e conservarli in uno spool in caso di errori temporanei di consegna. Mail logs e mail spool appartengono esplicitamente a questo modello operativo. La configurazione completa è descritta in Configurare Mail Protection in MTA mode.

Secondo la guida di SFOS 22, MTA mode non è disponibile su XGS 87/87w e XGS 88/88w. Questo non rende però automaticamente Legacy mode una buona architettura per la posta cloud. Microsoft 365, Google Workspace e i moderni servizi in hosting utilizzano requisiti propri per TLS, autenticazione e protezione dagli abusi. Prima di introdurre un proxy trasparente è necessario verificarne il supporto.

In breve: MTA mode dispone di un proprio flusso di posta. Legacy mode protegge un percorso SMTP già funzionante. Confondere i due modelli porta a cercare nel log sbagliato, nella destinazione NAT errata o in uno spool inesistente.

Topologia di esempio e percorso di ripristino

L’esempio seguente utilizza valori di documentazione e deve essere adattato all’ambiente reale prima dell’implementazione:

• mail server interno 10.20.30.25 nella zona DMZ
• indirizzo SMTP pubblico 192.0.2.25 sul percorso WAN
• servizio SMTP in entrata TCP 25
• SMTPS facoltativo su TCP 465, solo se i peer e il server utilizzano realmente questa variante
• regole firewall SMTP_In_Legacy e SMTP_Out_Legacy

192.0.2.25 appartiene all’intervallo TEST-NET e non è un valore di produzione. Prima della modifica si eseguono un test in entrata dall’esterno e un test in uscita con timestamp. Si salvano le Rule IDs attualmente applicate, l’indirizzo sorgente pubblico usato dal server in uscita e la catena di certificati.

Il percorso di ripristino non consiste soltanto nel ricambiare la modalità. Anche le nuove opzioni di scansione, l’ordine delle policy, il DNAT, le regole SNAT reflexive o manuali e i test temporanei devono poter essere ripristinati allo stato precedente documentato.

Definire le impostazioni SMTP globali

Limite di dimensione, azione per i messaggi sovradimensionati e protezione DoS

In Email > General settings > SMTP settings, Don’t scan emails greater than definisce la dimensione massima dei messaggi da sottoporre a scansione. Nel percorso SMTP, secondo la guida di SFOS 22, il valore 0 significa 51,200 KB e non illimitato. Per i messaggi più grandi sono disponibili Accept, Reject e Drop.

Accept consegna un messaggio sovradimensionato senza analizzarlo. Reject lo rifiuta e informa il mittente, mentre Drop lo elimina senza notifica. Questa scelta è una decisione consapevole in termini di rischio e operatività. Un Drop non testato complica la diagnosi; un Accept non valutato crea una lacuna di scansione che deve essere documentata.

Verify sender’s IP reputation verifica l’IP del mittente prima dei criteri antispam della policy SMTP. I valori SMTP DoS limitano connessioni, messaggi e destinatari. I limiti di produzione vengono derivati dal volume reale di posta e da una baseline, non copiati da un generico esempio trovato su internet.

Bypass spam check for SMTP/S authenticated connections ignora globalmente il controllo antispam per le connessioni che il server email segnala come autenticate. Questa scelta è accettabile solo dopo aver verificato autenticazione, sorgenti consentite e protezione dagli abusi del percorso. Un accesso riuscito non sostituisce né la scansione antimalware né un test negativo con una connessione non autenticata. Anche i domini in Spam check exceptions costituiscono un bypass globale e non vengono usati come rapido sostituto di un’eccezione strettamente limitata.

Il banner email globale offre Inline, no conversion, MIME part e Off. Appare solo se la scansione SMTP o SMTPS è attiva nella regola firewall corrispondente. Poiché la modifica del body può invalidare una firma DKIM esistente, il percorso in uscita reale viene validato controllando gli header presso il destinatario.

Non sopravvalutare TLS per una casella selezionata

In SMTP TLS configuration si seleziona il certificato CA o server previsto per la scansione. Allow invalid certificate rimane disattivato. Secondo la guida, Disable legacy TLS protocols disattiva soltanto i protocolli precedenti a TLS 1.1 e non dimostra una specifica sessione TLS 1.2 o TLS 1.3.

Sophos segnala inoltre un’importante limitazione del Legacy mode: il firewall stabilisce la connessione TLS usando l’indirizzo IP del dominio anziché il nome del dominio. Se più domini condividono lo stesso indirizzo IP, la convalida del certificato può fallire. In questo caso Sophos consiglia un percorso di protezione diverso, come Sophos Email Security. Il controllo non viene aggirato con Allow invalid certificate.

Require TLS negotiation impone TLS per i Remote Hosts o le reti selezionate; Require sender email domains lo impone per i domini mittenti. Se la connessione TLS non può essere stabilita, SFOS elimina i messaggi interessati. Skip TLS negotiation consente intenzionalmente connessioni SMTP non cifrate verso i peer selezionati e deve essere usato solo per eccezioni documentate.

Utilizzare consapevolmente le policy di scansione

Dopo l’attivazione della sottoscrizione Email Protection, Sophos Firewall applica automaticamente la policy predefinita default-smtp-av al traffico SMTP in Legacy mode. Le policy personalizzate vengono create in Email > Policies ed elaborate nell’ordine dell’elenco. Occorre quindi verificare innanzitutto quale policy esistente corrisponde al mittente e al destinatario interessati.

SMTP malware scan

Una policy SMTP malware scan controlla i tipi di file bloccati, le eccezioni MIME, la scansione antivirus e le azioni di consegna. Con Single antivirus, secondo la guida il motore selezionato si applica solo ai messaggi in entrata; quelli in uscita vengono analizzati da entrambi i motori. Dual antivirus esegue in sequenza il motore primario e quello secondario.

L’azione Quarantine viene combinata con le azioni per il destinatario e l’amministratore. Don’t deliver, Deliver original e Remove and deliver hanno conseguenze molto diverse. Un allegato protetto o non analizzabile non deve essere automaticamente equiparato a malware. Ogni azione richiede quindi un messaggio di test, uno stato previsto per il destinatario e un percorso di rilascio documentato.

Quarantine non significa automaticamente che il destinatario non riceva alcun messaggio; la Delivery option for recipient resta determinante. Secondo Sophos, Notify sender funziona solo insieme a Don’t deliver. Gli allegati protetti non vengono analizzati, ma possono comunque attivare una notifica. L’azione separata per l’amministratore stabilisce se agli amministratori non viene inviata alcuna copia, viene inviato l’originale o un messaggio senza allegato. Questi quattro risultati non vengono dedotti da un solo messaggio di prova riuscito.

SMTP spam scan

Una policy SMTP spam scan può corrispondere alla classificazione spam, alla sorgente o destinazione, a una RBL, alla dimensione del messaggio, agli header o a una Data Control List. A seconda del percorso, sono disponibili le azioni Reject, Accept, Change recipient, Prefix subject, Drop e Quarantine.

Il criterio Data control list e l’assegnazione SPX in questa policy si applicano solo ai messaggi in uscita. None, invece, applica l’azione selezionata a tutti i messaggi tra i gruppi di mittenti e destinatari specificati. Change recipient non consegna anche al destinatario originale, ma lo sostituisce con la destinazione configurata. Questi tre ambiti vengono verificati con un caso destinatario positivo e uno negativo prima di collocare la policy nell’ordine di produzione.

Preparare tipi di file personalizzati e Data Control

In Legacy mode, i tipi di file personalizzati si creano in Email > Policies > File type > Add a partire da un template, da estensioni o da tipi MIME. Le estensioni vanno inserite senza il punto iniziale e solo i tipi personalizzati sono modificabili. Un nuovo tipo non viene aggiunto automaticamente alle policy esistenti. Occorre aprire la scan policy interessata, aggiungere il tipo e salvarla nuovamente. Un test positivo con un allegato e un test negativo simile mostrano se viene applicata davvero l’azione prevista.

Una Data Control List si crea in Email > Data control list > Add a partire dalle Content Control List necessarie. I filtri Type e Region aiutano a selezionare solo i modelli pertinenti di dati finanziari, di identità o di altri dati sensibili. Il match della lista non stabilisce ancora un’azione; questa viene configurata nella scan policy collegata. Una piccola lista pilota con un test positivo e uno negativo è più sicura di un’ampia raccolta di CCL non verificate.

In Legacy mode è possibile selezionare SPX in questa policy per i messaggi in uscita. Il modello di password, il portale e la verifica costituiscono tuttavia un processo di sicurezza separato, descritto in Configurare la crittografia email SPX. Alla prima prova di base del proxy non si aggiungono una Data Control List o un’assegnazione SPX.

Una classificazione errata confermata non si risolve disattivando una policy estesa. Creare e testare in sicurezza le eccezioni email spiega come ignorare singoli controlli per una combinazione precisa di sorgente, mittente e destinatario e come testare successivamente il traffico che non deve corrispondere.

Utilizzare l’email journaling opzionale nel rispetto della protezione dei dati

In Email > General settings > Email journaling > Add, SFOS può inviare le copie dei messaggi SMTP/S in entrata destinati a utenti o gruppi di indirizzi selezionati a un indirizzo di journaling separato. La selezione Any include tutti i messaggi in entrata. La funzione si applica solo a SMTP/S e non registra il traffico POP o IMAP.

Il journaling crea una copia aggiuntiva dell’email. Non costituisce automaticamente un archivio a prova di manomissione e non dimostra il rispetto degli obblighi legali di conservazione. Prima di attivarlo si definiscono lo scopo, i destinatari autorizzati, l’accesso alla casella di journaling, la crittografia, il periodo di conservazione, lo spazio necessario e il responsabile.

Per il primo test si seleziona una sola casella di prova invece di Any. Un messaggio in entrata destinato a questa casella deve comparire nella destinazione normale e nella casella di journaling; un messaggio per un destinatario non selezionato non deve generare alcuna copia. L’indirizzo di journaling non deve attivare un flusso che rinvia la copia a SFOS e crea un loop.

La selezione dei destinatari viene ampliata solo dopo i test positivo e negativo. Per il rollback si rimuove la voce di journaling oppure si ripristina lo stato precedente documentato. Le copie già recapitate rimangono nella casella di journaling e devono essere gestite secondo le relative regole di conservazione.

Combinare NAT e regole firewall

Pubblicare il percorso SMTP in entrata

Per i messaggi in entrata, una regola DNAT traduce l’indirizzo WAN pubblico verso il mail server interno. Original Source viene limitato per quanto consentito dal design della posta; Original Destination è l’indirizzo pubblico previsto; Translated Destination è 10.20.30.25 o il mail server effettivo. Original service e translated service restano limitati alle porte SMTP realmente offerte.

Una regola reflexive crea inoltre SNAT per la direzione opposta. Viene selezionata solo se questa esatta identità sorgente pubblica è prevista per il percorso in uscita. Più collegamenti WAN, smarthost o percorsi provider differenti richiedono un design specifico di routing e SNAT. L’ordine generale e la zona di destinazione dopo il NAT sono spiegati in Pubblicare un server tramite DNAT.

Utilizzare due regole firewall ristrette

Per la verifica, due regole separate sono più comprensibili di una regola bidirezionale con più zone e oggetti Any:

• In entrata: da WAN alla zona del mail server interno, host di destinazione 10.20.30.25, solo i servizi SMTP necessari, logging attivato
• In uscita: zona e host del mail server interno verso WAN o lo smarthost specifico, solo i servizi SMTP necessari, logging attivato

In Scan email content si attiva Scan SMTP in entrambe le direzioni necessarie e Scan SMTPS solo quando SMTPS viene realmente utilizzato. Una casella attivata non aggiunge automaticamente un servizio mancante a un design di sicurezza corretto. Servizio, NAT, listener del server e opzione di scansione devono descrivere lo stesso percorso di porta.

Le regole vengono posizionate sopra quelle più generali che corrispondono già allo stesso traffico. Dopo il salvataggio, è determinante la Firewall Rule ID registrata. Struttura delle regole, zona NAT e ordine sono approfonditi in Configurare in sicurezza le regole di Sophos Firewall.

Verificare il flusso di posta e la scansione proxy

Per prima cosa si invia un piccolo messaggio esterno a una casella di test. In seguito il mail server interno invia un secondo messaggio a un destinatario esterno controllato. Entrambi i test ricevono oggetti univoci e timestamp UTC.

Per STARTTLS sulla porta 25 e una connessione TLS diretta sulla porta 465, da un sistema di test autorizzato possono essere utili i seguenti controlli in sola lettura:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

mail.example.net viene sostituito con il FQDN effettivo e si testano solo le porte realmente offerte. OpenSSL conferma raggiungibilità, catena di certificati e parametri TLS negoziati. Non dimostra né la consegna riuscita né la scansione malware, spam o Data Control.

In Log Viewer, sorgente, destinazione, servizio, azione e Firewall Rule ID devono corrispondere alle nuove regole. Per il proxy SMTP/S Legacy, awarrensmtp.log e awarrenmta.log vengono correlati con lo stesso timestamp. I file di log sono descritti in Servizi e log di Sophos Firewall.

Segue un test negativo. Una sorgente non prevista, una porta non autorizzata o un messaggio di test privo del criterio della policy non devono ricevere per errore lo stesso percorso di protezione. Nei test di produzione non si usa malware reale; per verificare la scansione si impiegano modelli di test innocui consolidati e una casella controllata.

Circoscrivere gli errori in base al sintomo

SMTP funziona, ma la policy non viene applicata

Verificare innanzitutto la Firewall Rule ID. Se corrisponde un’altra regola, correggere ordine, sorgente, destinazione, destinazione NAT e servizio. Se corrisponde la regola prevista, Scan SMTP o Scan SMTPS, ordine delle policy e gruppi di mittenti e destinatari devono essere coerenti con il test. Una policy da sola non attiva il proxy trasparente.

La posta in entrata non raggiunge il server

Controllare separatamente l’indirizzo di destinazione pubblico, l’hit DNAT, la translated destination, la zona di destinazione, il listener del server e il percorso di ritorno. Una connessione TCP aperta fino al firewall non dimostra che DNAT e la regola firewall raggiungano il server interno. Packet Capture e Rule ID devono mostrare ingresso e inoltro.

La posta in uscita usa l’indirizzo IP pubblico sbagliato

Controllare SNAT, la regola reflexive, il gateway WAN, la rotta SD-WAN e il comportamento dei reply packets. Il proxy Legacy non seleziona automaticamente l’indirizzo sorgente pubblico richiesto per SPF, RDNS o l’autorizzazione del provider. Prima di una modifica globale di Route Precedence, dimostrare il percorso specifico.

TLS non funziona dopo l’attivazione della scansione

Registrare FQDN, IP di destinazione, certificato, emittente, catena e versione negoziata. Con più domini su un indirizzo IP, il controllo del certificato basato sull’IP documentato può essere la causa. Allow invalid certificate non viene attivato come soluzione rapida.

Manca un messaggio e nel MTA mail spool non compare nulla

Questo non è un criterio di successo utile in Legacy mode, perché mail spool e i mail logs specifici dell’MTA appartengono al MTA mode. La catena rilevante comprende la regola firewall, il NAT, i log del server SMTP, Log Viewer, awarrensmtp.log e awarrenmta.log. I messaggi in quarantena vengono controllati separatamente in Email > SMTP quarantine.

Eseguire un rollback sicuro

Per il rollback si ripristinano innanzitutto le regole pilota e le opzioni di scansione allo stato precedente documentato. In seguito si rimuovono le nuove assegnazioni delle policy oppure se ne ripristina l’ordine. Le modifiche temporanee a DNAT, SNAT o certificati vengono rimosse solo se nessun altro servizio ne dipende.

Solo dopo si ripristina lo SMTP Deployment Mode, se il change includeva questa commutazione. Il flusso di posta originale in entrata e in uscita deve tornare a funzionare con le Rule IDs, gli indirizzi pubblici e i log server previsti. Messaggi, contenuti della quarantena o log del proxy non vengono eliminati come operazione standard di rollback.

Checklist operativa

• Il proxy trasparente è stato scelto consapevolmente e i requisiti MTA sono stati esclusi.
• Backup, accesso di gestione e Rule IDs originali sono documentati.
• Il limite di dimensione SMTP, l’azione per i messaggi sovradimensionati, IP Reputation e i limiti DoS sono motivati.
• Certificato, eccezioni TLS e domini interessati sono stati verificati.
• DNAT, SNAT, zona di destinazione e porte reali del server corrispondono.
• Le regole firewall in entrata e in uscita sono ristrette, registrate e la loro corrispondenza è stata dimostrata.
• Le policy predefinite e personalizzate hanno un ordine tracciabile.
• Il journaling opzionale è limitato ai destinatari necessari e ha uno scopo documentato di protezione e conservazione dei dati.
• I test positivo, negativo, TLS e di consegna sono riusciti.
• I log del proxy Legacy e del mail server possono essere correlati temporalmente.
• Responsabile, data di revisione e percorso di ripristino completo sono registrati.

FAQ