Signaturregeln mit Snort und Suricata

Snort und Suricata sind die beiden führenden Open-Source-Engines für IDS/IPS. Sie verwenden eine weitgehend kompatible Regelsprache, sodass eine für die eine Engine geschriebene Regel normalerweise auch auf der anderen läuft.

Suricata ergänzt Multithreading, native Protokollparser, Dateiextraktion und umfangreiche Protokollierung (EVE JSON); Snort 3 hat seine eigene Engine in ähnlicher Weise modernisiert. Wenn Sie die Regelsyntax einmal lernen, können Sie beide effektiv einsetzen.

Jede Regel besteht aus zwei Teilen: einem Header und einem in Klammern gesetzten Body mit Optionen. Der Header legt Aktion, Protokoll und Verkehrsrichtung fest; der Body definiert, wonach gesucht wird und wie das Ergebnis gemeldet wird.

Der Header wird von links nach rechts gelesen:

• action — alert, drop, reject, pass
• protocol — tcp, udp, icmp, ip (oder Anwendungsprotokolle in Suricata: http, dns, tls)
• source IP/port und destination IP/port
• direction — -> unidirektional oder <> bidirektional

Variablen wie $HOME_NET und $EXTERNAL_NET stammen aus Ihrer Konfiguration, damit Regeln standortübergreifend portierbar bleiben.

Die action bestimmt, ob sich diese Regel wie ein IDS oder IPS verhält:

• alert — protokolliert und benachrichtigt, stoppt den Datenverkehr aber nicht (IDS)
• drop — verwirft das Paket stillschweigend (IPS, nur inline)
• reject — verwirft das Paket und sendet einen TCP-Reset oder ICMP-Fehler „unreachable“
• pass — erlaubt den Datenverkehr ausdrücklich und überspringt spätere Regeln

Dieselbe Engine fungiert als IDS oder IPS – je nachdem, ob sie inline eingesetzt wird und welche Aktionen Sie verwenden.

Das Schlüsselwort content gleicht ein Byte-Muster in der Payload ab. Text steht in Anführungszeichen; Binärdaten werden in Pipes als Hexadezimalwerte angegeben.

Schlüsselwörter zur Verankerung präzisieren die Treffer: offset, depth, distance und within schränken ein, an welcher Stelle das Muster vorkommen darf, und verbessern dadurch Genauigkeit und Performance.

Moderne Regeln gleichen Muster mit protokollspezifischen Buffern statt mit dem rohen Datenstrom ab. Nach einem Buffer-Schlüsselwort beziehen sich nachfolgende content-Treffer auf den entsprechenden Teil des geparsten Protokolls.

• http_uri — die Request-URI
• http_header — Request- und Response-Header
• http_user_agent — der User-Agent
• tls_sni / dns_query — TLS-Servername / DNS-Abfrage

Das ist deutlich zuverlässiger, als das gesamte Paket nach einer Teilzeichenkette zu durchsuchen.

Wenn feste Zeichenketten nicht ausreichen, stellt pcre Perl-kompatible reguläre Ausdrücke bereit. Kombinieren Sie einen kostengünstigen content-Vorfilter mit pcre, damit der reguläre Ausdruck nur auf mögliche Treffer angewendet wird und die Performance erhalten bleibt.

Der Modifikator nocase macht einen content-Abgleich unabhängig von Groß- und Kleinschreibung – wichtig für Header und benutzergesteuerte Felder, die Angreifer variieren können.

Die Option flow beschränkt eine Regel auf den Verbindungsstatus und die Richtung und reduziert so Fehlalarme und Ressourcenaufwand.

• established — nur bei abgeschlossenen TCP-Sitzungen
• to_server / to_client — Richtung von Request bzw. Response

Wenn Sie Serverantworten nur bei established und to_client abgleichen, vermeiden Sie Treffer bei verirrten oder gefälschten Paketen.

Verwaltungsoptionen halten einen Regelsatz wartbar:

• sid — eindeutige Signatur-ID (für lokale Regeln 1000000+ verwenden)
• rev — Revisionsnummer, bei jeder Änderung erhöhen
• msg — der Alarmtext, den Analysten sehen
• classtype — Kategorie, die die Priorität bestimmt
• reference — Link auf eine CVE oder ein Advisory

Stabile sids und fortlaufend erhöhte revs ermöglichen es Ihnen, Regeln nachzuverfolgen und zu aktualisieren, ohne Dashboards und Suppressions zu beeinträchtigen.

Obwohl die Regeln kompatibel sind, unterscheiden sich die Engines in ihrem Funktionsumfang:

• Suricata ist multithreadfähig, analysiert Anwendungsprotokolle nativ, extrahiert Dateien, berechnet JA3 und erzeugt EVE JSON
• Snort 3 hat seine Engine für bessere Performance und ein modulares Plugin-System neu geschrieben

Einige Schlüsselwörter sind enginespezifisch. Suricata ergänzt Schlüsselwörter für die Anwendungsschicht (tls.sni, dns.query, http.method) sowie Funktionen für Datasets und Flowbits. Wenn Sie Regeln gemeinsam nutzen, richten Sie sie auf den kleinsten gemeinsamen Nenner aus oder pflegen Sie enginespezifische Regelsätze.

Um zu verhindern, dass eine Regel die Konsole mit Meldungen überflutet, wenden Sie Schwellenwerte an. detection_filter wird erst nach N Ereignissen innerhalb eines Zeitfensters ausgelöst; threshold mit limit begrenzt die Zahl der Alarme.

Das ist für die Erkennung von Brute-Force-Angriffen und Scans entscheidend, da ein einzelnes Ereignis bedeutungslos ist, während eine Häufung das eigentliche Signal darstellt.

Lesen Sie eine Regel und sagen Sie ihr Verhalten voraus.

Sie können jetzt Snort-/Suricata-Signaturen lesen und schreiben:

• Eine Regel besteht aus einem Header (action, proto, src/dst, direction) und Body-Optionen
• Die action legt IDS oder IPS fest: alert, drop, reject, pass
• content gleicht mit offset/depth und Hexadezimalwerten Payload-Bytes ab
• Sticky Buffers (http.uri, tls.sni, dns.query) gleichen geparste Protokollfelder ab
• pcre und nocase verarbeiten variable Muster
• flow beschränkt den Abgleich auf Status und Richtung
• sid/rev/msg/reference halten Regeln wartbar
• Schwellenwerte reduzieren das Rauschen durch Brute-Force-Angriffe und Scans

Als Nächstes: Bedrohungen ohne jede Signatur erkennen.