Eigene Snort Regel bauen

Snort OpenApp ID mit Custom Rule

Nutzt man Snort wie zum Beispiel in diesem Blogbeitrag von uns beschrieben, fehlen ganz sicher mindestens einmal Anwendungen, welche man gerne blockieren oder erkennen möchte. Aber auch das Erkennen dieser Anwendungen, welche nicht in den offiziellen Snort / OpenApp ID Regeln vorhanden sind, ist möglich. Hier möchten wir kurz zeigen, wie man eine eigene Snort Regel bauen und damit solche Anwendungen erkennen kann.

Traffic identifizieren

Damit Snort den Traffic erkennen kann, muss man erstmal ein eindeutiges Merkmal des Pakets finden. Dabei kann beispielsweise WireShark hilfreich sein.

In diesem Beispiel möchten wir den Web-Traffic zur Domain „example.com“ blockieren. Dafür starten wir WireShark und rufen „example.com“ im Browser auf. Alternativ dazu die gewünschte Anwendung starten. Es ist sinnvoll am Testgerät alle anderen Anwendungen zu beenden, um den WireShark Mitschnitt möglichst klein zu halten.

DNS Anfragen erkennen

In WireShark suchen wir nun nach verdächtigen Paketen, die mit der Anwendung zusammen hängen könnten. Zuerst fällt dabei häufig die DNS Anfrage auf.

Eigene Snort Regel bauen

Gewonnene Informationen hier:

  • Ziel Port: 53 (DNS)
  • DNS Anfrage Name: example.com (Hex: „65 78 61 6d 70 6c 65 2e 63 6f 6d“)

Weiteren Traffic erkennen

In diesem Fall gibt es zusätzlich noch HTTP Pakete. Darin enthalten ist zum Beispiel der Hostname oder die URL. Da HTTP heutzutage aber eine Seltenheit ist, kann auch der SNI aus HTTPS Paketen verwendet werden.

Wireshark Mitschnitt

Gewonnene Informationen hier:

  • Ziel Port: 80 (HTTP)
  • Host: example.com

Eigene Snort Regel bauen

Aus den gewonnenen Informationen muss man nun die entsprechenden Regeln für Snort bauen. Die hier gezeigten Regeln können durch einfaches Anpassen des Zielports (z. B. 443 für HTTPS Anfragen) und des Hostnamens für die meisten Anwendungen verwendet werden.

alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (content:"example.com"; nocase; msg:"example.com Web blockiert"; sid:9000001; classtype:misc-activity;)

alert udp $HOME_NET any <> any 53 (content:"|65 78 61 6d 70 6c 65 03 63 6f 6d|"; nocase; msg:"example.com DNS blockiert"; sid:9000002; classtype:misc-activity;)

Tipp: Bei DNS verwendet man den Hexcode des Hostnamens. Diesen könnt ihr entweder aus Wireshark herauslesen oder ihr nutzt einen ASCII zu Hex Konverter im Internet.

Syntax der Regeln

Die Syntax muss mindestens die oben gezeigten Parameter enthalten.

  • alert (Feststehender Begriff)
  • Protokoll (udp / tcp / icmp)
  • Quellnetz (z. B. $HOME_NET, CIDR Netz oder any)
  • Quellport (Meistens any, da der Quellport häufig dynamisch ist.)
  • Richtungsoption (->, <- oder <>)
  • Zielnetz (z. B. $EXTERNAL_NET, CIDR Netz oder any)
  • Zielport (z. B. 80 für HTTP, 443 für HTTPS oder any)

Paket-Inhalte in Klammern, getrennt durch ein Semikolon:

  • content:“Hier steht ein Inhalt aus dem Paket z.B. der Hostname“ (Achtung, bei einigen Anfragetypen wie z. B. DNS Anfragen muss der Hostname als Hex Code genutzt werden.
  • nocase (Groß und Kleinschreibung bei content Option wird ignoriert.)
  • msg:“Beliebige Nachricht“
  • sid: (Ab 9000000, nie doppelt verwenden!)
  • classtype: (Typ des Pakets. Mögliche Werte weiter unten.)

Mögliche classtype Parameter

classtype:misc-activity
classtype:policy-violation
classtype:web-application-attack
classtype:trojan-activity
classtype:attempted-admin
classtype:protocol-command-decode
classtype:bad-unknown
classtype:attempted-recon
classtype:web-application-activity
classtype:successful-recon-limited
classtype:network-scan
classtype:attempted-user
classtype:attempted-dos
classtype:misc-attack
classtype:denial-of-service
classtype:shellcode-detect
classtype:unsuccessful-user
classtype:unknown
classtype:non-standard-protocol
classtype:rpc-portmap-decode
classtype:suspicious-filename-detect
classtype:unusual-client-port-connection
classtype:not-suspicious
classtype:successful-user
classtype:string-detect
classtype:successful-admin
classtype:system-call-detect
classtype:suspicious-login
classtype:default-login-attempt

Eigene Regel in Snort unter pfSense benutzen

Die selbst gebauten Regeln fügt man nun noch in der Snort Konfiguration ein. Dazu im Menü „Services > Snort > Rules > Interface“ im Reiter „Interface Rules“ die Kategorie „custom.rules“ auswählen. Hier kann man die Regeln dann einfügen.

Eigene Snort Regel bauen

Nach dem Klick auf Save wird die Regel vom Snort Dienst auf Korrektheit der Syntax geprüft und der Dienst neu gestartet.

Test der eigenen Regeln

Nun müssen die Regeln noch auf Funktion getestet werden. Dazu das Menü „Services > Snort > Alerts“ aufrufen. Im Dropdown Menü „Interface to Inspect“ das konfigurierte Interface auswählen.
Anschließend kann man die erkannten Anwendungen sehen. Sollten dies zu viele sein, um die eigenen Regeln zu entdecken, einfach im Filterbereich mit der eigenen SID filtern.

Jetzt muss man den zu blockierenden Traffic verursachen. Dafür ruft man die Webseite im Browser auf oder startet die Anwendung.

Web Anfrage

Hier sieht man den erzeugten HTTP Snort Alert mit einigen erfassten Details.

Snort Alert HTTP

DNS Anfrage

Hier sieht man den erzeugten DNS Snort Alert mit einigen erfassten Details.

Snort Alert DNS

Achtung, der DNS Traffic wird vielleicht nur beim ersten Aufrufen der Webseite erzeugt. Sicherer kann man diesen zum Beispiel mit dem Befehl nslookup in PowerShell reproduzieren.

nslookup auf example.com

Zusammenfassung

In diesem Beitrag haben wir gelernt, wie man eigene Snort Regeln für eine Webseite erstellt. Natürlich gibt es etliche Webseiten, Protokolle oder Anwendungen die man blockieren könnte. Hierfür ist etwas Verständnis für die Funktion von Snort erforderlich. Gerne unterstützen wir soweit es uns möglich ist dabei. Kontaktiert uns zum Beispiel über Twitter.