Erster Eindruck: Die stark überarbeitete Snort-Version 2.0

Snort, das Open-Source-NIDS (Network Intrusion Detection System) von Martin Roesch, hat sich seit seiner ersten Veröffentlichung im Jahre 1998 zu einem mächtigen Werkzeug entwickelt. Ursprünglich handelte es sich um einen einfachen Packet Sniffer auf Basis der Libpcap-Bibliothek, der die Pakete mit einer sehr einfachen Signaturdatenbank verglich. Inzwischen ist Snort von einem Leichtgewicht-NIDS zu einem recht umfangreichen System angewachsen und braucht den Vergleich mit kommerziellen und hochpreisigen Lösungen nicht zu scheuen.

Snort verfügt unter anderem über IP-Defragmentierung, TCP-Stream-Reassemblierung und Unicode-Dekodierung. Hin-ter diesen Begriffen steckt die Normalisierung der Pakete, bei der Snort für eine einheitliche Darstellung der Daten sorgt. Danach vergleicht das NIDS die Pakete mit den Regeln seiner umfangreichen Signaturdatenbank und erkennt so mögliche Angriffe. Hat es eine Attacke bemerkt, meldet es den Vorfall über eines seiner vielen Ausgabe-Plugins.

Dieser Artikel stellt die wesentlichen Neuerungen des Release-Kandidaten von Snort 2.0 vor und erläutert die Konfiguration. Funktionen, die in den vorherigen Versionen bereits enthalten waren, sind dabei bewusst ausgeklammert. Mehr dazu ist in verschiedenen Artikeln[3] und Büchern[2] zu finden.

Neu in Snort 2.0

Die Version 2.0 weist eine ganze Reihe von Neuerungen auf, einige sind für den Administrator offen erkennbar. So gibt es seit Snort 1.9 einen überarbeiteten Portscan-Detektor »portscan2«, einen Detektor für polymorphen Shellcode »fnord« sowie einen Performance-Monitor »perfmonitor«. Die Version 2.0 bringt zudem den neuen Präprozessor HTTP-Flow mit. Fnord wurde leider noch nicht in die Version 2.0 übernommen.

Die wichtigste Neuerung der Version 2.0 betrifft aber Snort selbst. Die Entwickler haben die gesamte Detektionsmaschine ausgetauscht und durch eine neue, wesentlich schnellere Variante ersetzt.

HTTP-Flow

Der HTTP-Flow-Analysator ist als Präprozessor in der Lage, die Kommunikation zwischen einem Webclient und einem Webserver in zwei Teile aufzuteilen, den Client-Flow und den Server-Flow. Die Detektionsmaschine behandelt dann diese Flüsse getrennt.

Snort geht davon aus, dass bei einer HTTP-Kommunikation etwa fünf Prozent des Verkehrs auf den Client und 95 Prozent auf den Server entfallen. Bei der Antwort des Servers sind die Header nur einige hundert Byte lang. Meist umfassen sie nur drei bis fünf Prozent der übertragenen Daten. Der HTTP-Flow-Analysator nutzt dieses Wissen und belastet die Detektionsmaschine nur mit dem Client-Flow und den Headern des Server-Flows, da sich hier bereits die bösartigen Angriffe offenbaren. Das reduziert die zu analysierenden Daten typischerweise um 80 Prozent.

Dieser Präprozessor unterstützt zwei unterschiedliche Modi: Quick und Full. Im Quick-Modus untersucht er jedes Paket einzeln. Dazu muss er wissen, auf welchen Ports die Webserver lauschen. Zusätzlich benötigt er die Anzahl der zu untersuchenden Bytes in der Antwort des Webservers. Ein typischer Aufruf lautet:

preprocessor httpflow: quick depth 200 
  ports 80 3128

Der Präprozessor analysiert die ersten 200 Bytes der Server-Antworten, die von den Ports 80 und 3128 stammen.

Im Full-Modus benutzt HTTP-Flow den Stream4-Präprozessor, um die Einzelpakete der Kommunikation wieder zusammenzusetzen. Stream4 gibt nur Pakete zur Analyse weiter, deren TCP-Zustand er validiert hat. In diesem Modus ist es nicht nötig, die Header-Länge anzugeben. Der Präprozessor erkennt sie selbstständig.

preprocessor httpflow: full

Snort wendet die Präprozessoren in der Reihenfolge an, in der sie in der Konfigurationsdatei aufeinander folgen. Daher ist es im Full-Modus zwingend erforderlich, dass HTTP-Flow erst nach Frag2 und Stream4 steht.

Der neue Portscan-Detektor Portscan2 benutzt eine eigene Zustandstabelle, um Scans besser zu erkennen und dabei weniger falsche Alarme auszulösen. Der Detektor lässt sich über vier Direktiven konfigurieren (siehe Listing 1).