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.

PHP2Shell: kontrollera detektering och uppdateringsstatus separat

För PHP2Shell (CVE-2026-109618 och CVE-2026-109619) beskriver Sophos rådgivning, version 4 från 22 oktober 2026 IPS-signaturer för brandvägg och Endpoint som har funnits sedan detta datum för att upptäcka angreppsförsök. Detta innebär varken en generell garanti för blockering eller ett specifikt WAF-skydd. Berörda PHP-miljöer måste uppdateras oberoende av detta.

Kontrollera på brandväggen att IPS-mönstren har laddats ned korrekt, vilken regel den berörda trafiken faktiskt träffar, dess IPS-policy och signaturens effektiva åtgärd. Diagnosavsnitten nedan förklarar dessa kontroller. Jämför brandväggs- och serverloggar utifrån tidpunkten; utan larm går det inte att bevisa vare sig en installerad säkerhetsuppdatering eller att inget angrepp har skett. En riktig exploateringsförfrågan är inget lämpligt produktionstest.

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 hjälper till med den tekniska avgränsningen; kategorireferensen följer efter konfigurationsflödet.

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

SID är det unika ID:t för en IPS-signatur. Category beskriver dess funktionsgrupp, Severity hotets allvarlighetsgrad och Platform den berörda plattformen, till exempel Microsoft Windows. Target skiljer mellan klient- och serversignaturer; Recommended action anger den avsedda åtgärden vid en träff. Kategorinamnen och beskrivningarna nedan garanterar inte blockering: den policyregel som faktiskt tillämpas avgör åtgärden.

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:

Warning bevisar inte blockering: Hjälpen för Severity beskriver Warning som att den alltid genererar en varning, medan den allmänna regelhjälpen beskriver att den rekommenderade åtgärden kan åsidosättas. Det framgår därför inte tydligt hur dessa uppgifter samverkar för en viss Warning-signatur. Dra inte slutsatsen att trafiken blockeras enbart utifrån Severity-etiketten eller en vald Drop-åtgärd. Kontrollera den faktiska åtgärden i ett kontrollerat pilottest för detta användningsfall och klargör osäkert beteende med Sophos Support före användning i produktion.

• 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.

Skilj DDoS-signaturer från lokala DoS-gränser

DDoS-signaturer finns endast på XGS 5500 och brandväggar med högre kapacitet. Skapa på en modell som stöds en separat policy, till exempel DDoS_Protection, under Intrusion prevention > IPS policies > Add och spara den med Save. Öppna sedan Edit > Add, ange ett regelnamn, välj Select all, skriv ddos i Smart filter och tryck på Enter. Ställ in Action på Drop packet, spara först regeln och sedan policyn med Save. Tilldela policyn under Rules and policies > Firewall rules till den regel som faktiskt matchar trafiken. Kontrollera licensen, den globala IPS-knappen, tillgängliga signaturer och policytilldelningen enligt ovan; modellnamnet ensamt bevisar inte aktiv inspektion.

De lokala DoS settings under Intrusion prevention > DoS & spoof protection är separata och stöder IPv4 och IPv6. Anpassa paket- och bursthastigheterna till den egna trafiken, välj motsvarande Apply Flag och klicka på Apply. När en källa överskrider den aktiverade ICMP/ICMPv6-gränsen per minut kastar brandväggen de överskjutande paketen så länge attacken pågår. Dokumentationsexemplet 1200 paket per minut och källa är inget standardvärde för produktion. DoS- och spoofskydd förklarar mätning, status, undantag och återställning. Om internetförbindelsen redan är mättad krävs skydd hos leverantören eller uppströms; IPS kan inte återvinna den bandbredden. Generera inte en verklig floodattack för funktionstestning.

Kategorireferens

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.

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

Bedöm IPS-konfiguration via XML API säkert

För reproducerbara konfigurationer skiljer XML API mellan två uppgifter: IPSFullSignaturePack styr pakethämtningen, medan IPSPolicy beskriver en policy med signatururval och åtgärder. Inget av dessa objekt ersätter licenskontrollen, det globala IPS-reglaget, tilldelningen till den brandväggsregel som trafiken faktiskt matchar eller verifieringen med ny trafik. Förutsättningarna och pilotprocessen ovan gäller därför även vid automatiserade ändringar. Åtkomst och tolkning av svar beskrivs i Använd XML API säkert.

Fullständigt paket: Status är ingen generell Get-operation

För IPSFullSignaturePack beskriver API-referensen för SFOS-22/23 det obligatoriska skalära fältet Status. Dess värden är exakt, med gemener, enable, disable och show: de första två aktiverar respektive inaktiverar hämtningen av det fullständiga paketet, medan det tredje används för att fråga efter status i detta objekt. Exemplet visar endast enable/disable; det går inte att härleda någon generell Get-operation från detta. API-parametertabellen anger disable som standardvärde, medan hjälpen för Device Console ovan inte anger något standardvärde. Detta ersätter inte avläsning av det faktiska ursprungsläget.

Även via API är alternativet begränsat till enheter med minst 32 GB RAM och ett styrkt behov. Det är varken ett licensreglage eller en policytilldelning. För operationen IPSFullSignaturePack anger referensen status 200 med Operation Successful. och 500 med Operation Fail.. Ett lyckat konfigurationssvar bevisar ännu inte att mönsterhämtningen är slutförd eller att IPS-skyddet är verksamt: genomför de ovan nämnda kontrollerna av signaturer, resurser och trafik efter nästa uppdatering.

Policyer: skilj ärvda regler från eget urval

I konfigurationsexemplet omsluter IPSPolicy fälten Name, Description, Template och RuleList. Kommentaren till Template beskriver följande: om en befintlig policy väljs som mall ärvs alla dess regler och ytterligare angivna regler läggs till; utan mall innehåller policyn endast de angivna reglerna. En kort egen regellista innebär därför inte automatiskt en snäv policy när en mall används. Kontrollera hela den faktiskt sparade listan och ordningsföljden så att ingen ärvd bred regel åsidosätter ett planerat SID-undantag. Exemplet ger ingen garanti för hur en senare uppdatering behandlar regler som inte skickas med.

Varje post Rule i RuleList kopplar samman ett RuleName, RuleType, urvalet och en Action. RuleType skiljer mellan Default Signature och Custom Signature. Urvalsfältet heter i referensen bokstavligen SignaturSelectionType, utan någon bokstav tillagd i efterhand. Det skiljer mellan All Application och Individual Application. Exemplet visar även CategoryList med Category, SeverityList med Severity, PlatformList med Platform, TargetList med Target samt SignatureList med Signature. Filterkriterier avgränsar det tekniska urvalet; enskilda signaturer anges separat. Beskrivningarna för Platform och Target talar om listor efter ID: använd inte visningsetiketter som API-ID:n utan att först kontrollera dem.

För Action visar exemplet textvärdena Allow Packet, Drop Packet, Disable, Drop Session, Reset, Bypass Session och Recommended. Deras effekt förklaras ovan. Parametertabellen anger dessutom 7, men förklarar ingen koppling till en namngiven åtgärd. Gissa inte någon betydelse eller produktionsinställning utifrån detta tal; om valet är oklart, redigera policyn i WebAdmin eller klargör syntaxen med Sophos Support.

Parametertabellen kräver ett skalärt UTF-8-policynamn utan kommatecken och med högst 60 tecken; Description är valfritt. För regler anger den obligatoriska namn med högst 70 tecken samt Rule Type, signatururvalsläge och åtgärd som arrayer med flera värden. Enligt tabellen ignoreras dubblettvärden endast för regelnamn, inte för de andra nämnda arrayerna. Enskilda signaturer och de fyra filterlistorna är valfria tvådimensionella strängarrayer. Dessa tabelluppgifter garanterar varken atomär bearbetning eller att utelämnade urvalsfält förblir oförändrade vid en uppdatering. Säkerhetskopiera hela policyn inklusive ärvda regler, åtgärder, undantag och tilldelningar till brandväggsregler före en ändring; läs därefter av det sparade urvalet och ordningsföljden och verifiera pilottestet med nya sessioner.

Svar: kontrollera operationen och det sparade läget tillsammans

Följande kopplingar finns i båda SFOS-22/23-referenserna. Beteckningarna Message.* förblir dokumentationssymboler vars betydelse inte är klarlagd: de är varken garanterade meddelanden vid körning eller bevis för en viss orsak. Värdena är XML-API-statusvärden, inte automatiskt HTTP-statuskoder.

Särskilt vid 505 efter Add ska du inte anta att policyn har förblivit oförändrad eller dra slutsatsen att motorn ska startas om enbart utifrån symbolen. Vid 502, jämför det befintliga namnet och den önskade policyn i stället för att skapa en andra policy; vid 522, kontrollera det faktiska beståndet. Vid 506, läs av licensen och det globala IPS-läget utan att aktivera IPS som automatisk felhantering. Dessa kontroller avgränsar läget men ersätter inte en analys av det faktiska svaret.

Enligt referensen identifierar Delete policyn via det obligatoriska Name med samma namngränser. Delete-sidan innehåller ingen fullständig struktur för begäran; därför sammanställs ingen körbar borttagningsbegäran utifrån den här. Kontrollera tilldelningar och beroenden före en avsedd borttagning och säkerställ den återställningsväg som behövs. Vid 503, kontrollera särskilt befintliga referenser utan att härleda en fullständig lista över blockerande relationer från symbolen. Efter ett oklart eller misslyckat svar ska du först kontrollera i WebAdmin om policyn fortfarande finns och vilka regler, åtgärder och tilldelningar som faktiskt är sparade. Besluta om ett riktat nytt försök eller återställning av de dokumenterade ursprungsvärdena först när det aktuella läget är klarlagt; svarstabellerna utlovar varken automatisk upprepbarhet eller återställning. Följ även då den centrala säkerhetsprocessen för API.

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