Konfigurera Sophos Firewall Mail Protection i Legacy mode

I Legacy mode fungerar Sophos Firewall som en transparent e-postproxy. Den interna e-postservern förblir den faktiska SMTP-endpointen; brandväggen vidarebefordrar trafiken genom befintliga brandväggs- och NAT-regler och söker samtidigt efter spam, malware, filtyper och Data Control-träffar.

Detta skiljer sig grundläggande från MTA mode. Brandväggen blir inte en Mail Transfer Agent, tar inte över e-postleverans för skyddade domäner och erbjuder ingen MTA mail spool för denna väg. Ett lyckat SMTP-porttest bevisar därför varken proxyskanning eller att rätt policy tillämpas.

⚠️ En ändring av SMTP Deployment Mode är en global ändring av e-postskyddsvägen. Före växlingen måste backup, befintliga policyer, brandväggs- och NAT-regler samt en testad återställningsväg dokumenteras. Ett MTA-problem är inget skäl att oplanerat växla till Legacy mode.

Legacy mode i nio steg

1. Dokumentera den befintliga inkommande och utgående SMTP-vägen med IP-adresser, portar, NAT och Firewall Rule IDs.
2. Kontrollera om transparent proxy verkligen passar bättre än MTA mode.
3. Säkerställ en konfigurationsbackup och oberoende managementåtkomst.
4. Välj Switch to legacy mode under Email > General settings.
5. Fastställ SMTP-storleksgräns, åtgärd för för stora meddelanden, IP Reputation, DoS-gränser och TLS-beteende.
6. Skapa endast nödvändiga SMTP malware- och SMTP spam-policyer eller kontrollera deras ordning.
7. Begränsa inkommande DNAT- och utgående SNAT-vägar till den faktiska e-postservern.
8. Aktivera Scan SMTP eller Scan SMTPS i de brandväggsregler som faktiskt matchar.
9. Verifiera inkommande och utgående testmeddelanden med Rule ID, policyresultat, certifikat och Legacy-proxyloggar.

Välja Legacy mode eller MTA mode

Legacy mode passar främst befintliga miljöer där den interna e-postservern redan publiceras direkt via NAT och denna väg ska behållas. SFOS ligger transparent mellan den externa motparten och servern. MX-mål, SMTP-mottagning och leveranslogik förblir delar av den befintliga e-postserverdesignen.

MTA mode är det bättre valet när brandväggen själv ska ta emot meddelanden, routa dem per skyddad domän, relaya dem och behålla dem i en spool vid tillfälliga leveransfel. Mail logs och mail spool hör uttryckligen till denna driftsmodell. Den fullständiga konfigurationen finns i Konfigurera Mail Protection i MTA mode.

Enligt SFOS 22-hjälpen är MTA mode inte tillgängligt på XGS 87/87w och XGS 88/88w. Det gör dock inte automatiskt Legacy mode till en lämplig molne-postarkitektur. Microsoft 365, Google Workspace och moderna hostade tjänster använder egna krav för TLS, autentisering och skydd mot missbruk. Deras stöd för en transparent proxy måste bekräftas i förväg.

Kort sagt: MTA mode har ett eget e-postflöde. Legacy mode skyddar en redan fungerande SMTP-väg. Om dessa modeller blandas ihop söker man senare i fel logg, vid fel NAT-mål eller i en spool som inte finns.

Exempeltopologi och återställningsväg

Följande exempel använder dokumentationsvärden och måste anpassas till den verkliga miljön före implementering:

• intern e-postserver 10.20.30.25 i zonen DMZ
• offentlig SMTP-adress 192.0.2.25 på WAN-vägen
• inkommande SMTP-tjänst TCP 25
• valfri SMTPS på TCP 465, endast om peers och server faktiskt använder denna variant
• brandväggsregler SMTP_In_Legacy och SMTP_Out_Legacy

192.0.2.25 tillhör TEST-NET-intervallet och är inget produktionsvärde. Före ändringen utförs ett externt inkommande test och ett utgående test med tidsstämpel. Spara aktuella matchande Rule IDs, den offentliga källadress som används av den utgående servern och certifikatkedjan.

Återställningsvägen består inte bara av att byta tillbaka läget. Även nya skanningsalternativ, policyordning, DNAT, reflexive eller manuella SNAT-regler och tillfälliga tester måste kunna återställas till det dokumenterade tidigare tillståndet.

Fastställa globala SMTP-inställningar

Storleksgräns, åtgärd för stora meddelanden och DoS-skydd

Under Email > General settings > SMTP settings anger Don’t scan emails greater than den maximala meddelandestorleken för skanning. I SMTP-vägen betyder värdet 0 enligt SFOS 22-hjälpen 51,200 KB, inte obegränsat. För större meddelanden finns Accept, Reject och Drop.

Accept levererar ett för stort meddelande utan att skanna det. Reject avvisar det och informerar avsändaren, medan Drop tar bort det utan meddelande. Detta val är ett medvetet risk- och driftsbeslut. Ett otestat Drop försvårar felsökning; ett obeaktat Accept skapar ett skanningsgap som måste dokumenteras.

Verify sender’s IP reputation kontrollerar avsändarens IP-adress före spamkriterierna i SMTP-policyn. SMTP DoS-värden begränsar anslutningar, meddelanden och mottagare. Produktionsgränser härleds från den verkliga e-postvolymen och en baseline, inte från ett generiskt internetexempel.

Bypass spam check for SMTP/S authenticated connections hoppar globalt över spamkontrollen för anslutningar som e-postservern rapporterar som autentiserade. Detta är endast acceptabelt efter att autentisering, tillåtna källor och skydd mot missbruk på denna väg har verifierats. En lyckad inloggning ersätter varken malware-skanning eller ett negativt test med en icke-autentiserad anslutning. Domäner under Spam check exceptions är också ett globalt undantag och används inte som en snabb ersättning för ett snävt avgränsat undantag.

Den globala e-postbannern erbjuder Inline, no conversion, MIME part och Off. Den visas endast när SMTP- eller SMTPS-skanning är aktiv i den matchande brandväggsregeln. Eftersom ändringen av meddelandets body kan bryta en befintlig DKIM-signatur verifieras den verkliga utgående vägen genom kontroll av headers hos mottagaren.

Överskatta inte TLS på grund av en kryssruta

Under SMTP TLS configuration väljs det CA- eller servercertifikat som ska användas för skanningen. Allow invalid certificate förblir avstängt. Enligt hjälpen stänger Disable legacy TLS protocols endast av protokoll före TLS 1.1 och bevisar inte en konkret TLS 1.2- eller TLS 1.3-session.

Sophos påpekar dessutom en viktig Legacy-begränsning: brandväggen etablerar TLS-anslutningen via domänens IP-adress i stället för domännamnet. Om flera domäner delar en IP-adress kan certifikatvalideringen misslyckas. I detta fall rekommenderar Sophos en annan skyddsväg, till exempel Sophos Email Security. Kontrollen kringgås inte med Allow invalid certificate.

Require TLS negotiation tvingar TLS för valda Remote Hosts eller nätverk; Require sender email domains tvingar det för avsändardomäner. Om TLS-anslutningen inte kan etableras tar SFOS bort de berörda meddelandena. Skip TLS negotiation tillåter avsiktligt okrypterade SMTP-anslutningar till valda peers och hör endast hemma i dokumenterade undantag.

Använda skanningspolicyer medvetet

När Email Protection-prenumerationen har aktiverats tillämpar Sophos Firewall automatiskt standardpolicyn default-smtp-av på SMTP-trafik i Legacy mode. Egna policyer skapas under Email > Policies och bearbetas i listordning. Kontrollera därför först vilken befintlig policy som matchar den konkreta avsändaren och mottagaren.

SMTP malware scan

En SMTP malware scan-policy styr blockerade filtyper, MIME-undantag, antivirusskanning och leveransåtgärder. Med Single antivirus gäller den valda motorn enligt hjälpen bara för inkommande meddelanden; utgående meddelanden skannas av båda motorerna. Dual antivirus kör primär och sekundär motor efter varandra.

Åtgärden Quarantine kombineras med åtgärderna för mottagare och administratör. Don’t deliver, Deliver original och Remove and deliver har mycket olika konsekvenser. En skyddad eller icke skanningsbar bilaga får inte automatiskt likställas med malware. Varje åtgärd behöver därför ett testmeddelande, ett förväntat mottagartillstånd och en dokumenterad frigivningsväg.

Quarantine betyder inte automatiskt att mottagaren inte får något meddelande; Delivery option for recipient är fortfarande avgörande. Enligt Sophos fungerar Notify sender endast tillsammans med Don’t deliver. Skyddade bilagor skannas inte, men kan fortfarande utlösa en avisering. Den separata administratörsåtgärden avgör om ingen kopia, originalet eller ett meddelande utan bilaga skickas till administratörerna. Dessa fyra resultat härleds inte från ett enda lyckat testmeddelande.

SMTP spam scan

En SMTP spam scan-policy kan matcha spamklassificering, källa eller destination, RBL, meddelandestorlek, headers eller en Data Control List. Beroende på väg finns åtgärderna Reject, Accept, Change recipient, Prefix subject, Drop och Quarantine.

Kriteriet Data control list och SPX-tilldelningen i denna policy gäller endast utgående meddelanden. None tillämpar däremot den valda åtgärden på alla meddelanden mellan de angivna avsändar- och mottagargrupperna. Change recipient levererar inte dessutom till den ursprungliga mottagaren, utan ersätter den med den konfigurerade destinationen. Dessa tre omfattningar testas med ett positivt och ett negativt mottagarfall innan policyn placeras i produktionsordningen.

Förbered egna filtyper och Data Control

I Legacy mode skapas egna filtyper under Email > Policies > File type > Add från en mall, filändelser eller MIME-typer. Filändelser anges utan inledande punkt och endast egna typer kan redigeras. En ny typ läggs inte automatiskt till i befintliga policyer. Öppna den berörda scan-policyn, lägg till filtypen och spara policyn igen. Ett positivt test med en bilaga och ett liknande negativt test visar om den avsedda policyåtgärden verkligen används.

En Data Control List skapas under Email > Data control list > Add av de Content Control Lists som behövs. Filtren Type och Region hjälper till att välja endast relevanta mönster för finansiella uppgifter, identitetsdata eller andra känsliga uppgifter. En listmatchning definierar ännu ingen åtgärd; den anges i den länkade scan-policyn. En liten pilotlista med ett positivt och ett negativt innehållstest är säkrare än en bred samling overifierade CCL:er.

I Legacy mode kan SPX väljas i denna policy för utgående meddelanden. Lösenordsmodell, portal och verifiering är dock ett separat säkerhetsflöde; se Konfigurera SPX-e-postkryptering. Lägg inte till en Data Control List eller SPX-tilldelning i det första grundläggande proxytestet.

En bekräftad felklassificering ska inte korrigeras genom att en bred policy stängs av. Skapa och testa e-postundantag på ett säkert sätt förklarar hur enskilda kontroller hoppas över för en exakt kombination av källa, avsändare och mottagare och hur trafik som inte ska matcha sedan testas.

Använda valfri e-postjournalföring med hänsyn till dataskydd

Under Email > General settings > Email journaling > Add kan SFOS skicka kopior av inkommande SMTP/S-meddelanden för valda mottagare eller adressgrupper till en separat journaladress. Valet Any omfattar alla inkommande meddelanden. Funktionen gäller endast SMTP/S och journalför inte POP- eller IMAP-trafik.

Journalföring skapar en extra kopia av e-postmeddelandet. Den utgör inte automatiskt ett manipulationssäkert arkiv och bevisar inte att lagstadgade lagringskrav uppfylls. Före aktiveringen fastställs syfte, behöriga mottagare, åtkomst till journalbrevlådan, kryptering, lagringstid, lagringsbehov och ansvarig ägare.

För det första testet väljs en enda testbrevlåda i stället för Any. Ett inkommande meddelande till denna brevlåda ska visas både på den normala destinationen och i journalbrevlådan. Ett meddelande till en mottagare utanför urvalet får inte skapa någon journalkopia. Journaladressen får inte utlösa ett e-postflöde som skickar kopian tillbaka till SFOS och skapar en loop.

Mottagarurvalet utökas först efter det positiva och negativa testet. Vid rollback tas journalposten bort eller återställs till det dokumenterade tidigare tillståndet. Redan levererade kopior finns kvar i journalbrevlådan och måste hanteras enligt dess egna lagringsregler.

Kombinera NAT och brandväggsregler

Publicera den inkommande SMTP-vägen

För inkommande meddelanden översätter en DNAT-regel den offentliga WAN-adressen till den interna e-postservern. Original Source begränsas så långt e-postdesignen tillåter; Original Destination är den avsedda offentliga adressen; Translated Destination är 10.20.30.25 eller den faktiska e-postservern. Original service och translated service förblir begränsade till de SMTP-portar som verkligen erbjuds.

En reflexive regel skapar dessutom SNAT för motsatt riktning. Den väljs endast om exakt denna offentliga källidentitet är avsedd för den utgående vägen. Flera WAN-länkar, smarthosts eller avvikande operatörsvägar kräver en egen routing- och SNAT-design. Den allmänna ordningen och destinationszonen efter NAT förklaras i Publicera en server med DNAT.

Använda två snäva brandväggsregler

För verifiering är separata regler tydligare än en dubbelriktad regel med flera zoner och Any-objekt:

• Inkommande: WAN till den interna e-postserverns zon, destinationshost 10.20.30.25, endast nödvändiga SMTP-tjänster, logging aktiverad
• Utgående: den interna e-postserverns zon och host till WAN eller den specifika smarthosten, endast nödvändiga SMTP-tjänster, logging aktiverad

Under Scan email content aktiveras Scan SMTP i båda nödvändiga riktningarna och Scan SMTPS endast när SMTPS faktiskt används. En aktiverad kryssruta lägger inte automatiskt till en saknad tjänst i en korrekt säkerhetsdesign. Tjänst, NAT, serverlistener och skanningsalternativ måste beskriva samma portväg.

Placera reglerna ovanför mer allmänna regler som redan matchar samma trafik. Efter att de har sparats är den loggade Firewall Rule ID avgörande. Regelstruktur, NAT-zon och ordning behandlas i Konfigurera Sophos Firewall-regler säkert.

Verifiera e-postflöde och proxyskanning

Skicka först ett litet externt meddelande till en testbrevlåda. Låt därefter den interna e-postservern skicka ett andra meddelande till en kontrollerad extern mottagare. Ge båda testerna unika ämnesrader och UTC-tidsstämplar.

För STARTTLS på port 25 och en direkt TLS-anslutning på port 465 kan följande kontroller, som inte ändrar systemet, vara till hjälp från ett behörigt testsystem:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

Ersätt mail.example.net med verklig FQDN och testa endast portar som faktiskt erbjuds. OpenSSL bekräftar nåbarhet, certifikatkedja och förhandlade TLS-parametrar. Det bevisar varken lyckad e-postleverans eller skanning av malware, spam eller Data Control.

I Log Viewer måste källa, destination, tjänst, åtgärd och Firewall Rule ID stämma överens med de nya reglerna. För Legacy SMTP/S-proxyn korreleras awarrensmtp.log och awarrenmta.log med samma tidsstämpel. Loggfilerna förklaras i Sophos Firewall-tjänster och loggar.

Utför därefter ett negativt test. En oavsedd källa, en port som inte har godkänts eller ett testmeddelande utan policykriteriet får inte av misstag få samma skyddsväg. Använd inte verklig malware vid produktionstestning; använd etablerade ofarliga testmönster och en kontrollerad brevlåda för skanningsverifieringen.

Avgränsa fel efter symtom

SMTP fungerar, men policyn tillämpas inte

Kontrollera först Firewall Rule ID. Om en annan regel matchar korrigeras ordning, källa, destination, NAT-mål och tjänst. Om den förväntade regeln matchar måste Scan SMTP eller Scan SMTPS, policyordningen och avsändar- och mottagargrupperna passa testet. En policy i sig aktiverar inte den transparenta proxyn.

Inkommande e-post når inte servern

Kontrollera offentlig destinationsadress, DNAT-träff, translated destination, destinationszon, serverlistener och returväg separat. En öppen TCP-anslutning fram till brandväggen bevisar inte att DNAT och brandväggsregeln når den interna servern. Packet Capture och Rule ID måste visa ingång och vidarebefordran.

Utgående e-post använder fel offentlig IP-adress

Kontrollera SNAT, reflexive-regeln, WAN-gateway, SD-WAN-route och beteendet för reply packets. Legacy-proxyn väljer inte automatiskt den offentliga källadress som behövs för SPF, RDNS eller operatörens godkännande. Bevisa den konkreta vägen före en global ändring av Route Precedence.

TLS misslyckas efter att skanningen har aktiverats

Registrera FQDN, destinations-IP, certifikat, utfärdare, kedja och förhandlad version. Om flera domäner delar en IP-adress kan den dokumenterade IP-baserade certifikatkontrollen vara orsaken. Allow invalid certificate aktiveras inte som snabb lösning.

Ett meddelande saknas och inget syns i MTA mail spool

Detta är inget användbart framgångskriterium i Legacy mode, eftersom mail spool och MTA-specifika mail logs hör till MTA mode. Den relevanta kedjan består här av brandväggsregeln, NAT, SMTP-serverloggar, Log Viewer, awarrensmtp.log och awarrenmta.log. Kontrollera meddelanden i karantän separat under Email > SMTP quarantine.

Genomföra en säker rollback

För rollback återställs först pilotreglerna och skanningsalternativen till dokumenterat tidigare tillstånd. Därefter tas nya policytilldelningar bort eller deras ordning återställs. Tillfälliga ändringar av DNAT, SNAT eller certifikat tas endast bort om ingen annan tjänst är beroende av dem.

Först därefter återställs SMTP Deployment Mode om ändringen omfattade denna växling. Det ursprungliga inkommande och utgående e-postflödet måste åter fungera med förväntade Rule IDs, offentliga adresser och serverloggar. Meddelanden, karantäninnehåll eller proxyloggar raderas inte som standardåtgärd vid rollback.

Driftchecklista

• Transparent proxy har valts medvetet och MTA-krav har uteslutits.
• Backup, managementåtkomst och ursprungliga Rule IDs är dokumenterade.
• SMTP-storleksgräns, åtgärd för för stora meddelanden, IP Reputation och DoS-gränser är motiverade.
• Certifikat, TLS-undantag och berörda domäner har kontrollerats.
• DNAT, SNAT, destinationszon och verkliga serverportar stämmer överens.
• Inkommande och utgående brandväggsregler är snäva, loggade och bevisat matchande.
• Standardpolicyer och egna policyer har en spårbar ordning.
• Valfri journalföring är begränsad till nödvändiga mottagare och har ett dokumenterat syfte för dataskydd och lagring.
• Positivt, negativt, TLS- och leveranstest har lyckats.
• Legacy-proxyloggar och e-postserverloggar kan tidskorreleras.
• Ansvarig, granskningsdatum och fullständig återställningsväg är dokumenterade.

FAQ