Konfigurera och testa IPS säkert på Sophos Firewall

Intrusion Prevention System (IPS) kontrollerar trafiken efter kända attackmönster, exploits och avvikande protokollegenskaper. För att IPS faktiskt ska skydda måste det vara globalt aktiverat och en lämplig IPS-policy tilldelad till den brandväggsregel som behandlar trafiken.

Den striktaste policyn bör inte tillämpas generellt på alla regler. En policy som passar dataflödet, en pilotdrift och fullständiga loggar förhindrar onödiga avbrott utan att skyddseffekten minskas förhastat.

Aktivera IPS och tilldela det till en brandväggsregel

Förutsättningar

Följande villkor måste vara uppfyllda före konfigurationen:

• aktiv Network Protection-prenumeration eller testlicens
• tillgängliga IPS-signaturer och fungerande mönsteruppdateringar
• en känd brandväggsregel som faktiskt behandlar trafiken som ska kontrolleras
• aktiverad regelloggning och en process för falska positiva träffar

IPS Protection är inaktiverat som standard. På en brandvägg med internetanslutning uppdateras IPS-signaturerna endast med en giltig licens och aktiverat IPS. Licensierade Air Gap-brandväggar är det dokumenterade undantaget: de kan få IPS-signaturer via den avsedda uppdateringsprocessen även när IPS är inaktiverat. Detaljer finns i Air Gap-licensiering och mönsteruppdateringar.

När Network Protection löper ut kan IPS-reglaget fortfarande se aktivt ut trots att brandväggen inte längre upprätthåller IPS-skyddet. Om IPS inaktiveras manuellt uppdateras inga onlinesignaturer längre och det går inte längre att konfigurera policyer eller egna signaturer. Efter 30 dagar tar brandväggen bort IPS-signaturerna och reglerna.

När en testlicens löper ut inaktiveras IPS automatiskt. Under de följande 30 dagarna upprätthåller det inget skydd, hämtar inga signaturer och tillåter ingen policykonfiguration. Därefter tas signaturer och regler bort. Den som vill behålla konfigurationen måste exportera den eller skapa en säkerhetskopia i förväg.

Aktivera IPS globalt

1. Öppna Protect > Intrusion prevention > IPS policies. Beroende på vy är den förkortade sökvägen Intrusion prevention > IPS policies.
2. Aktivera IPS Protection.
3. Kontrollera licensstatus och mönsteruppdateringar.
4. Vänta tills signaturerna är tillgängliga.
5. Kontrollera befintliga standardpolicyer.
6. Om en egen policy behövs klonar du en lämplig standardpolicy via Add.

Efter aktiveringen bör du inte bara kontrollera reglaget. En aktuell mönsterstatus och den första träffen i loggen visar betydligt bättre om hela skyddskedjan verkligen fungerar.

När Firewall Acceleration eller PKI Acceleration aktiveras eller inaktiveras startas IPS eller DPI Engine om. Sådana ändringar hör hemma i ett underhållsfönster och inte mitt under en pågående felsökning.

Aktivera IPS i brandväggsregeln

1. Öppna Rules and policies > Firewall rules.
2. Redigera den regel som faktiskt matchar trafiken.
3. Aktivera alternativet Detect and prevent exploits (IPS) under Other security features.
4. Välj en IPS-policy som passar trafiken.
5. Aktivera regelloggning, spara och testa med verklig trafik.

Enbart den globala aktiveringen räcker inte. Om trafiken först matchar en annan regel utan IPS-policy ger en senare regel inget skydd. I så fall kan Sophos Firewall-regeln matchar inte: kontrollera orsakerna hjälpa.

För publicerade servrar innebär detta att DNAT, en strikt begränsad brandväggsregel, IPS-policy, loggning och patchhantering måste passa ihop. För interna segment måste du också kontrollera om trafiken över huvud taget går via brandväggen och den förväntade regeln.

Välja rätt IPS-policy

Policyn baseras på källa, mål och applikation:

• Klienter till internet: använd en klient- eller LAN-to-WAN-policy och samordna den med Web Protection, Application Control och vid behov TLS Inspection. Webbläsare, uppdateringstjänster och verksamhetsapplikationer ska ingå i piloten. För misstänkta nedladdningar kompletterar Zero-Day Protection signaturkontrollen.
• Internet till en server via DNAT: anpassa en server- eller webbserverpolicy strikt till målsystemet och de publicerade portarna. Skyddet gäller de tjänster som faktiskt erbjuds och inte generellt all serverteknik. NAT- och regelkontexten förklaras i Publicera en server via DNAT. Kända skadliga IP-adresser, domäner eller webbadresser kan dessutom blockeras med Threat Feeds.
• Site-to-Site- eller Remote Access-VPN: välj policy efter käll- och målsystem. Produktionsapplikationer, MTU/MSS, latens och genomströmning måste testas över den verkliga VPN-sträckan.
• VoIP: testa SIP/RTP med en särskild policy och en återställningsplan. En aggressiv klient- eller serverpolicy kan störa signaleringen eller medieflödet.
• Nät för hantering, säkerhetskopiering och infrastruktur: skydda dem restriktivt utan att avbryta nödvändiga anslutningar för administration, övervakning eller säkerhetskopiering. Här är strikt avgränsade regler oftast mer värdefulla än ett särskilt brett signatururval.

Även vid segmentgränser som klient till server eller VPN till server försvårar IPS lateral rörelse efter ett intrång. Det är dock bara ett komplement till korrekta brandväggsregler. De separata inställningarna för skydd mot spoofing och DoS hanterar enkla spoofing- och floodingmönster.

Skapa en egen policy från en mall

Via Add går det att klona en standardpolicy och sedan anpassa den specifikt. Det är mer överskådligt än en fritt sammansatt signatursamling och bibehåller ett rimligt grundskydd. Namnet bör visa syfte och dataflöde, till exempel IPS-Pilot-LAN eller IPS-DNAT-Webserver.

Policyreglerna utvärderas uppifrån och ned. En bred regel för alla serversignaturer kan därför åsidosätta en särskild regel längre ned för ett enskilt SID. Specifika anpassningar ska placeras ovanför de mer allmänna reglerna. Därefter måste en passande träff i loggen bekräfta att den förväntade åtgärden tillämpas.

Filtrera och bedöma signaturer

Signaturer kan filtreras efter Category, Severity, Platform och Target. Det går även att skapa egna IPS-signaturer, men de bör endast användas för ett tydligt beskrivet detekteringsfall och granskas på nytt senare. Följande uppgifter är avgörande för loggar, ärenden och undantag:

• SID: unikt signatur-ID
• Category: tekniskt område, till exempel DNS, webbläsare eller skadlig kod
• Severity: allvarlighetsgrad
• Platform: berörd plattform, till exempel Windows eller Linux
• Target: klient- eller serversignatur
• Recommended action: åtgärd som rekommenderas av Sophos

Sophos klassificerar CVSS 9 till 10 som Critical, 7 till under 9 som Major, 4 till under 7 som Moderate och 1 till under 4 eller överordnade signaturer som Minor. Warning markerar avvikande trafik som en varning. Allvarlighetsgraden avgör dock inte ensam bedömningen: en Major-signatur på en exponerad server ska bedömas annorlunda än en Warning-träff i ett testnät. Målsystem, åtkomlighet, patchnivå och den faktiska åtgärden måste alltid ingå i bedömningen.

Förstå IPS-åtgärder

En policyregel kan åsidosätta den åtgärd som Sophos rekommenderar:

• Recommended: en lämplig utgångspunkt för produktionsregler; Sophos aktuella rekommendation tillämpas
• Allow packet: loggar träffen men tillåter paketet; lämpar sig för en pilot men förhindrar inte den identifierade attacken
• Drop packet: kastar endast det berörda paketet; applikationen kan fortsätta fungera eller reagera med fel
• Drop session: avslutar hela sessionen efter en träff; ett kraftigare ingrepp vid en bekräftad attackrisk
• Reset: återställer TCP-sessionen aktivt; användaren eller applikationen ser ett abrupt avbrott
• Disable: inaktiverar signaturen; skyddet mot just denna detektering upphör
• Bypass session: slutar kontrollera återstoden av sessionen; trafiken kan då hamna i FastPath eller Offload och därmed undantas från kontrollen i större utsträckning än avsett

Paketåtgärder gäller per paket. Sessionsåtgärder kontrollerar fram till den första träffen och påverkar därefter hela anslutningen. Avvikelser från Recommended kräver därför en anteckning med signatur, policy, brandväggsregel, orsak, ansvarig och granskningsdatum.

PQC-mönster från SFOS 22.0 MR2

SFOS 22.0 MR2 identifierar rena och hybrida ML-KEM-förhandlingar, däribland ML-KEM-512, -768, -1024 och X25519 med ML-KEM-768. De nya PQC-mönstren är inställda på Disabled som standard eftersom PQC inte automatiskt är misstänkt. Den som vill utvärdera dem bör först testa en egen pilotpolicy med Allow packet och loggning och använda Drop session eller Reset först efter analysen. Bakgrunden förklaras i Sophos Firewall v22 MR2: PQC-kontroll.

Införa och testa kontrollerat

1. Välj en pilotregel: börja med ett känt testnät för klienter eller en enskild DNAT-regel. Den förväntade trafiken och den ansvariga personen måste vara tydligt definierade före testet.
2. Testa verkliga applikationer: kontrollera inloggning, filöverföring, uppdateringar, API:er och långvariga sessioner. Ett kort pingtest bevisar inte att applikationen fungerar stabilt med IPS.
3. Utvärdera träffar: kontrollera källa, mål, tjänst, brandväggsregel, signatur, SID, Severity, åtgärd och tidpunkt i Log viewer. Verktygen nedan ger den tekniska kontexten.
4. Utöka stegvis: inkludera fler regler först efter stabila tester. VoIP, ERP, industriprotokoll, VPN och äldre applikationer kräver ett testfönster och en återställningsplan.

För analysen hjälper Tjänster och loggar, gemensam användning av Log Viewer och Packet Capture samt analys av kastade paket.

Verktygen besvarar olika frågor:

• ips.log: djupare information om beslut från IPS, DPI och Application Control
• Packet Capture: paketflöde, riktning, Firewall Rule ID, NAT ID och IPS Policy ID
• Regeltest: vilken brandväggsregel som faktiskt behandlar trafiken
• Syslog eller Central Reporting: längre lagring och korrelation

När flera skyddsmoduler är aktiva måste tidpunkten jämföras mellan 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.

Jämföra prestanda

Hur mycket resurser IPS behöver varierar beroende på modell, trafik, signaturer, TLS Inspection, Application Control, VPN och paketstorlek. Därför bör följande värden registreras före och efter aktiveringen under jämförbar belastning:

• processor- och minnesbelastning
• genomströmning på de berörda gränssnitten
• latens och omsändningar för kritiska applikationer
• IPS-/DPI- och Syslog-volym
• meddelanden från användare och applikationer

Att bara inaktivera IPS en kort stund bevisar ännu inte orsaken. Reproducerbara jämförelser kan göras med korrekt tolkade prestandamätvärden för brandväggen och ett kontrollerat iPerf-test.

Hantera falska positiva träffar och undantag

Om legitim trafik blockeras får IPS inte reflexmässigt inaktiveras globalt. En träff kan vara en falsk positiv träff, en oväntad applikation eller ett verkligt försök att utnyttja en sårbarhet. Samla först in:

• signatur-ID och signaturnamn
• källa, mål, tjänst och matchande brandväggsregel
• tidpunkt, frekvens och berörd applikation
• målsystemets patchnivå
• relevant loggutdrag eller Packet Capture

Konkreta frågor hjälper: uppstår felet bara för en värd eller port? Går det att reproducera? Försvinner det efter en patch? Pekar samma SID upprepade gånger på samma mål? Först dessa fakta motiverar en ändring av policyn.

Begränsa därefter ändringen så snävt som möjligt:

• anpassa en enskild signatur i stället för en hel kategori
• använd en egen IPS-policy endast för den berörda brandväggsregeln
• kontrollera policyreglernas ordning
• begränsa källa, mål och tjänst striktare i brandväggsregeln
• dokumentera orsak, ansvarig och granskningsdatum
• kontrollera efter ändringen att endast den förväntade trafiken berörs

Ett tillfälligt undantag är oftast bättre än en permanent inaktivering. Efter en uppdatering av applikation, firmware eller system måste det kontrolleras på nytt. Om många signaturer stör samma applikation är en egen policy eller bättre segmentering en lämpligare lösning än ett stort globalt undantag.

Felsökning och drift

IPS har ingen effekt

Kontrollera i följande ordning:

1. Är Network Protection eller testlicensen giltig?
2. Är IPS Protection globalt aktiverat?
3. Är IPS-mönstren aktuella? I ett HA-kluster uppdateras de på Primary och synkroniseras automatiskt till Auxiliary.
4. Matchar trafiken den förväntade brandväggsregeln med IPS-policy och loggning?
5. Åsidosätter en bred policyregel en specifik regel?
6. Innehåller policyn omotiverade åtgärder som Allow packet, Disable eller Bypass session?
7. Passar policyn för klient-, server-, VPN- eller VoIP-trafik?
8. Har verklig trafik använts för att kontrollera om Log Viewer och ips.log visar passande händelser?

Undantag utan ansvarig eller granskningsdatum betraktas som öppna och ska tas upp vid nästa driftgranskning.

IPS-tjänsten har statusen DEAD

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

I CLI leder 5 Device Management > 3 Advanced Shell till det skal som behövs. Följande read-only-kommando visar alla tjänsterader med ips i namnet:

service -S | grep -i ips

Endast raden vars första tjänstenamn är exakt ips är relevant. ipsec-monitor avses inte. I ett HA-kluster måste varje berörd nod kontrolleras separat.

Om tjänsten har statusen DEAD bör du spara SFOS-versionen, tidpunkten, noden, den fullständiga statusutmatningen samt ips.log och sig_upgrade.log och kontakta Sophos Support med hänvisning till NC-181971. Kommandot i sig bevisar inte att detta fel föreligger. Sophos publicerar fortfarande ingen korrigerad version och tillhandahåller endast en workaround via supporten. Upprepade omstartsförsök eller odokumenterade reparationskommandon är ingen lämplig lösning.

FAQ