Ställ in Sophos Firewall Mail Protection i MTA-läge

Sophos Firewall kan acceptera SMTP trafik i MTA läge själv, kontrollera den och vidarebefordra den till den interna e-postservern eller nästa e-posthopp. Brandväggen är då inte bara en portrelease för TCP 25, utan en aktiv e-postöverföringsagent med routing, spam- och malware-kontroll, karantän, spool- och e-postloggar.

Vi rekommenderar Mail Protection på brandväggen idag speciellt för medvetet planerade lokaler eller hybridscenarier, till exempel om en lokal Exchange eller annan intern e-postserver ska skyddas direkt via brandväggen. För Microsoft 365, Google Workspace och många moderna molnmailmiljöer är Sophos Central Email eller annan molnpostgateway vanligtvis en renare arkitektur eftersom MX, karantän, rubriker, TLS, SPF/DKIM/DMARC och support ligger närmare den faktiska e-posttjänsten.

Om Mail Protection används i MTA-läge måste artikeln göra mer än en funktionsdeklaration: MX-post, automatisk MTA-regel, SMTP rutt- och skanningspolicy, reläsläpp, TLS, användarkontroll, spool, karantän och loggar måste matcha. Annars kan brandväggen avvisa legitima e-postmeddelanden, försena e-postmeddelanden eller oavsiktligt bli nåbar som ett relä.

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

Mail Protection på Sophos Firewall är särskilt användbar om SMTP-trafik ska flöda avsiktligt genom brandväggen och brandväggen ska göra mer än att bara vidarebefordra port 25.

Typiska scenarier:

• Inkommande e-postmeddelanden bör först accepteras och kontrolleras på brandväggen.
• En intern e-postserver ska inte vara tillgänglig direkt från Internet.
• Spam, skadlig programvara, filtyp eller innehållskontroller bör ske före leverans.
• Utgående e-post ska skickas på ett kontrollerat sätt via brandväggen eller en smart värd.
• Karantän, postspool och SMTP-loggar bör kunna spåras på brandväggen.

Alla e-postinställningar bör inte köras genom brandväggen. Om Sophos Central Email, Microsoft Defender för Office 365 eller en annan molnpostgateway redan tar över hela e-postflödet, bör du inte också byta Mail Protection på brandväggen utan att dokumentera e-postflödet i detalj. Duplicerade gateways leder snabbt till oklara ansvarsområden för karantän, rubriker, SPF/DKIM/DMARC, TLS och felsökning.

Skilj mellan MTA-läge, äldre läge och SMTP-relä

Med Sophos Firewall måste du separera tre saker rent:

• MTA Läge: Brandväggen accepterar e-post, kontrollerar den och vidarebefordrar den. Detta passar inkommande eller utgående SMTP postflöde med policyer.
• Äldret läge: Äldre proxybaserad e-postbearbetning. Relevant för befintliga miljöer som migreras eller avsiktligt fortsätter att fungera.
• SMTP Relä som lokal tjänst: Interna system skickar över brandväggen. Typiska exempel är skrivare, skannrar, applikationer eller övervakningssystem.

MTA-läge är det normala målläget för moderna brandväggsskyddsscenarier. Den lokala tjänsten SMTP Relay är å andra sidan ett ämne för enhetsåtkomst. Den ska endast vara tillgänglig från definierade interna nätverk. En för bred release kan uppmuntra till relämissbruk. Förstärkning av lokala tjänster beskrivs i Sophos Firewall Säkra åtkomst: Konfigurera Device Access korrekt.

Krav

Innan du installerar bör dessa punkter förtydligas:

• Sophos Firewall med giltigt e-postskydd eller lämpligt paket.
• Alla modeller stöder inte läget MTA. XGS 87/87w och XGS 88/88w är apparater utan stöd för MTA-läge.
• Offentlig DNS-zon och MX-post är kända.
• Intern e-postserver, destinationsport och leveransväg dokumenteras.
• Offentlig IP-adress eller WAN-adress för inkommande SMTP-trafik är definierad.
• Brandväggen kan dirigera och nå den interna e-postservern.
• Brandvägg utgående DNS åtkomst fungerar.
• Önskad TLS och certifikatstrategi har förtydligats.
• Karantän och frigivningsprocess är organisatoriskt definierad.

Ett underhållsfönster bör planeras innan du gör ändringar i postflödet. Att testa på produktiva MX-poster utan en reservplan är riskabelt eftersom inkommande e-postmeddelanden snabbt försenas eller avvisas, beroende på avsändaren.

Bestäm målarkitektur

Först bör du bestämma vilken riktning brandväggen ska bearbeta.

Inkommande postflöde

I det inkommande e-postflödet pekar externa MX-poster till den offentliga adressen genom vilken Sophos Firewall accepterar SMTP. Brandväggen kontrollerar meddelandet och vidarebefordrar det till den interna e-postservern.

Typisk process:

1. Extern avsändare ansluter via SMTP till den offentliga MX-adressen.
2. Sophos Firewall accepterar anslutningen i MTA-läge.
3. Mail Protection kontrollerar avsändare, mottagare, skräppost, skadlig programvara, bilagor och policyer.
4. Brandväggen levererar e-postmeddelandet till den interna e-postservern.
5. Den interna e-postservern levererar till brevlådan eller bearbetar meddelandet vidare.

Det är viktigt att den interna e-postservern inte förblir tillgänglig från Internet ofiltrerad. Om en DNAT-regel pekar direkt till e-postservern samtidigt, kan en del av trafiken kringgå Mail Protection. För normal serverpublicering är publicera server via DNAT lämplig bas, men i MTA-läge är själva brandväggen SMTP-acceptanspunkten.

Utgående postflöde

För utgående e-postflöde skickar den interna e-postservern via Sophos Firewall. Brandväggen kan inspektera meddelanden, vidarebefordra dem till en smart värd eller leverera dem direkt, beroende på konfigurationen.

Förtydliga i förväg:

• Kan den offentliga brandväggens IP skicka e-post direkt?
• Är SPF, DKIM och DMARC korrekta för den valda fraktmetoden?
• Krävs en smart värd för leverantören?
• Behöver utgående SMTP-trafik begränsas till specifika interna system?
• Var övervakas avvisade eller försenade meddelanden?

En separat, begriplig regel och policystruktur bör användas för utgående e-posttrafik. En allmän LAN to WAN-regel utan en tydlig begränsning är vanligtvis för grov för e-postservrar. Grunderna för regelsekvens och säkerhetsprofiler finns i Sophos Firewall Förstå regler och ställa in dem korrekt.

Förbered MX konvertering och externa tester

En förändring av e-postskyddet blir avgörande först när externa avsändare faktiskt använder den nya metoden. Det är därför du bör kontrollera MX-Record, DNS-TTL, extern tillgänglighet och återställning innan den produktiva förändringen.

Innan ändringen:

• Dokumentera aktuell MX-post, prioritet och TTL.
• Minska DNS-TTL tidigt när snabbt återfall kan vara nödvändigt.
• Skilj tydligt mellan den gamla e-postsökvägen och den nya Sophos brandväggsadress.
• Identifiera gamla direkta DNAT-regler på e-postservern.
• Definiera testmottagare och testavsändare.
• Ange reservplan: gammal MX, gammal DNAT regel eller tillfällig smart värd.
• Förbered övervakning för spool, karantän och e-postserverkö.

Användbara externa kontroller från ett system utanför ditt eget nätverk:

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 komplett e-postflödestest, men de visar snabbt om DNS, port 25 och STARTTLS är allmänt tillgängliga. example.com och mail.example.com måste ersättas med den riktiga domänen och e-postvärden.

Efter bytet ska du omedelbart skicka ett inkommande testmail och dokumentera hela sökvägen:

• Syns anslutningen i Log Viewer?
• Inlägg tillgängligt i smtpd_main.log?
• Mottagarekontrollen lyckades?
• Leverans till intern mailserver?
• Har meddelandet kommit till din inkorg?
• Ingen parallell direktleverans förbi MTA?

Om brandväggen accepterar e-postmeddelanden men inte levererar dem, bör MX inte återställas omedelbart. Förklara först om det är ett internt routing-, DNS-, TLS- eller e-postserverproblem. Men om externa avsändare inte kan upprätta en anslutning till brandväggen eller om legitima e-postmeddelanden avvisas allmänt, är en snabb återgång till den tidigare e-postsökvägen ofta mer meningsfull än långvariga experiment i den produktiva MX-sökvägen.

MTA Aktivera läge

Grundinställningarna är nedan:

Email > General settings

För dessa instruktioner måste MTA-läget vara aktivt. Om brandväggen fortfarande körs i äldre läge görs bytet med Byt till läge MTA.

När den har aktiverats skapar Sophos Firewall automatiskt en brandväggsregel för SMTP/SMTPS med namnet Auto added firewall policy for MTA. Denna regel ska förbli synlig och högt upp i regelbasen. En MTA-regel får inte behandlas som en vanlig LAN-till-WAN-regel eller slentrianmässigt flyttas ned, annars kommer inkommande SMTP-trafik inte längre att hamna i den förväntade MTA-sökvägen.

Grundinställningarna kontrolleras sedan:

1. Under SMTP inställningar ställ in SMTP värdnamn. Detta är värdnamnet som brandväggen använder i HELO- och bannersammanhang för systemgenererade meddelanden. Ange inte blint det interna e-postservernamnet om det offentliga e-postnamnet är ett annat.
2. Aktivera Avvisa baserat på IP-rykte om inkommande SMTP-anslutningar ska avvisas baserat på dåligt avsändarrykte.
3. Välj ett lämpligt offentligt pålitligt certifikat under SMTP TLS konfiguration om SMTP TLS ska presenteras rent via brandväggen.
4. Aktivera Inaktivera äldre TLS-protokoll om det inte finns medvetet dokumenterade äldre system mot det.
5. Aktivera Skanna utgående e-post om utgående meddelanden från e-postservern också ska kontrolleras via brandväggen.

I befintliga miljöer, växla inte bara mellan äldre läge och MTA läge utan att testa e-postflödet. Bearbetningen, loggarna och policylogiken skiljer sig åt. Innan en migrering ska den aktuella brandväggskonfigurationen, MX-poster, e-postserveranslutningar och reläinställningar dokumenteras.

SMTP Konfigurera routing och domäner

För inkommande e-postmeddelanden måste brandväggen veta vilka domäner som ska accepteras och var de ska levereras.

Skapa adressgrupper för e-postdomäner

Först skapas en adressgrupp för de skyddade e-postdomänerna:

1. Öppna Email > Address group.
2. Klicka på Lägg till.
3. Kontrollera Grupptyp för E-postadress/domän.
4. Lämna Typ inställt på Manuell om domänerna underhålls manuellt.
5. Ange domänen under E-postadress/domän, till exempel example.com, och lägg till den.
6. Klicka på Spara.

Det handlar om domäner, inte enskilda mottagaradresser. Enskilda befintliga eller migrerade e-postadresser kan fortfarande användas beroende på konfigurationen, men kan inte längre planeras som nya poster i nuvarande SMTP rutt- och skanningspolicyer. För att uppnå ett rent måltillstånd bör du därför arbeta med domäner och lämpliga mottagarkontroller.

SMTP Skapa rutt- och skanningspolicy

Den faktiska MTA-policyn skapas under följande sökväg:

Email > Policies and exceptions > Add a policy > SMTP route and scan

En typisk process för inkommande e-postmeddelanden till en intern e-postserver:

1. Ange ett meningsfullt namn, till exempel Inbound example.com to Exchange.
2. Välj den tidigare skapade adressgruppen under Skyddad domän.
3. Ställ in Rutt efter:
   • Statisk värd: För fasta interna e-postserver IP-adresser.
   • DNS värd: För ett DNS namn som mailserver.example.com.
   • MX: Om brandväggen ska leverera baserat på MX-poster.
4. För Statisk värd, välj den interna e-postservern under Värdlista. IP-värdar skapas under Hosts and services > IP host om det behövs.
5. Ställ in Global action på Acceptera om domänen ska accepteras och kontrolleras för policy.
6. Aktivera Skräppostskydd och avgör medvetet om skräppost varnas, sätts i karantän, släpps eller levereras utan åtgärd.
7. Aktivera Skydd mot skadlig programvara. Zero-Day Protection med enkel antivirusskanning kräver att Sophos används som primär motor.
8. Aktivera endast Filskydd och Dataskydd om effekterna på bilagor, stora meddelanden, SPX och DKIM förstås.
9. Klicka på Spara.

Om du har flera interna e-postservrar är routningstypen viktig. Statisk värd byter till nästa värd om den första värden inte kan nås. För DNS värd med flera A-poster kan leverans distribueras. Detta är praktiskt, men måste passa e-postserverns design, TLS-certifikat och felanalys.

DNS är särskilt viktigt för interna e-postservrar. Brandväggen måste kunna lösa interna destinationer korrekt och externa avsändare måste nå den offentliga MX-posten. Om intern DNS upplösning spelar en roll, ställ DNS Request Routes till Sophos Firewall hjälper.

Planera policyer för spam, skadlig programvara och bilagor

Mail Protection är bara så bra som de policyer som faktiskt fungerar. En policy ska inte bara skapas utan namnges med ett tydligt syfte.

Viktiga policyfrågor:

• Vilka domäner eller mottagargrupper berörs?
• Bearbetas inkommande, utgående eller tvåvägsposttrafik?
• Vad händer om det finns spam, skadlig programvara, misstänkta bilagor eller oönskade filtyper?
• Är e-postmeddelanden blockerade, i karantän, levererade eller markerade med rubriker?
• Bör mottagarverifiering användas via bildtext eller Active Directory?
• Vem kan kontrollera karantän och släppa e-postmeddelanden?
• Vilka falska positiva processer finns det?

När det gäller spamskydd ska SPF, RBL, Greylisting, BATV och mottagarverifiering inte behandlas som rena kryssrutor. RBL- eller SPF-träffar behandlas inte som vanliga skräppoståtgärder, men kan avvisa meddelanden direkt. Mottagareverifiering minskar backscatter och ogiltiga mottagare, men kan i sig bli en källa till fel i AD, TLS eller e-postserverproblem.

DKIM är särskilt känsligt för utgående meddelanden. SPX-kryptering, ämnesprefix, blockerade filtyper, dataskydd eller en utgående banner kan ändra rubriker eller kroppar. Detta kan göra att en DKIM-hash går sönder hos mottagaren MTA. Om utgående signaturer är viktiga bör du bestämma om signeringen ska ske på e-postservern, på Sophos Firewall eller vid en senare gateway.

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

Säkert relä och Device Access

Ett vanligt misstag är förvirring mellan MTA postflöde och öppet SMTP relä. Brandväggen får inte användas som ett relä från något nätverk.

För inkommande e-postmeddelanden måste SMTP alltid accepteras på WAN-sidan så att externa e-postservrar kan leverera domänen. För utgående mejl måste det dock framgå vilka interna värdar som får vidarebefordra via brandväggen.

Kontrollera:

• Under Administration > Device access är SMTP Relay endast aktiverad i de zoner som verkligen behövs.
• När ACL Exception Rules används är källorna snävt definierade.
• Under Email > Relay settings anges endast definierade e-postservrar, skannrar eller applikationsservrar som tillåtna källor för Värdbaserat relä.
• Onödiga zoner, gästnätverk och opålitliga nätverk får inte förmedlas över hela linjen.
• Om molntjänster som Exchange Online Protection ska leverera eller vidarebefordra via brandväggen måste de tillåtna källområdena underhållas mycket exakt. Breda Any-släpp är en öppen relärisk.
• Loggningen är aktiv så att missbruk eller felkonfigurationer uppmärksammas.

Om skrivare, skannrar eller applikationer behöver skicka e-post ska en separat intern reläväg dokumenteras. Sådana system bör inte tala direkt till några externa SMTP-mål om miljön kan undvika det.

Testa mailflöde

När konfigurationen är klar räcker det inte med en enda lyckad sändning. Du bör utföra flera tester och dokumentera resultaten.

Testa noggrant

Kontrollera åtminstone:

• Extern MX post pekar på den förväntade adressen.
• Port 25 kan nås externt.
• Brandväggen accepterar anslutningen i läge MTA.
• E-post vidarebefordras till den interna e-postservern.
• Mottagare finns och tar emot meddelandet.
• Testning av skräppost eller skadlig programvara hanteras som förväntat.
• Karantän eller loggpost är spårbar.

Testa utgående

Kontrollera åtminstone:

• Intern e-postserver skickar via förväntad rutt.
• Brandväggsregler och e-postpolicyer gäller.
• SPF, DKIM och DMARC matchar fraktmetoden.
• Destinationsservern accepterar meddelandet.
• Avvisningar eller uppskjutna meddelanden övervakas.
• Inga andra interna system skickar oplanerad data direkt externt.

Kontrollera loggar

Log Viewer hjälper till för en snabb visuell inspektion. E-postloggfilerna är viktiga för djupare analys. Uppgiften finns i Sophos Firewall Felsökning: tjänster och loggar.

Relevanta loggfiler:

• SMTP MTA: smtpd_main.log.
• SMTP Fel: smtpd_error.log, smtpd_panic.log och smtpd_reject.log.
• Anti-spam: sasi.log.
• Äldre SMTP/MTA: awarrensmtp.log, awarrenmta.log och awarrenmta_debug.log.
• POP/IMAP-proxy: warren.log.

Vid akut felsökning bör du notera tidpunkten för testet, samla in avsändare, mottagare, ämne, käll-IP och meddelande-ID och sedan korrelera Log Viewer och loggfiler i tid.

Karantän, spole och förvaring

Mail Protection genererar lokal data. Beroende på volym hamnar meddelanden i karantän, spool eller tillfälliga områden. Detta gör lagringsutrymme, SSD-hälsa och återställningsplan mer relevant än med en ren brandväggsregel.

Praktiska operativa frågor:

• Vem kontrollerar karantän och hur ofta?
• Hur släpps falska positiva ut? – Pratar du om Meddelande för att smällar?
• Hur upptäcks en växande e-postspool?
• Finns det övervakning av lagringsutrymme och systemtillstånd?
• Är ett kort e-postflödestest schemalagt efter firmwareuppdateringar?

För lagrings- och rapporteringsämnen är Sophos Firewall Rensa lagring och rapporter och Sophos Firewall Kontrollera SSD-tillstånd lämpliga. I HA-miljöer bör det också noteras att postkarantän och bearbetad postdata kan vara nodrelaterad driftdata. Grunderna för HA finns i Sophos Firewall HA klustervarianter.

Kontrollera karantän direkt i WebAdmin

Om en brandvägg hanteras via Sophos Central är åtkomst via Central bekvämt. För Mail Protection bör du fortfarande veta var karantänen är lokalt och hur du kontrollerar den direkt på brandväggen.

Den lokala vägen är:

Email > SMTP quarantine

Där kan du filtrera meddelanden i karantän efter period, avsändare, mottagare, ämne och orsak till karantän. Tre åtgärder är särskilt relevanta för verksamheten:

• Delete: Ta bort meddelande från karantän.
• Release: Släpp meddelande till mottagaren.
• Release och rapportera: Frisläpp och rapportera falska positiva till SophosLabs.

Viktigt: Virusinfekterade meddelanden och meddelanden som klassificerats som skadliga av Zero-Day Protection kan inte enkelt delas. Nolldagsskyddsposter kräver också lämpliga behörigheter om de ska raderas. När karantänen är full rensas äldre e-postmeddelanden. Detta är ytterligare ett skäl till att inte kontrollera karantän och förvaring förrän klagomål uppstår.

Det finns ett viktigt specialfall med SFOS 22.0 MR1: Om du hanterar brandväggen via Sophos Central kan karantänåtgärder som Release eller Delete med Invalid API request misslyckas. Detta betyder inte automatiskt att e-postflödet, själva karantänen eller MTA-policyn är bruten. Den praktiska lösningen är att logga in direkt på brandväggens lokala WebAdmin och släppa eller ta bort meddelandet där under Email > SMTP quarantine.

Efter en uppdatering till SFOS 22.0 MR2 eller senare bör du testa processen igen: sätt ett ofarligt testmeddelande i karantän, utför åtgärden via den planerade administrationsvägen och kontrollera sedan Log Viewer, karantän och mottagarbrevlåda. Detta gör det tydligt om problemet verkligen är löst eller om ytterligare roller, central åtkomst eller lokala behörigheter är inblandade.

Felsökning

Externa e-postmeddelanden kommer inte fram

Kontrollera först DNS och tillgänglighet: MX post, offentlig IP, port 25, NAT äldre filer, MTA läge och ansvarig e-postdomän. Kontrollera sedan i Log Viewer och smtpd_main.log om anslutningen når brandväggen. Om ingen anslutning är synlig ligger problemet troligen i Mail Protection.

Brandväggen accepterar e-postmeddelanden men levererar dem inte

Då är intern e-postserver, routing, DNS, destinationsport, TLS, mottagarkontroll eller policy mer sannolikt. Du kontrollerar om brandväggen kan nå mailservern och om mailservern accepterar anslutningen. Avvisningsloggar och e-postserverloggar bör utvärderas tillsammans.

Många mejl finns kvar i spolen

En växande spool indikerar ofta leveransproblem: intern e-postserver går inte att nå, TLS-begäran matchar inte, DNS-upplösningen misslyckas eller destinationsservern avvisar meddelandet. I det här fallet ska du inte bara leverera om enskilda meddelanden, utan leta efter orsaken i routing- och SMTP-sökvägen.

Ett viktigt regelorderfall är lätt att förbise: Om en automatiskt eller manuellt skapad brandväggsregel ligger över MTA-regeln och SMTP-trafiken matchas, utvärderas inte längre den faktiska MTA-regeln. E-postmeddelanden kan då fastna i e-postspoolen även om DNS, port 25 och e-postservern i princip ser korrekta ut.

Kontrollera:

1. Öppna Rules and policies > Firewall rules.
2. Kontrollera reglerna ovanför regeln MTA eller SMTP.
3. Styr nya automatiskt genererade regler, IPsec-regler, hotspot-regler eller regler manuellt inställda på Top.
4. Kör SMTP-testet igen och jämför Log Viewer, e-postspool och smtpd_main.log.

Regeln kan inte blint flyttas nedåt om den tjänar andra produktiva syften. Det som spelar roll är om den oväntat fångar upp SMTP-trafik före MTA-regeln.

Karantänsammandrag saknas för aliasadresser

Om användare använder aliasadresser bör du kontrollera karantäninställningarna för mer än bara den primära e-postadressen. Enligt Sophos tillämpas som standard inte karantäninställningar automatiskt på aliasadresser. Om sammanfattade e-postmeddelanden eller releaser för aliasmottagare saknas, måste aliasadresser beaktas tillsammans med den primära adressen i karantänen eller användarkontexten.

Karantänåtgärdsrapporter Invalid API request

Om Release eller Delete misslyckas med Invalid API request på en brandvägg som öppnats via Sophos Central, kontrollera SFOS-versionen först. Med SFOS 22.0 MR1 kan just denna process påverkas.

Nästa steg är att inte bygga om e-postpolicyn. Byt först direkt till brandväggens lokala WebAdmin och redigera meddelandet under Email > SMTP quarantine. Dokumentera sedan:

1. SFOS version och build.
2. Om åtgärden utfördes via Sophos Central eller direkt i WebAdmin.
3. Avsändare, mottagare, ämne och karantänskäl.
4. Resultat efter ett test via den direkta WebAdmin.
5. Om en uppdatering till SFOS 22.0 MR2 eller nyare är planerad eller redan installerad.

Legitima avsändare identifieras som spam

Falska positiva svar bör inte omedelbart besvaras med breda undantag. Kontrollera först avsändarens domän, SPF/DKIM/DMARC, rubriker, rykte, policymatchning och berörda mottagare. Om ett undantag är nödvändigt bör det vara strikt begränsat och dokumenterat med ett granskningsdatum.

Interna system kan inte reläa

Kontrollera att SMTP Relay är tillåten under Administration > Device access från rätt zon och att källan matchar ACL. Kontrollera sedan e-postloggarna. Om en skanner eller applikation ska vidarebefordra ska källan dokumenteras som ett värdobjekt och inte ett helt nätverk ska släppas i onödan.

Mail fungerar annorlunda efter en firmwareuppdatering

Efter firmwareuppdateringar bör MTA-läge, policyer, certifikat, e-postspool, karantän och relevanta loggar kontrolleras. För större uppdateringar passar Sophos Firewall före SFOS 22 Kontrollera uppgradering också.

Checklista för verksamheten

• Mail Protection Licens och apparatsupport kontrolleras.
• MTA Mode medvetet valt och dokumenterat.
• MX post, offentlig IP och intern målserver är korrekta.
• MX konvertering, externa tester och återställning är förberedda.
• Ingen parallell ofiltrerad DNAT-regel går förbi MTA.
• Inkommande och utgående policyer är tydligt namngivna.
• Adressgruppen för de skyddade domänerna underhålls rent.
• Brandväggsregelordningen hindrar inte MTA-regeln från att träda i kraft.
• TLS, DKIM, Banner, SPX och dataskydd är testade för biverkningar.
• SMTP Relä är endast tillåtet från definierade interna källor.
• Karantän och falska positiva processer etableras.
• Aliasadresser ingår i karantän- och sammanfattningsprocessen.
• Direkt WebAdmin-åtkomst för karantänutgåvor är känd om centrala åtgärder misslyckas.
• E-postspool, lagringsutrymme och systemtillstånd övervakas.
• Loggar lagras lokalt, i Sophos Central eller via syslog under en tillräcklig tidsperiod.
• Ett e-postflödestest utförs efter firmwareuppdateringar.

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

FAQ