Sophos Phish Threat: tillåt avsändare, domäner och IP-adresser
Sophos Phish Threat kan bara ge realistiska kampanjresultat om simuleringarna levereras och användarna kan nå tillhörande nätfiske- och utbildningssidor. Därför måste avsändardomänerna, IP-adresserna och webbmålen som Sophos tillhandahåller tillåtas vid alla kontrollpunkter som trafiken faktiskt passerar. Det är dock varken nödvändigt eller lämpligt att generellt kringgå e-post- eller webbsäkerheten.
Den här processen är leverantörsneutral. Den gäller för överordnade e-postgatewayar, Mail Transfer Agents, Secure Web Gateways, proxyservrar, brandväggar, DNS- och URL-filter samt produkter som automatiskt granskar länkar eller bilagor. Produktspecifika steg finns i leveransanvisningarna för Microsoft 365 och Google Workspace.
Hämta aktuella värden i Sophos Fusion (tidigare Sophos Central)
Den auktoritativa listan ska hämtas från den berörda Sophos Fusion-klientorganisationen:
- Klicka på ikonen Global Settings.
- Öppna Products and Services > Sophos Phish Threat.
- Klicka på Sending domains and IPs.
- Dokumentera alla avsändardomäner, IP-adresser och webbmål som visas, inklusive hämtningsdatumet.
De regionala Sophos Mailflow-IP-adresserna ska inte generellt läggas till i Phish Threats tillåtelselista. De används endast för automatiskt konfigurerade Microsoft 365 Mailflow-anslutningar eller för att återställa dessa efter konfigurationsändringar. Sådana nätverk ska därför endast anges som en del av den dokumenterade konfigurationen av Mailflow-anslutningar och bara för den region som används – inte förebyggande i överordnade gatewayar, proxyservrar eller webbfilter.
Listan kan innehålla värden för olika funktioner:
- IP-adresser och domäner för utskick av kampanjmeddelanden,
- avsändar- eller Return-Path-domäner,
- spårnings- och omdirigeringsmål för klickmätning,
- domäner för simulerade nätfiske- eller inloggningssidor,
- utbildningssidor och andra webbmål som behövs för kampanjflödet.
Phish Threat-länkar kan omdirigera via AWS-spårningsmålet awstrack.me som dokumenterats av Sophos. En sådan omdirigering är förväntad vid klickmätning. Jämför före pilotutskicket de värdar som faktiskt behövs med den aktuella Sophos-listan och målen för den aktuella kampanjen. Tillåt inte ytterligare underdomäner om behovet inte kan styrkas där eller i produktdokumentationen.
Kartlägg dataflödet före tillåtelsen
Tillåtelselistan måste implementeras vid varje kontrollpunkt, inte bara på den sista e-postservern. Dokumentera först den faktiska vägen för ett testmeddelande och ett testklick:
- Sophos Phish Threat skickar simuleringen.
- Ett överordnat molnfilter, en Secure Email Gateway eller en MTA tar emot meddelandet.
- Ytterligare tjänster för skräppostskydd, nätfiskeskydd, sandbox eller länkanalys behandlar det.
- Målsystemet levererar det till postlådan.
- När användaren klickar passerar begäran DNS-filter, proxyserver, Secure Web Gateway, brandvägg och eventuellt webbläsar- eller endpointskydd.
- Spårnings-, nätfiske- och utbildningssidorna skickar tillbaka händelserna till Phish Threat.
Dokumentera för varje steg produkt, regelägare, nödvändigt värde, önskat undantag, utgångs- eller granskningsdatum och återställningsväg. Om flera filter följer efter varandra måste varje relevant filter beaktas. En tillåtelse enbart i målpostlådan löser inte en blockering i en överordnad gateway.
Implementera en tillåtelselista med minsta möjliga omfattning
Regeln ska inte vara mer omfattande än vad som är tekniskt nödvändigt för simuleringen. Exakta IP-adresser eller värdnamn, den aktuella Phish Threat-listan och de avsedda testmottagarna ska föredras. Använd en fullständig domän, ett jokerteckenmönster eller ett globalt skannerundantag endast om kampanjkonfigurationen eller produkten inte medger en snävare regel.
| Kontrollpunkt | Typisk tillåtelse | Kontrollera därefter |
|---|---|---|
| E-postgateway eller MTA | dokumenterad käll-IP-adress för det sändande SMTP-systemet, Envelope Sender-domän eller synlig From-domän | SMTP-mottagning, rubriker, leveransväg och skräppost-/nätfiskebedömning |
| Skräppost- eller nätfiskeskydd | snävt avgränsat simuleringsundantag | meddelandet levereras; kontroller mot verklig skadlig kod förblir aktiva för andra meddelanden |
| Länk- och bilageskanner | undantag endast för identifierade Phish Threat-värden | skannern genererar inga kampanjklick och öppnar inga simuleringsbilagor |
| DNS- eller URL-filter | nödvändiga spårnings-, nätfiske- och utbildningsmål | namnuppslagning, omdirigering och målsida fungerar |
| Webbproxy eller Secure Web Gateway | exakta värdar eller nödvändigt jokerteckenmönster | TLS-anslutningen och omdirigeringskedjan blockeras eller skrivs inte om |
| Brandvägg | nödvändiga anslutningar enligt dataflödet | inga onödiga tillåtelser för källor, mål eller portar |
| Webbläsar- eller endpointtillägg | riktat undantag, om det stöds tekniskt | verkliga användarklick registreras; andra webbmål förblir skyddade |
Vissa produkter skiljer mellan leverans, skräppostbedömning, omskrivning av URL:er, Time-of-Click-kontroll, Attachment Sandboxing och webbåtkomst. En enskild ”Allow”-regel omfattar inte automatiskt alla dessa funktioner. Omvänt får en tillåtelse för e-postleverans inte oavsiktligt undanta alla filer eller URL:er från samma avsändare från samtliga kontroller.
Tillåt variabla värdar endast när behovet har styrkts
Lägg till en början endast till de enskilda värdar som anges i Sophos Fusion eller produktdokumentationen och används i kampanjen. Om ett visst produkt- eller kampanjmål bevisligen använder variabla värdar och tillåtelsen tekniskt inte kan begränsas till exakta värdnamn, kan ett jokertecken krävas. Då gäller ytterligare kontroller:
- placera jokertecknet endast under den basdomän som Sophos visar,
- tillåt inte leverantörens hela överordnade domän,
- begränsa regeln till Phish Threat-trafik och om möjligt till pilotmottagare,
- dokumentera ansvarig person och granskningsdatum,
- kontrollera före varje ny kampanjmall om ytterligare en värd används.
En mycket bred tillåtelse, exempelvis en hel delad moln- eller utskicksplattform, ökar risken för att orelaterad trafik släpps igenom. Om en produkt inte kan implementera den snäva omfattning som krävs måste denna kvarstående risk accepteras före ändringen eller en annan leveransväg väljas.
Förhindra falska klick och automatiskt öppnade bilagor
E-postsäkerhetsprodukter kontrollerar ofta meddelanden genom att öppna URL:er eller bilagor i en sandbox. Phish Threat kan tolka en sådan begäran som en användaråtgärd. Resultatet blir skenbara klick eller öppnade bilagor trots att mottagaren ännu inte har hanterat meddelandet.
Typiska tecken på att en händelse kommer från en skanner i stället för en användare är:
- händelserna inträffar före eller omedelbart vid leveransen,
- många mottagare uppvisar nästan samtidigt samma åtgärd,
- källadresser eller User-Agents tillhör säkerhetstjänsten,
- flera länkar i samma meddelande öppnas i snabb följd,
- mönstret kan återskapas med ett nyligen skickat pilotmeddelande.
Korrigeringen ska göras på den skanner som orsakar problemet: lägg till de aktuella Phish Threat-IP-adresserna och -domänerna i dess avsedda lista för godkända nätfiskesimuleringar eller riktade skanningsundantag. Undantaget måste motsvara både den identifierade källan och den berörda skanningsfunktionen. Det räcker inte att bara tillåta en avsändaradress om tjänsten oberoende av detta öppnar varje URL i en sandbox.
Uteblivna klickhändelser har ofta den motsatta orsaken. Spårningsmål kan blockeras av Secure Web Gateways, DNS-filter eller webbläsartillägg som annonsblockerare. Starta därför inte om kampanjen direkt om telemetri saknas, utan kontrollera först omdirigeringskedjan i webbläsaren samt proxy-, DNS- och endpointloggarna.
Microsoft 365-bypassrubriker endast som äldre undantag
Äldre anvisningar använder transportregler med rubrikerna X-MS-Exchange-Organization-SkipSafeLinksProcessing eller X-MS-Exchange-Organization-SkipSafeAttachmentProcessing. Sådana regler är inte baslinjen för en ny installation. För SMTP-baserad leverans genom Microsoft 365-transportpipelinen tillhandahåller Microsoft en Advanced Delivery Policy. För nya installationer rekommenderar Sophos däremot M365 Direct Delivery. Denna leveransväg kringgår transportpipelinen, så Advanced Delivery tillämpas inte på den. Den konkreta Microsoft 365-konfigurationen måste följa Sophos aktuella anvisningar för den valda leveransvägen och omfattas inte av den här artikeln.
Äldre rubriker bör bara övervägas om en befintlig miljö bevisligen fortfarande behöver dem, den aktuella supportstatusen har kontrollerats och det finns en godkänd ändring med snäv IP-/domänomfattning. Regelns prioritet, effekt och säkerhetskonsekvenser måste testas separat. Kör inte gamla rubrikregler ”för säkerhets skull” parallellt med en aktuell simuleringstillåtelse.
Validera en pilotkampanj
Börja med en liten pilotgrupp med kontrollerade testkonton. Den bör innehålla minst en postlåda per relevant leveransväg, policygrupp och plats. Testet omfattar ett meddelande med en länk och – om det används i verksamheten – en kampanj med bilaga och utbildning.
Dokumentera före utskicket tidsstämplar, kampanj-ID, mottagare, förväntad avsändare, använd domän och ID:n för de ändrade reglerna. Kontrollera sedan följande:
- Gatewayen tar emot meddelandet och levererar det exakt en gång till den förväntade postlådan.
- De värden som faktiskt används för den avsedda regelmatchningen stämmer överens med den aktuella Sophos-listan: rätt synlig From-domän eller Envelope Sender-/Return-Path-domän och, om regeln är IP-baserad, käll-IP-adressen för det sändande SMTP-system som den kontrollerande gatewayen har loggat som anslutningspart. Kontrollera dessa fält separat. Den mottagande serverns IP-adress får inte användas som avsändarens käll-IP-adress.
- Meddelandet hamnar varken i karantän eller oväntat i skräppostmappen.
- Ingen klick- eller bilagehändelse visas i Phish Threat innan användaren agerar.
- Ett kontrollerat användarklick öppnar den förväntade omdirigerings-, simulerings- eller utbildningssidan.
- Exakt denna åtgärd visas i kampanjresultatet vid en rimlig tidpunkt.
- Proxy-, brandväggs-, DNS- och skannerloggarna visar den förväntade regeln men ingen onödigt omfattande förbikoppling.
- Ett normalt externt testmeddelande och ett webbmål som inte har tillåtits kontrolleras fortfarande enligt befintliga säkerhetspolicyer.
Framgång innebär inte bara att ”e-postmeddelandet kom fram”. Leverans, korrekt kampanjmätning, nåbara webbmål och fortsatt verksamma säkerhetskontroller måste bekräftas tillsammans. Först därefter ska regeln utökas till den avsedda mottagargruppen.
Avgränsa fel systematiskt
Om leveransen uteblir ska du kontrollera inåt från den första mottagningspunkten: SMTP-logg, överordnad gateway, karantän, efterföljande transportregel och målpostlåda. SMTP-felet eller produktens bedömning visar var meddelandet avvisades. Ytterligare breda undantag utan detta underlag försvårar orsaksanalysen.
Vid falska klick ska du i stället jämföra tidslinjen från utskick till leverans. Använd skannerloggar, käll-IP och User-Agent för att hänföra en reproducerbar automatisk begäran till den produkt som orsakar den. Om verkliga klick inte registreras ska du kontrollera DNS-namnuppslagning, proxybeslut, TLS-anslutning, omdirigeringar och webbläsartillägg.
Stoppa pilotkampanjen om orsaken förblir oklar. Ett undantag får inte stegvis göras allt bredare tills leveransen råkar fungera.
Återställ ändringar och underhåll dem löpande
Definiera en återställning för varje regel före implementeringen: tidigare tillstånd, regel-ID, export eller skärmbild, ansvarig person och återställningsordning. Inaktivera ändringen eller återställ det senast validerade tillståndet om orelaterade meddelanden oväntat levereras, säkerheten kringgås i för stor omfattning, misstänkt proxyåtkomst förekommer eller kampanjdata fortsätter att vara missvisande. Kontrollera därefter e-post- och webbloggarna på nytt.
Följande minimikontroller gäller för den löpande driften:
- jämför aktuella värden med Sophos Fusion före varje större kampanj,
- testa reglerna på nytt efter byte av produkt, routning eller leverantör,
- granska regelbundet om jokertecken och globala undantag kan få en snävare omfattning,
- ta bort domäner, IP-adresser och äldre regler som inte längre behövs,
- registrera granskningsdatum, ägare och teknisk motivering för varje undantag,
- kör alltid en pilotkampanj utan automatiskt falskt klick efter ändringar.