Sophos Email: konfigurera avsändarautentisering och Smart Banners

Sophos Email kontrollerar inkommande meddelanden med DMARC, SPF och DKIM och kan även upptäcka avvikelser i rubriker och domäner. Kontrollerna avgör inte på egen hand hur ett meddelande ska hanteras: tillämplig Email Security policy anger feltyperna, deras ordning och vilka åtgärder som ska vidtas. Smart Banners visar resultatet för mottagarna och kan ge dem tillgång till säkra användaråtgärder.

Rekommenderad snabbmetod: Öppna berörd Email Security policy under My Products > Email Security > Policies och konfigurera felåtgärderna för DMARC, SPF och DKIM under Settings > Inbound > Authentication. Välj till en början Quarantine i stället för Reject för kritiska fel, ordna villkoren uppifrån och ned och kontrollera sedan Header anomaly, Domain anomaly och End-user message settings. Jämför legitima testmeddelanden och meddelanden som inte klarar kontrollerna i Message History innan du lägger till undantag eller aktiverar strängare åtgärder.

Förbered omfattning, tester och återställning

Identifiera de skyddade domänerna och postlådorna, kända legitima sändningstjänster och en begränsad testgrupp innan du gör några ändringar. Dokumentera:

berörd policy, dess position och om den har statusen Enforced;
riktningen Inbound och tilldelade användare, grupper och domäner;
aktuella regler för DMARC, SPF, DKIM och avsändarkontroll i befintlig ordning;
befintliga poster i tillåtelselistan och verksamhetsgodkända undantag;
ursprungliga åtgärder, bannertexter och alternativ för slutanvändare;
testavsändare, testmottagare och förväntade resultat.

Om du behöver återställa konfigurationen återinför du den dokumenterade regelordningen, åtgärderna och banneralternativen eller ändrar en ny pilotpolicy till Policy Bypassed. Ändra bara en sammanhängande uppsättning regler åt gången under piloten, så att ett oväntat resultat går att härleda entydigt.

Varning: Använd aldrig ett autentiseringsundantag som skäl för att inaktivera skanning efter skadlig kod. Även en tillåten eller korrekt autentiserad avsändare kan använda ett komprometterat konto eller skicka skadligt innehåll. Begränsa varje undantag till det bekräftade autentiseringsproblemet och minsta nödvändiga omfattning, och låt alla andra skyddskontroller vara aktiva.

Förstå DMARC, SPF och DKIM korrekt

De tre metoderna besvarar olika frågor:

SPF jämför den sändande e-postservern med de värdar, IP-adresser och nätverk som ägaren av kuvertavsändarens domän har auktoriserat i DNS.
DKIM validerar meddelandets digitala signatur med den offentliga nyckel som den signerande domänen har publicerat i DNS.
DMARC bedömer om SPF eller DKIM godkänns och om domänen i den godkända kontrollen är justerad mot den synliga domänen i From-rubriken. Utan en giltig DMARC-post och en SPF- eller DKIM-kontroll som går att utvärdera kan Sophos inte göra en fullständig DMARC-bedömning.

Reglaget som visas i policyn styr åtgärden vid fel; själva autentiseringskontrollerna körs alltid. Den här artikeln gäller endast bedömning av inkommande meddelanden. Den skapar eller lagrar inte DNS-poster för dina utgående domäner och aktiverar inte DKIM-signering av utgående meddelanden.

Konfigurera Message Authentication

Öppna My Products > Email Security > Policies, välj rätt Email Security policy och kontrollera dess målgrupp och position.
Öppna Settings > Inbound > Authentication.
Aktivera önskade felåtgärder för DMARC, SPF och DKIM.
Klicka på Add Rule för varje kontroll och välj sedan en feltyp och tillhörande åtgärd.
Ordna villkoren från det specifika fallet till det mer allmänna. Sophos kontrollerar dem uppifrån och ned och använder den första träffen.
Spara policyn och bekräfta att den är Enforced för testmottagarna.

Sophos rekommenderar Quarantine för varje kategori i Message Authentication. Det är också en lämplig pilotinställning eftersom meddelandet förblir tillgängligt för analys och kan frisläppas under kontrollerade former. Reject avvisar meddelandet under bearbetningen; obearbetade rubriker är inte tillgängliga i Sophos för avvisade meddelanden. Tag subject line märker meddelandet och skickar det vidare till efterföljande bearbetningssteg. Även Deliver innebär att meddelandet går vidare till nästa skanningslager, inte nödvändigtvis att det levereras till postlådan. Include In End User Quarantine gör ett meddelande i karantän tillgängligt i användarens karantän.

Bedöm feltyperna medvetet

För DMARC innebär Hard failure att varken SPF eller DKIM godkänns med nödvändig domänjustering. Standardinställningen är Conform to sender policy, vilket innebär att hanteringen följer avsändarens DMARC-policy. Övriga valbara fall är p=none, Unsupported, Temporary failure och Permanent failure. Här gäller Unsupported endast för Gateway mode, medan M365 bestguesspass endast gäller för M365 Mailflow mode. En separat regel för p=none är främst användbar när Hard failure fortfarande är inställt på Conform to sender policy.

För SPF finns, utöver Hard failure, alternativen Soft failure, Neutral, Unsupported, Temporary failure och Permanent failure. För DKIM finns, utöver Hard failure, alternativen Unsupported, Temporary failure och Permanent failure. Ett tillfälligt DNS-fel kan försvinna utan åtgärd; ett permanent fel innebär att den publicerade posten inte kan tolkas. Betrakta inte något av resultaten automatiskt som bevis för spoofing.

Bearbetningsordning och Sender check

Kontrollerna i Message Authentication körs i den ordning som visas i policyn. För att bedöma DMARC kör Sophos de SPF- och DKIM-kontroller som behövs, oavsett vilka felåtgärder som har konfigurerats för dem. DMARC misslyckas om varken SPF eller DKIM godkänns med nödvändig domänjustering. Om det finns flera felregler används alltid den första matchande regeln, räknat uppifrån.

Om en DMARC-, SPF- eller DKIM-regel matchar och åtgärden är Quarantine eller Reject, avbryts bearbetningen av den grenen. Om alla tre kontrollerna godkänns i en konfiguration med dessa åtgärder fortsätter inte kontrollerna av rubrikavvikelser, och meddelandet levereras. Ordningen påverkar alltså säkerhetsbeteendet i praktiken; den är inte bara en visuell sortering i portalen.

Under Sender check lägger Sophos till två avvikelsekontroller:

Header anomaly skyddar dina egna domäner mot extern spoofing. Kontrollen utlöses endast när domänen i den synliga From-rubriken matchar någon av domänerna som har konfigurerats i Sophos Fusion-kontot och den rubrikadressen skiljer sig från MAIL FROM-adressen i SMTP-kuvertet. Samtliga kontodomäner kontrolleras, inte bara mottagarens domän.
Domain anomaly identifierar avsändardomäner som varken har en MX-post eller en A-post.

För båda kontrollerna kan du välja Tag subject line, Quarantine, Reject eller Deliver; Tag subject line är den dokumenterade standardinställningen. Använd märkning eller karantän under piloten och granska legitim vidarebefordran, CRM-system, ärendehanteringsplattformar och externa sändningstjänster innan du aktiverar Reject.

Konfigurera Smart Banners

Under End-user message settings aktiverar du varje bannertyp separat, anpassar den fördefinierade texten och väljer vilka användaråtgärder som ska erbjudas. Inställningarna gäller inkommande externa meddelanden i både HTML och oformaterad text. Sophos-meddelanden, till exempel karantänsammanfattningar, får ingen Smart Banner.

Bannerns färg och budskap bygger på tillåtelselistan och DMARC-resultatet:

Trusted är grön: avsändaren finns i tillåtelselistan och meddelandet har godkänts av DMARC.
External är gul: avsändaren har godkänts av DMARC men finns inte i tillåtelselistan; avsändaren finns i listan men Trusted är inaktiverat; eller avsändaren saknar DMARC-post, så det går inte att fastställa ett godkänt eller underkänt resultat.
Untrusted är orange: det finns en DMARC-policy, men meddelandet har inte godkänts av DMARC.

En banner är ett beslutsstöd, inte ett bevis på att meddelandet är ofarligt. Inte ens en grön banner ersätter innehållsskanning eller försiktighet när länkar och bilagor öppnas.

Aktivera användaråtgärder på ett säkert sätt

För varje banner kan du erbjuda Allow sender, Block sender och Report Spam messages to Sophos. Allow och Block öppnar en bekräftelsesida och uppdaterar användarens personliga lista; Report skickar meddelandet till SophosLabs som spam.

Guiden om Inbound Allow/Block-undantag beskriver hur personliga och globala poster samverkar och hur de skyddas med autentisering, export, import och återställning.

För att Allow sender och Block sender ska fungera i HTML-bannern öppnar du Global Settings > Products and Services > Email > User Settings, aktiverar först Release/Delete och sedan Allow/Block List och sparar. Länkarna för Allow och Block är inte tillgängliga i bannerformatet oformaterad text.

När länkar i Smart Banners används måste utgående e-post dirigeras genom Sophos Fusion (tidigare Sophos Central). Sophos rekommenderar att den dirigeringen införs innan End-user message settings aktiveras; annars kan externa mottagare se bannern i svar eller vidarebefordrade meddelanden. I HTML visas bannern i färg överst, medan den i oformaterad text visas som text i början av meddelandetexten. En befintlig banner kan fortsätta att visas när någon svarar på ett meddelande eller vidarebefordrar det internt.

Validera resultatet i Message History

Skicka kontrollerade inkommande meddelanden till en pilotmottagare för varje relevant policyomfattning:

ett legitimt meddelande som förväntas autentiseras utan fel;
ett legitimt meddelande via en känd vidarebefordrings- eller sändningstjänst;
om det kan göras på ett säkert sätt, ett meddelande från din egen testdomän med ett avsiktligt orsakat och dokumenterat autentiseringsfel.

Förfalska inte produktionsmeddelanden och ändra inte någon annans DNS-poster för ett test. Sök i Message History efter avsändare, mottagare och tidsintervall, öppna meddelandet och jämför tillämpad policy, kategori, autentiserings- eller avsändarkontrolldetaljer och faktiskt utförd åtgärd. Kontrollera även bannerns typ, text, färg och synliga åtgärder i både HTML och oformaterad text för levererade meddelanden. Resultatet är korrekt när legitima meddelanden når förväntat nästa skanningssteg eller avsedd postlåda, fel utlöser den första matchande konfigurerade åtgärden och inga oavsiktliga användaråtgärder visas.

Felsök metodiskt

Oväntat DMARC- eller DKIM-fel: Spara de obearbetade rubrikerna och informationen från avsändarkontrollen. Kontrollera om en uppströms gateway, en ansvarsfriskrivning, en distributionslista eller en vidarebefordringsväg har ändrat meddelandetexten eller de signerade rubrikerna. Särskilt när Sophos EMS står bakom ett annat primärt e-postsäkerhetssystem kan sådana ändringar göra DKIM och DMARC-justeringen ogiltiga; enbart felet bevisar då inte att meddelandet utgör en risk.
Fel åtgärd trots en matchande regel: Kontrollera först policyomfattning, tillämpning och policyordning och läs sedan felreglerna uppifrån och ned. En tidigare generell träff kan dölja en senare specifik regel.
Header anomaly för en legitim tjänst: Jämför den synliga From-rubriken med kuvertets MAIL FROM och identifiera vilken av dina domäner som matchade. Rätta först sändningskonfigurationen eller domänjusteringen. Överväg endast ett mycket snävt autentiseringsundantag om en rättning inte är möjlig och tjänsten har identifierats med säkerhet.
Domain anomaly för legitim e-post: Testa upplösningen av avsändardomänens MX- och A-poster separat. Lös inte ett tillfälligt DNS-problem med en permanent, global tillåtelseregel.
Banner saknas: Kontrollera att rätt policy och bannertyp är aktiva, att meddelandet var externt och inkommande och att det inte är ett Sophos-systemmeddelande.
Allow/Block saknas eller fungerar inte: Kontrollera Release/Delete och Allow/Block List i User Settings, HTML-formatet och utgående dirigering genom Sophos. Oformaterad text erbjuder inte dessa länkar.

Ändra först efter den här analysen ordningen, åtgärden eller den minsta nödvändiga och mest avgränsade posten i tillåtelselistan och upprepa samma test. Om resultatet fortfarande är oklart samlar du in Message-ID, tidsstämpel, avsändare, mottagare, policynamn, faktisk åtgärd och fullständiga obearbetade rubriker för eskalering, i stället för att göra breda undantag från autentisering eller skydd mot skadlig kod.