Hoppa till innehållet
Avanet

Konfigurera och testa IPS på Sophos Firewall säkert

Intrusion Prevention System (IPS) är en av de viktigaste skyddsfunktionerna i Sophos Firewall. IPS granskar trafik efter kända attackmönster, exploits och avvikande protokollmönster. När funktionen används korrekt ger den klienter, servrar, publicerade tjänster och VPN-förbindelser ett extra skydd utöver brandväggsregler, Web Protection, Application Control och TLS Inspection.

I praktiken är IPS däremot inte en funktion som bör aktiveras maximalt överallt. En felaktig eller alltför bred IPS-policy kan stoppa legitim trafik, störa VoIP, förbruka resurser eller skapa falsklarm. Därför bör IPS aktiveras planerat, väljas utifrån varje regel och därefter kontrolleras med loggar och tester.

När IPS är lämpligt

IPS är särskilt värdefullt där trafiken innebär en högre risk eller där kända exploits ska blockeras tidigt.

Typiska användningsområden:

  • Klientnät med internetåtkomst
  • Servernät och DMZ
  • DNAT-regler till interna servrar
  • Site-to-site-VPN-trafik mellan platser
  • Remote Access-trafik när interna system nås efter VPN-anslutningen
  • VoIP, men endast med försiktigt policyval och tester
  • Särskilt kritiska segment, till exempel nät för administration, säkerhetskopiering eller infrastruktur

För publicerade servrar bör IPS alltid bedömas tillsammans med korrekt NAT, snäva brandväggsregler, loggning och patchhantering. Artikeln Publicera en server med DNAT på Sophos Firewall beskriver sammanhanget för NAT och brandväggsregler. För den grundläggande regelstrukturen passar Förstå och konfigurera regler på Sophos Firewall korrekt.

Förutsättningar

IPS fungerar endast när de nödvändiga förutsättningarna är uppfyllda.

Kontrollera följande före utrullningen:

  • Det finns en aktiv Network Protection-prenumeration eller testlicens.
  • IPS Protection är aktiverat under Intrusion prevention > IPS policies.
  • Mönsteruppdateringarna fungerar: för internetanslutna brandväggar via Sophos uppdateringstjänster och för licensierade air-gap-brandväggar via den avsedda air-gap-processen.
  • Brandväggsreglerna innehåller lämpliga IPS-policyer under Detect and prevent exploits (IPS).
  • Loggning är aktiverad för berörda regler och loggtyper.
  • Det finns en process för falska positiva träffar, undantag och policyändringar.
  • För publicerade tjänster och segmentgränser är det tydligt vilken brandväggsregel som faktiskt hanterar trafiken.

När Network Protection-prenumerationen löper ut kan IPS-reglaget fortfarande se aktivt ut, trots att IPS inte längre tillämpas. Om IPS stängs av manuellt stoppas signaturuppdateringarna och policykonfigurationen blir inte längre tillgänglig. Efter 30 dagar raderas IPS-signaturer och regler. När en testlicens löper ut stängs IPS av automatiskt. En säkerhetskopia eller export av IPS-konfigurationen måste därför göras inom 30 dagar.

Observera: IPS är beroende av licensen och uppdateringarna. En brandväggsregel med en vald IPS-policy innebär inte automatiskt att trafiken verkligen skyddas av IPS. Licensstatus, global IPS-aktivering, signaturer och loggar måste kontrolleras.

Aktivera IPS globalt

I aktuella SFOS-versioner finns den globala aktiveringen under Protect > Intrusion prevention > IPS policies. I vissa vyer visas den förkortade menysökvägen Intrusion prevention > IPS policies.

  1. Öppna Protect > Intrusion prevention > IPS policies.
  2. Aktivera IPS Protection.
  3. Kontrollera licensinformationen.
  4. Vänta tills signaturerna är tillgängliga.
  5. Kontrollera befintliga standardpolicyer.
  6. Klona vid behov en befintlig policy som grund för en egen policy.

En egen policy skapas via Add. Ange ett tydligt namn och klona en befintlig policy som utgångspunkt. Anpassa därefter endast de regler som verkligen behövs. Det är lättare att följa upp än en helt fristående samling enskilda signaturer där syftet senare kan vara oklart.

När Firewall Acceleration eller PKI Acceleration aktiveras eller inaktiveras startas IPS-tjänsten respektive DPI Engine om. Sådana ändringar bör därför inte göras under pågående felsökning i produktion eller i ett kort underhållsfönster utan en plan.

Välj rätt IPS-policy

IPS-policyer ska passa trafiken. Den striktaste policyn är inte automatiskt den bästa.

  • Klienter till internet: Vanligtvis passar en klient- eller LAN-to-WAN-policy. Web, Application Control och TLS Inspection bör också vägas in.
  • Internet till en intern server via DNAT: Välj en server- eller webbserverpolicy och följ målsystem, portar och falska positiva träffar noggrant.
  • VPN mellan platser: Välj policy efter käll- och målsystem. Testa prestanda, MTU/MSS och applikationer.
  • VoIP: Arbeta mycket försiktigt och specifikt. SIP/RTP får inte brytas av alltför aggressiva signaturer.
  • Administrationsnät: Skydda dem riktat och restriktivt. Administratörsåtkomst, övervakning och säkerhetskopieringstrafik måste testas.

IPS är också användbart vid segmentgränser: klient till server, VPN till server samt administration till infrastruktur. Det försvårar lateral förflyttning efter att ett första system har komprometterats. Brandväggsreglernas ordning är fortfarande avgörande. IPS skyddar endast trafik som faktiskt passerar en regel med en vald IPS-policy.

En egen IPS-policy är lämplig när en standardpolicy är för bred eller när bara vissa signaturer behöver en anpassad åtgärd. Signaturer bör dock inte stängas av utan analys. Först måste det vara klart vilken trafik som berörs, vilken signatur som utlöstes och om det verkligen rör sig om en falsk positiv träff.

Bygg egna IPS-policyer på ett kontrollerat sätt

Egna IPS-policyer bör klonas från en befintlig policy och sedan anpassas målinriktat. Reglerna i en IPS-policy innehåller signaturer och en åtgärd. Brandväggen utvärderar reglerna uppifrån och ned. En alltför bred regel ovanför en specifik regel kan därför åsidosätta det avsedda beteendet.

När en regel läggs till i en IPS-policy väljs signaturer. De kan filtreras efter Category, Severity, Platform och Target. I specialfall går det att använda egna IPS-signaturer. Det bör endast göras när detekteringsfallet är tydligt beskrivet och policyn senare granskas på nytt.

Följande fält är särskilt viktiga för signaturer:

  • SID: unikt signatur-ID för loggar, ärenden och undantag.
  • Category: tekniskt område, till exempel webbläsare, operativsystem, DNS, RPC eller skadlig kod.
  • Severity: hotets allvarlighetsgrad.
  • Platform: målplattform, till exempel Windows, Linux eller webbläsarrelaterade komponenter.
  • Target: klient- eller serverinriktad signatur.
  • Recommended action: den standardåtgärd som Sophos rekommenderar.

Severity bör inte tolkas på känsla. Sophos kopplar i grova drag Critical till CVSS 9–10, Major till 7 upp till men inte 9, Moderate till 4 upp till men inte 7 och Minor till 1 upp till men inte 4 eller till mindre kritiska signaturer. Warning avser avvikande trafik och behandlas som en varning. För policyn innebär det att en Major-signatur på en exponerad server måste bedömas annorlunda än en Warning-träff i ett testnät.

Åtgärden i en policyregel kan åsidosätta signaturens rekommenderade åtgärd. Det är användbart men riskfyllt. Ett generellt Allow packet, Disable eller Bypass session kan ta bort skydd utan att det märks direkt i den dagliga driften.

Paketbaserade åtgärder granskar varje paket. Sessionsbaserade åtgärder granskar fram till den första träffen och påverkar därefter sessionen. Drop session, Reset och Bypass session är därför större ingrepp än att tillåta eller kassera ett enskilt paket.

Praktisk användning av åtgärderna:

  • Recommended: standard för de flesta produktionsregler. Beteendet beror på signaturen.
  • Allow packet: observation utan blockering, till exempel under pilotfasen. Ett verkligt angrepp skulle inte stoppas.
  • Drop packet: kasserar enskilda paket. Det kan störa applikationer.
  • Drop session: avslutar sessionen när ett angrepp ska stoppas. Det är ett större ingrepp i produktionstrafiken.
  • Reset: återställer TCP-sessionen aktivt. Användaren eller applikationen märker ett abrupt avbrott.
  • Disable: stänger av signaturen. Skyddet för den signaturen försvinner.
  • Bypass session: slutar granska resten av sessionen. Beroende på arkitekturen kan sådan trafik gå via FastPath eller Offload. Det kan undanta mer trafik från granskning än väntat.

För produktionspolicyer är det därför lämpligt med en kort ändringsnotering: vilken signatur ändrades, varför, i vilken policy, för vilken brandväggsregel och när ändringen senast ska granskas igen.

Använd IPS i brandväggsregler

IPS aktiveras inte enbart globalt. Policyn måste också användas i rätt brandväggsregel.

  1. Öppna Rules and policies > Firewall rules.
  2. Redigera eller skapa den aktuella regeln.
  3. Aktivera Detect and prevent exploits (IPS) under Other security features.
  4. Välj en lämplig IPS-policy.
  5. Aktivera regelloggning.
  6. Spara ändringen.
  7. Testa trafiken under kontrollerade former.

Om brandväggsregeln saknar en IPS-policy har den globala IPS-aktiveringen ingen effekt på den trafiken. När flera regler överlappar är ordningen avgörande. Om trafiken träffar en regel utan IPS hjälper inte IPS-policyn i en senare regel. I sådana fall passar Sophos Firewall-regeln matchar inte: kontrollera orsakerna.

Utrullning i produktionsmiljöer

IPS bör införas stegvis.

1. Börja med pilotregler

Välj först en liten, välkänd regel, till exempel ett klienttestnät eller en enskild DNAT-regel. Kontrollera därefter loggarna och testa med verkliga applikationer.

2. Utvärdera träffar

Filtrera efter IPS-händelser i Log viewer. Källa, mål, tjänst, regel, signatur, SID, Severity, åtgärd och tidpunkt är viktiga. Om flera skyddsmoduler är inblandade måste loggar för Web, Application Control, SSL/TLS Inspection och brandväggen bedömas tillsammans.

3. Avgränsa falska positiva träffar

Om legitim trafik blockeras bör IPS inte omedelbart stängas av globalt. Gör i stället en avgränsad analys:

  • Vilken signatur utlöstes?
  • Vilken applikation eller tjänst påverkades?
  • Påverkas en värd, ett nät eller bara en port?
  • Är målsystemet uppdaterat med aktuella patchar?
  • Går det att använda en snävare brandväggsregel?
  • Räcker en anpassad IPS-policy i stället för ett globalt undantag?

4. Utöka stegvis

Först när pilotregeln fungerar stabilt bör IPS rullas ut till fler regler. Särskilt VoIP, ERP-system, industriprotokoll, VPN-förbindelser och äldre applikationer kräver testfönster och en återställningsplan.

Kontrollera undantag och signaturändringar

IPS-undantag är säkerhetsbeslut. Om en signatur stör legitim trafik kan en justering behövas. Hela IPS-policyn bör ändå inte försvagas reflexmässigt, och IPS bör inte stängas av i regeln. Först måste det fastställas om det verkligen är en falsk positiv träff eller om signaturen synliggör en faktisk risk.

Samla minst in följande innan ett undantag skapas:

  • Signatur-ID och signaturnamn: visar vilken detektering som utlöstes.
  • Källa, mål, tjänst och brandväggsregel: avgränsar den berörda trafiken.
  • Tidpunkt och frekvens: skiljer en enstaka händelse från ett återkommande mönster.
  • Applikation eller protokoll: hjälper till att bedöma om trafiken är legitim.
  • Målsystemets patchnivå: minskar risken för att en verklig exploit tillåts.
  • Packet Capture eller loggutdrag: ger underlag före policyändringen.

Om ett undantag behövs bör det göras så snävt som möjligt:

  • stäng av 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 så att breda regler inte åsidosätter specifika regler
  • begränsa källa, mål och tjänst i brandväggsregeln
  • dokumentera undantaget med orsak, ansvarig och granskningsdatum
  • kontrollera efter ändringen att endast den förväntade trafiken påverkas

Ett tillfälligt undantag är ofta bättre än en permanent avstängning. Efter en applikations- eller firmwareuppdatering eller efter att målsystemet har patchats bör undantaget granskas igen. Om många signaturer stör samma applikation är en egen policy eller korrekt segmentering vanligtvis bättre än ett stort globalt undantag.

Loggning och felsökning

IPS-analys kräver flera perspektiv.

  • Log viewer: IPS-träff, signatur, åtgärd, källa, mål och regel.
  • ips.log: mer detaljerad information om beslut från IPS, DPI och Application Control.
  • Packet Capture: paketflöde, rule ID, NAT ID, IPS policy ID och riktning.
  • Regeltest: kontroll av vilken brandväggsregel som faktiskt matchar.
  • Syslog eller Central Reporting: längre lagring och korrelation.

Artikeln Felsökning på Sophos Firewall: tjänster och loggar beskriver ips.log och relaterade loggfiler. För att kombinera Log Viewer och Packet Capture passar Testa en Sophos Firewall-regel med Log Viewer och Packet Capture. Om paket släpps oväntat hjälper Analysera släppta paket på Sophos Firewall.

IPS-tjänsten har status DEAD

I SFOS 22.0 GA och senare kan IPS-tjänsten i sällsynta fall övergå till status DEAD. Den går då inte att starta om, och uppdateringar av IPS-mönster samt beroende Web Policy-tjänster kan sluta fungera. I ett HA-kluster kan varje nod påverkas oberoende av den andra.

Följande read-only-kommando visar alla tjänstrader vars namn innehåller ips i Advanced Shell:

service -S | grep -i ips

Den relevanta raden är den där det första tjänstenamnet är exakt ips; tjänster med liknande namn, till exempel ipsec-monitor, avses inte. Om IPS-tjänsten står på DEAD och mönsteruppdateringarna misslyckas bör SFOS-version, tidpunkt, berörd HA-nod, fullständig statusutdata samt ips.log och sig_upgrade.log sparas innan Sophos Support kontaktas. Kommandot ensamt bevisar inte att det kända problemet NC-181971 föreligger. Sophos anger för närvarande ingen korrigerad version och tillhandahåller bara workaround-lösningen via Support. Upprepade omstartsförsök eller odokumenterade reparationskommandon är därför ingen lämplig lösning.

Beakta prestandan

IPS kräver resurser. Hur mycket belastningen ökar beror på modell, trafik, aktiverade signaturer, TLS Inspection, Application Control, VPN, paketstorlek och genomströmning.

Kontrollera följande före och efter aktiveringen:

  • Processor- och minnesbelastning
  • IPS- och DPI-relaterad belastning
  • Genomströmning på berörda gränssnitt
  • Latens och omsändningar i kritiska applikationer
  • Loggvolym och syslogbelastning
  • Meddelanden från användare eller applikationer efter ändringen

Vid misstänkta genomströmningsproblem bör IPS inte bara stängas av och ärendet avslutas. Gör i stället en jämförelse med en tydlig testmetod, till exempel med hjälp av Tolka prestandadata för Sophos Firewall korrekt och Testa prestandan på Sophos Firewall med iPerf.

Vanliga fel

  • IPS Protection är globalt avstängt.
  • Network Protection har löpt ut eller är inte aktivt.
  • Ingen IPS-policy är vald i brandväggsregeln.
  • Trafiken träffar en annan regel än väntat.
  • En bred IPS-policyregel ligger ovanför en specifik regel och åsidosätter den.
  • Loggning är avstängd i den berörda regeln.
  • En serverpolicy tillämpas på klienttrafik eller tvärtom.
  • VoIP eller specialprotokoll granskas med en aggressiv policy utan pilotfas.
  • Falska positiva träffar hanteras genom global avstängning i stället för en snäv anpassning.
  • Signaturer stängs av utan underlag, ansvarig eller granskningsdatum.
  • Efter att testlicensen har löpt ut kontrolleras inte om signaturer eller policyer fortfarande är tillgängliga.
  • Prestandaproblem jämförs inte med mätvärden före och efter ändringen.

Driftchecklista

  • Network Protection eller testlicens har kontrollerats.
  • IPS Protection har aktiverats under Protect > Intrusion prevention > IPS policies.
  • Signaturer och mönsteruppdateringar har kontrollerats.
  • En lämplig IPS-policy har valts för varje brandväggsregel.
  • Regelloggning har aktiverats.
  • Pilotregeln har testats med verklig trafik.
  • Log viewer och ips.log har kontrollerats.
  • En process för falska positiva träffar har definierats.
  • IPS-undantag är snävt dokumenterade och granskas senare igen.
  • Egna IPS-policyer innehåller inga omotiverade regler med Allow, Disable eller Bypass session.
  • Prestandan har jämförts före och efter aktiveringen.
  • Kritiska undantag är dokumenterade och har ett granskningsdatum.

Relaterade ämnen inom Security Inspection

IPS är bara en del av Security Inspection. Beroende på problemet eller målet för utrullningen kan en annan artikel passa bättre:

På så sätt förblir skyddslogiken begriplig: brandväggsregler begränsar den tillåtna trafiken, IPS granskar trafiken efter attackmönster, Web Protection styr webbinnehåll, TLS Inspection ger bättre insyn i HTTPS och Zero-Day Protection kompletterar granskningen av filer och nedladdningar.

FAQ

Måste IPS aktiveras både globalt och i brandväggsregeln?

Ja. IPS Protection måste vara globalt aktivt under Intrusion prevention > IPS policies. Dessutom behöver den berörda brandväggsregeln en vald IPS-policy under Detect and prevent exploits (IPS).

Vilken licens krävs för IPS på Sophos Firewall?

IPS Protection kräver en aktiv Network Protection-prenumeration eller testlicens. När prenumerationen löper ut kan IPS se aktivt ut men ändå inte längre skydda trafiken.

Bör alltid den striktaste IPS-policyn användas?

Nej. Policyn måste passa trafiken. En alltför strikt policy kan blockera legitima applikationer, störa VoIP eller skapa onödig belastning.

Var visas IPS-träffar?

IPS-händelser visas i Log viewer. För en djupare analys är även ips.log relevant. Packet Capture hjälper till att identifiera paketflödet, regeln och IPS policy ID.

Hur bör falska positiva IPS-träffar hanteras?

Kontrollera först signatur, källa, mål, tjänst, berörd applikation och patchnivå. Anpassa därefter så snävt som möjligt: en egen IPS-policy, en enskild signatur eller en snävare brandväggsregel i stället för global avstängning. Varje undantag behöver en orsak, en ansvarig och ett granskningsdatum.

Vilken IPS-åtgärd bör användas i egna policyer?

För de flesta produktionsregler är Recommended den lämpligaste utgångspunkten. Avvikande åtgärder som Allow packet, Disable eller Bypass session bör endast användas medvetet, dokumenterat och strikt avgränsat, eftersom de åsidosätter signaturens rekommenderade åtgärd.

Ersätter IPS patchhantering?

Nej. IPS kan blockera kända attackmönster men ersätter inte uppdateringar av servrar, klienter, applikationer eller brandväggar. IPS är ett kompletterande skydd, inte ett frikort för opatchade system.