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 Central 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. Per questo flusso sono particolarmente importanti gli endpoint SMTP su TCP 25. Si documentano owner 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 IPv4 EOP corrente, ad esempio con il prefisso O365_EOP_. Non aggregare gli intervalli in una rete più ampia. Dopo una modifica Microsoft, aggiungere e rimuovere le reti con un change controllato 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 controlla una relazione di destinazione separata e non sostituisce questo controllo della sorgente.
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 creare in Mail flow > Connectors un connettore From: Office 365 e To: Partner organization. Per inviare tutta la posta in uscita attraverso SFOS, applicare la condizione di destinazione a tutti i domini destinatari (*). Un sottoinsieme limitato deve corrispondere al design documentato. Come smarthost usare l’IP pubblico o il FQDN mail.example.com della firewall.
Richiedere TLS per il connettore. La guida Sophos mostra anche un’opzione compatibile che accetta qualsiasi certificato digitale, compresi quelli autofirmati. In produzione è più robusto un certificato pubblico attendibile con identità corrispondente al FQDN, da verificare con un vero 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 Exchange Online e l’identità mittente pubblica della firewall. Sophos mostra v=spf1 include:spf.protection.outlook.com mx -all come semplice esempio. Non sostituire alla cieca il record attuale: inventariare prima servizi di invio esistenti, sottodomini, catene include e limite di lookup DNS. Verificare nuovamente DKIM e DMARC negli header reali.
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
Disattivare prima il connettore Exchange Online o ripristinarne lo stato precedente. Ripristinare quindi MX e SPF e verificarne la risoluzione pubblica. Rimuovere policy pilota, oggetti EOP e voci relay da SFOS solo dopo che i test in entrata e uscita funzionano nuovamente sul vecchio percorso.
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.