Konfigurera Sophos Firewall Mail Protection i MTA-läge

I MTA-läge tar Sophos Firewall själv emot e-post, kontrollerar den och levererar den till den interna e-postservern eller nästa e-posthopp. E-postflödet fungerar bara när MX-posten, den automatiska MTA-regeln, SMTP route and scan-policyn, relä, TLS och mottagarverifiering samverkar.

Konfigurationen består av sex steg: definiera e-postflödet och reservvägen, aktivera MTA-läge, lägg till e-postdomänen, skapa route and scan-policyn, säkra reläåtkomsten och ändra MX-posten. Validera därefter inkommande och utgående e-postflöde med externa kommandon, karantän, spool och loggar.

När MTA-läge passar

Mail Protection på brandväggen är främst användbart i medvetet utformade lokala miljöer och hybridmiljöer där en lokal Exchange-server eller en annan e-postserver ska skyddas. För Microsoft 365, Google Workspace och många rena molnmiljöer är Sophos Central Email eller en annan molnbaserad e-postgateway oftast den tydligare arkitekturen. Två e-postgatewayer efter varandra komplicerar karantän, headers, TLS, SPF/DKIM/DMARC och felsökning.

Tre funktioner i Sophos Firewall måste hållas isär:

• MTA mode: Brandväggen tar emot, kontrollerar och routar e-post.
• Legacy mode: Äldre transparent proxybearbetning för befintliga installationer.
• SMTP Relay i Device Access: Styr från vilka zoner MTA:n kan nås. Inkommande e-post från internet kräver WAN; utgående relä begränsas dessutom till specifika interna e-postservrar.

Förutsättningarna omfattar en giltig Email Protection-licens, fungerande routing och DNS, en känd offentlig IP-adress, den interna e-postservern och målporten samt planerade strategier för TLS, karantän och återställning. Enligt Sophos aktuella översikt är MTA-läge inte tillgängligt på XGS 87/87w och XGS 88/88w.

Anti-spam, RDNS, SPF, RBL, IP Reputation och SXL2 Live Protection kräver internetåtkomst. E-postrouting, skanning efter skadlig kod, MIME-filtrering och SPX kan fortsätta med rätt licens i en air-gap-miljö, men en aktiv MTA innebär inte att alla skyddskontroller är tillgängliga där.

Konfigurera MTA-läge från början till slut

1. Definiera e-postflödet och reservvägen

För inkommande e-post pekar den offentliga MX-posten på adressen där Sophos Firewall tar emot TCP 25. Brandväggen kontrollerar meddelandet och levererar det till den interna e-postservern. En gammal DNAT-regel får inte lämna servern direkt nåbar från internet utan kontroll, eftersom MTA:n då kan kringgås. Publicera en server med DNAT beskriver den allmänna DNAT-logiken.

För utgående e-post skickar endast den avsedda e-postservern via brandväggen. Leveransväg, smarthost, PTR/rDNS, HELO, SPF, DKIM och DMARC måste stämma överens med den offentliga avsändaridentiteten. En generell LAN to WAN-regel är för bred; regelbasen ska tydligt identifiera den tillåtna SMTP-avsändaren. Förstå regler i Sophos Firewall beskriver regelordningen.

Dokumentera följande före migreringen:

• aktuell MX-post, prioritet och TTL;
• ny offentlig brandväggsadress och intern målserver;
• befintliga DNAT- och SMTP-regler samt e-postserveranslutningar;
• testavsändare för inkommande och utgående e-post;
• gammal MX-post eller e-postväg som reserv;
• övervakning av e-postserverns kö, brandväggens spool och karantän.

Sänk TTL-värdet i god tid om en snabb återställning kan behövas. Ändringar av den produktiva MX-posten ska göras under ett underhållsfönster.

2. Konfigurera MTA-läge och grundläggande SMTP-inställningar

Gå till Email > General settings och välj Switch to MTA mode vid behov. Sophos Firewall skapar då Any-to-Any-regeln Auto added firewall policy for MTA för SMTP och SMTPS. Redigera inte regeln och behåll den högst upp i brandväggens regellista. Ett byte till Legacy mode tar bort den; ett byte tillbaka skapar den på nytt.

Konfigurera grundinställningarna:

1. Ange domännamnet, exempelvis example.com, som SMTP hostname, inte den interna e-postserverns värdnamn. Värdet visas i HELO och SMTP-bannern för systemgenererade meddelanden.
2. Aktivera Reject based on IP reputation för att avvisa anslutningar från avsändare med dåligt rykte.
3. Välj ett offentligt betrott certifikat under SMTP TLS configuration och tillåt Allow invalid certificate endast för dokumenterade undantag.
4. Aktivera Disable legacy TLS protocols om inga dokumenterade äldre system kräver annat. Inställningen inaktiverar protokoll äldre än TLS 1.1; den tvingar inte automatiskt fram enbart aktuella TLS-versioner.
5. Aktivera Scan outgoing mails om även utgående meddelanden ska kontrolleras.

Använd Require TLS negotiation med försiktighet: om SFOS inte kan upprätta den TLS-anslutning som krävs kasseras e-post till berörd destination eller från den konfigurerade avsändardomänen. Brandväggen validerar dessutom SMTP TLS med domänens IP-adress i stället för domännamnet. Flera domäner på samma IP-adress kan därför orsaka certifikatvalideringsfel.

3. Lägg till e-postdomänen som Address Group

1. Öppna Email > Address group > Add.
2. Ställ in Group type på Email address/domain och Type på Manual.
3. Lägg till den skyddade domänen, exempelvis example.com.
4. Spara gruppen.

Nya SMTP route and scan-policyer är utformade för domäner, inte enskilda mottagaradresser. Migrerade enskilda adresser kan fortsätta fungera, men de kan inte läggas till eller redigeras i aktuella policyer.

4. Skapa en SMTP route and scan-policy

Gå till Email > Policies and exceptions > Add a policy > SMTP route and scan:

1. Ange ett tydligt namn, exempelvis Inbound example.com to Exchange.
2. Välj Address Group under Protected domain.
3. Välj Route by:
   • Static host: Fast IP-adress till den interna e-postservern. Om den inte svarar provar brandväggen nästa värd i listan.
   • DNS host: Ett DNS-namn som mailserver.example.com. Flera A-poster används mellan leveranser och servrar som inte svarar hoppas över.
   • MX: Leverans utifrån en MX-post.
4. För Static host väljer du e-postservern under Host list. Skapa vid behov dess IP host under Hosts and services > IP host.
5. Ställ in Global action på Accept.
6. Aktivera Spam protection och Malware protection enligt driftpolicyn.
7. Aktivera File protection och Data protection först när deras påverkan på bilagor, stora meddelanden, SPX och DKIM är klarlagd.
8. Spara policyn.

Med Route by MX får den MX-post som brandväggen löser upp inte peka tillbaka på samma brandvägg, eftersom det skapar en routningsloop. Brandväggen måste kunna lösa interna destinationer korrekt; DNS request routes hjälper vid split DNS.

Alternativet Route inbound mail through gateway behövs bara för särskilda designer, exempelvis målservrar i WAN-zonen, tillämpning av den ursprungliga brandväggsregeln på LAN/DMZ-mål eller val av en bestämd gateway med flera internetanslutningar. Aktivera det inte utan ett konkret routingkrav.

5. Säkra inkommande åtkomst och utgående relä

Tillåt under Administration > Device access SMTP Relay från varje zon som måste nå MTA:n. Inkommande e-post från internet kräver WAN; utgående e-post kräver dessutom den interna e-postserverns zon, vanligtvis LAN eller DMZ. Begränsa sedan åtkomsten till de specifika e-postservrarna, skannrarna eller programmen via Email > Relay settings > Host-based relay.

Breda värd- eller nätverksbehörigheter innebär risk för ett öppet relä. Om skrivare eller program måste skicka e-post ska de dokumenteras som specifika värdobjekt. Säkra åtkomst till Sophos Firewall beskriver grunderna i Device Access.

SMTP route and scan-policyn stöder inte SMTP AUTH. Host-based relay är därför det pålitliga alternativet för enheter. Det finns separata Authenticated relay settings för användare och grupper, men enligt Sophos följer de inte en RFC-kompatibel standard för SMTP-autentisering, så klientkompatibiliteten måste testas. Detta skiljer sig från när brandväggen autentiserar sig mot en överordnad smarthost, där SFOS stöder PLAIN och LOGIN. Ange aldrig en gränssnitts-IP från samma brandvägg som smarthost, eftersom det skapar en routningsloop.

6. Ändra MX-posten

Ändra den offentliga MX-posten till brandväggens adress först när MTA-regeln, domänen, policyn, reläet och den interna leveransvägen är klara. Skicka omedelbart ett externt testmeddelande och kontrollera att det visas i Log Viewer eller Mail logs, levereras till den interna servern och når postlådan.

Om externa avsändare inte kan nå brandväggen eller legitima meddelanden avvisas i stor omfattning återställer du den dokumenterade tidigare e-postvägen. Om brandväggen tar emot meddelanden men inte kan leverera dem kontrollerar du först routing, DNS, TLS, mottagarverifiering och e-postserverns loggar.

Välj skyddsinställningar medvetet

Spamskydd är mer än åtgärden som tillämpas på skräppost. Fel i SPF och RBL avvisas direkt och följer inte de vanliga åtgärderna för spam eller probable spam. Greylisting avvisar avsiktligt ett meddelande tillfälligt och kräver att den sändande servern försöker igen.

Recipient verification förhindrar meddelanden till okända mottagare:

• With callout: Frågar målservern. Om den tillfälligt inte är tillgänglig godkänner SFOS mottagare efter en definierad tid i stället för att permanent blockera hela e-postflödet.
• In Active Directory: Kontrollerar via Simple, SSL eller STARTTLS och har en tidsgräns på 30 sekunder.

Malware Protection kan använda enkel eller dubbel antivirusskanning. För att använda Zero-Day Protection med enkel antivirusskanning ska Sophos anges som primär motor. Sophos Firewall Zero-Day Protection beskriver begränsningar och beslut om frisläppning.

För utgående meddelanden spelar bearbetningsordningen roll. SPX encryption, subject prefixes, File eller Data Protection och utgående banners kan ändra header eller body efter att en befintlig DKIM-signatur har lagts till. DKIM-valideringen misslyckas då hos mottagaren. Bestäm om den interna e-postservern, Sophos Firewall eller en senare gateway ska signera meddelanden.

Konfigurera och testa SPX-e-postkryptering förklarar hur mall, utlösarprioritet, lösenordsmodell och Reply Portal fungerar tillsammans.

Validera e-postflödet

Kör följande kommandon från ett system utanför det egna nätverket:

dig MX example.com
dig A mail.example.com
dig AAAA 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 example.com och mail.example.com med de riktiga värdena. Kommandona testar DNS, TCP 25 och STARTTLS, men inte reläbehörighet eller fullständig leverans. openssl s_client förblir interaktivt efter handskakningen; avsluta med Ctrl+C.

Testa åtminstone följande fall:

• externt meddelande till en giltig mottagare;
• externt meddelande till en ogiltig mottagare;
• utgående meddelande via den avsedda e-postservern;
• spam- eller malwaretest som passar policyn;
• STARTTLS och den presenterade certifikatkedjan;
• karantänåtgärd och leverans efter frisläppning;
• blockerat reläförsök från en obehörig källa;
• ingen direktleverans som kringgår MTA:n via en gammal DNAT-regel.

För den första kontrollen använder du Email > Mail logs, Email > Mail spool, Email > SMTP quarantine och Log Viewer. För en djupare analys noterar du testtid, avsändare, mottagare, ämne, käll-IP och Message-ID och korrelerar dem med följande filer:

• MTA: smtpd_main.log
• avvisningar: smtpd_reject.log
• skanningsfel: smtpd_error.log
• interna MTA-fel: smtpd_panic.log
• anti-spam: sasi.log
• äldre SMTP-proxy: awarrensmtp.log
• POP/IMAP-proxy: warren.log

Sophos Firewall-tjänster och loggar beskriver mappningen och Advanced Shell-åtkomst.

Hantera karantän och e-postspool

Under Email > SMTP quarantine kan du filtrera efter tid, avsändare, mottagare, ämne och karantänorsak:

• Release: Leverera meddelandet.
• Delete: Ta bort meddelandet.
• Release and report: Frisläpp och rapportera endast falska positiva som klassificerats som Spam eller Probable spam till SophosLabs.

Virusinfekterade meddelanden och meddelanden som Zero-Day Protection klassificerar som skadliga kan inte frisläppas. För att ta bort Zero-Day Protection-poster krävs skrivbehörighet för funktionen. När karantänen är full rensas äldre meddelanden bort.

Endast användare som har autentiserat sig mot brandväggen minst en gång får karantänsammanställningar. Kontrollera aliasadresser separat i karantändesignen; meddelanden till alias visas inte i User Portal.

Email > Mail spool innehåller meddelanden som ännu inte har levererats eller vars leverans misslyckats. SFOS försöker leverera i tre dagar och kasserar meddelandena efter ytterligare fyra dagar; kasserade meddelanden är fortsatt synliga i Mail logs. En växande spool är därför en varningssignal för problem med routing, DNS, TLS, policy eller e-postservern, inte en anledning att upprepade gånger välja Retry utan diagnos.

Karantän och spool använder lokal lagring. Övervaka ledigt utrymme, SSD-status och System Health; se Rensa lagring och rapporter och Kontrollera SSD Health. I HA är loggar och rapporter separata för varje nod och synkroniseras inte, så kontrollera båda noderna. Sophos Firewall HA-kluster beskriver grunderna.

Felsökning

Extern e-post kommer inte fram

Kontrollera MX, A/AAAA, offentlig IP, TCP 25 och SMTP Relay från WAN. Kontrollera därefter att MTA-läge är aktivt, att den skyddade domänen matchar policyn och att ingen gammal DNAT-regel eller brandväggsregel med högre prioritet ändrar den förväntade vägen. Om smtpd_main.log inte visar någon anslutning ligger problemet sannolikt före Mail Protection.

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

Kontrollera den interna e-postservern, routen, DNS, målporten, TLS och mottagarverifieringen. Static host, DNS host och MX använder olika vägar för namnuppslagning och redundans. Korrelera brandväggens avvisnings- och felloggar med e-postserverns loggar.

Många meddelanden ligger kvar i spoolen

Kontrollera först Email > Mail spool och MTA-loggarna. En vanlig orsak är en regel ovanför den automatiskt genererade MTA-regeln som redan matchar SMTP. Kontrollera under Rules and policies > Firewall rules nya regler som placerats vid Top, automatiskt genererade IPsec- eller hotspot-regler och andra överlappningar. Flytta inte en regel på måfå; det är dess faktiska SMTP-matchning som är avgörande.

SFOS 22.0 MR2 åtgärdar också NC-177930, där meddelanden låg kvar i spoolen efter en mailpoller-krasch. Ta med firmwareversionen i diagnosen om problemet uppstår på en äldre version.

Central rapporterar Invalid API request

I SFOS 22.0 MR1 kunde Release och Delete misslyckas när brandväggen öppnades via Sophos Central. Den säkra tillfälliga lösningen är att logga in direkt i lokal WebAdmin och utföra åtgärden under Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 åtgärdade problemet. Om det fortfarande misslyckas där kontrollerar du administratörsprofil, Central-åtkomst och lokala behörigheter separat.

Reject based on RBL kan inte aktiveras

Sophos beskriver under NC-144563 ett versionsspecifikt fall för SFOS 20.0.2 MR2 Build 378: om standard-RBL-grupperna under Email > Address group har bytt namn kan Reject based on RBL inte aktiveras när en SMTP route and scan-policy skapas. I en befintlig policy kan alternativet inte aktiveras igen efter att det har inaktiverats. Den aktuella Known Issues List anger ingen korrigerad version.

Standardgrupperna heter Premium RBL services och Standard RBL services. Dokumentera först exakt build och gruppernas aktuella namn. Om båda villkoren är uppfyllda återställs standard-RBL:ernas ursprungliga namn, policyn öppnas på nytt och alternativet kontrolleras. Blanda inte ihop egna RBL:er med dessa två systemgrupper.

På andra builds, eller om standardnamnen är oförändrade, bevisar ett nedtonat alternativ inte NC-144563. Kontrollera policytyp, Spam protection, Email Protection-licens och övrig konfiguration separat.

En legitim avsändare klassificeras som spam

Kontrollera avsändardomänen, SPF/DKIM/DMARC, headers, reputation, policymatchning och berörda mottagare. Skapa först därefter ett snävt undantag med ett datum för omprövning.

Interna system kan inte använda reläet

Kontrollera källzonen under Administration > Device access, värdobjektet under Email > Relay settings > Host-based relay och MTA-loggarna. Om en skanner förväntar sig SMTP AUTH enligt standard är Host-based relay normalt mer pålitligt. Testa det separata, icke RFC-kompatibla Authenticated relay med den aktuella klienten.

Checklista för drift

• Licens, modellstöd, DNS och nödvändiga internettjänster är verifierade.
• MX, TTL, offentliga och interna e-postvägar samt återställning är dokumenterade.
• Den automatiska MTA-regeln är oförändrad och ligger fortfarande högst upp.
• Ingen gammal DNAT-regel kringgår Mail Protection.
• Address Group, routingmål och policymatchning är testade.
• Inkommande SMTP Relay från WAN och utgående värdbehörigheter är korrekt åtskilda.
• Effekterna av SPF/RBL, mottagarverifiering, TLS, DKIM, SPX och banners är klarlagda.
• Externa positiva och negativa tester är slutförda.
• Karantän, spool, lagring och loggar övervakas.
• E-postflödet testas på nytt efter firmwareuppdateringar.

För längre lagring och korrelation använder du Central Firewall Reporting eller skickar Sophos Firewall-loggar till ett SIEM.

FAQ