Konfigurera Sophos Firewall Mail Protection i MTA mode

Sophos Firewall kan inte bara tillåta e-posttrafik som en vanlig brandväggsanslutning, utan i MTA mode även själv fungera som Mail Transfer Agent mellan Internet och den interna mailservern. Brandväggen tar emot SMTP-anslutningar, kontrollerar meddelanden med Mail Protection och levererar dem sedan till den definierade mailservern.

I dag rekommenderar vi Mail Protection på brandväggen endast för medvetet planerade specialfall, till exempel när en lokal Exchange eller en annan intern mailserver ska skyddas direkt via brandväggen. För Microsoft 365, Google Workspace och de flesta moderna cloudmailmiljöer är Sophos Central Email normalt den bättre lösningen. Central Email ligger närmare den egentliga mailtjänsten, integreras renare med cloudmailboxar, minskar komplexiteten i brandväggsreglerna och undviker många klassiska MTA-frågor som MX-ändringar, lokala spools, relayfrågor och felsökning på brandväggen.

En annan praktisk punkt: Email Protection på brandväggen har jämfört med Sophos Central Email länge känts som en beståndsfunktion som framför allt förblir relevant för befintliga on-premises-mailservrar. Den som planerar nytt i dag bör därför först kontrollera om en cloud mail gateway är den renare arkitekturen.

Detta är tekniskt starkt, men också känsligt för fel om DNS, MX-record, TLS, relay, användarkontroll, policies och loggar inte planeras ordentligt. En felkonfigurerad MTA kan blockera legitima e-postmeddelanden, fördröja mailflow eller i värsta fall uppfattas som relay.

Artikeln förklarar den praktiska uppbyggnaden för Sophos Firewall Mail Protection i MTA mode. Den ersätter inte planering för Sophos Central Email. För många Microsoft 365- eller Google Workspace-miljöer är en cloud mail gateway ofta mer lämplig. Men om en lokal Exchange, en hybridmailserver eller en medvetet brandväggsbaserad SMTP-väg används krävs en tydlig driftplan.

När Mail Protection på brandväggen är meningsfullt

Mail Protection på Sophos Firewall är framför allt meningsfullt när SMTP-trafik medvetet ska gå via brandväggen och brandväggen ska göra mer än att bara vidarebefordra port 25.

Typiska scenarier:

• Inkommande e-post ska först tas emot och kontrolleras på brandväggen.
• En intern mailserver ska inte vara direkt nåbar från Internet.
• Spam-, malware-, filtyps- eller innehållskontroll ska gälla före leverans.
• Utgående e-post ska skickas kontrollerat via brandväggen eller en smarthost.
• Karantän, mail spool och SMTP-loggar ska kunna spåras på brandväggen.

Inte varje mailsetup bör gå via brandväggen. Om Sophos Central Email, Microsoft Defender for Office 365 eller en annan cloud mail gateway redan hanterar hela mailflow bör Mail Protection på brandväggen inte dessutom läggas emellan utan att mailflödet dokumenteras exakt. Dubbla gateways leder snabbt till oklara ansvar för karantän, headers, SPF/DKIM/DMARC, TLS och troubleshooting.

Skilj på MTA mode, Legacy mode och SMTP Relay

I Sophos Firewall måste tre saker hållas tydligt isär:

MTA mode är det normala målläget för moderna firewall-Mail-Protection-scenarier. Den lokala tjänsten SMTP Relay är däremot ett Device Access-ämne. Den bör bara vara nåbar från definierade interna nät. En för bred tillåtelse kan främja relaymissbruk. Härdning av lokala tjänster beskrivs i Säkra åtkomst till Sophos Firewall: konfigurera Device Access korrekt.

Förutsättningar

Före konfigurationen bör dessa punkter vara klara:

• Sophos Firewall med giltig Email Protection eller lämpligt bundle.
• Inte varje modell stöder MTA mode. XGS 87 och XGS 88 är appliances utan stöd för MTA mode.
• Publik DNS-zon och MX-record är kända.
• Intern mailserver, målport och leveransväg är dokumenterade.
• Publik IP-adress eller WAN-adress för inkommande SMTP-trafik är definierad.
• Brandväggen kan routa till och nå den interna mailservern.
• Utgående DNS-åtkomst från brandväggen fungerar.
• Önskad TLS- och certifikatstrategi är klarlagd.
• Karantän- och frisläppningsprocess är organisatoriskt definierad.

Före ändringar i mailflow bör ett underhållsfönster planeras. Ett test på produktiva MX-record utan fallbackplan är riskabelt, eftersom inkommande e-post snabbt kan fördröjas eller avvisas beroende på avsändare.

Fastställ målarkitekturen

Först bör man besluta vilken riktning brandväggen ska bearbeta.

Inkommande mailflow

Vid inkommande mailflow pekar externa MX-records på den publika adress där Sophos Firewall tar emot SMTP. Brandväggen kontrollerar meddelandet och vidarebefordrar det till den interna mailservern.

Typiskt förlopp:

1. Extern avsändare ansluter via SMTP till den publika MX-adressen.
2. Sophos Firewall tar emot anslutningen i MTA mode.
3. Mail Protection kontrollerar avsändare, mottagare, spam, malware, bilagor och policy.
4. Brandväggen levererar e-postmeddelandet till den interna mailservern.
5. Den interna mailservern levererar till mailboxen eller bearbetar meddelandet vidare.

Det är viktigt att den interna mailservern inte dessutom förblir ofiltrerat nåbar från Internet. Om en DNAT-regel parallellt fortfarande pekar direkt på mailservern kan en del av trafiken passera förbi Mail Protection. För normala serverpubliceringar är Publicera server via DNAT rätt grund, men vid MTA mode är brandväggen själv SMTP-mottagningspunkten.

Utgående mailflow

Vid utgående mailflow skickar den interna mailservern via Sophos Firewall. Brandväggen kan kontrollera meddelanden, vidarebefordra dem till en smarthost eller leverera direkt, beroende på konfiguration.

Klargör i förväg:

• Får brandväggens publika IP skicka e-post direkt?
• Stämmer SPF, DKIM och DMARC för den valda sändvägen?
• Behövs en provider-smarthost?
• Måste utgående SMTP-trafik begränsas till vissa interna system?
• Var övervakas avvisade eller fördröjda meddelanden?

För utgående mailtrafik bör en egen, spårbar regel- och policystruktur användas. En generell LAN to WAN-regel utan tydlig begränsning är oftast för grov för mailservrar. Grunderna för regelordning och säkerhetsprofiler finns i Förstå och bygga Sophos Firewall-regler rent.

Förbered MX-ändring och externa tester

En Mail Protection-ändring blir kritisk först när externa avsändare verkligen använder den nya vägen. Därför bör MX-record, DNS-TTL, extern nåbarhet och rollback kontrolleras före produktionsbytet.

Före ändringen:

• Dokumentera aktuellt MX-record, prioritet och TTL.
• Minska DNS-TTL i god tid om snabb fallback kan behövas.
• Skilj tydligt på gammal mailväg och ny Sophos Firewall-adress.
• Identifiera gamla direkta DNAT-regler till mailservern.
• Definiera testmottagare och testavsändare.
• Fastställ fallbackplan: gammalt MX, gammal DNAT-regel eller temporär smarthost.
• Förbered monitoring för spool, karantän och mailserverqueue.

Användbara externa kontroller från ett system utanför det egna nätet:

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

Kommandona ersätter inte ett fullständigt mailflow-test, men visar snabbt om DNS, port 25 och STARTTLS i princip är nåbara. example.com och mail.example.com måste ersättas med den riktiga domänen och den riktiga mailhosten.

Efter omkopplingen bör man omedelbart skicka ett inkommande testmail och dokumentera hela vägen:

• Anslutning synlig i Log Viewer?
• Post finns i smtpd_main.log?
• Mottagarkontroll lyckad?
• Leverans till intern mailserver genomförd?
• Meddelande kommit fram i mailboxen?
• Ingen parallell direktleverans förbi MTA?

Om brandväggen tar emot e-post men inte levererar den bör MX inte omedelbart återställas. Klargör först om det är ett internt routing-, DNS-, TLS- eller mailserverproblem. Men om externa avsändare inte kan ansluta till brandväggen eller legitima e-postmeddelanden avvisas brett är snabb fallback till tidigare mailväg ofta klokare än längre experiment i den produktiva MX-vägen.

Aktivera MTA mode

Grundinställningarna finns i Sophos Firewall under:

Email > General settings

Där fastställs e-postläget. För denna guide är MTA mode relevant. Efter bytet bör man kontrollera om befintliga policies, hostobjekt och maildomäner fortfarande passar den önskade driften.

I befintliga miljöer bör man inte bara växla mellan Legacy mode och MTA mode utan att testa mailflow. Bearbetning, loggar och policylogik skiljer sig. Före en migrering bör aktuell firewallkonfiguration, MX-records, mailserverconnectors och relayinställningar dokumenteras.

Konfigurera SMTP-routing och domäner

För inkommande e-post måste brandväggen veta vilka domäner den ska ta emot och vart den ska leverera dem.

Typiskt förlopp:

1. Under Email > Policies and exceptions respektive i Mail Protection-områdena planera berörda domäner och målservrar.
2. Ange maildomän, till exempel example.com.
3. Definiera intern mailserver eller hostobjekt som leveransmål.
4. Kontrollera om brandväggen når mailservern på målporten.
5. Kontrollera TLS-krav och certifikat.
6. Skicka testmail utifrån till en känd mottagare.

För interna mailservrar är DNS särskilt viktigt. Brandväggen måste kunna lösa interna mål korrekt, och externa avsändare måste nå det publika MX-recordet. Om intern DNS-upplösning spelar roll hjälper Konfigurera DNS Request Routes på Sophos Firewall.

Planera policies för spam, malware och bilagor

Mail Protection är bara så bra som de policies som faktiskt träffar. En policy bör inte bara skapas, utan även namnges med ett tydligt syfte.

Viktiga policyfrågor:

• Vilka domäner eller mottagargrupper påverkas?
• Bearbetas inkommande, utgående eller dubbelriktad mailtrafik?
• Vad händer vid spam, malware, misstänkta bilagor eller oönskade filtyper?
• Blockeras, sätts i karantän, levereras eller header-markeras e-postmeddelanden?
• Vem får kontrollera karantän och släppa e-post?
• Vilka false-positive-processer finns?

Om Zero-Day Protection används kan misstänkta e-postbilagor analyseras ytterligare. Gränserna, rapporterna och frisläppningsbeslutet förklaras i Förstå och driva Sophos Firewall Zero-Day Protection.

Säkra relay och Device Access

Ett vanligt fel är att blanda ihop MTA-mailflow med ett öppet SMTP Relay. Brandväggen får inte kunna användas som relay från godtyckliga nät.

Kontrollera:

• Under Administration > Device access är SMTP Relay bara nåbart från nödvändiga interna zoner.
• Om ACL Exception Rules används är källor snävt definierade.
• Endast definierade interna mailservrar, skannrar eller applikationsservrar får relaya via brandväggen.
• Från WAN, gästnät och untrusted zones är SMTP Relay inte generellt tillåtet.
• Logging är aktivt så att missbruk eller felkonfigurationer syns.

Om skrivare, skannrar eller applikationer behöver skicka e-post bör en egen intern relayväg dokumenteras för detta. Sådana system bör inte tala direkt med godtyckliga externa SMTP-mål om miljön kan undvika det.

Testa mailflow

Efter konfigurationen räcker inte en enda lyckad sändning. Flera tester bör genomföras och resultaten dokumenteras.

Testa inkommande

Kontrollera minst:

• Externt MX-record pekar på förväntad adress.
• Port 25 är nåbar utifrån.
• Brandväggen tar emot anslutningen i MTA mode.
• E-post vidarebefordras till den interna mailservern.
• Mottagaren finns och får meddelandet.
• Spam- eller malware-test behandlas som förväntat.
• Karantän- eller loggpost är spårbar.

Testa utgående

Kontrollera minst:

• Intern mailserver skickar via förväntad route.
• Firewallregel och mail policy träffar.
• SPF, DKIM och DMARC passar sändvägen.
• Målservern accepterar meddelandet.
• Bounces eller Deferred-meddelanden övervakas.
• Inga andra interna system skickar oplanerat direkt ut.

Kontrollera loggar

För snabb visuell kontroll hjälper Log Viewer. För djupare analys är mailloggarna viktiga. Mappningen finns i Sophos Firewall Troubleshooting: tjänster och loggar.

Relevanta loggfiler:

Vid akut troubleshooting bör man notera testtidpunkten, samla avsändare, mottagare, ämne, käll-IP och Message-ID och sedan tidskorrelera Log Viewer och loggfiler.

Karantän, spool och lagring

Mail Protection skapar lokala data. Beroende på volym hamnar meddelanden i karantän, spool eller temporära områden. Därför blir lagringsutrymme, SSD-status och recoveryplan viktigare än vid en ren firewallregel.

Praktiska driftfrågor:

• Vem kontrollerar karantän och hur ofta?
• Hur släpps false positives?
• När raderas ett meddelande i stället för att släppas?
• Hur upptäcks en växande mail spool?
• Finns monitoring för lagringsutrymme och System Health?
• Planeras ett kort mailflow-test efter firmware updates?

För lagrings- och reportingämnen passar Rensa Sophos Firewall-lagring och reports och Kontrollera Sophos Firewall SSD Health. I HA-miljöer bör man dessutom observera att mailkarantän och bearbetade maildata kan vara nodspecifika driftdata. HA-grunderna finns i Sophos Firewall HA-klustervarianter.

Troubleshooting

Externa e-postmeddelanden kommer inte fram

Kontrollera först DNS och nåbarhet: MX-record, publik IP, port 25, gamla NAT-rester, MTA mode och ansvarig maildomän. Kontrollera därefter i Log Viewer och i smtpd_main.log om anslutningen når brandväggen. Om ingen anslutning syns ligger problemet sannolikt före Mail Protection.

Brandväggen tar emot e-post men levererar den inte

Då är intern mailserver, routing, DNS, målport, TLS, mottagarkontroll eller policy mer sannolikt. Kontrollera om brandväggen kan nå mailservern och om mailservern accepterar anslutningen. Reject-loggar och mailserverloggar bör utvärderas tidsmässigt tillsammans.

Många e-postmeddelanden blir kvar i spool

En växande spool tyder ofta på leveransproblem: intern mailserver inte nåbar, TLS-krav passar inte, DNS-upplösning misslyckas eller målserver avvisar meddelandet. I detta fall bör man inte bara leverera enskilda meddelanden igen, utan söka orsaken i routing- och SMTP-vägen.

Ett viktigt regelordningsfall förbises lätt: Om en automatiskt eller manuellt skapad firewallregel ligger ovanför MTA-regeln och matchar SMTP-trafik utvärderas den egentliga MTA-regeln inte längre. Då kan e-post bli kvar i mail spool trots att DNS, port 25 och mailserver i princip ser korrekta ut.

Kontrollera:

1. Öppna Rules and policies > Firewall rules.
2. Kontrollera regler ovanför MTA- eller SMTP-regeln.
3. Kontrollera nya automatiskt skapade regler, IPsec-regler, hotspotregler eller regler som manuellt satts på Top.
4. Gör SMTP-testet igen och jämför Log Viewer, mail spool och smtpd_main.log.

Regeln får inte blint flyttas ned om den fyller andra produktiva syften. Avgörande är om den oväntat fångar SMTP-trafik före MTA-regeln.

Karantändigest saknas för aliasadresser

Om användare använder aliasadresser bör karantäninställningar inte bara kontrolleras för den primära mailadressen. Enligt Sophos tillämpas karantäninställningar som standard inte automatiskt på aliasadresser. Om digestmail eller frisläppningar saknas för aliasmottagare måste aliasadresser beaktas tillsammans med den primära adressen i karantän- respektive användarkontexten.

Legitima avsändare identifieras som spam

False positives bör inte direkt besvaras med breda undantag. Kontrollera först avsändardomän, SPF/DKIM/DMARC, headers, reputation, policy match och berörda mottagare. Om ett undantag behövs bör det begränsas snävt och dokumenteras med granskningsdatum.

Interna system kan inte relaya

Kontrollera om SMTP Relay under Administration > Device access är tillåtet från rätt zon och om källan passar ACL. Kontrollera därefter mailloggar. Om en skanner eller applikation ska relaya bör källan dokumenteras som hostobjekt och inte ett helt nät öppnas i onödan.

Efter firmware update fungerar mail annorlunda

Efter firmware updates bör MTA mode, policies, certifikat, mail spool, karantän och relevanta loggar kontrolleras. För större updates passar dessutom Kontrollera Sophos Firewall före SFOS 22-upgrade.

Driftchecklista

• Mail Protection-licens och appliance-stöd kontrollerade.
• MTA mode medvetet valt och dokumenterat.
• MX-record, publik IP och intern målserver stämmer.
• MX-ändring, externa tester och rollback är förberedda.
• Ingen parallell ofiltrerad DNAT-regel kringgår MTA.
• Inkommande och utgående policies är begripligt namngivna.
• Firewallregelordning hindrar inte att MTA-regeln träffar.
• SMTP Relay är endast tillåtet från definierade interna källor.
• Karantän- och false-positive-process är fastställd.
• Aliasadresser beaktas i karantän- och digestprocessen.
• Mail spool, lagringsutrymme och System Health övervakas.
• Loggar sparas lokalt, i Sophos Central eller via Syslog tillräckligt länge.
• Efter firmware updates genomförs ett mailflow-test.

För längre lagring och korrelation med andra säkerhetshändelser bör man kontrollera Central Firewall Reporting eller Skicka Sophos Firewall Syslog till SIEM.

FAQ