Konfigurera Sophos Firewall ATP: X-Ops Threat Feeds

Den tidigare funktionen Advanced Threat Protection (ATP) heter Sophos X-Ops Threat Feeds i SFOS 22. Brandväggen jämför utgående trafik med en databas som Sophos underhåller över kända skadliga IP-adresser, domäner och URL:er. Den kan till exempel förhindra att en infekterad klient når en känd command-and-control-server.

Ett Threat Feed är en löpande uppdaterad lista över sådana indikatorer, förkortat IoCs (Indicators of Compromise). X-Ops får automatiskt den globala SophosLabs-databasen; ingen egen feed-URL anges. Under Active Threat Response kan en eller flera moduler konfigureras: MDR Threat Feeds ger information från MDR-analytikerna om aktiva hot i det egna nätverket; NDR Essentials analyserar brandväggstrafik med maskininlärning, bedömer identifierade IoCs och loggar dem. För Third-Party Threat Feeds anger man däremot egna feed-URL:er. En aktiv X-Ops-modul aktiverar inte de andra modulerna automatiskt.

För produktionsbruk är Log and drop målet. Funktionen är inaktiverad som standard och blockerar efter aktivering endast om den här åtgärden har valts.

Konfigurera X-Ops Threat Feeds

X-Ops-modulen kräver Network Protection. För att implementera threat-feed-inspektionen krävs dessutom Web Protection. Båda licenserna ingår i Standard- och Xstream Protection-paketen eller kan licensieras separat; X-Ops kräver ingen extra Sophos Fusion-licens (tidigare Sophos Central).

Före ändringar dokumenteras firmwarebuild, licenser, tidigare Action, kontrollomfattning, loggmål och undantag. För Synchronized Security krävs dessutom en Intercept-X-licens i Sophos Fusion eller Sophos Central; X-Ops-licensen ensam ger ingen endpoint-integration. Man kontrollerar också om brandväggsregler reagerar på en röd Security Heartbeat: den statusändring som dokumenteras i SFOS 23 kan då påverka endpointens åtkomst utöver att den enskilda anslutningen blockeras.

Öppna System services > Log settings.
Aktivera minst Local reporting på raden Active threat response. Välj beroende på drift även önskad syslogdestination och Central reporting. Spara de loggmål som stöds på den här modellen på sidan Log settings med Apply. Ladda om sidan och bekräfta att de valda målen fortfarande är inställda innan man går vidare till X-Ops-konfigurationen. Lokala händelseloggar är inte samma sak som lokal rapportering; alternativen för modeller utan lokal rapportering anges nedan.
Öppna Protect > Active threat response > Sophos X-Ops threat feeds.
Aktivera Sophos X-Ops threat feeds.
Välj under Action antingen Log only för en kort, kontrollerad pilot eller Log and drop för produktionsskydd.
SFOS 23: Log only loggar händelsen utan att ändra endpointens Security Heartbeat-status. Log and drop loggar händelsen, blockerar hotet och ändrar endpointens Security Heartbeat-status till röd.
Välj mellan Inspect untrusted content och Inspect all content under Advanced security settings.
Spara med Apply.
Kontrollera därefter inställningen, loggdestinationerna och befintliga undantag.

XGS 87/87w och 88/88w stöder inte lokal rapportering. På dessa modeller används i stället Central Reporting eller en syslogserver. Kolumnen Central reporting visas först när alternativet Send reports and logs to Sophos Central har aktiverats under Sophos Fusion (tidigare Sophos Central).

Sophos rekommenderar att kända IoC:er blockeras och inte bara loggas. För en ny eller tidigare oövervakad miljö kan Log only ändå vara lämpligt under en kort observationsfas med en tydlig sluttid. Fasen behöver en ansvarig och ett datum för övergången; annars kan funktionen lätt förbli aktiv permanent utan blockerande effekt.

Vad X-Ops skyddar – och vad det inte skyddar

X-Ops kontrollerar kända skadliga mål i utgående vidarebefordrad trafik. En typisk träff uppstår när en klient eller server försöker nå en känd IP-adress, domän eller URL för malware, phishing eller C2. Beroende på åtgärd loggas försöket eller avvisas direkt.

Översikten och X-Ops-beskrivningen är inte helt samstämmiga: Trafikmatrisen i översikten för SFOS 22/23 anger att Destination Match inte stöds för X-Ops, medan lokal Source Match stöds. Konfigurationsavsnittet för X-Ops beskriver däremot matchning mot skadliga IP-adresser, domäner och URL:er, vilket destinationskontrollen i den här artikeln bygger på. Denna motsägelsefulla matris ger varken någon garanti för alla destinationer för vidarebefordrad trafik eller något tillförlitligt underlag för täckningen av lokal Source Match. För denna avgränsning behövs en bekräftelse för den build som används innan befintliga skyddsregler ersätts. Matrisen visar samstämmigt att X-Ops inte skyddar mot fjärrkällor vid DNAT/WAF eller mot källor för trafik till själva systemet via WebAdmin, VPN-Portal eller VPN. För dessa tjänster behövs fortfarande restriktiva brandväggs-, WAF- och Device-Access-regler; alternativa feeds behandlas i artikeln om Third-Party Threat Feeds.

Även IPS, Malware Scanning och Zero-Day Protection har andra uppgifter. X-Ops arbetar indikatorbaserat: ett mål måste redan vara känt som en skadlig IoC. IPS identifierar däremot kända attackmönster i trafiken. Funktionerna kompletterar varandra men ersätter inte varandra.

Active Threat Response kontrollerar modulerna i följande ordning: MDR, NDR Essentials, Sophos X-Ops och därefter Third-Party Threat Feeds. Om en tidigare modul blockerar samma IoC avbryter brandväggen kontrollen. Att en X-Ops-loggpost saknas betyder därför inte automatiskt att inget skydd har aktiverats. Guiden om Third-Party Threat Feeds förklarar ordningen och överlappande indikatorer mer ingående.

Krav för en träff

Enbart aktivering garanterar inte att brandväggen kan se varje IP-, domän- eller URL-indikator. Det avgörande är vilken information som är synlig i den aktuella nätverksvägen.

IP-adresser

För en träff på en mål-IP måste den utgående trafiken gå genom en lämplig brandväggsregel. Brandväggen kan jämföra måladressen direkt med X-Ops-feeden; TLS-dekryptering krävs inte.

Domäner

För domänidentifiering måste de nödvändiga IPS-relaterade inställningarna vara verksamma: Application Classification måste vara aktiverat eller en IPS-policy vald i den berörda brandväggsregeln. Enligt dokumentationen är Application Classification aktiverat som standard; det faktiska tillståndet kontrolleras ändå. Det ska här inte förstås som ett extra reglage i varje brandväggsregel. Kravet gäller särskilt HTTPS och DNS-frågor till externa resolvrar via HTTP respektive HTTPS. Om den nödvändiga klassificeringen saknas kan domänmatchningen utebli i den aktuella trafikvägen.

Om brandväggen själv besvarar klienternas DNS-frågor utför DNS-modulen domänmatchningen. Om klienterna använder en extern resolver måste även den DNS-vägen gå genom brandväggen och vara synlig med de IPS-relaterade inställningar som krävs. När en domänträff saknas ska den resolverväg som faktiskt används kontrolleras, inte bara klientregeln till webbmålet.

Fullständiga URL:er över HTTPS

En URL innehåller utöver domänen även en sökväg, till exempel https://example.invalid/download/payload.exe. Vid krypterad HTTPS-trafik ser brandväggen utan dekryptering normalt bara domänen via SNI, inte sökvägen /download/payload.exe.

För att kontrollera hela URL-indikatorn krävs Web Proxy med aktiverad HTTPS-dekryptering eller en lämplig SSL/TLS Inspection-regel med Decrypt. TLS Inspection bör inte aktiveras okontrollerat globalt enbart för X-Ops: certifikatdistribution, integritet, undantag, applikationskompatibilitet och prestanda hör hemma i en separat utrullning.

För Web Proxy väljs alternativen Use web proxy instead of DPI engine och Decrypt HTTPS during web proxy filtering under Web filtering i den relevanta brandväggsregeln. För DPI-vägen förblir Use web proxy instead of DPI engine avstängt; den relevanta dekrypteringsregeln skapas under Rules and policies > SSL/TLS inspection rules med Action Decrypt. Båda vägarna kräver även de klassificeringsförutsättningar som nämns ovan för fullständig kontroll av HTTPS-URL:er. Endast den godkända trafikvägen ändras, och därefter kontrolleras certifikatförtroendet, den normala verksamhetsprocessen och vilken regel som faktiskt matchar i Log Viewer.

Välj inspektionsomfattning medvetet

Under Advanced security settings anges hur brett X-Ops ska inspektera trafiken:

Inspect untrusted content begränsar inspektionen till trafik med ej betrodda källor eller mål. Inställningen kräver färre resurser och är en lämplig startpunkt när belastning och bieffekter ännu inte är kända.
Inspect all content inspekterar både betrodd och ej betrodd trafik. Det ger bredare täckning men kan påverka prestandan, särskilt i hårt belastade miljöer.

För särskilt skyddsvärda klient-, server- eller administrationsnät kan Inspect all content vara lämpligt om brandväggsenheten har tillräcklig kapacitet. Ändringen bör göras under ett underhållsfönster. Därefter jämförs CPU-belastning, latens, genomströmning och återkoppling från helpdesk med det tidigare läget.

Dokumentationen beskriver prestandaskillnaden mellan de två kontrollomfattningarna som oftast liten, men vid hög trafik kan den vara betydande. Före bytet dokumenteras det tidigare värdet. Om jämförelsen visar en relevant försämring återställs den tidigare kontrollomfattningen under Advanced security settings, ändringen sparas med Apply och verksamhetsprocessen, belastningen och loggningen kontrolleras igen. Blockeringsåtgärden behöver inte stängas av generellt för detta.

Åtgärd och inspektionsomfattning bör vid en introduktion helst inte ändras flera gånger samtidigt. Om synligheten ändras först och blockeringsåtgärden därefter blir det lättare att avgöra vilken inställning som orsakade ett problem.

Kontrollera effekt och loggning

Efter att inställningen har sparats bör kontrollen inte begränsas till om reglaget är aktivt. En tillförlitlig driftskontroll omfattar tre nivåer:

Konfiguration: X-Ops är aktiverat och önskad åtgärd och inspektionsomfattning är sparade.
Synlighet: brandväggsregeln, Application Classification eller IPS samt TLS-dekryptering för fullständiga HTTPS-URL:er motsvarar indikatortypen.
Verifiering: träffar kan hittas under Log viewer > Active threat response eller i den konfigurerade Central- eller syslogdestinationen.

För en lokal sammanfattning öppnar man Reports > Network & threats > Active threat response. Widgeten med samma namn i Control Center visar en översikt över berörda värdar och hothändelser. MDR och X-Ops visar status och blockerade hot, NDR Essentials visar status och övervakade hot; Third-Party Threat Feeds visar dessutom konfigurerade feeds och deras synkroniseringsstatus. Configure leder till konfigurationen, Reports till rapporterna och More details utökar widgetvyn. På enheter utan lokal rapportering saknas knappen Reports; där används de konfigurerade Central- eller Syslog-målen. Ett NDR-antal för övervakade hot är inte bevis på blockering. Den konkreta åtgärden och anslutningsdetaljerna kontrolleras i rapporten eller Log Viewer. Widgeten visar för Third-Party Threat Feeds även antalet hot som har blockerats av dessa feeds.

Den tekniska loggtypen i syslog heter fortfarande ATP, även om gränssnittet numera använder X-Ops och Active Threat Response. Beroende på bearbetningsväg kan log_component visa Firewall, DNS, IPS eller Web. Vid en undersökning är tidsstämpel, åtgärd, källa, destination, portar, domän eller URL, threat name, feed name och Event ID särskilt användbara.

I Advanced Shell är ips.log den viktigaste engine-loggen för Active Threat Response. garner.log hjälper vid bearbetning och vidarebefordran av events, särskilt när Central Reporting verkar ofullständig. Dessa filer och säker SSH-åtkomst förklaras i översikten över Sophos Firewall-tjänster och loggfiler.

Det finns ingen allmänt dokumenterad ofarlig X-Ops-testindikator. Därför bör inte en verklig malware-domän eller känd skadlig IP-adress öppnas avsiktligt. Om ett reproducerbart funktionstest behövs är en egen Third-Party-pilotfeed med ett kontrollerat testmål den säkrare metoden. För X-Ops i sig kontrolleras konfiguration och synlighet; nästa verkliga, noggrant undersökta träff bekräftar den faktiska blockeringen.

När en IoC inte blockeras eller ingen X-Ops-logg visas

Börja med den specifika indikatortypen och den faktiska trafikvägen. På så sätt undviks breda undantag eller globala TLS-ändringar som bygger på antaganden:

Kontrollera under Protect > Active threat response > Sophos X-Ops threat feeds att X-Ops är aktivt och att Action verkligen är inställt på Log and drop. Log only skapar bara en post.
Kontrollera modul, faktisk åtgärd och anslutningsdetaljer för samma IoC i Log viewer > Active threat response. Endast en verifierad blockerande åtgärd från en tidigare modul, till exempel MDR med Log and drop, avslutar den fortsatta kontrollen före X-Ops. NDR Essentials upptäcker och loggar med Log threats, men blockerar inte. En övervakad NDR-händelse ensam avslutar inte X-Ops-kontrollen och förklarar inte en saknad X-Ops-loggpost.
För mål-IP-adresser kontrolleras den LAN-to-WAN-regel som faktiskt matchar. För domäner kontrolleras även Application Classification, IPS-policyn och resolvervägen.
För fullständiga HTTPS-URL:er söks servernamnet i Log viewer > SSL/TLS inspection. Om den matchande SSL/TLS rule visar Don't decrypt kan X-Ops inte se URL-sökvägen. Planera en så snäv Decrypt-regel som möjligt först efter att regeln har identifierats.
Sök efter domänen eller URL:en i Log viewer > Web filter; kontrollera även kolumnen Category och detaljvyn. Där framgår brandväggsregelns ID och den valda webbpolicyn. Om den ansvariga Web policy visar Allow, kontrollera ordningen för regler och policyer. För en bekräftat skadlig domän eller URL kan en snävt avgränsad URL-grupp med webbpolicyåtgärden Block användas i en lämplig LAN-to-WAN-regel ovanför den regel som hittills tillåtit trafiken. För webbproxyvägen kontrolleras även Web > Exceptions: URL pattern matches, Web categories, Destination IP addresses och Source IP addresses kan omfatta indikatorn eller den endpoint som skickar begäran. För DPI-vägen kontrolleras SSL/TLS Exclusion Lists. Ett undantag tas inte bort generellt; först klargörs syftet, den berörda verksamhetsprocessen och godkännandet.
Sök under Protect > Active threat response > Add threat exclusions efter både IoC:n och den anropande värden eller nätverket. Undantagen gäller för alla moduler.

Efter varje korrigering upprepas samma verksamhetsprocess och relevanta loggar kontrolleras. Om orsaken fortfarande är oklar sparas tidsstämpel, brandväggsregel-ID, Web- eller SSL/TLS-regel-ID och detaljvyn för Active Threat Response-händelsen till supportärendet.

Undersök ett X-Ops-larm

En blockerad IoC är en stark signal men ännu ingen fullständig incidentanalys. Måladressen kan till exempel ha kontaktats av malware, en phishinglänk, ett komprometterat webbläsartillägg eller en legitim men felklassificerad tjänst.

Ett lämpligt förlopp är:

Spara tidsstämpel, brandvägg eller HA-nod, åtgärd och fullständiga loggdetaljer.
Registrera käll-IP, mål-IP, domän eller URL, portar, protokoll, threat name och feed name.
Korrelera brandväggs-, DNS-, IPS- och webbloggar inom samma tidsfönster.
Identifiera den interna klienten via DHCP-leasen, användartilldelningen eller Endpoint-data.
Sök på det berörda systemet efter den tillhörande processen, webbläsarhistoriken, nedladdningen och ytterligare security events.
Om en kompromettering bekräftas ska systemet isoleras och hanteras enligt den interna Incident Response-runbooken.
Först efter analysen avgörs om sanering, en ytterligare blockering eller ett snävt avgränsat undantag krävs.

Med Synchronized Security kan processanvändare, Endpoint ID och exekveringssökväg dessutom visas på Windows-endpoints som stöds. På macOS är dessa processdetaljer inte tillgängliga; där är käll-IP-adressen fortsatt särskilt viktig för tilldelningen.

Känt falskt HA-larm `NC-170292`

På ett HA-system med SFOS 21.5.1 MR1 Build 261 kan NC-170292 utlösa ett felaktigt Advanced threat detected-larm med Raw Logs i Sophos Fusion. Samtidigt kan ett e-postmeddelande från brandväggen komma utan användbara detaljer.

Begränsningen gäller inte generellt för andra builds eller standalone-brandväggar. Ett larm ska därför först sparas och undersökas enligt beskrivningen ovan. Om systemet exakt motsvarar den berörda builden och tillförlitliga träffdetaljer saknas, anger Sophos omstart av Garner-tjänsten som en tillfällig workaround. Eftersom Known Issues-listan inte anger något specifikt CLI-kommando för felet bör omstarten endast göras enligt en godkänd support- eller underhållsprocess. Vid återkommande meddelanden ska HA-status, firmwarebuild, tidsstämpel och garner.log ingå i Sophos Support-ärendet.

Lägg endast till undantag efter bekräftad analys

Under Protect > Active threat response > Add threat exclusions kan Host and network exclusions och Threat exclusions skapas för IP-adresser, domäner eller URL:er. En post under Threat exclusions får innehålla högst 128 tecken. Ett sådant undantag gäller inte bara för X-Ops utan för alla Active Threat Response-moduler. Ett snabbt undantag kan därför samtidigt försvaga skyddet från MDR, NDR eller Third-Party Threat Feeds.

Om en false positive har bekräftats bör endast minsta nödvändiga indikator undantas. Undantaget ska innehålla orsak, ärende, ansvarig person och granskningsdatum. Att förebyggande undanta hela klientnät eller breda domänområden tar visserligen bort det synliga larmet, men även en stor del av skyddet.

För ett godkänt undantag öppnar man Protect > Active threat response > Add threat exclusions och använder ett av följande alternativ beroende på typen av undantag:

Värdar eller nätverk: Under Host and network exclusions, klicka på Add new item och välj endast de godkända värd- eller nätverksobjekten.
Hotindikator: Ange i stället den godkända IP-adressen, domänen eller URL:en under Threat exclusions och lägg till den i listan med Add. Observera gränsen på 128 tecken per post.

Spara därefter med Apply. Öppna sidan igen och kontrollera att endast de avsedda posterna har sparats. Enbart Add new item respektive Add ersätter inte detta avslutande steg för att spara.

Efter ändringen testas samma affärsprocess igen och Log Viewer kontrolleras för att säkerställa att endast den avsedda träffen uteblir. Andra X-Ops-händelser måste fortsätta att loggas eller blockeras.

För att återgå till det tidigare läget återställs endast den senast gjorda ändringen: inspektionsomfattningen ställs in på det dokumenterade tidigare värdet och sparas med Apply; en nyskapad Web/SSL/TLS-regel eller ett nyskapat undantag återtas specifikt, utan att befintliga regler eller andra undantag ändras. Därefter kontrolleras affärsprocessen, den regel som faktiskt matchar och loggarna på nytt. Om ett undantag återtas kan den berörda träffen blockeras igen. Om en driftstörning tillfälligt kräver Log only upphör X-Ops blockering under den tiden; ansvariga och sluttid fastställs och Log and drop återställs när orsaken har klarlagts. En inaktiverad modul är inte ett likvärdigt sätt att återgå till det tidigare läget, eftersom även dess inspektion då upphör. Ett kontrollerat test med en egen, särskild pilot-feed under Third-Party Threat Feeds verifierar endast trafikvägen för denna feed, inte leveransen av eller matchningen mot X-Ops-databasen.

XML API: Hantera aktivering, åtgärd och undantag separat

Den som automatiserar X-Ops måste skilja mellan tre oberoende inställningar i det dokumenterade XML-objektet ATP. API-referensen för SFOS 22/23 beskriver:

ATP/ThreatProtectionStatus: skalärt modulreglage med Enable eller Disable. Det aktiverar respektive inaktiverar X-Ops; det är varken åtgärden vid en träff eller ett enskilt undantag.
ATP/Policy: skalär åtgärd vid en träff. Parametertabellen anger Log Only och Log and Drop, listar Log Only som standardvärde och markerar fältet som obligatoriskt när X-Ops är aktiverat. Detta är en uppgift i API-tabellen, inte ett bevis på det sparade tillståndet i den egna brandväggen.
ATP/InspectContent: skalär inspektionsomfattning med all eller untrusted. En annan inspektionsomfattning är inte likvärdig med Disable eller med att byta åtgärd vid en träff.
ATP/HostException/Host: lista med strängar för källvärdar eller källnätverk som ska undantas. I exemplet anges HostName; för en post behövs den godkända objektreferensen från den egna konfigurationen.
ATP/ThreatException/Threat: separat lista med strängar för målindikatorer som ska undantas. API-tabellen anger mål-IP-adresser och domäner. Den URL-inmatning i gränssnittet som beskrivs ovan bevisar inte i sig någon XML-payloadsyntax för URL:er.

De två undantagslistorna ligger alltså under olika överordnade element och kan innehålla flera poster. De är inga globala avstängningsreglage. API-tabellen anger deras verkan för X-Ops, MDR och Third-Party Threat Feeds; den mer omfattande varningen om påverkan på flera moduler och reglerna för godkännande i avsnittet om undantag är därför fortfarande viktiga.

Klargör Policy-konflikten före en skrivande begäran: XML-exemplet använder texten alert/drop för Policy, medan parametertabellen anger Log Only och Log and Drop. Dessa skrivsätt omvandlas inte automatiskt till varandra; inte heller UI-labelarnas skrivsätt är ett bevis på ett giltigt API-värde. Före automatisering bekräftar man det konkreta värdet och begärans struktur med hjälp av API-hjälpen för den installerade builden eller med Sophos Support. Fram till dess är exemplet inte en begäran som är färdig att kopiera och verifierad som fungerande.

Säker konfiguration av XML API behandlas separat. Före en godkänd ändring sparar man modulstatus, åtgärd, inspektionsomfattning och båda undantagslistorna. Därefter läser man åter av det faktiskt sparade tillståndet eller öppnar konfigurationssidan och jämför dessa fem områden var för sig. Vid ett fel kontrolleras först det sparade tillståndet innan ett nytt försök görs; ett undantag eller en annan inspektionsomfattning får inte oavsiktligt leda till global inaktivering.