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 Central-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 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. Ange rätt adress från Avanets feedlista eller från den egna leverantören under External URL. Filen måste innehålla en indikator per rad.
9. Konfigurera vid behov API key eller Basic Authentication. Inloggningsuppgifter ska inte finnas i ärenden eller skärmbilder.
10. 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.
11. Välj ett Polling interval som motsvarar leverantörens uppdateringsintervall.
12. 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.

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.

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 Central. Den separata guiden beskriver Central-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 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.

Domänfeed kräver dessutom Application Classification eller en IPS-policy i brandväggsregeln för vidarebefordrad trafik.

För fullständiga HTTPS-URL:er måste brandväggen även kunna se sökvägen. Det kräver antingen Web Proxy med HTTPS-dekryptering eller DPI med en lämplig SSL/TLS-inspektionsregel. 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 Central- 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

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 bör feedens omfattning, kvalitet och prioritet 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

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.

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 tillhandahåller kurerade feed så att administratörer inte själva behöver samla in, normalisera och löpande kontrollera flera OSINT-listor. Data kommer bland annat från community- och OSINT-källor, kommersiell Threat Intelligence, honeypots samt anonymiserade angrepps- och avvikelseloggar från hanterade Sophos Firewall-miljöer.

Avanet har testat flera Threat Feed-leverantörer i verkliga brandväggsmiljöer. Enligt vår bedömning erbjuder Cybora för närvarande det bästa förhållandet mellan pris och prestanda för Sophos Firewall. Bedömningen omfattade feedkvalitet, täckning, uppdateringsintervall och kostnader. Även en sådan feed bör först testas i en egen pilot med Monitor.

Jämför abonnemang

Free (Basic) lämpar sig för hemanvändare, proof of concept och kompatibilitetstester. Standard kompletterar IPv4-feeden med domäner för malware och phishing. Premium utökar täckningen med domäner och URL:er som uppdateras varje timme. Ultimate riktar sig med uppdateringar var 15:e minut till kritisk infrastruktur och högriskperimetrar.

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.