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. Local reporting lagrar händelseloggar lokalt för Log Viewer; dessa loggar är inte rapporter som genereras på enheten. Använd alternativt Sophos Fusion (tidigare Sophos Central) eller en syslogserver som loggdestination.
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 enligt leverantörens anvisningar. För API key anges det header- eller parameternamn som leverantören anger och det hemliga värdet separat; välj därefter Header eller Query parameters som överföringsplats. Om leverantören exempelvis kräver headern X-API-Key är detta namnet, inte den hemliga nyckeln. För Basic authentication anges användarnamn och lösenord. API-nyckelns värde och lösenordet stöder vardera 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 en lyckad anslutning eller HTTP-GET-förfrågan, men varken att listan har utvärderats fullständigt eller att den förväntade trafiken faktiskt identifieras eller blockeras. Innehåll och effekt måste valideras separat.

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

Indikatorer som stöds

Varje feedkonfiguration utvärderar exakt en av dessa indikatortyper:

• 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. Om leverantörens fil innehåller flera typer tar SFOS endast hänsyn till vald Indicator type. Därför behövs en separat konfiguration för varje önskad typ; en blandad fil behöver inte delas upp enbart på grund av blandningen. IP-intervall, IPv6-adresser, nätverk, wildcard-domäner och reguljära uttryck används inte i Third-Party Threat Feeds som ersättning för enskilda IoC:er som stöds.

Ett rent IPv4-formatexempel ser ut så här:

192.0.2.10
198.51.100.20

Dessa dokumentationsadresser visar endast formatet, inte verkliga hot eller nåbara testdestinationer. För det kontrollerade testet längre ned används i stället den enskilda IPv4-adressen till den egna testdestinationen, inte dess nätverk med CIDR-suffix. För Cybora används de tillhandahållna feedfilerna direkt.

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. Integrationen är inte begränsad till en fast lista med valbara leverantörer: alla Third-Party Feeds kan anslutas om de uppfyller de beskrivna filkraven. Sophos nämner till exempel GreyNoise Intelligence, CrowdSec och Q-Feeds som leverantörer; att de nämns ersätter varken kontrollen av den konkreta endpointen eller den egna piloten i Monitor.

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. Modulernas licensöversikt anger Xstream Appliance Bundle, medan konfigurationshjälpen anger Xstream Protection Bundle. Använd den specifika jämförelsen av licenser och källor för NDR Essentials före köp eller utrullning och få avtalsmässig åtkomst bekräftad för den aktuella brandväggen.
• 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än- och URL-feeds 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.

Den ansvariga inspektionsvägen är webbmodulen för Web Proxy respektive IPS för DPI Engine med SSL/TLS-inspektionsregler. Detta gäller både krypterad och dekrypterad HTTPS; vilka IoC:er som kan identifieras beror fortfarande på om endast domänen eller även URL-sökvägen är synlig.

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

Sync status: Success bekräftar en lyckad anslutning eller HTTP-GET-förfrågan till External URL, inte att alla förväntade indikatorer är med eller har utvärderats korrekt. Test connection är också enbart en anslutningskontroll. 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 som antalet aktiva och totalt konfigurerade feeds, Total threat indicators som antalet IPv4-, domän- och URL-indikatorer samt Storage quota som utnyttjat lagringsutrymme inom den modellberoende kvoten. Större enheter har mer utrymme än desktopmodeller. Refresh uppdaterar bara dessa visade räknare. Synchronize now under Manage hämtar däremot den valda feeden omedelbart. Enskilda IoC:er kan öppnas och sökas via Threat indicators eller via antalet under Total indicators för den aktuella feeden. Fetching betyder att hämtningen pågår; Disabled betyder att feeden är inaktiverad.

Vid Authentication error kontrolleras först API-nyckelns namn, det hemliga värdet och överföringsplatsen respektive användarnamn och lösenord. Om uppgifterna stämmer ska även en misslyckad TLS-handskakning undersökas: kontrollera feedserverns certifikat och förtroendekedja och kontakta leverantören vid behov. Alla autentiseringsfel är inte TLS-fel. Validate server certificate ska förbli aktiverat; saknat CA-förtroende åtgärdas med rätt CA-certifikat, inte genom att stänga av kontrollen.

Vid Connection error kontrolleras DNS, internetåtkomst, feedservern och HTTP-status; även 404, 500 och 302 är möjliga orsaker. SSL/TLS error är en separat status för certifikatproblem. Vid Failed kontrolleras att den faktiskt levererade filen är ren text, har en indikator per rad och innehåller lämpliga typer som stöds; även andra fel är möjliga. Efter korrigeringen körs Test connection och Synchronize now igen, tidsstämpeln och förväntad IoC kontrolleras och först därefter upprepas det kontrollerade trafiktestet. Om felet kvarstår dokumenteras status, tidpunkt och rensade feeduppgifter utan hemligheter för leverantören eller supporten.

Storage full betyder att det inte finns tillräckligt med utrymme för hela listan. Brandväggen fortsätter 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 och URL:er 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. Bekräfta först att hämtningen och inspektionsvägen fungerar och kontrollera om MDR, NDR eller X-Ops redan identifierar samma IoC:er. Ett kort test utan träffar är inget skäl att ta bort feeden. Om feeden därefter verkligen visar sig vara redundant dokumenteras namn, URL, indikatortyp, åtgärd, position, pollingintervall och den säkra förvaringen av inloggningsuppgifterna innan den tas bort. Ta bort den kontrollerade feeden under Protect > Active threat response > Third-party threat feeds för att frigöra lagringsutrymme. Kontrollera därefter Refresh, Storage quota och Active feeds och hämta på nytt en feed som tidigare misslyckades på grund av Storage full med Synchronize now. För att återgå skapas den borttagna feeden på nytt med de dokumenterade värdena, till att börja med i Monitor. Tillfällig inaktivering för rollback är en separat åtgärd och betraktas inte som bevis på att lagringsutrymme har frigjorts.

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. Välj befintliga host- eller nätverksobjekt under Host and network exclusions > Add new item. 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 träffen 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.

Automatisera ThirdPartyFeed via XML

För att automatisera samma feedkonfiguration använder XML-gränssnittet objektet ThirdPartyFeed. Det konfigurerar hämtningen och åtgärden, inte de enskilda nedladdade IoC:erna. Åtkomst, explicit skrivoperation, versionsberoende uppbyggnad av begäran och säker tolkning av svar förklaras under Säkra XML-API-åtkomst. Följande fältnamn och gränser gäller SFOS 22 och 23. Bekräfta den konkreta Add-/Edit-operationen och dess payload i API help för den installerade builden före användning. Skriv inte vid oklar syntax eller motstridiga källuppgifter, utan red ut frågan med supporten.

Identifiera den befintliga feeden via dess Name i WebAdmin före en ändring och spara namn, indikatortyp, URL, åtgärd, aktivering, position och pollingintervall. Namnet betecknar feedkonfigurationen, inte leverantören eller en enskild IoC. Samma leverantör kan ha flera separat namngivna konfigurationer för IPv4, domäner och URL:er. Härled inte någon obekräftad semantik för namnbyte, upsert eller överskrivning från objektnamnet.

• Identitet och källa: Name är obligatoriskt, tillåter högst 63 tecken och endast bokstäver, siffror, understreck och bindestreck. Description är valfritt och begränsat till 255 tecken. ExternalURL är obligatoriskt och begränsat till 1024 tecken; använd även fortsättningsvis en direkt åtkomlig HTTPS-feed i klartext med en indikator per rad.
• Åtgärd och ordningsföljd: Action kräver exakt block eller monitor, vilket motsvarar Block respektive Monitor i användargränssnittet. monitor loggar träffar utan blockering via feeden; block loggar och blockerar. Beteckningarna Log only och Log and drop i andra moduler är inte ersättningsvärden för detta fält. Position tillåter top eller bottom, vilket motsvarar Top eller Bottom. Detta väljer positionen inom Third-Party Feeds, inte deras prioritet framför MDR, NDR Essentials eller Sophos X-Ops. Block- och Monitor-listor förblir separata; den första träffen i respektive lista är avgörande.
• Indikatortyp: IndicatorType kräver ip, domain eller url, vilket motsvarar IPv4 address, Domain eller URL. ip är här inte en typ för IPv6, nätverk eller adressintervall. Skapa en separat konfiguration för varje önskad indikatortyp.
• Autentisering: Authorization kräver noAuthentication, basicAuthentication eller apiKey. Endast vid Basic Authentication ingår Username och Password, vardera med högst 64 tecken. Endast vid API-nyckelautentisering ingår Key, Value och AddTo: nyckelnamnet och det hemliga värdet är separata och vardera begränsade till 64 tecken; överföringsplatsen är exakt header eller queryParam, vilket motsvarar Header eller Query parameters. Leverantörens krav avgör, inte ett antaget standardvärde. Använd endast de fält som hör till metoden; hämta hemligheter från ett skyddat Secret Store och håll dem borta från XML-filer i kodarkivet, URL:er i ärenden, skalhistorik, skärmbilder och loggar. Var särskilt noga med att maskera loggade feed-URL:er när frågeparametrar används.
• Certifikatvalidering: ValidateServerCertificate är obligatoriskt; objektexemplet visar true och false. Aktivera valideringen uttryckligen för säker drift och konfigurera förtroendet för rätt CA i förväg. Ett TLS- eller autentiseringsfel motiverar inte att valideringen stängs av.
• Hämtningsintervall: PollingInterval är obligatoriskt och tillåter endast 5m, 15m, 30m, 1h, 6h, 24h, 7d eller 30d. Detta är fasta token, inte ett fritt valbart antal minuter. På XGS 87/87w, 88/88w och 107/107w är valet fortsatt begränsat till 24h, 7d och 30d. Exempelvis passar 1h för en leverantörsuppdatering varje timme endast på en modell som stöder detta intervall.
• Aktivering och standardvärden: För Enabled anger parametertabellen 1 och 0, medan objektexemplet anger true och false. Detta är en olöst skillnad i representation, inte ett belägg för att skrivsätten är utbytbara. Klarlägg den giltiga formen i den installerade builden före ett skrivförsök. Tabellen anger dessutom monitor, top, ip och noAuthentication som standardvärden för motsvarande fält; dessa uppgifter är inte testade garantier för beteendet vid körning. Ange åtgärd, position, typ och autentisering medvetet i stället för att förlita dig på utelämnade värden.

Tolka Add-/Edit-svar säkert

För Add Third-party threat feed och Edit Third-party threat feed är följande kopplingar dokumenterade. Värdena Message.* är olösta meddelandesymboler, inte ordagranna feltexter och inte en tillräcklig grund för att avgöra åtgärder:

I synnerhet hör 409 / Message.CPResourceConflict till Add och 404 / Message.CPRecordNotFound till Edit. Likställ inte dessa objektspecifika kopplingar med allmänna XML-koder eller en HTTP-transportstatus; det faktiska svaret och Status Message Information i builden är avgörande. Jämför efter varje ändring den sparade feeden i WebAdmin med de avsedda värdena och kontrollera Audit Trail. Vid fel, timeout eller oklart svar ska det faktiskt sparade tillståndet kontrolleras först, innan ett Add eller Edit skickas på nytt. Härled inte någon automatisk upprepning, namnändring eller förmodad felavhjälpning från en symbol.

Ett motsvarande konfigurationssvar bevisar varken feedhämtning, IoC-innehåll eller effekt på trafiken. Kontrollera därefter även Test connection, Synchronize now, Last updated, Storage quota, en förväntad IoC och ett kontrollerat trafiktest med Monitor. Byt till Block först efter denna kontroll; vid oväntade avbrott ska den sparade åtgärden återställas eller feeden inaktiveras kontrollerat enligt beskrivningen ovan, inte ersättas med en global Threat Exclusion.

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.