Konfigurera och hantera Sophos Firewall Threat Feeds säkert

Sophos Firewall Threat Feeds importerar automatiskt kända skadliga IP-adresser, domäner och URL:er som Indicators of Compromise (IoC:er). För en säker driftsättning ska feeden först observeras i läget Monitor, träffar och bieffekter kontrolleras och först därefter ändras till Block.

Den här artikeln behandlar främst Third-Party Threat Feeds, till exempel feeden från Cybora. Funktionen introducerades med Sophos Firewall v21.

Konfigurera en Threat Feed

Third-Party Threat Feeds kräver Xstream Protection Bundle, men ingen extra Sophos Fusion-licens. Brandväggen måste kunna nå feedens URL via DNS och HTTPS.

1. Öppna System services > Log settings.
2. Aktivera minst en loggdestination som stöds under Active threat response. För den lokala Log Viewer är detta Local reporting. XGS 87/87w och 107/107w stöder inte lokal rapportering; använd Sophos Fusion (tidigare Sophos Central) eller en syslogserver på dessa modeller.
3. Aktivera även Remote source match (inbound traffic) för att se träffar på inkommande DNAT- och WAF-trafik. Alternativet är inaktiverat som standard.
4. Öppna Protect > Active threat response > Third-party threat feeds > Add.
5. Ange ett tydligt namn och en beskrivning, till exempel:
   • Pilot: Name cybora-premium-ipv4-monitor, Description Cybora Premium IPv4 - Pilot
   • Testad produktionsfeed: Name cybora-premium-ipv4, Description Cybora Feed - Premium
6. Välj IPv4 address, Domain eller URL som Indicator type. Om en källa levererar flera typer skapas en separat feed för varje typ.
7. Ställ in Action på Monitor vid införandet. Efter en kontrollerad observationsperiod kan den ändras till Block.
8. Välj Top under Position för en pilotfeed, så att dess träff inte döljs av en annan tredjepartsfeed. Bottom passar en feed med lägre prioritet där överlappningen redan är känd.
9. Ange rätt adress från Avanets feedlista eller från leverantören under External URL. URL:en måste returnera textfilen direkt. Om endpointen i stället till exempel svarar med HTTP 302, klassificerar SFOS det som ett Connection error. Filen innehåller en indikator per rad.
10. Välj No authentication, API key eller Basic authentication under Authorization. En API key kan skickas i Header eller i Query parameters; både dess värde och lösenordet för Basic Authentication stöder högst 64 tecken. Inloggningsuppgifter ska inte finnas i ärenden eller skärmbilder.
11. Aktivera Validate server certificate. För ett publikt certifikat måste utfärdande CA finnas under Certificates > Certificate authorities; för en privat CA importeras dess certifikat först.
12. Välj ett Polling interval som motsvarar leverantörens uppdateringsintervall.
13. Kör Test connection och spara med Save.

Kontrollera därefter Sync status, Last updated, antalet Threat indicators och tillgänglig Storage quota. Success bekräftar hämtningen, men inte att den förväntade trafiken faktiskt identifieras eller blockeras. Den effekten måste valideras separat i Log Viewer.

Välj rätt feed och åtgärd

Indikatorer som stöds

En feed innehåller exakt en av dessa typer:

• IPv4 address: skannrar, botnät, komprometterade system eller C2-servrar
• Domain: domäner för malware, phishing eller command-and-control
• URL: specifika skadliga sökvägar eller nedladdningslänkar

Feeden måste vara en ren textfil med en indikator per rad. IP-intervall, IPv6-adresser, nätverk, wildcard-domäner och reguljära uttryck kan inte användas i Third-Party Threat Feeds som ersättning för enskilda IoC:er som stöds.

SFOS anger inget fast antal IoC:er per Third-Party Feed. Den användbara storleken begränsas av den modellberoende Storage quota. Kontrollera därför efter importen ledig quota, antalet Threat indicators och att feeden har hämtats utan fel.

En stor lista är inte automatiskt bra. Ursprung, aktualitet, uppdateringsintervall, risk för false positives och träffar i den egna miljön är viktigare än det totala antalet poster. En feed som inte ger någon bestående nytta tar bara upp lagringsutrymme.

Monitor före Block

Monitor loggar träffar men tillåter trafiken. Det visar vilka källor, destinationer och tjänster som skulle påverkas. Block loggar och släpper inte igenom matchande trafik.

För en ny feed är följande arbetsgång lämplig:

1. Placera feeden högt upp i Third-Party-listan.
2. Börja med Monitor.
3. Kontrollera träffar och möjliga false positives under en representativ period.
4. Dokumentera ansvarig person och undantagsprocessen.
5. Växla först därefter till Block.

En välkurerad IPv4-feed för starkt exponerade tjänster kan sättas i produktion snabbare än en domän- eller URL-feed. De senare matchar oftare delad infrastruktur, CDN:er eller omdirigeringar och kräver därför särskilt noggrann kontroll.

Dokumentera feednamn, antal IoC:er, position och hittills observerade träffar innan du växlar till Block. Om ändringen orsakar oväntade störningar ställer du omedelbart tillbaka Action för samma feed till Monitor och testar den berörda trafiken igen. En felaktig eller okontrollerbar feed kan inaktiveras tillfälligt. En global Threat Exclusion är inte en likvärdig rollback, eftersom den även påverkar MDR, NDR och Sophos X-Ops.

Ordning och namn

Active Threat Response bearbetar modulerna i följande ordning: MDR, NDR Essentials, Sophos X-Ops och därefter Third-Party Threat Feeds. Med Log and drop avslutar en träff i en tidigare modul den fortsatta kontrollen. Med Log only eller Monitor loggar brandväggen däremot separata händelser för MDR, X-Ops och Third-Party Threat Feeds.

Inom Third-Party Threat Feeds utvärderar brandväggen listorna för Block och Monitor separat i den ordning de visas. Den loggar den första träffen i varje lista och blockerar utifrån den första träffen i Block-listan. Produktionsfeed, pilotfeed och tillfälliga incidentlistor ska därför namnges och ordnas tydligt:

• cybora-premium-ipv4-block
• cybora-standard-domain-monitor
• incident-2026-06-c2-ipv4

Ett bra namn visar leverantör eller syfte, indikatortyp och åtgärd. Det sparar tid vid logganalys och granskningar.

Skilj mellan Threat Feed-moduler

Under Active threat response finns flera funktioner med olika uppgifter och licenskrav:

• Sophos X-Ops Threat Feeds: Sophos egna indikatorer; kräver Network Protection och dessutom Web Protection för tillämpningen. Båda ingår i Standard- eller Xstream-paketet eller kan licensieras separat.
• MDR Threat Feeds: IoC:er från Sophos MDR; kräver Xstream Protection Bundle och MDR Essentials eller MDR Complete i Sophos Fusion. Den separata guiden beskriver Sophos Fusion-koppling, lokal åtgärd, Audit ID, Task Queue och incidentverifiering.
• Third-Party Threat Feeds: externa IPv4-, domän- eller URL-listor; kräver Xstream Protection Bundle.
• NDR Essentials: analyserar trafik med machine learning och kräver Xstream Appliance Bundle.
• NDR Active Threat Intelligence: loggar NDR-mönster som kurerats av Sophos, kräver Xstream Protection Bundle och måste aktiveras per brandväggsregel via Scan with NDR Active threat intelligence. XGS 87/87w och 88/88w stöds inte.

För Synchronized Security och den extra endpointkontexten i Active Threat Response-loggar krävs dessutom en Intercept X-licens i Sophos Fusion. Licensen krävs inte för själva Threat Feed-funktionen, utan för att komplettera händelsen med uppgifter om värd, användare och process.

Synchronized Security är valfritt för matchning mot Threat Feeds. Om en hanterad Sophos Endpoint skickar en röd Security Heartbeat efter kontakt med en skadlig server kan en korrekt konfigurerad Heartbeat-regel blockera trafiken; Lateral Movement Protection kan dessutom isolera den komprometterade endpointen från det interna nätverket. Endpointreaktionen kompletterar feeden och dess loggar, men ersätter varken feedkonfigurationen eller brandväggsregeln.

För NDR finns den separata guiden Hantera Sophos Firewall NDR och Active Threat Response.

Förstå påverkan på trafiken

IPv4-, domän- och URL-trafik

Vidarebefordrad IPv4-trafik kräver en brandväggsregel som bearbetar den berörda trafiken. Systemriktad trafik till tjänster under Administration > Device access, till exempel WebAdmin, VPN Portal och VPN, jämförs separat med indikatorer för käll-IP och går inte genom en transit-brandväggsregel.

DNS-förfrågningar som brandväggen själv besvarar som DNS-server matchas mot domän-IoC:er av DNS-modulen. Om klienterna använder en annan DNS-server måste IPS kunna se DNS-trafiken. En domänfeed i sig bevisar därför inte att den faktiska resolvervägen inspekteras.

Domänfeed kräver dessutom Application Classification eller en IPS-policy i brandväggsregeln för vidarebefordrad trafik. Application Classification är aktiverad som standard, men bör ändå kontrolleras i den berörda regelvägen.

För fullständiga HTTPS-URL:er måste brandväggen även kunna se sökvägen. För Web Proxy-vägen väljs Use web proxy instead of DPI engine och Decrypt HTTPS during web proxy filtering under Web filtering i brandväggsregeln. För DPI-vägen lämnas Use web proxy instead of DPI engine avstängd och en lämplig SSL/TLS-inspektionsregel med Action: Decrypt läggs till. Utan dekryptering ser brandväggen bara domänen via SNI, inte hela URL-sökvägen.

DNAT och WAF från SFOS 22

Sedan SFOS 22 kan brandväggen jämföra käll-IP-adressen för inkommande, vidarebefordrad trafik till DNAT och WAF med MDR-, NDR- och Third-Party Threat Feeds. Därmed kan kända skannrar och botnät identifieras innan de når publicerade tjänster.

För att dessa träffar ska visas i Active Threat Response-loggen måste Remote source match (inbound traffic) vara aktiverat under System services > Log settings > Active threat response. Det är inaktiverat som standard. Utan denna inställning kan blockeringen fungera samtidigt som de förväntade DNAT- eller WAF-händelserna saknas i Log Viewer.

Typiska användningsområden

Threat Feeds hjälper inte bara till med utgående klienttrafik. Publikt tillgängliga tjänster skannas ofta automatiskt redan kort efter publiceringen.

• DNAT till interna servrar: En IPv4-feed kan blockera kända skadliga källor innan de når den publicerade servern.
• WAF-publiceringar: Reputationsdata kompletterar WAF-regler mot bottrafik, CVE-skanningar, kartläggning av CMS-system och credential stuffing.
• VPN Portal, User Portal och WebAdmin: Dessa tjänster skyddas först med MFA, källnätverk samt Device Access och Local Service ACL. Threat Feeds minskar dessutom trafiken från kända angreppskällor.
• Utgående klienttrafik: Domän- och URL-feeds kan blockera kända destinationer för malware, phishing och C2.
• Hårt skannade WAN-adresser: En bra IPv4-feed minskar automatiserat brus och avlastar brandväggen och loggarna.

Threat Feeds kompletterar grundläggande härdning men ersätter den inte. Publicerade tjänster behöver fortfarande restriktiva DNAT- eller WAF-regler, endast nödvändiga portar, lämpliga käll- eller landsbegränsningar, IPS respektive WAF och aktiverad loggning. En feed är inget frikort för breda Any-regler. Den övergripande processen finns i Sophos Firewall Hardening Hub.

Kontrollera synkronisering och drift

Testa hämtning av feeden och trafikeffekten separat

En lyckad anslutning och Sync status: Success bevisar bara att brandväggen kunde hämta och läsa listan. En fullständig kontroll omfattar tre nivåer:

1. Hämtning: Test connection, Sync status, Last updated och Storage quota är rimliga.
2. Innehåll: en förväntad IoC finns under Threat indicators.
3. Effekt: kontrollerad testtrafik ger en träff i Log viewer > Active threat response eller i den konfigurerade Sophos Fusion- eller syslogdestinationen. Beroende på matchningen går det att följa feednamn, Log/Drop, matchningsriktning, källa och destination eller URL, protokoll och portar.

För ett reproducerbart test kan en kort egen pilotfeed på en kontrollerad HTTPS-server användas. Den innehåller IPv4-adressen till en likaså kontrollerad testdestination. Feeden förblir i Monitor, en laboratorieklient ansluter till testdestinationen och administratören kontrollerar loggposten. Öppna inga aktiva malware-destinationer eller externa system för testning.

Synkronisering och Storage Quota

Följande värden i feedöversikten är viktiga för den löpande driften:

• Success, Fetching eller Disabled under Sync status
• förväntad tidsstämpel under Last updated
• ett rimligt antal Threat indicators
• tillräcklig ledig Storage quota
• en lyckad manuell uppdatering via Synchronize now

Summary visar Active feeds, Total threat indicators och Storage quota. Refresh uppdaterar bara dessa visade räknare. Synchronize now hämtar däremot den valda feeden omedelbart. Enskilda IoCs kan öppnas och sökas via Threat indicators eller via antalet indikatorer för den aktuella feeden.

Vid Authentication error kontrolleras API key eller inloggningsuppgifter, och vid Connection error DNS, internetåtkomst, HTTP-status och feedservern. Ett SSL/TLS error tyder på certifikatet eller certifikatkedjan, medan Failed ofta orsakas av feedformatet eller ogiltiga indikatorer.

Om lagringsutrymmet är fullt fortsätter brandväggen att hämta feeden enligt det konfigurerade pollingintervallet, men uppdaterar den lagrade IoC-listan först när utrymme blir tillgängligt igen. Feedens omfattning, kvalitet och prioritet bör därför granskas i stället för att fler listor läggs till. På XGS 87/87w, 88/88w och 107/107w finns endast pollingintervallen 24h, 7d och 30d tillgängliga för Third-Party Threat Feeds. En leverantörsfeed som uppdateras oftare upphäver inte denna begränsning i enheten.

Om inga träffar visas

Rekommenderad kontrollordning:

1. Feeden är aktiverad, Sync status: Success och förväntad IoC under Threat indicators
2. en MDR-, NDR- eller X-Ops-detektering med högre prioritet för samma IoC
3. Active Threat Response-loggning och för DNAT/WAF Remote source match
4. matchande brandväggsregel och dess loggning
5. för domäner Application Classification eller en IPS-policy
6. för URL:er Web Proxy eller DPI och SSL/TLS Inspection
7. Threat Exclusions, Web Exclusions och SSL/TLS Exclusion Lists

För att spåra en tillåten domän- eller URL-IoC till den ansvariga regeln öppnar man Log viewer > Web filter, söker efter IoC:n i Category eller direkt efter domänen och öppnar detaljvyn. Där visas Firewall Rule ID och den Web policy som valts i regeln. Om åtgärden i den matchande policyn är Allow måste regel- och policyordningen kontrolleras. En avsiktlig blockering använder en snävt avgränsad URL Group i en blockerande Web Policy som tilldelats en LAN-to-WAN-regel med högre prioritet. Därefter upprepas samma trafiktest.

För DPI-sökvägen öppnar man även Log viewer > SSL/TLS inspection, söker efter URL:en i Server name och kontrollerar Action och SSL/TLS rule. En URL-IoC kräver Decrypt. Om träffen visar Don't decrypt identifierar Rule ID undantaget eller regeln som kringgår dekryptering. Lägg till en snävt avgränsad URL Group i en Decrypt-regel med högre prioritet först efter denna tilldelning. Rulla ut TLS Inspection stegvis beskriver det kontrollerade arbetssättet.

Om en feed inte ger några relevanta träffar under en representativ observationsperiod bör dess nytta utvärderas på nytt.

Hantera false positives

Vid en felaktig blockering öppnas först loggposten och feednamn, Log/Drop, matchningsriktning, källa och destination eller URL, protokoll och portar dokumenteras. Kontrollera därefter att trafiken är legitim, rapportera den berörda indikatorn till feedleverantören och skapa endast ett så snävt undantag som möjligt med orsak, ansvarig och granskningsdatum.

Ett brett undantag för hela nätverk är ingen bra lösning. Vid domän- eller URL-träffar kan även TLS Inspection, en Web Policy, DNS Protection eller en annan säkerhetsfunktion vara involverad.

Skapa ett kontrollerat undantag under Protect > Active threat response > Add threat exclusions. Host and network exclusions använder befintliga host- eller nätverksobjekt. Under Threat exclusions anger man en enskild IP-adress, domän eller URL; en post får innehålla högst 128 tecken. Efter Add och Apply upprepas samma trafiktest och i Log Viewer bekräftas att endast den förväntade detekteringen uteblir.

⚠️ En Threat Exclusion gäller för alla Active Threat Response-moduler, inte bara för den feed som orsakade false positive. Bedöm före Apply effekten på MDR, NDR, Sophos X-Ops och Third-Party Threat Feeds. Dokumentera posten, orsaken, ansvarig och granskningsdatum och ta bort undantaget när det inte längre behövs.

Backup och restore

En firewallbackup innehåller konfigurationen för Third-Party Threat Feeds, men inte de hämtade listorna. Efter en restore hämtar brandväggen omedelbart källorna igen och tillämpar den konfigurerade åtgärden. DNS, internetåtkomst, certifikatvalidering och inloggningsuppgifter måste därför fungera direkt efter återställningen.

Threat Feed-konfigurationer kan inte importeras eller exporteras separat; Threat Exclusions kan däremot både importeras och exporteras. Efter en restore ska hämtningen av feeden, antalet IoC:er och trafikeffekten kontrolleras igen.

Cybora Threat Feeds för Sophos Firewall

Cybora levererar sina IPv4-, domän- och URL-feeds som textfiler via HTTPS, med en indikator per rad. Enligt den offentliga produktbeskrivningen kombineras OSINT- och communitykällor, kommersiell Threat Intelligence, honeypots, sensorer och brandväggssignaler. Formatet passar därför direkt i SFOS gränssnitt för tredjepartsfeed, men värdet i det egna nätverket måste ändå bekräftas med en pilot i läget Monitor.

Cybora används här som ett konkret leverantörsexempel. Samma tekniska urvalskriterier gäller för alla andra leverantörer: lämpliga indikatortyper, en direkt åtkomlig fil, aktuella data, acceptabla false positives, spårbara träffar och en tillgänglig process för korrigeringar.

Jämför abonnemang

Free (Basic) innehåller endast IPv4-indikatorer och uppdateras var 24:e timme, vilket gör att leverans och SFOS-kompatibilitet kan valideras före köp. Standard levererar IPv4 och en mindre domänuppsättning var sjätte timme. Premium levererar IPv4, domäner och URL:er varje timme, medan Ultimate levererar samma indikatortyper var 15:e minut. På XGS 87/87w, 88/88w och 107/107w är dock det kortaste valbara SFOS-intervallet fortfarande 24h, oavsett leverantörsplan.

Utöver antal och pris är aktualitet, indikatortyper som stöds, källkvalitet, uppdateringsintervall, risk för false positives och spårbarhet i Log Viewer viktiga. Rätt feed är den som ger relevanta träffar med acceptabla bieffekter i den egna miljön.

Avanet Firewall Network

En del av Premium-feeden kommer från ett distribuerat brandväggsnätverk. Det perspektivet hjälper till att upptäcka angreppsmönster som knappt syns på en enskild brandvägg.

Vid distribuerade brute-force-angrepp gör varje bot bara några få misslyckade inloggningsförsök och ligger ofta under ett lokalt tröskelvärde. Genom att sammanföra anonymiserade signaler blir IP-adresser synliga som riktat angriper infrastruktur i flera system. Resultatet är en kontinuerligt uppdaterad Threat Intelligence Feed för automatiserat försvar.