Eigene IPS-Signaturen auf Sophos Firewall erstellen und testen

Eine eigene IPS-Signatur ist sinnvoll, wenn Sophos für ein klar beschriebenes Netzwerk- oder Anwendungsmuster keine passende Signatur liefert. Sie kann beispielsweise einen bekannten Klartext-String, ein ungewöhnliches Protokollmerkmal oder eine präzise Kombination aus Port, Richtung und Payload erkennen.

Die Signatur allein schützt noch nichts. Sie muss in einer IPS Policy verwendet werden, diese Policy muss an der tatsächlich getroffenen Firewallregel hängen und der Datenstrom muss für IPS sichtbar sein. Ein zu breites Muster kann legitimen Traffic blockieren, ein zu enges bleibt ohne Treffer.

Eine neue Signatur zuerst in einer Pilot-IPS-Regel mit Action: Allow packet testen. Auch wenn Recommended action bereits Allow packet lautet, entscheidet die Aktion der IPS-Policy-Regel. Drop packet, Drop session, Reset oder Bypass session verändern produktiven Traffic und gehören erst nach einem reproduzierbaren Positiv- und Negativtest in den Betrieb.

In sechs Schritten zum kontrollierten Pilot

1. Den Erkennungsfall mit Protokoll, Richtung, Port und einem eindeutigen Muster beschreiben.
2. Unter Intrusion prevention > Custom IPS signatures eine Signatur mit enger Regel und Recommended action: Allow packet anlegen.
3. Die Signatur einer eigenen Regel in einer löschbaren IPS Policy hinzufügen und dort Action: Allow packet wählen.
4. Diese IPS Policy nur der vorgesehenen Pilot-Firewallregel zuweisen und dort Log firewall traffic aktivieren.
5. Einen passenden sowie einen absichtlich unpassenden Test erzeugen und Log Viewer, ips.log und Regelmatch vergleichen.
6. Erst nach stabiler Abnahme die Aktion der IPS-Policy-Regel ändern; bei unerwarteten Treffern die vorherige Policy-Zuweisung wiederherstellen.

Ein gespeicherter Eintrag oder ein erfolgreicher Syntaxcheck ist noch kein Funktionsnachweis. Erfolg bedeutet: Der positive Test trifft genau die erwartete Custom Signature und Firewallregel, der negative Test bleibt ohne Treffer und die produktive Anwendung verhält sich unverändert.

Wann eine eigene Signatur passt

Custom Signatures eignen sich für ein stabiles, auf Paket- oder Stream-Ebene sichtbares Merkmal. Das kann ein proprietärer Protokollwert, ein klarer Exploit-Indikator oder ein temporärer Schutz für eine intern bekannte Schwachstelle sein. Der erwartete Datenpfad und die gewünschte Reaktion müssen vor dem Schreiben feststehen.

Für wechselnde IP-Adressen oder Domains sind Hosts, Services und Gruppen, Threat Feeds oder enge Firewallregeln meist besser geeignet. Eine Custom Signature ersetzt zudem weder Patchmanagement noch eine saubere Herstellerregel. Für einen einmaligen Logtreffer ist eine dauerhafte Eigenentwicklung selten verhältnismässig.

Verschlüsselte Nutzdaten sind eine wichtige Grenze. Ein content-Muster im HTTPS-Payload kann IPS nur erkennen, wenn der Inhalt im gewählten Verarbeitungspfad tatsächlich entschlüsselt und für die Engine sichtbar ist. Ohne passende TLS Inspection bleiben normalerweise nur unverschlüsselte oder anderweitig sichtbare Merkmale.

Lizenz und Lebenszyklus vorab prüfen

Eigene Signaturen lassen sich nicht konfigurieren, wenn die IPS-Trial abgelaufen oder IPS Protection unter Intrusion prevention > IPS policies ausgeschaltet ist. Sophos empfiehlt, IPS innerhalb von 30 Tagen wieder einzuschalten, wenn die vorhandenen Custom Signatures erhalten bleiben sollen. Ein Backup oder Export gehört deshalb vor Lizenz-, IPS- oder grösseren Policy-Änderungen zum Rückfallplan.

IPS muss danach global aktiv sein und die verarbeitende Firewallregel benötigt eine IPS Policy. Der vollständige Grundaufbau steht unter Sophos Firewall IPS einrichten und sicher testen. Eine Custom Signature ist eine Ergänzung dieses Datenpfads, kein paralleler Schutzmechanismus.

Die Regelsyntax verständlich eingrenzen

Die Eingabemaske trennt Protocol und Custom rule. In der Regel werden einzelne Schlüsselwörter mit ihren Werten und einem Semikolon kombiniert. Je mehr unabhängige Merkmale zusammenpassen müssen, desto kleiner ist normalerweise das Risiko zufälliger Treffer. Gleichzeitig darf die Signatur nicht so spezifisch werden, dass eine harmlose Protokolländerung sie wirkungslos macht.

Für einen ausschliesslich kontrollierten Klartext-Test kann als Protokoll TCP und als enges Payload-Muster beispielsweise Folgendes verwendet werden:

content:"AVANET-IPS-PILOT"; nocase;

AVANET-IPS-PILOT ist ein bewusst auffälliger Dokumentationswert. Die zugehörige Pilot-Firewallregel wird zusätzlich auf den Testdienst, beispielsweise TCP-Port 8080, begrenzt. Token, Richtung und Port werden durch Werte ersetzt, die im realen, für IPS sichtbaren Datenstrom vorkommen. Dieses Beispiel ist keine universelle Angriffssignatur und sollte nicht unverändert auf breite Produktionsregeln gelegt werden.

Payload und Suchfenster

content sucht eine Zeichen- oder Bytefolge; Binärwerte werden innerhalb von Pipe-Zeichen notiert. nocase ignoriert bei einem Content-Match Gross- und Kleinschreibung, rawbytes arbeitet auf den Rohdaten. depth und offset begrenzen die Suche absolut im Payload, während distance und within relativ zum vorherigen Treffer arbeiten. uricontent, isdataat und pcre decken speziellere URI-, Positions- und reguläre Ausdrücke ab.

Ein enger Suchbereich reduziert Zufallstreffer und Rechenaufwand. Besonders pcre, grosse Fenster oder mehrere breite Content-Muster sollten nur mit realistischen Paketen und unter beobachteter Last eingeführt werden. Wenn depth kleiner als das gesuchte Content-Muster ist, kann die Signatur nie treffen.

Die Modifier nocase, rawbytes, depth, offset, distance und within gehören zu content; sie sind keine unabhängigen Erkennungsregeln. Ohne depth läuft die Suche ab offset bis zum Payload-Ende. Ohne within bleibt auch die Suche nach einem zweiten Content-Muster ab distance bis zum Ende offen. Deshalb reicht ein Startpunkt allein nicht, um das Suchfenster eng zu halten. uricontent durchsucht die normalisierte Request-URI, nicht beliebige Nutzdaten. isdataat prüft, ob an einer angegebenen Position Daten vorhanden sind; mit relative bezieht sich diese Position auf das Ende des vorherigen Content-Treffers.

Header, Stream und strukturierte Werte

Quelle, Ziel und Port lassen sich mit srcaddr, dstaddr, srcport und dstport eingrenzen. Für IP-Header stehen unter anderem ttl, tos, id, ipopts, fragoffset, fragbits, dsize, ip_proto und samip zur Verfügung. TCP-Merkmale werden mit flags, flow, seq, ack und window beschrieben; itype, icode, icmp_id und icmp_seq gelten für ICMP. rpc, byte_test und byte_jump sind für strukturierte oder binäre Protokolle gedacht.

flow gilt nur für TCP. Dabei sind to_server und from_client gleichbedeutend, ebenso to_client und from_server. bi_direction erweitert die Erkennung auf beide Richtungen; bei einer Portbindung muss der Negativtest deshalb auch den Rücktraffic berücksichtigen. Die Auswahl zwischen no_stream und only_stream darf nicht mit einer Paketgrössenprüfung verwechselt werden: dsize prüft die Payload-Grösse eines Pakets und trifft nicht auf aus einem Stream wieder zusammengesetzten Paketen. Eine Kombination mit only_stream ist daher ungeeignet. Bei einem fehlenden Treffer wird zuerst entschieden, ob das Merkmal im einzelnen Paket oder im zusammengesetzten Stream gesucht werden soll, statt nur die Grösse oder das Content-Muster zu ändern.

Für komplexe Regeln gilt die oben beschriebene, von SFOS 22 unterstützte Custom-IPS-Syntax. Nicht dokumentierte Snort-Schlüsselwörter oder aus fremden Engines kopierte Regeln sollten nicht ungeprüft übernommen werden.

Operanden: Adresse, Port, URI und Datenposition

Die folgenden Fragmente gehören in Custom rule, nicht in die Shell. Sie sind eine Referenz für SFOS 22/23, keine fertig getesteten Angriffssignaturen. Nur die für den Erkennungsfall passenden Bedingungen werden kombiniert; Protocol, Pilot-Policy und Allow packet bleiben Teil des oben beschriebenen Tests. Eckige Klammern in Syntaxmustern kennzeichnen optionale Teile und werden nicht mit eingegeben.

• srcaddr:192.0.2.10; dstaddr:198.51.100.20; vergleicht Quell- und Ziel-IP mit einzelnen Adressen. Die Dokumentationsadressen werden durch die beobachteten Testadressen ersetzt; daraus lässt sich keine Unterstützung für Subnetze oder Adresslisten ableiten.

• srcport:40000; dstport:8080; vergleicht Quell- und Zielport mit Zahlen. Der Zielport steht hier für den Testdienst. Einen wechselnden Client-Quellport sollte man nur fest vorgeben, wenn er wirklich Teil des Erkennungsfalls ist; sonst scheitern neue Verbindungen an dieser Bedingung.

• uricontent:"/ips-pilot"; sucht den ersetzbaren Pfad in der normalisierten Request-URI. Auch gemischte Text-/Binärmuster sind möglich. Der Vergleich muss zum normalisierten URI-Wert passen, nicht lediglich zur Schreibweise in der Browseradresszeile.

• content:"AVANET-IPS-PILOT"; isdataat:50,relative; verlangt zusätzlich Daten an Position 50 relativ zum Ende dieses Content-Treffers. Ohne relative ist die Position im Payload absolut. Die Zahl wird nach dem tatsächlichen Protokollaufbau gewählt; sie prüft Datenverfügbarkeit, nicht den Inhalt dieser Daten.

• content:"ABC"; content:"DEF"; distance:1; within:10; verwendet zwei ersetzbare Muster mit einem relativen Suchfenster. distance legt den Abstand ab dem Ende des ersten Treffers fest, within begrenzt die folgende Suche. Für absolute Fenster erhalten offset und depth ebenfalls Zahlenwerte, beispielsweise offset:4; depth:20; am zugehörigen content. Diese Zahlen werden aus der tatsächlichen Lage und Länge des Musters gewählt; sie sind keine Protokoll-Defaults.

Reguläre Ausdrücke mit pcre

Die Grundformen sind pcre:"/REGEX/"; und pcre:"m/REGEX/";. Ein ! vor der öffnenden Anführungsmarke negiert den Ausdruck, beispielsweise pcre:!"/AVANET-IPS-PILOT/i";. Das ist eine Nichttreffer-Bedingung und kann ohne zusätzliche Eingrenzung sehr breit wirken. REGEX beziehungsweise das Pilottoken wird durch das benötigte Muster ersetzt. Optionen stehen nach dem schliessenden /, etwa pcre:"/AVANET-IPS-PILOT/i";.

• i ignoriert Gross-/Kleinschreibung; s lässt . auch Zeilenumbrüche erfassen.
• m lässt ^ und $ zusätzlich an Zeilenanfängen und -enden im Puffer greifen. x ignoriert ungeschützte Leerraumzeichen im Muster, ausser in Zeichenklassen.
• A verankert den Treffer am Pufferanfang. E bindet $ nur an das tatsächliche Ende, nicht an die Position vor einem abschliessenden Zeilenumbruch.
• G kehrt die standardmässige Gierigkeit der Quantifizierer um; ein nachfolgendes ? kehrt sie wiederum um.
• R beginnt relativ zum Ende des letzten Mustertreffers. U verwendet dekodierte URI-Puffer, B verwendet keine dekodierten Puffer.

Vor dem Pilot wird deshalb festgelegt, in welchem Puffer und ab welcher Position das Muster gelten soll. Ein korrektes Regex auf Rohdaten muss nicht auf einer dekodierten URI treffen.

Binärfelder lesen: byte_test und byte_jump

byte_test liest ein Feld und prüft seinen Zahlenwert. Das Schema lautet byte_test:COUNT,[!]OPERATOR,VALUE,OFFSET[,relative][,big|little][,NUMBER_TYPE,string];. COUNT ist die Zahl der gelesenen Bytes, OFFSET der Start im Payload; mit relative liegt der Start relativ zum letzten Mustertreffer. VALUE ist der Vergleichswert. Dokumentiert sind <, >, =, ! und &: kleiner, grösser, gleich, ungleich beziehungsweise bitweises UND. Ein ! vor einem Vergleichsoperator negiert dessen Ergebnis. big oder little legt die Byte-Reihenfolge fest. Mit string werden Textziffern statt eines binären Zahlenfelds gelesen; hex, dec und oct gelten nur für diesen Textmodus.

Beispiel für ein binäres Feld: byte_test:2,=,16,0,big; liest zwei Bytes ab Payload-Position 0 als Big Endian und vergleicht mit 16. Anzahl, Position, Byte-Reihenfolge und Vergleichswert müssen aus dem Protokoll stammen, nicht aus diesem Beispiel. Ein zufälliger Zahlenwert ist kein Angriffsnachweis.

byte_jump liest dagegen eine Länge und verschiebt die Position für folgende Prüfungen. Das Schema lautet byte_jump:COUNT,OFFSET[,relative][,multiplier FACTOR][,big|little][,string][,hex|dec|oct][,align][,from_beginning];. Die ersten beiden Operanden bestimmen Feldbreite und Leseposition; relative bezieht den Offset auf den letzten Mustertreffer. multiplier multipliziert den gelesenen Wert für die Sprungweite. align rundet diese auf die nächste 32-Bit-Grenze auf. Mit from_beginning wird die Sprungweite vom Payload-Anfang statt von der aktuellen Position aus angewendet. string und die Zahlenbasen haben denselben Zweck wie bei byte_test.

byte_jump:2,0,big; ist somit ein Fragment für ein Zwei-Byte-Längenfeld am Payload-Anfang mit ausdrücklich gewählter Byte-Reihenfolge. Es ist kein Grössenvergleich; Vergleichsoperator und Vergleichswert sind keine Operanden von byte_jump. Für beide Byte-Schlüsselwörter wird bei binären Mehrbytefeldern big oder little ausdrücklich gewählt: Auf eine aus der Dokumentation abgeleitete Default-Byte-Reihenfolge sollte man sich nicht verlassen. Zuerst Feld und Sprungziel am realen Testpayload nachvollziehen, danach einen Positiv- und Negativfall für die folgende Bedingung prüfen. Eine falsche Länge kann die Suchposition am gewünschten Muster vorbeiführen.

IP-Felder, Optionen und Fragmente

• ttl:64;, ttl:>64; und ttl:<64; vergleichen die IP Time to Live exakt, nach oben oder nach unten. tos:16; vergleicht das TOS-Feld, id:1234; das IP-ID-Feld. Diese Beispielzahlen sind keine empfohlenen Erkennungswerte; sie werden aus dem tatsächlich gesuchten Headermerkmal gewählt.
• ipopts:rr; prüft eine vorhandene IP-Option. Zulässige Werte sind rr (Record Route), eol (End of List), nop (No Operation), ts (Timestamp), sec (Security), lsrr (Loose Source Routing), ssrr (Strict Source Routing), satid (Stream Identifier) und any (eine beliebige IP-Option). any verlangt also eine Option, nicht einfach ein beliebiges IP-Paket.
• fragoffset:0; vergleicht den Fragment-Offset im IP-Header mit einer Dezimalzahl. Das Feld ist nicht der Content-Suchoffset im Payload.
• fragbits prüft M (More Fragments), D (Don’t Fragment) und R (Reserved). Ein vorangestelltes + erlaubt neben den angegebenen Bits weitere, * verlangt mindestens eines der angegebenen Bits und ! verlangt, dass die angegebenen Bits nicht gesetzt sind. So prüft fragbits:+M; auf gesetztes More Fragments, ohne andere Bits auszuschliessen.
• dsize:300;, dsize:>300;, dsize:<300; und dsize:300<>400; beschreiben exakte Payload-Grösse, oberen/unteren Vergleich oder einen Bereich. Die Zahlen beziehen sich auf die Paketnutzdaten, nicht auf die gesamte Verbindung. Die oben erklärten Grenzen gegenüber rekonstruierten Streams bleiben bestehen.
• ip_proto:6;, ip_proto:!6;, ip_proto:>6; und ip_proto:<6; vergleichen die numerische Protokollkennung im IP-Header, nicht den TCP-/UDP-Port. samip; hat keinen Wert und verlangt gleiche Quell- und Ziel-IP.

TCP-Felder und Stream-Auswahl

flags prüft TCP-Flags: S für SYN, A für ACK, F für FIN, R für RST, U für URG und P für PSH. Ohne Modifier prüft beispielsweise flags:S; auf genau SYN. Vorangestelltes +, * oder ! hat die oben bei fragbits erklärte Bedeutung. flags:+S; erlaubt daher zusätzliche Flags. Hinter einem Komma kann eine Maske stehen: flags:S,A; nimmt ACK aus dem Vergleich aus, statt zusätzlich ACK zu verlangen. Eine solche Maske erweitert den Trefferbereich. Sonderfälle für reservierte TCP-Bits und «keine Flags gesetzt» sind hier bewusst nicht als kopierbare Syntax freigegeben; sie benötigen eine versionsspezifisch bestätigte Regel und dürfen nicht aus einer unklaren Beschriftung abgeleitet werden.

Für flow stehen die bereits erklärten Richtungen sowie established, no_stream und only_stream zur Verfügung. flow:established; verlangt eine etablierte TCP-Verbindung. flow:no_stream; schliesst rekonstruierte Stream-Pakete aus, flow:only_stream; beschränkt die Erkennung auf diese. Diese Fragmente erläutern die einzelne Auswahl und sind keine Aufforderung, beide Stream-Optionen zusammen zu verwenden. bi_direction bleibt die oben beschriebene Erweiterung auf Hin- und Rücktraffic.

seq:1234;, ack:1234; und window:4096; vergleichen TCP-Sequenznummer, Bestätigungsnummer und Fenstergrösse jeweils mit einer Zahl. Exakte Sequenz- oder ACK-Werte ändern sich zwischen Verbindungen und sind nur sinnvoll, wenn genau dieser Wert zum Erkennungsfall gehört. Das TCP-Fenster ist kein Payload-Suchfenster.

ICMP und RPC

itype:8; und icode:0; vergleichen ICMP-Typ und -Code. Beide unterstützen auch <, > und Bereiche wie itype:3<>5;; Typ und Code sind unterschiedliche Felder. icmp_id:1234; und icmp_seq:1; vergleichen ICMP-Identifier und Sequenzwert exakt. Die Werte werden anhand des gewünschten ICMP-Falls gewählt, nicht mit TCP-Sequenznummern gleichgesetzt.

rpc:100000,2,*; prüft in SUNRPC-CALL-Anfragen die Anwendungsnummer 100000, Version 2 und eine beliebige Prozedur. Das Schema ist rpc:APPLICATION,VERSION,PROCEDURE;; * ist für Version und Prozedur erlaubt, nicht für die Anwendungsnummer. Die Zahlen werden durch die gesuchte Anwendung, Version und Prozedur ersetzt. Eine Wildcard spart keine Analyse des Protokolls: Sie lässt den jeweiligen Teil bewusst offen und erweitert damit die Erkennung.

Signatur erstellen und einer Policy zuweisen

Unter Intrusion prevention > Custom IPS signatures > Add werden Name, Protocol, Custom rule, Severity und Recommended action festgelegt. Ein Name wie PILOT-TCP-8080-AVANET-TOKEN macht Zweck und Testgrenze sichtbar. Severity beschreibt die eigene Risikoeinschätzung; sie beweist nicht, dass das Muster bösartig ist.

Für den ersten Lauf bleibt die Recommended action auf Allow packet. Wichtig: Die Aktion der IPS-Policy-Regel überschreibt diese Empfehlung. Deshalb muss auch die Pilotregel Allow packet verwenden. Die weiteren Aktionen haben deutlich stärkere Folgen:

• Drop packet verwirft nur das passende Paket.
• Drop session beendet die Sitzung nach dem Treffer.
• Reset beendet eine TCP-Sitzung und sendet einen Reset an den Ursprung.
• Bypass session erlaubt den Traffic und prüft den Rest der Sitzung nicht weiter.

Bei sitzungsbasierten Aktionen prüft SFOS nur bis zum ersten passenden Paket. Vor dem Wechsel von Allow packet zu einer solchen Aktion muss daher bestätigt sein, dass genau dieser erste Treffer die beabsichtigte Sitzung betrifft.

Beim Speichern konfiguriert SFOS die IPS Engine neu. Ist genügend freier RAM vorhanden, geschieht dies ohne Unterbrechung. Bei wenig freiem RAM kann die Engine neu starten und kurzzeitig unterbrechen. Änderungen gehören deshalb auch bei einer scheinbar kleinen Signatur in ein beobachtetes Zeitfenster. Nach dem Speichern werden der IPS-Status und ips.log auf einen Neustart oder Fehler geprüft, bevor der Pilot fortgesetzt wird.

Danach folgt der oft übersehene zweite Teil: Unter Intrusion prevention > IPS policies eine löschbare, für den Pilot bestimmte Policy öffnen, eine Regel hinzufügen, Custom signature wählen, die Signatur markieren und die spezifische Regel oberhalb breiterer Regeln platzieren. SFOS wertet IPS-Policy-Regeln von oben nach unten aus. Anschliessend wird diese Policy unter Rules and policies > Firewall rules > [Pilotregel] > Detect and prevent exploits (IPS) an die tatsächlich getroffene Pilotregel gebunden.

Positiv- und Negativtest durchführen

Der Positivtest sendet das vereinbarte Muster über den vorgesehenen Port und in der erwarteten Richtung. Im Log Viewer, oben rechts im WebAdmin, wird das IPS-Modul gewählt und nach Testzeit, Source und Destination gefiltert. Signatur beziehungsweise SID, Aktion und Zeitpunkt müssen zum Test passen. ips.log liefert ergänzende Engine-Details. Packet Capture unter Diagnostics > Packet capture zeigt zusätzlich Firewall Rule ID und IPS Policy ID. Die Verbindung zwischen Regel, Packet Capture und Sicherheitsmodul erklärt Firewallregel systematisch testen.

Nach der Pilotphase lässt sich die Wirkung ausserdem unter Reports > Network & threats > Intrusion attacks auswerten. Der Bericht ist für Zeitraumvergleiche nützlich, ersetzt aber nicht den zeitnahen Positiv- und Negativtest im Log Viewer.

Danach folgt mindestens ein Negativtest: derselbe Dienst ohne Token, ein anderer Port oder eine abweichende Richtung. Die Signatur darf dabei nicht treffen. Bei einem Content-Muster sind auch normale Requests der Anwendung wichtig, weil kurze oder allgemeine Strings in völlig legitimen Payloads vorkommen können.

Erst wenn beide Tests stabil sind, wird die geplante Blockaktion gesetzt und erneut geprüft. Eine blockierende Signatur gilt nur dann als abgenommen, wenn genau der positive Fall gestoppt wird, der negative Fall weiterläuft und keine andere Firewall- oder IPS-Regel den Effekt verursacht.

Anzahl der Signaturen prüfen

Die Anzahl lässt sich im WebAdmin ohne Shell ermitteln. Unter Intrusion prevention > IPS policies wird eine löschbare Policy geöffnet und eine neue Policy-Regel angelegt. Mit Select all zeigt SFOS die Gesamtzahl oberhalb von Action. Die Liste ist nur beim Hinzufügen einer Regel zu einer löschbaren Policy sichtbar; der Dialog kann danach ohne Speichern geschlossen werden.

Sophos dokumentiert zusätzlich zwei lesende Abfragen unter 5. Device management > 3. Advanced shell:

psql -U nobody -d signature -p 5434 -c "select count (*) from tblidprules;"
psql -U nobody -d corporate -c "select count (*) from tblidpcustomsignature;"

Der erste Befehl zählt die Standard-, der zweite die Custom Signatures. Diese Datenbankabfragen ändern nichts, gehören aber in eine dokumentierte Support- oder Diagnose-Session. Die Zahl ist kein Qualitäts- oder Funktionsnachweis und kann sich mit Pattern-Updates ändern.

Wenn die Signatur nicht wie erwartet arbeitet

Es gibt keinen Treffer

Zuerst wird geprüft, ob IPS aktiv ist, der Traffic die erwartete Firewallregel mit der richtigen IPS Policy trifft und die Custom Signature tatsächlich in einer ausgewerteten Policy-Regel steht. Danach folgen Protokoll, Richtung, Port, Verschlüsselung und der reale Payload. Ein String in einer Browseranzeige muss nicht unverändert im Netzwerkpaket stehen.

Hilfreich ist ein eng gefilterter Packet Capture, der den sichtbaren Inhalt und die Richtung bestätigt. Fehlt das Muster bereits dort, kann eine Anpassung der IPS-Regel es nicht herbeizaubern. Sind die Pakete sichtbar, werden offset, depth, distance, within, Stream-Zustand und Reihenfolge der Policy-Regeln geprüft.

Zu viele Verbindungen treffen

Die Signatur bleibt auf Allow packet, bis Source, Destination, Port, Richtung oder Suchfenster enger gefasst sind. Allgemeine Wörter, kurze Binärfolgen und ungebremste reguläre Ausdrücke sind typische Ursachen. Eine breite Firewallregel macht die Wirkung zusätzlich schwer kontrollierbar.

Zeigt die Firewall nach dem Speichern einen Ressourcenanstieg oder einen IPS-Neustart, werden Zeitpunkt, Modell, Firmware, freie Ressourcen und ips.log gesichert. Wiederholtes Speichern unterschiedlicher Varianten ist dann kein sauberer Test; zuerst wird die Ursache und ein Wartungsfenster geklärt.

Sicher zurückrollen

Bei unerwarteten Treffern wird zuerst die Custom-Regel aus der Pilot-Policy entfernt oder die vorherige IPS Policy an der Firewallregel wiederhergestellt. Danach werden neue Sitzungen mit positivem und negativem Test geprüft. Erst wenn kein anderer Verwendungszweck besteht, wird die Custom Signature gelöscht.

Vor dem Löschen sollte dokumentiert sein, welche Policy, Firewallregel und Anwendung sie verwendet haben. Logs, getestete Regelversion und der Grund für den Rollback gehören in den Change-Nachweis. IPS global auszuschalten oder die ganze Produktions-Policy zu entfernen ist kein angemessener Rollback für eine einzelne fehlerhafte Signatur.

FAQ