Configurare Sophos Firewall MTA con Microsoft 365
Sophos Firewall può operare in MTA mode come gateway di posta separato davanti a Microsoft 365. I messaggi in entrata raggiungono prima il firewall e vengono poi consegnati a Exchange Online Protection. Exchange Online rinvia i messaggi in uscita al firewall tramite un connettore, affinché vengano analizzati e inoltrati a Internet.
Questo design è possibile, ma non è automaticamente l’architettura migliore. Sophos Email, Microsoft Defender for Office 365 e Mail Protection sulla firewall si sovrappongono in parte. Prima della modifica si stabilisce quale sistema è responsabile di spam, malware, quarantena, TLS, DKIM e troubleshooting.
⚠️ Un’autorizzazione relay troppo ampia può trasformare la firewall in un open relay. Prima di modificare il record MX devono restare disponibili una sessione amministrativa locale, il flusso esistente e un percorso di ripristino testato. Il passaggio in produzione avviene solo quando un test di relay non autorizzato viene respinto in modo affidabile.
Disegnare prima il flusso bidirezionale
Il percorso in entrata è Internet → Sophos Firewall MTA → Exchange Online Protection → casella Microsoft 365. Il record MX pubblico punta quindi all’indirizzo SMTP pubblico della firewall. La policy SMTP route and scan consegna poi alla destinazione Microsoft specifica del tenant, ad esempio example-com.mail.protection.outlook.com.
Il percorso in uscita è Exchange Online → connettore Microsoft 365 → Sophos Firewall MTA → Internet. La firewall deve accettare relay solo dalle reti Exchange Online Protection correnti. HELO, certificato, IP sorgente pubblico, PTR/rDNS, SPF, DKIM e DMARC devono corrispondere a questo percorso.
Configurare Mail Protection in MTA mode spiega le basi MTA, i campi delle policy, la quarantena e i log. Questo articolo si concentra sul collegamento con Microsoft 365.
Valori di esempio e prerequisiti
L’esempio usa il dominio example.com, il FQDN della firewall mail.example.com, l’indirizzo di documentazione 192.0.2.25 e la destinazione tenant example-com.mail.protection.outlook.com. Vanno sostituiti con il dominio reale, un indirizzo pubblico fisso e la destinazione Microsoft effettiva. 192.0.2.25 appartiene a TEST-NET e non deve essere usato in produzione.
TCP 25 deve funzionare da Internet verso la firewall, dalla firewall verso Microsoft 365 e dalla firewall verso server di posta esterni. Servono inoltre una licenza Email Protection adeguata, supporto MTA sul modello, un certificato pubblico attendibile, accesso DNS controllato e permessi per Exchange Admin Center e il DNS autoritativo.
Le reti Exchange Online Protection cambiano. Non si copiano da un esempio statico, ma si mantengono dalla lista corrente degli endpoint Microsoft 365 collegata da Sophos. Va usata la voce Exchange Online obbligatoria per *.mail.protection.outlook.com e *.mx.microsoft su TCP 25 (ID endpoint 10 nell’istanza Worldwide), non l’insieme molto più ampio di tutti gli indirizzi Exchange Online. Per un’altra istanza cloud Microsoft si usa la lista corrispondente. Si documentano responsabile e intervallo di revisione degli oggetti host.
Collegare Microsoft 365 e SFOS in otto passaggi
- Registrare MX, SPF, connettori, header, IP sorgente pubblico e percorso di ripristino correnti.
- Preparare MTA mode, regola MTA automatica, certificato e scansione in uscita su SFOS.
- Creare oggetti IP host separati per gli intervalli EOP correnti.
- Consentire
SMTP RelaydaWAN, limitare Host-based relay agli oggetti EOP e bloccare tutte le altre sorgenti. - Creare una policy SMTP route and scan per il dominio protetto e la destinazione Microsoft del tenant.
- Creare in Exchange Online un connettore da Microsoft 365 all’indirizzo pubblico della firewall.
- Modificare MX e SPF durante una finestra di manutenzione.
- Verificare messaggi in entrata, in uscita e relay respinti con header, Mail logs, spool e trace Microsoft.
Preparare Sophos Firewall
MTA mode, regola automatica e certificato
Attivare MTA mode in Email > General settings. SFOS crea Auto added firewall policy for MTA per SMTP e SMTPS. La regola non viene modificata e resta in cima come raccomandato da Sophos. Se manca nonostante MTA mode sia attivo, non si crea una sostituzione Any-to-Any: prima si verificano modalità, configurazione e percorso di supporto.
In SMTP settings, impostare SMTP hostname sul dominio previsto. Selezionare un certificato pubblico attendibile in SMTP TLS configuration e lasciare Allow invalid certificate disattivato. Scan outgoing mails deve essere attivo se si vogliono analizzare anche i messaggi provenienti da Exchange Online.
Consentire il relay dalle sorgenti EOP
In Hosts and services > IP host, creare un oggetto con nome chiaro per ogni intervallo SMTP corrente della voce Microsoft, ad esempio con il prefisso O365_EOP_. Non aggregare gli intervalli in una rete più ampia. Se SMTP viene pubblicato o instradato su IPv6, includere anche gli intervalli IPv6 elencati; altrimenti, evitare che un percorso IPv6 involontario aggiri il controllo IPv4. Dopo una modifica Microsoft, aggiungere o rimuovere le reti con una modifica controllata e ripetere i test.
Attivare SMTP Relay per WAN in Administration > Device access. Da solo questo selettore di zona è troppo ampio e viene quindi ristretto in Email > Relay settings > Host-based relay:
- Allow relay from hosts/networks: solo gli oggetti EOP mantenuti;
- Block relay from hosts/networks: Any.
Sophos valuta una corrispondenza Allow prima del Block sovrapposto. Per questo la lista Allow non deve contenere reti provider o cloud ampie né Any. Upstream host definisce separatamente le reti da cui vengono accettati messaggi in entrata per i domini protetti; questa autorizzazione non concede a tali sorgenti un relay in uscita illimitato.
Per la normale posta Internet in entrata, la procedura Sophos imposta Upstream host > Allow relay from hosts/networks su Any. Questo consente agli host SMTP esterni di consegnare ai domini protetti e non è la stessa autorizzazione dell’Host-based relay in uscita. Se davanti a SFOS è già presente un gateway esterno definito, la lista Upstream viene limitata alle sue reti sorgente reali.
Policy route and scan per la consegna Microsoft
Creare il dominio protetto come Email address/domain in Email > Address group. Aggiungere quindi in Email > Policies and exceptions > Add a policy > SMTP route and scan una policy con:
- l’Address Group in Protected domain;
- Global action: Accept;
- Route by: DNS host e la destinazione Microsoft specifica del tenant;
- impostazioni di protezione spam, malware, file e dati scelte consapevolmente.
L’host di routing non è il record MX pubblico di example.com dopo che punta alla firewall. Altrimenti la firewall consegna a sé stessa e crea un loop. La destinazione Microsoft reale viene registrata prima della modifica del MX e deve essere risolta correttamente da SFOS.
Creare il connettore Exchange Online
In Exchange Admin Center aprire Mail flow > Connectors > Add a connector e selezionare Connection from: Office 365 e Connection to: Partner organization. In Use of connector, scegliere Only when email messages are sent to these domains e inserire * per instradare tutta la posta in uscita attraverso SFOS. Un elenco di domini volutamente limitato deve corrispondere al design documentato. In Routing, selezionare Route email through these smart hosts e usare l’IP pubblico o il FQDN mail.example.com della firewall. Questi campi seguono la procedura Microsoft 365 corrente di Sophos.
In Security restrictions, attivare Always use Transport Layer Security (TLS) to secure the connection (recommended). La procedura Sophos seleziona quindi Any digital certificate, including self-signed certificates. Questa scelta impone TLS, ma non verifica né una CA attendibile né il nome. In produzione, seguire la documentazione Microsoft sui connettori: selezionare Issued by a trusted certificate authority (CA) e richiedere anche il nome subject o SAN mail.example.com. Sostituirlo con il vero FQDN della firewall e verificarlo con un test del connettore.
La validazione del connettore può fallire prima del cambio DNS. Non sostituisce quindi il successivo test end-to-end né il test relay negativo. Dopo il salvataggio, Microsoft Message Trace deve confermare che i messaggi in uscita usino davvero il connettore e la firewall previsti.
Modificare MX e SPF in modo controllato
Il record MX pubblico punta a mail.example.com solo quando policy della firewall, relay EOP, destinazione Microsoft interna e connettore sono pronti. Ridurre il TTL prima della finestra. Conservare la vecchia destinazione MX per il rollback documentato, ma non in parallelo se i mittenti potrebbero eludere casualmente il nuovo controllo.
Il record SPF deve autorizzare ogni origine che invia realmente verso Internet. Sophos mostra v=spf1 include:spf.protection.outlook.com mx -all come semplice esempio: mx autorizza gli indirizzi degli host MX, mentre include:spf.protection.outlook.com resta necessario se Exchange Online invia anche direttamente a Internet per questo dominio. Se tutta la posta esterna esce invariabilmente tramite SFOS, non si autorizza per abitudine un percorso diretto Microsoft inutilizzato. Non sostituire mai alla cieca il record esistente: prima occorre censire gli altri servizi di invio, i sottodomini, le catene include e il limite SPF documentato da Microsoft di dieci meccanismi che generano query DNS. Gli header reali devono poi confermare che SPF passa per l’ultimo IP mittente osservato e che DKIM e DMARC restano allineati.
Verificare il percorso completo
Da un sistema di test esterno sono utili questi controlli in sola lettura:
dig MX example.com
dig A mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com
Sostituire i nomi di esempio con i valori reali. DNS, TCP e TLS non dimostrano la consegna. Testare almeno un messaggio esterno verso Microsoft 365, uno in uscita da Microsoft 365, un destinatario non valido e un tentativo relay da un IP non autorizzato.
Su SFOS correlare Email > Mail logs, Mail spool, SMTP quarantine, Log Viewer, smtpd_main.log, smtpd_reject.log e smtpd_error.log allo stesso timestamp. Sul lato Microsoft, Message Trace e stato del connettore mostrano se EOP ha accettato o inviato il messaggio. Servizi e log di Sophos Firewall classifica i file di log.
Circoscrivere gli errori in base al sintomo
La posta esterna non raggiunge Microsoft 365
Controllare prima MX, indirizzo pubblico, TCP 25, SMTP Relay da WAN, regola MTA automatica e Mail logs. Se SFOS accetta ma non consegna, verificare risoluzione DNS della destinazione tenant, policy route and scan, TLS e spool.
La posta in uscita evita la firewall
Controllare ambito e priorità del connettore e Message Trace in Exchange Admin Center. Solo quando il trace mostra la firewall come smarthost si valutano match del relay SFOS, policy e indirizzo sorgente pubblico. Con più WAN, consultare la sezione corrispondente in Mail Protection in MTA mode.
Il relay viene respinto o sarebbe autorizzato troppo ampiamente
Confrontare l’IP sorgente EOP reale con la lista Microsoft corrente e gli oggetti SFOS. Una rete EOP consentita deve comparire in Allow relay from hosts/networks; tutte le altre sorgenti raggiungono Block relay from hosts/networks: Any. Un’autorizzazione cloud o WAN ampia non è una correzione.
TLS o la validazione del connettore non riescono
Controllare separatamente FQDN, DNS pubblico, nome certificato, catena completa, validità e STARTTLS. Un openssl s_client riuscito conferma l’endpoint firewall, ma non l’ambito del connettore o la consegna completa. Allow invalid certificate non è un workaround permanente.
Si crea un loop di posta
Confrontare MX pubblico e destinazione della policy SMTP route and scan. Se entrambi puntano a mail.example.com, correggere la policy verso la destinazione Microsoft del tenant. Ripristinare il vecchio percorso documentato finché il routing non è univoco.
Eseguire un rollback sicuro
Il rollback ripristina lo stato precedente documentato, non un valore predefinito presunto. Ripristinare prima l’esatto stato di attivazione, l’ambito, il routing e le impostazioni TLS precedenti del connettore Exchange Online; disattivarlo solo se è stato creato per questa modifica. Ripristinare quindi le destinazioni e le priorità MX registrate e il valore TXT SPF precedente completo. Verificare che il DNS autoritativo e diversi resolver pubblici restituiscano i vecchi valori.
Mantenere policy pilota, oggetti EOP e voci relay finché i test in entrata e in uscita non funzionano nuovamente sul vecchio percorso e non è trascorso il precedente TTL DNS. Rimuovere quindi solo gli elementi creati per questa modifica, lasciando invariati gli oggetti preesistenti o condivisi.
Non cancellare alla cieca i messaggi dallo spool o dalla quarantena. Fanno parte della transizione documentata e vengono gestiti solo dopo aver verificato mittente, destinatario e percorso desiderato.
Checklist operativa
- Le responsabilità di SFOS, Microsoft 365 e altri gateway sono definite.
- MX, SPF, connettore e flusso precedenti sono documentati come ripristino.
- Gli oggetti EOP provengono dalla lista Microsoft corrente e hanno un owner.
SMTP Relayè utilizzabile solo tramite voci Host-based relay ristrette; le sorgenti non autorizzate sono respinte.- La policy route and scan punta alla destinazione Microsoft del tenant, non al MX pubblico.
- Connettore, certificato, DNS, MX, SPF, DKIM e DMARC sono stati verificati con messaggi reali.
- I test in entrata, in uscita, destinatario non valido e relay non autorizzato sono riusciti.
- Mail logs, spool, quarantena e Microsoft Message Trace sono correlabili nel tempo.
- Reti EOP e scadenza del certificato vengono riesaminate regolarmente.