Naar de inhoud
Avanet

Sophos Firewall MTA met Microsoft 365 configureren

Sophos Firewall kan in MTA mode als afzonderlijke mailgateway voor Microsoft 365 werken. Inkomende berichten bereiken eerst de firewall en worden daarna aan Exchange Online Protection bezorgd. Exchange Online stuurt uitgaande berichten via een connector terug naar de firewall, die ze scant en naar internet doorstuurt.

Dit ontwerp is mogelijk, maar niet automatisch de beste architectuur. Sophos Central Email, Microsoft Defender for Office 365 en Mail Protection op de firewall overlappen gedeeltelijk. Bepaal vooraf welk systeem verantwoordelijk is voor spam, malware, quarantaine, TLS, DKIM en foutanalyse.

⚠️ Een brede relayvrijgave kan van de firewall een open relay maken. Houd vóór de MX-wijziging een lokale beheersessie, de bestaande mailflow en een getest terugvalpad beschikbaar. Voer de productieomschakeling pas uit wanneer een ongeautoriseerde relaytest betrouwbaar wordt geweigerd.

Teken eerst de tweerichtingsmailflow

Het inkomende pad is Internet → Sophos Firewall MTA → Exchange Online Protection → Microsoft 365-mailbox. Het openbare MX-record wijst daarom naar het openbare SMTP-adres van de firewall. Het SMTP route and scan-beleid bezorgt vervolgens aan het tenantspecifieke Microsoft-doel, bijvoorbeeld example-com.mail.protection.outlook.com.

Het uitgaande pad is Exchange Online → Microsoft 365-connector → Sophos Firewall MTA → Internet. De firewall mag alleen relay accepteren vanuit de huidige Exchange Online Protection-netwerken. HELO, certificaat, openbaar bron-IP, PTR/rDNS, SPF, DKIM en DMARC moeten bij dit pad passen.

Mail Protection in MTA mode configureren behandelt de MTA-basis, beleidsvelden, quarantaine en logs. Dit artikel richt zich op de Microsoft 365-verbinding.

Voorbeeldwaarden en vereisten

Het voorbeeld gebruikt maildomein example.com, firewall-FQDN mail.example.com, documentatieadres 192.0.2.25 en tenantspecifiek doel example-com.mail.protection.outlook.com. Vervang ze door het echte domein, een vast openbaar adres en het werkelijke Microsoft-doel. 192.0.2.25 behoort tot TEST-NET en mag niet productief worden gebruikt.

TCP 25 moet werken van internet naar de firewall, van de firewall naar Microsoft 365 en van de firewall naar externe mailservers. Ook zijn een passende Email Protection-licentie, MTA-ondersteuning op het model, een publiek vertrouwd certificaat, gecontroleerde DNS-toegang en rechten voor Exchange Admin Center en autoritatieve DNS nodig.

Exchange Online Protection-netwerken veranderen. Neem ze niet over uit een statisch voorbeeld, maar onderhoud ze vanuit de actuele Microsoft 365-endpointlijst waar Sophos naar verwijst. Voor deze mailflow zijn vooral de SMTP-endpoints op TCP 25 relevant. Leg een eigenaar en controle-interval voor de hostobjecten vast.

Microsoft 365 en SFOS in acht stappen verbinden

  1. Leg huidig MX-record, SPF, connectors, headers, openbaar bron-IP en terugvalpad vast.
  2. Bereid MTA mode, automatische MTA-regel, certificaat en uitgaande scan op SFOS voor.
  3. Maak afzonderlijke IP-hostobjecten voor de actuele EOP-bereiken.
  4. Sta SMTP Relay toe vanuit WAN, beperk Host-based relay tot de EOP-objecten en blokkeer alle andere bronnen.
  5. Maak een SMTP route and scan-beleid voor het beschermde domein en het Microsoft-doel van de tenant.
  6. Maak in Exchange Online een connector van Microsoft 365 naar het openbare firewalladres.
  7. Wijzig MX en SPF binnen een onderhoudsvenster.
  8. Valideer inkomende, uitgaande en geweigerde relaypogingen met headers, Mail logs, spool en Microsoft-traces.

Sophos Firewall voorbereiden

MTA mode, automatische regel en certificaat

Activeer MTA mode onder Email > General settings. SFOS maakt Auto added firewall policy for MTA voor SMTP en SMTPS. Bewerk deze regel niet en laat haar volgens Sophos bovenaan staan. Ontbreekt zij terwijl MTA mode actief is, maak dan geen eigen Any-to-Any-vervanging; controleer eerst modus, configuratie en supportpad.

Vul bij SMTP hostname onder SMTP settings de geplande domeinnaam in. Kies onder SMTP TLS configuration een publiek vertrouwd certificaat en laat Allow invalid certificate uit. Scan outgoing mails moet aan staan wanneer ook berichten vanuit Exchange Online worden gescand.

Relay vanuit EOP-bronnen toestaan

Maak onder Hosts and services > IP host voor elk actueel EOP-IPv4-bereik een herkenbaar object, bijvoorbeeld met prefix O365_EOP_. Voeg de bereiken niet samen tot een groter netwerk. Na een Microsoft-wijziging worden netwerken gecontroleerd toegevoegd of verwijderd en opnieuw getest.

Activeer SMTP Relay voor WAN onder Administration > Device access. Deze zoneschakelaar is op zichzelf te breed en wordt daarom beperkt onder Email > Relay settings > Host-based relay:

  • Allow relay from hosts/networks: alleen de onderhouden EOP-hostobjecten;
  • Block relay from hosts/networks: Any.

Sophos beoordeelt een passende Allow-regel vóór het overlappende Block. Daarom mag de Allow-lijst geen brede provider-, cloud- of Any-netwerken bevatten. Upstream host regelt een afzonderlijke doelrelatie en vervangt deze broncontrole niet.

Voor normale inkomende internetmail zet de Sophos-procedure Upstream host > Allow relay from hosts/networks daarentegen op Any. Daardoor kunnen externe SMTP-hosts naar de beschermde domeinen bezorgen; dit is niet dezelfde toestemming als uitgaande Host-based relay. Staat er al een gedefinieerde externe mailgateway voor SFOS, beperk de Upstream-lijst dan tot diens werkelijke bronnetwerken.

Route-and-scan-beleid voor Microsoft-bezorging

Maak het beschermde domein als Email address/domain onder Email > Address group. Voeg daarna onder Email > Policies and exceptions > Add a policy > SMTP route and scan een beleid toe met:

  • de Address Group onder Protected domain;
  • Global action: Accept;
  • Route by: DNS host en het tenantspecifieke Microsoft-doel;
  • bewust gekozen spam-, malware-, file- en data-protection-instellingen.

De routinghost is niet het openbare MX-record van example.com nadat dit naar de firewall wijst. Anders bezorgt de firewall aan zichzelf en ontstaat een lus. Leg het echte Microsoft-doel vóór de MX-wijziging vast en controleer dat SFOS het correct oplost.

Exchange Online-connector maken

Maak in Exchange Admin Center onder Mail flow > Connectors een connector From: Office 365 en To: Partner organization. Om alle uitgaande mail via SFOS te sturen, geldt de doelvoorwaarde voor alle ontvangerdomeinen (*). Een bewust beperkte subset moet bij het gedocumenteerde mailontwerp passen. Gebruik het openbare IP-adres of firewall-FQDN mail.example.com als smarthost.

Verplicht TLS voor de connector. De Sophos-help toont ook een compatibele keuze die elk digitaal certificaat accepteert, inclusief zelfondertekende certificaten. Productief is een publiek vertrouwd certificaat met een identiteit die bij de FQDN past robuuster; valideer dit met een echte connectortest.

Connectorvalidatie kan vóór de DNS-wijziging mislukken. Ze vervangt daarom de latere end-to-end-test en negatieve relaytest niet. Gebruik na opslaan Microsoft Message Trace om te bevestigen dat uitgaande berichten werkelijk de geplande connector en firewall gebruiken.

MX en SPF gecontroleerd wijzigen

Laat het openbare MX-record pas naar mail.example.com wijzen wanneer firewallbeleid, EOP-relay, intern Microsoft-doel en connector klaar zijn. Verlaag de TTL vóór het onderhoudsvenster. Houd het oude MX-doel voor de gedocumenteerde rollback beschikbaar, maar niet parallel als afzenders het nieuwe beschermingspad willekeurig kunnen omzeilen.

Het SPF-record moet Exchange Online en de openbare afzenderidentiteit van de firewall autoriseren. Sophos toont v=spf1 include:spf.protection.outlook.com mx -all als eenvoudig voorbeeld. Vervang het bestaande record niet blind: inventariseer eerst bestaande verzenders, subdomeinen, include-ketens en de DNS-lookuplimiet. Controleer DKIM en DMARC opnieuw met echte headers.

Het volledige pad valideren

Vanaf een extern testsysteem zijn deze alleen-lezen controles nuttig:

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

Vervang de voorbeeldnamen door echte waarden. DNS, TCP en TLS bewijzen geen bezorging. Test minimaal een extern bericht naar Microsoft 365, een uitgaand bericht vanuit Microsoft 365, een ongeldige ontvanger en een relaypoging vanaf een niet-toegestaan bron-IP.

Correleer op SFOS Email > Mail logs, Mail spool, SMTP quarantine, Log Viewer, smtpd_main.log, smtpd_reject.log en smtpd_error.log met hetzelfde tijdstip. Aan Microsoft-zijde tonen Message Trace en connectorstatus of EOP het bericht heeft geaccepteerd of verzonden. Sophos Firewall-services en logs licht de logbestanden toe.

Fouten per symptoom afbakenen

Externe mail bereikt Microsoft 365 niet

Controleer eerst MX, openbaar firewalladres, TCP 25, SMTP Relay vanuit WAN, automatische MTA-regel en Mail logs. Accepteert SFOS het bericht maar bezorgt het niet, controleer dan DNS-resolutie van het tenantdoel, route-and-scan-beleid, TLS en spool.

Uitgaande mail omzeilt de firewall

Controleer scope, prioriteit en Message Trace van de connector in Exchange Admin Center. Beoordeel SFOS-relaymatch, beleid en openbaar bronadres pas wanneer de trace de firewall als smarthost toont. Zie bij meerdere WAN-links de betreffende sectie in Mail Protection in MTA mode.

Relay wordt geweigerd of zou te breed zijn toegestaan

Vergelijk het echte EOP-bron-IP met de actuele Microsoft-lijst en SFOS-objecten. Een toegestaan EOP-netwerk moet onder Allow relay from hosts/networks staan; alle andere bronnen vallen onder Block relay from hosts/networks: Any. Een brede cloud- of WAN-vrijgave is geen oplossing.

TLS of connectorvalidatie mislukt

Controleer FQDN, openbare DNS, certificaatnaam, volledige keten, geldigheid en STARTTLS afzonderlijk. Een geslaagde openssl s_client bevestigt het firewallendpoint, maar niet de connectorscope of volledige bezorging. Gebruik Allow invalid certificate niet als permanente workaround.

Er ontstaat een maillus

Vergelijk het openbare MX-record met het doel van het SMTP route and scan-beleid. Wijzen beide naar mail.example.com, wijzig het beleid naar het tenantspecifieke Microsoft-doel. Herstel het gedocumenteerde oude pad zolang routing niet eenduidig is.

Veilig terugrollen

Schakel eerst de Exchange Online-connector uit of herstel de gedocumenteerde vorige toestand. Herstel daarna MX en SPF en controleer de openbare resolutie. Verwijder het pilotbeleid, de EOP-hostobjecten en relayregels op SFOS pas wanneer inkomende en uitgaande tests weer via het oude pad werken.

Verwijder berichten uit spool of quarantaine niet blind. Ze horen bij de gedocumenteerde overgang en worden pas na controle van afzender, ontvanger en gewenst bezorgpad behandeld.

Operationele checklist

  • Verantwoordelijkheden van SFOS, Microsoft 365 en andere mailgateways zijn vastgelegd.
  • Vorige MX, SPF, connector en mailflow zijn als terugval gedocumenteerd.
  • EOP-IP-objecten komen uit de actuele Microsoft-lijst en hebben een eigenaar.
  • SMTP Relay is alleen bruikbaar via nauwe Host-based-relay-regels; ongeautoriseerde bronnen worden geweigerd.
  • Het route-and-scan-beleid wijst naar het Microsoft-doel van de tenant en niet terug naar het openbare MX-record.
  • Connector, certificaat, DNS, MX, SPF, DKIM en DMARC zijn met echte berichten gevalideerd.
  • Inkomende, uitgaande, ongeldige-ontvanger- en ongeautoriseerde-relaytests zijn geslaagd.
  • Mail logs, spool, quarantaine en Microsoft Message Trace zijn tijdsmatig te correleren.
  • EOP-netwerken en certificaatverval worden regelmatig gecontroleerd.

FAQ

Heeft Microsoft 365 Sophos Firewall verplicht als MTA nodig?

Nee. Dit is één mogelijke gatewayarchitectuur. Sophos Central Email of Microsoft-cloudbeveiliging kan voor cloud-only omgevingen eenvoudiger zijn. Belangrijk is een bewuste taakverdeling zonder ongeplande dubbele inspectie.

Mag Host-based relay eenvoudig Any toestaan?

Nee. Voor Microsoft 365 worden alleen de actuele EOP-bronnetwerken toegestaan. Any hoort in de Block-lijst, zodat elke niet expliciet toegestane bron wordt geweigerd.

Waarom mag het route-and-scan-beleid het openbare MX-record niet gebruiken?

Omdat het openbare MX-record na de omschakeling naar de firewall wijst. Als het beleid hetzelfde MX-record oplost, bezorgt SFOS aan zichzelf. Gebruik de tenantspecifieke Microsoft 365-mailhost als doel.