Konfigurera och testa Sophos Firewall IPS säkert

Intrusion Prevention System (IPS) granskar nätverkstrafik för att upptäcka kända attackmönster, exploateringsförsök och avvikande protokollegenskaper. För att IPS faktiskt ska skydda måste funktionen vara globalt aktiverad. Dessutom måste brandväggsregeln som behandlar dataflödet använda en lämplig IPS-policy.

Den säkra snabbvägen är att kontrollera licensen och signaturmönstren, aktivera IPS, välja en policy utifrån det system som ska skyddas, tilldela den till rätt brandväggsregel och verifiera dataflödet med en liten pilotgrupp. Den striktaste policyn i varje regel ger inte automatiskt bäst skydd. Ett olämpligt val skapar onödiga träffar, belastning eller störningar och försvårar den egentliga analysen.

Kontrollera förutsättningar och licensstatus

Följande krävs före konfigurationen:

• en aktiv Network Protection-prenumeration eller testlicens;
• tillgängliga IPS-signaturer och fungerande mönsteruppdateringar;
• Firewall Rule ID för den regel som faktiskt behandlar den avsedda trafiken;
• regelloggning för att kunna korrelera session, brandväggsregel och IPS-händelse;
• en ansvarig person, definierade tester och en återställningsplan för falska positiva resultat.

IPS Protection är avstängt som standard. På en internetansluten brandvägg uppdateras IPS-signaturerna endast om licensen är giltig och IPS är aktiverat. Licensierade Air Gap-brandväggar är det dokumenterade undantaget: de kan hämta IPS-signaturer via den avsedda uppdateringsprocessen även när IPS är avstängt. Skillnaderna beskrivs i Air Gap-licensiering och mönsteruppdateringar.

När en Network Protection-prenumeration löper ut kan IPS-reglaget fortfarande se aktiverat ut, trots att brandväggen inte längre upprätthåller IPS-skyddet. Testlicensen fungerar annorlunda: när den löper ut stängs IPS av automatiskt. När IPS är avstängt hämtas inga fler onlinesignaturer, och det går inte längre att konfigurera policyer eller egna signaturer. Efter 30 dagar i detta avstängda läge tar SFOS bort IPS-signaturerna och reglerna. Den som behöver bevara konfigurationen bör därför först skapa en export eller säkerhetskopia.

Även när IPS är avstängt kan befintliga IPS-policyer fortfarande tilldelas brandväggsregler. Denna tilldelning bevisar inte att aktiv inspektion eller skydd finns. Om den betalda prenumerationen har löpt ut och IPS är avstängt, eller om en utgången testlicens automatiskt har stängt av IPS, måste först en Network Protection-prenumeration aktiveras innan IPS kan slås på igen. Kontrollera IPS-reglaget och signaturerna på nytt efter aktiveringen.

Inte heller en giltig prenumeration ger obegränsat skydd utan kontakt med licenstjänsten. Internetanslutna brandväggar synkroniserar normalt sina licenser var 24:e timme. Om synkroniseringen uteblir i 90 dagar i följd inaktiverar SFOS säkerhetsprenumerationerna; för en Air Gap-licens är tidsgränsen 180 dagar. Inloggningar och trafik kan då fortsätta att fungera, men utan skyddet från de inaktiverade prenumerationerna. Licensstatusen ska därför ingå i felsökningen när IPS verkar vara konfigurerat men inte har någon effekt.

Under Backup & firmware > Pattern updates visar SFOS bland annat statusvärdena Ready to install, Downloading, Success och Failed. Update pattern now startar en uppdatering av de vanliga mönsterdefinitionerna. En lyckad post för Application Signatures bevisar inte att IPS-signaturerna också har hämtats: på internetanslutna system kräver de fortfarande en giltig licens och att IPS är aktiverat.

Aktivera IPS och fastställ dataflödet

1. Öppna Intrusion prevention > IPS policies.
2. Aktivera IPS Protection.
3. Kontrollera tidpunkt och status för IPS-mönstren under Backup & firmware > Pattern updates.
4. Dokumentera det tidigare läget för IPS Protection, Firewall Rule ID för pilotflödet, den tidigare IPS-policyn, Log firewall traffic och befintliga undantag.

Om Firewall Acceleration eller PKI Acceleration aktiveras eller inaktiveras startas IPS respektive DPI Engine om. Sådana ändringar hör inte hemma i denna aktiveringsprocess. Om ett reproducerbart problem berör en global motorinställning beskriver Kontrollera globala IPS-inställningar säkert vilka ändringar som gäller omedelbart, vilka som kräver ett Apply-steg eller en omstart och hur ursprungsvärdet bevaras.

Systemet som ska skyddas avgör policyn

Target avser den sida vars sårbara programvara en signatur skyddar. Det är inte samma sak som Source Zone eller Destination Zone. För en webbläsare som tar emot ett manipulerat svar kan Target exempelvis vara Client; för en publicerad webbserver som tar emot en skadlig begäran kan det vara Server.

Valet kan göras med hjälp av tre frågor:

1. Vilket system i det aktuella flödet ska skyddas: klienten eller servern?
2. Vilka plattformar, protokoll och tjänster körs faktiskt där?
3. Täcker en befintlig policy detta område utan ovidkommande signaturgrupper?

För en vanlig klients internettrafik är en lämplig Client- eller LAN-to-WAN-policy utgångspunkten. Vid en DNAT-publicering väljer du en Server- eller Webserver-policy som stämmer överens med operativsystemet och de portar som faktiskt publiceras. Även i ett VPN- eller segmenteringsflöde är det den skyddade applikationen som avgör, inte enbart källzonens namn. MTU, MSS, latens och genomströmning kontrolleras då över den verkliga VPN-sträckan.

VoIP kräver ett separat funktionstest av SIP-signalering och RTP-media samt en förberedd återgång till den tidigare policyn. För administrations-, säkerhetskopierings- och infrastrukturnät är snäva regler oftast värdefullare än ett särskilt brett signatururval. IPS kan även försvåra laterala angrepp vid interna segmentgränser, men tröskelvärden för spoofing och flooding hanteras separat i inställningarna för skydd mot spoofing och DoS.

En egen policy är lämplig när dataflödet behöver avgränsas snävare, en enskild SID behöver ett dokumenterat undantag eller en åtgärd avsiktligt ska avvika från Recommended. Skapa då ett unikt namn, exempelvis IPS-Pilot-LAN eller IPS-DNAT-Webserver, under Intrusion prevention > IPS policies > Add och klona en lämplig befintlig policy som utgångspunkt. Spara först den nya eller klonade policyn med Save; detta skapar ännu ingen ny policyregel. Anpassa därefter reglerna i kopian; de medföljande signaturerna kan inte redigeras.

Filtrera signaturer och ordna policyreglerna

När du lägger till en regel kan du välja enskilda signaturer, egna signaturer eller Select all. Smart Filter tar emot sökord och kriterier som Category, Severity, Platform och Target; tryck på Enter för att tillämpa filtret efter inmatningen.

Regeleditorn öppnas separat från skapandet av policyn: välj Edit för den önskade, redan sparade policyn under Intrusion prevention > IPS policies, välj sedan Add och ange ett unikt regelnamn. Välj därefter de signaturer som behövs: Select individual signature för enskilda signaturer eller Custom signature för egna signaturer. För att söka med Smart filter, välj först Select all, ange sökordet och tryck på Enter för att tillämpa filtret.

Kategorierna underlättar den tekniska avgränsningen. Den fullständiga tabellen nedan förklarar beteckningarna som SFOS visar. Använd Category som uppslagsstöd, inte som ett riskomdöme; kombinera med Platform och Target så att Smart Filter endast väljer relevanta signaturer.

Breda indikatorkategorier bör först användas i ett observerande pilottest. Särskilt indicator-compromise kan ge falska positiva resultat; kategorin ensam motiverar därför varken blockering eller undantag.

Ange Action medvetet efter signaturvalet; skillnaderna förklaras i avsnittet om Severity och åtgärd. Spara regeln med Save i regeleditorn. Detta är ett annat steg än att spara policyn första gången. I DDoS-processen sparas därefter även den omslutande policyn med Save.

Starta en ny testsession efter att policyn har sparats och kontrollera ips_policy_id eller idp_policy_id samt fw_rule_id; vid en träff jämför du även signature_id, classification och log_subtype med avsedd regel och åtgärd. En utebliven träff bevisar inte i sig att filtret eller policyn har tillämpats.

Policyregler utvärderas uppifrån och ned. En bred regel för alla serversignaturer kan därför åsidosätta en efterföljande specialregel för en enskild SID. Specifika undantag eller avvikande åtgärder ska placeras ovanför den mer generella regeln. En efterföljande träff måste visa förväntad policy, Rule ID och åtgärd.

Egna IPS-signaturer är avsedda för ett tydligt beskrivet detekteringsfall, inte som ersättning för ett olämpligt standardval. Processen med syntax, en snäv pilotpolicy samt positiva och negativa tester beskrivs i Skapa och testa egna IPS-signaturer.

Bedöm Severity och åtgärd separat

För loggar, ärenden och undantag är SID, Category, Severity, Platform, Target och Recommended action viktiga. Sophos klassificerar Critical som CVSS 9 till 10, Major som 7 till under 9, Moderate som 4 till under 7 och Minor som 1 till under 4 eller som överordnade signaturer. Warning betecknar en viss typ av trafik och genererar en varning. Severity avgör inte ensam risken: åtkomlighet, målsystem, patchnivå och faktisk åtgärd måste också ingå i bedömningen.

Denna CVSS-klassificering gäller inte utan undantag: Sophos beskriver fall där Severity-nivån inte stämmer överens med de angivna formlerna. Detta innebär varken att det finns en dokumenterad WebAdmin-funktion för att åsidosätta Severity eller ett förfarande för omklassificering; kontrollera den Severity-nivå som faktiskt visas för signaturen.

En policyregel kan åsidosätta den rekommenderade åtgärden:

• Recommended tillämpar den åtgärd som Sophos rekommenderar för respektive signatur och är den normala utgångspunkten för produktionsregler.
• Allow packet loggar träffen men tillåter paketet. Det passar för ett pilottest men förhindrar inte det identifierade angreppet.
• Drop packet kasserar endast det berörda paketet. Applikationen kan fortsätta eller svara med ett fel.
• Drop session avslutar hela sessionen efter en träff.
• Reset avslutar aktivt en TCP-session genom att skicka ett RST-paket till initiativtagaren.
• Disable inaktiverar just denna signatur; motsvarande detektering försvinner.
• Bypass session undantar resten av sessionen från fortsatt kontroll. Trafiken kan därmed hamna i FastPath eller Offload och undantas från mer inspektion än avsett.

Paketåtgärder gäller per paket. Sessionsåtgärder inspekterar fram till den första träffen och påverkar därefter hela anslutningen. Varje avvikelse från Recommended ska därför motiveras med signatur, policy, brandväggsregel, ansvarig person och granskningsdatum.

Välj IPS-policyn i brandväggsregeln

1. Öppna Rules and policies > Firewall rules.
2. Redigera den regel vars Rule ID har verifierats i pilotflödet.
3. Välj IPS-policyn under Other security features vid Detect and prevent exploits (IPS).
4. Aktivera Log firewall traffic, spara och skapa en ny session för testet.

Global aktivering räcker inte. Om trafiken först matchar en annan regel utan IPS-policy ger en efterföljande regel inget skydd. Sophos Firewall-regeln matchar inte: kontrollera orsakerna hjälper dig att felsöka regelmatchningen.

Brandväggsregler begränsar vilken trafik som över huvud taget tillåts. IPS identifierar attackmönster i det synliga dataflödet. Web Protection styr webbinnehåll och kategorier, Application Control klassificerar applikationer, TLS Inspection synliggör krypterat innehåll vid behov och Zero-Day Protection undersöker misstänkta filer. Threat Feeds, till exempel underhållna flöden från Cybora, blockerar som ett komplement kända skadliga IP-adresser, domäner eller URL:er. Modulerna kompletterar varandra; ingen av dem ersätter en snäv brandväggsregel, patchhantering eller rätt policyval.

Verifiera ett kontrollerat pilottest

Fastställ testperiod, ansvarig person, jämförelseunderlag och avbrottskriterier innan testet börjar. Baslinjen omfattar mönstrens tidsstämpel, Firewall Rule ID, tidigare och ny IPS-policy, kända undantag, CPU- och minnesutnyttjande samt minst en oförändrad kontrollanslutning. För VoIP, ERP, industriella protokoll, VPN och äldre applikationer kräver testet ett underhållsfönster.

1. Verifiera policytilldelningen: Skapa en ny session och kontrollera förväntat Firewall Rule ID och IPS Policy ID i Packet Capture eller brandväggsloggen. Det bevisar tilldelningen, men ännu ingen signaturträff. Den gemensamma processen för Log Viewer och Packet Capture kan tillämpas direkt på testanslutningen.
2. Testa verkliga arbetsflöden: Genomför inloggning, filöverföring, uppdateringar, API-anrop och långvariga sessioner. Ping ersätter inte dessa tester.
3. Utvärdera händelser: Spara signatur-ID, signaturnamn, policy, brandväggsregel, källa, mål, portar och faktisk åtgärd vid en träff. Skapa inte ett verkligt angrepp enbart för funktionstestet. Använd den kontrollerade piloten med en egen signatur för en deterministisk och ofarlig träff.
4. Jämför kontrollanslutningen: En tillåten anslutning inom samma tillämpningsområde ska fortfarande visa förväntad regel och applikation. Om paket försvinner hjälper en separat analys av kasserade paket till att avgränsa orsaken.
5. Utöka först därefter: Lägg endast till fler värdar eller regler om det inte finns några oförklarade blockeringar och de fördefinierade gränserna för belastning, latens och applikationer hålls.

Ett lyckat resultat innebär inte att en attacksignatur måste ha utlösts. Det avgörande är att policytilldelningen har verifierats, att test- och kontrollflöden fungerar, att inga oförklarade blockeringar finns och att resursvärdena är acceptabla. Om en kritisk verksamhetsprocess slutar fungera, en oförklarad blockering uppstår eller en överenskommen prestandagräns överskrids ska de dokumenterade ursprungsvärdena för policytilldelning och regelloggning återställas. En särskilt skapad pilotpolicy tas bort först när den inte längre är tilldelad någon regel och dess undantag har dokumenterats. Om IPS var globalt avstängt före pilottestet återställs även detta ursprungsläge först efter kontroll av vilka andra brandväggsregler som därmed förlorar sitt IPS-skydd.

Tolka loggar, Packet Capture och rapporter korrekt

Verktygen besvarar olika frågor:

• Brandväggslogg: ips_policy_id visar vilken policy som var kopplad till flödet. Det är användbart även utan en signaturträff.
• IPS-händelse: log_type=IDP, signature_id, signature_msg, idp_policy_id, fw_rule_id, classification och log_subtype kopplar samman signatur, policy, regel och resultat. detection_severity i loggen är inte automatiskt samma presentation som den kategoriska Severity-nivån i policyn.
• Packet Capture: visar bland annat Firewall Rule ID, NAT ID och IPS Policy ID i paketflödet.
• ips.log: ger mer detaljerad information om beslut från IPS, DPI, Application Control och Active Threat Response.
• sig_upgrade.log och sigmigration.log: visar signaturuppdatering respektive signaturmigrering.
• Reports > Network & threats > Intrusion attacks: lämpar sig för historisk analys; Log Viewer är fortfarande bättre för enskilda aktuella händelser.

Sophos Firewall-tjänster och loggar beskriver hur fler loggfiler och tjänster hör ihop. När flera skyddsmoduler är aktiva jämför du samma tidpunkt i loggarna för brandvägg, IPS, Web, Application Control och SSL/TLS Inspection. En brandväggsregel kan tillåta trafik som sedan blockeras av en efterföljande modul.

Kontrollera prestanda under jämförbar belastning

Hur mycket resurser IPS kräver beror på modell, trafik, signaturer, TLS Inspection, Application Control, VPN och paketstorlek. Före och efter aktiveringen registrerar du under jämförbar belastning CPU, minne, genomströmning, latens, omsändningar i kritiska applikationer samt volymen för IPS/DPI och Syslog.

Att kortvarigt stänga av IPS bevisar inte orsaken. Reproducerbara jämförelser kräver korrekt tolkade prestandadata för brandväggen och ett kontrollerat iPerf-test.

Utred falska positiva resultat i stället för att bara tillåta dem

En IPS-träff kan vara ett falskt positivt resultat, en oväntad applikation eller ett verkligt försök att utnyttja en sårbarhet. Spara först signatur-ID och signaturnamn, källa, mål, tjänst, brandväggsregel, tidpunkt, frekvens, berörd applikation och patchnivå. Fatta därefter beslutet enligt följande:

1. Reproducera det legitima flödet och bekräfta att det är just denna SID som utlöser träffen.
2. Kontrollera patchnivå, leverantörsinformation och åtkomlighet för det skyddade systemet.
3. Bedöm risken om träffen tillåts. Skapa inget permanent undantag om resultatet är oklart eller inte kan reproduceras.
4. Välj den snävaste reversibla åtgärden: patcha helst eller avgränsa dataflödet ytterligare; sätt annars en enskild SID till Allow packet under begränsad tid i en policy som endast används där. Disable och Bypass session tar bort mer skydd och kräver en starkare motivering.
5. Testa det legitima positiva flödet och ett negativt flöde eller kontrollflöde på nytt.
6. Dokumentera undantag, ansvarig person och granskningsdatum och gör en ny bedömning efter uppdateringar av applikation, mönster, firmware eller system.

Om många signaturer stör samma applikation är en egen snäv policy eller bättre segmentering en renare lösning än en samling permanenta globala undantag. Att stänga av IPS globalt är inte en lämplig återställning för en enskild SID.

Felsökning efter symtom

Inga IPS-händelser visas

Skapa först en ny session och kontrollera Firewall Rule ID och ips_policy_id i brandväggsloggen eller Packet Capture. Om Policy ID saknas matchar flödet en annan regel, eller också har den valda regeln ingen tilldelad IPS-policy. Om policyn kan verifieras men ingen signaturträff finns kan det vara korrekt för ofarlig trafik. Använd en snävt avgränsad egen signatur i en isolerad pilot för ett reproducerbart bevis, inte ett verkligt sårbarhetsangrepp.

Händelsen finns, men trafiken blockeras inte

Kontrollera signature_id, policyn och log_subtype i IPS-händelsen. Kontrollera därefter den första matchande policyregeln och dess faktiska åtgärd. Allow packet, Disable och Bypass session kan förhindra en förväntad blockering; en bred överordnad regel kan åsidosätta den specifika regeln. Testa en ny session efter varje ändring.

IPS-signaturer saknas eller mönsteruppdateringen misslyckas

Kontrollera licensstatusen, det globala IPS-reglaget och Backup & firmware > Pattern updates tillsammans. Failed eller aktuella Application Signatures bevisar inte att IPS-uppdateringen lyckades. sig_upgrade.log visar uppdateringsförloppet; vid licensproblem ger licensing.log ytterligare sammanhang. I ett HA-kluster uppdaterar Primary IPS-mönstren och synkroniserar dem automatiskt till Auxiliary.

IPS-tjänsten har status DEAD

Kontrollera och dokumentera statusen för tjänsten IPS under System services > Services. Om Sophos Support dessutom begär utdata från skalet för en viss nod leder 5 Device Management > 3 Advanced Shell till följande kontroll som inte gör några ändringar:

service -S | grep -i ips

Den relevanta raden är den vars första tjänstenamn är exakt ips; ipsec-monitor avses inte. Detta Advanced Shell-kommando ingår inte i den publicerade Known Issue-processen och används endast för diagnostik i samråd med supporten. I ett HA-kluster måste den begärda statusen samlas in separat på varje berörd nod.

I SFOS 22.0 GA och senare kan nödvändiga konfigurationsdata för Web Policy i sällsynta fall saknas. Tjänsten för Web Policy startar då inte, IPS kan inte initiera sin policy och stannar i läget DEAD; även mönsteruppdateringarna misslyckas. I ett HA-kluster kan varje nod drabbas oberoende av de andra.

Spara SFOS-version, tidpunkt, nod, tjänstestatus, ips.log och sig_upgrade.log och kontakta Sophos Support med hänvisning till NC-181971. Enbart statusen bevisar inte denna orsak. Sophos anger fortfarande ingen korrigerad version i den aktuella listan över Known Issues och tillhandahåller en tillfällig lösning via supporten. Upprepade omstarter eller odokumenterade reparationskommandon är inte en tillförlitlig diagnostikmetod.

Använd endast det fullständiga signaturpaketet i styrkta specialfall

Vid en mönsteruppdatering kan SFOS hämta det fullständiga IPS-signaturpaketet i stället för ett delpaket. Alternativet gäller endast enheter med minst 32 GB RAM och kan enligt Sophos påverka prestandan. Det aktiverar inte IPS och tilldelar inte någon policy till en brandväggsregel.

Ett motiverat användningsfall är en signatur som Sophos Support uttryckligen har identifierat och som saknas i delpaketet. Aktivera inte alternativet i förebyggande syfte enbart för att fler signaturer låter bättre. Läs först av det aktuella läget i Device Console:

system ips full-signature-pack show

Hjälpen i Device Console anger inget standardvärde. När RAM-gränsen och det konkreta behovet har bekräftats kan den fullständiga hämtningen aktiveras:

system ips full-signature-pack enable

Efter nästa mönsteruppdatering kontrollerar du mönstrens tidsstämpel, sig_upgrade.log, den förväntade signaturen, IPS-status, CPU, RAM och berörd trafik. Om den förväntade nyttan uteblir eller driften försämras återställer du det läge som lästes av tidigare. Om läget före testet var disable återställer du det så här:

system ips full-signature-pack disable

PQC-detektering från och med SFOS 22.0 MR2

SFOS 22.0 MR2 kan identifiera och styra rena och hybrida postkvantmetoder för nyckelutbyte som baseras på ML-KEM. De nya IPS-mönstren är avstängda som standard eftersom PQC inte automatiskt är misstänkt. Den som behöver analysera dessa anslutningar bör först använda en egen pilotpolicy med Allow packet och loggning. Först när det finns ett definierat användningsfall och stabila positiva tester och kontrolltester är Drop session eller Reset motiverat. Bakgrunden beskrivs i Sophos Firewall v22 MR2: PQC-kontroll.

FAQ