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 mit Allow packet und Logging in einem kleinen Pilotpfad testen. 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 Allow packet anlegen.
3. Die Signatur einer eigenen Regel in einer löschbaren IPS Policy hinzufügen.
4. Diese IPS Policy nur der vorgesehenen Pilot-Firewallregel zuweisen und Logging aktivieren.
5. Einen passenden sowie einen absichtlich unpassenden Test erzeugen und Log Viewer, ips.log und Regelmatch vergleichen.
6. Erst nach stabiler Abnahme die gewünschte Aktion setzen; bei unerwarteten Treffern Policy-Zuweisung oder Signatur zurücknehmen.

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.

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.

Die vollständige SFOS-22-Referenz der Custom-IPS-Syntax bleibt bei komplexen Regeln verbindlich. Nicht dokumentierte Snort-Schlüsselwörter oder aus fremden Engines kopierte Regeln sollten nicht ungeprüft übernommen werden.

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

Beim Speichern konfiguriert SFOS die IPS Engine neu. Ist genügend freier RAM vorhanden, geschieht dies laut Sophos 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.

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, die Custom Signature auswählen und die spezifische Regel oberhalb breiterer Regeln platzieren. Anschliessend wird diese Policy unter Rules and policies > Firewall rules 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. Parallel werden Firewall Rule ID, IPS Policy, Signaturname, Source, Destination, Aktion und Zeitpunkt im Log Viewer erfasst. ips.log liefert ergänzende Engine-Details; die Verbindung zwischen Regel, Packet Capture und Sicherheitsmodul erklärt Firewallregel systematisch testen.

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 in der 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