Konfigurera Sophos Firewall MTA med Microsoft 365

Sophos Firewall kan i MTA mode fungera som en separat e-postgateway framför Microsoft 365. Inkommande meddelanden når först brandväggen och levereras sedan till Exchange Online Protection. Exchange Online skickar utgående meddelanden tillbaka till brandväggen via en connector för skanning och vidarebefordran till internet.

Designen är möjlig, men inte automatiskt den bästa arkitekturen. Sophos Central Email, Microsoft Defender for Office 365 och Mail Protection på brandväggen överlappar delvis. Före ändringen måste det vara tydligt vilket system som ansvarar för spam, malware, karantän, TLS, DKIM och felsökning.

⚠️ En bred relaybehörighet kan göra brandväggen till en open relay. Behåll en lokal administratörssession, det befintliga e-postflödet och en testad återställningsväg innan MX ändras. Produktionsväxlingen görs först när ett obehörigt relaytest avvisas på ett tillförlitligt sätt.

Rita först det dubbelriktade e-postflödet

Den inkommande vägen är Internet → Sophos Firewall MTA → Exchange Online Protection → Microsoft 365-brevlåda. Den offentliga MX-posten pekar därför på brandväggens offentliga SMTP-adress. SMTP route and scan-policyn levererar därefter till det tenantspecifika Microsoft-målet, exempelvis example-com.mail.protection.outlook.com.

Den utgående vägen är Exchange Online → Microsoft 365-connector → Sophos Firewall MTA → Internet. Brandväggen får bara acceptera relay från de aktuella Exchange Online Protection-näten. HELO, certifikat, offentlig käll-IP, PTR/rDNS, SPF, DKIM och DMARC måste stämma med denna väg.

Konfigurera Mail Protection i MTA mode förklarar MTA-grunder, policyfält, karantän och loggar. Den här artikeln fokuserar på Microsoft 365-anslutningen.

Exempelvärden och förutsättningar

Exemplet använder e-postdomänen example.com, brandväggens FQDN mail.example.com, dokumentationsadressen 192.0.2.25 och tenantmålet example-com.mail.protection.outlook.com. Ersätt dem med den verkliga domänen, en fast offentlig adress och det faktiska Microsoft-målet. 192.0.2.25 tillhör TEST-NET och får inte användas i produktion.

TCP 25 måste fungera från internet till brandväggen, från brandväggen till Microsoft 365 och från brandväggen till externa e-postservrar. Det krävs också en lämplig Email Protection-licens, MTA-stöd på modellen, ett publikt betrott certifikat, kontrollerad DNS-åtkomst samt behörigheter till Exchange Admin Center och auktoritativ DNS.

Exchange Online Protection-näten ändras. Kopiera dem inte från ett statiskt exempel, utan underhåll dem från den aktuella Microsoft 365-endpointlistan som Sophos länkar till. SMTP-endpointarna på TCP 25 är särskilt relevanta. Dokumentera ägare och granskningsintervall för hostobjekten.

Koppla Microsoft 365 och SFOS i åtta steg

Dokumentera aktuella MX, SPF, connectors, headers, offentlig käll-IP och återställningsväg.
Förbered MTA mode, automatisk MTA-regel, certifikat och utgående skanning på SFOS.
Skapa separata IP host-objekt för de aktuella EOP-intervallen.
Tillåt SMTP Relay från WAN, begränsa Host-based relay till EOP-objekten och blockera övriga källor.
Skapa en SMTP route and scan-policy för den skyddade domänen och tenantens Microsoft-mål.
Skapa en connector i Exchange Online från Microsoft 365 till brandväggens offentliga adress.
Ändra MX och SPF i ett underhållsfönster.
Verifiera inkommande, utgående och avvisade relayförsök med headers, Mail logs, spool och Microsoft-traces.

Förbereda Sophos Firewall

MTA mode, automatisk regel och certifikat

Aktivera MTA mode under Email > General settings. SFOS skapar Auto added firewall policy for MTA för SMTP och SMTPS. Redigera inte regeln och låt den ligga överst enligt Sophos rekommendation. Om den saknas trots aktivt MTA mode skapas ingen egen Any-to-Any-ersättning. Kontrollera först läge, konfiguration och supportväg.

Ange det planerade domännamnet för SMTP hostname under SMTP settings. Välj ett publikt betrott certifikat under SMTP TLS configuration och lämna Allow invalid certificate av. Scan outgoing mails måste vara aktivt om meddelanden från Exchange Online också ska skannas.

Tillåta relay från EOP-källor

Skapa under Hosts and services > IP host ett tydligt namngivet objekt för varje aktuellt EOP-IPv4-intervall, exempelvis med prefixet O365_EOP_. Slå inte samman intervallen till ett större nät. Efter en Microsoft-ändring läggs nät till eller tas bort kontrollerat och testas igen.

Aktivera SMTP Relay för WAN under Administration > Device access. Zonvalet är för brett ensamt och begränsas därför under Email > Relay settings > Host-based relay:

Allow relay from hosts/networks: endast de underhållna EOP-hostobjekten;
Block relay from hosts/networks: Any.

Sophos utvärderar en matchande Allow-post före det överlappande Block. Därför får Allow-listan inte innehålla breda operatörs-, moln- eller Any-nät. Upstream host styr en separat målrelation och ersätter inte denna källkontroll.

För normal inkommande internetpost anger Sophos-proceduren i stället Upstream host > Allow relay from hosts/networks som Any. Det gör att externa SMTP-hostar kan leverera till de skyddade domänerna och är inte samma behörighet som utgående Host-based relay. Om en definierad extern e-postgateway redan står framför SFOS begränsas Upstream-listan i stället till dess verkliga källnät.

Route-and-scan-policy för Microsoft-leverans

Skapa den skyddade domänen som Email address/domain under Email > Address group. Lägg sedan till en policy under Email > Policies and exceptions > Add a policy > SMTP route and scan med:

Address Group under Protected domain;
Global action: Accept;
Route by: DNS host och det tenantspecifika Microsoft-målet;
medvetet valda inställningar för spam-, malware-, file- och data-protection.

Routinghosten är inte det offentliga MX-värdet för example.com efter att det pekar på brandväggen. Annars levererar brandväggen till sig själv och skapar en loop. Dokumentera det verkliga Microsoft-målet före MX-ändringen och kontrollera att SFOS kan slå upp det korrekt.

Skapa Exchange Online-connectorn

Skapa i Exchange Admin Center under Mail flow > Connectors en connector From: Office 365 och To: Partner organization. För att skicka all utgående e-post via SFOS gäller målvillkoret alla mottagardomäner (*). En avsiktligt begränsad delmängd måste stämma med den dokumenterade designen. Använd brandväggens offentliga IP eller FQDN mail.example.com som smarthost.

Kräv TLS för connectorn. Sophos-hjälpen visar även ett kompatibelt val som accepterar alla digitala certifikat, inklusive självsignerade. I produktion är ett publikt betrott certifikat vars identitet matchar FQDN mer robust och ska verifieras med ett verkligt connectortest.

Connectorvalideringen kan misslyckas före DNS-ändringen. Den ersätter därför varken det senare end-to-end-testet eller det negativa relaytestet. Efter att den sparats ska Microsoft Message Trace bekräfta att utgående meddelanden faktiskt använder avsedd connector och brandvägg.

Ändra MX och SPF kontrollerat

Låt det offentliga MX-värdet peka på mail.example.com först när brandväggspolicy, EOP-relay, internt Microsoft-mål och connector är klara. Sänk TTL före underhållsfönstret. Behåll det gamla MX-målet för dokumenterad rollback, men inte parallellt om avsändare då slumpmässigt kan kringgå det nya skyddet.

SPF-posten måste auktorisera Exchange Online och brandväggens offentliga avsändaridentitet. Sophos visar v=spf1 include:spf.protection.outlook.com mx -all som ett enkelt exempel. Ersätt inte befintlig post blint: inventera först andra sändare, underdomäner, include-kedjor och DNS-uppslagsgränsen. Kontrollera DKIM och DMARC på nytt i verkliga headers.

Verifiera hela vägen

Från ett externt testsystem hjälper följande skrivskyddade kontroller:

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

Ersätt exempelnamnen med verkliga värden. DNS, TCP och TLS bevisar inte leverans. Testa minst ett externt meddelande till Microsoft 365, ett utgående från Microsoft 365, en ogiltig mottagare och ett relayförsök från en otillåten käll-IP.

Korrelera på SFOS Email > Mail logs, Mail spool, SMTP quarantine, Log Viewer, smtpd_main.log, smtpd_reject.log och smtpd_error.log med samma tidpunkt. På Microsoft-sidan visar Message Trace och connectorstatus om EOP accepterade eller skickade meddelandet. Sophos Firewall-tjänster och loggar beskriver loggfilerna.

Avgränsa fel efter symtom

Extern e-post når inte Microsoft 365

Kontrollera först MX, offentlig adress, TCP 25, SMTP Relay från WAN, automatisk MTA-regel och Mail logs. Om SFOS accepterar men inte levererar kontrolleras DNS för tenantmålet, route-and-scan-policy, TLS och spool.

Utgående e-post går förbi brandväggen

Kontrollera connectorns omfattning, prioritet och Message Trace i Exchange Admin Center. Bedöm SFOS-relaymatch, policy och offentlig källadress först när trace visar brandväggen som smarthost. Vid flera WAN-länkar, se motsvarande avsnitt i Mail Protection i MTA mode.

Relay avvisas eller skulle vara för brett tillåtet

Jämför verklig EOP-käll-IP med aktuell Microsoft-lista och SFOS-objekt. Ett tillåtet EOP-nät måste finnas under Allow relay from hosts/networks; övriga källor når Block relay from hosts/networks: Any. En bred moln- eller WAN-behörighet är ingen lösning.

TLS eller connectorvalidering misslyckas

Kontrollera FQDN, offentlig DNS, certifikatnamn, fullständig kedja, giltighet och STARTTLS separat. En lyckad openssl s_client bekräftar brandväggens endpoint, men inte connectorns omfattning eller fullständig leverans. Allow invalid certificate är ingen permanent workaround.

En e-postloop uppstår

Jämför offentligt MX med målet i SMTP route and scan-policyn. Om båda pekar på mail.example.com ska policyn ändras till tenantens Microsoft-mål. Återställ den dokumenterade gamla vägen tills routingen är entydig.

Genomföra en säker rollback

Inaktivera först Exchange Online-connectorn eller återställ dess tidigare tillstånd. Återställ sedan MX och SPF och verifiera offentlig upplösning. Ta bort pilotpolicy, EOP-objekt och relayposter från SFOS först när inkommande och utgående tester åter fungerar via den gamla vägen.

Radera inte meddelanden i spool eller karantän utan kontroll. De ingår i den dokumenterade övergången och hanteras först efter kontroll av avsändare, mottagare och önskad leveransväg.

Driftchecklista

Ansvar för SFOS, Microsoft 365 och andra e-postgateways är fastställt.
Tidigare MX, SPF, connector och e-postflöde är dokumenterade som återställning.
EOP-objekten kommer från aktuell Microsoft-lista och har en ägare.
SMTP Relay kan endast användas via snäva Host-based relay-poster; obehöriga källor avvisas.
Route-and-scan-policyn pekar på tenantens Microsoft-mål och inte tillbaka på offentligt MX.
Connector, certifikat, DNS, MX, SPF, DKIM och DMARC har verifierats med verkliga meddelanden.
Inkommande, utgående, ogiltig mottagare och obehörigt relaytest har godkänts.
Mail logs, spool, karantän och Microsoft Message Trace kan tidskorreleras.
EOP-nät och certifikatets utgång granskas regelbundet.

FAQ

Måste Microsoft 365 använda Sophos Firewall som MTA?

Nej. Det är en möjlig gatewayarkitektur. Sophos Central Email eller Microsofts molnskydd kan vara enklare för rena molnmiljöer. Det viktiga är en medveten ansvarsfördelning utan oplanerad dubbel skanning.

Kan Host-based relay helt enkelt tillåta Any?

Nej. För Microsoft 365 tillåts endast de aktuella EOP-källnäten. Any hör hemma i Block-listan så att varje källa utan uttrycklig behörighet avvisas.

Varför får route-and-scan-policyn inte använda offentligt MX?

Eftersom offentligt MX pekar på brandväggen efter växlingen. Om policyn slog upp samma MX skulle SFOS leverera till sig själv. Målet ska vara tenantens specifika Microsoft 365-mailhost.