© Iryna Dobrovyns'ka, 123RF.com

Suricata, das wachsame Erdmännchen, heißt eine freie Software für die Intrusion Detection, die unter anderem von einer Stiftung des Homeland Security Department getragen wird. Die Snort-Alternative nutzt die GPU via Cuda, um auch in schnellen Netzen der herannahenden Daten Herr zu werden.

Administratoren, die eine Open-Source-IDS-Lösung suchen, landen meist bei Snort ([1], [2]), dem von Marty Roesch 1998 als Multiplatform Network Sniffer entworfenen Schnüffelschwein. In seiner langen Lebenzeit entwickelte sich Snort zu einer der führenden IDS-Lösungen. Die Weiterentwicklung bringt aber auch Nachteile: Konzeptionelle Änderungen lassen sich beispielsweise nur mehr schwer umsetzen.

Als Befreiungsschlag brachten die Entwickler 2009 mit Snort 3.0 [3] eine komplette Neuimplementierung, die aber immer noch nur als Beta unter dem Namen Snort Security Platform (Snort SP) auf der Snort-Homepage verfügbar ist.

Doch parallel dazu entstand im Zeichen des wachsamen Erdmännchens (Suricata suricatta) das Suricata-Projekt, dessen Entwickler sich zur Open Information Security Foundation zusammenschlossen (OISF, [4]) Die amerikanische Heimatschutzbehörde (Department of Homeland Security) finanziert die Stiftung, deren einziges Ziel die Entwicklung von Suricata ist und die am 31. Dezember 2009 erstmals eine Betaversion vorstellte. Seit wenigen Wochen steht bei der OISF die Version 1.1.1 zum Download bereit.

Eine neue IDS-Generation: Suricata

Die Entwickler bezeichnen Suricata als Next Generation IDS. Wesentliche neue Funktionen, die Suricata von Snort unterscheiden, sind das Multithreading, das Snort gar nicht bietet, und die automatische Protokollerkennung. Wer mit Snort Mehrkernprozessoren auslasten will, muss derzeit selbst dafür sorgen und mehrere Snort-Prozesse starten. Künftige Suricata-Versionen sollen für die Analyse der Pakete auch dedizierte Beschleuniger-Hardware nutzen, aktuell bindet Suricata bereits Nvidia-Grafikkarten über die Cuda-Bibliothek ein.

Grundsätzlich haben die Entwickler von Suricata allerorts versucht Snort-Kompatibilität herzustellen. Die Regelsyntax, die Protokollierung mit dem Unified2-Format und die Konfiguration der Variablen ist entweder direkt kompatibel oder zumindest sehr ähnlich und leicht konvertierbar. Jedoch weist die Hauptkonfigurationsdatei von Suricata eine andere Syntax auf, was es dem Administrator erschwert, seine vorhandene Snort-Konfiguration zu übernehmen.

Suricata ist für verschiedenste Plattformen verfügbar. Fedora bringt Suricata 1.1.1, Debian Squeeze die Version 1.0.1 und Ubuntu 11.10 die Suricata-Ausgabe 1.04 als Pakete im Repository mit. Das IDS läuft darüber hinaus auch auf Free BSD, Mac OS X und Windows.

Installation

Detaillierte Installationsanleitungen gibt es unter [5], die Kästen “Cuda” und “PF_Ring” zeigen, wie der Administrator die Grafikbibliothek und die modifizierte Libpcap-Ergänzung »pf_ring« einrichtet. Neben Cuda und PF_Ring erweist sich auch die Libcap-ng als sinnvoll. Sie ermöglicht es, Suricata als unprivilegierter Benutzer zu betreiben, was die Sicherheit des Systems deutlich erhöht. Anschließend lädt und installiert die Befehlssequenz aus Listing 1 Suricata.

chmod 755 cudatoolkit_4.0.17_linux_64_ubuntu10.10.run NVIDIA-Linux-x86_64-280.13.run
./cudatoolkit_4.0.17_linux_64_ubuntu10.10.run
./NVIDIA-Linux-x86_64-280.13.run

01 ./configure --enable-gccprotect --enable-profiling --enable-cuda --with-cuda-includes=/usr/local/cuda/include --with-cuda-libraries=/usr/local/cuda/lib64 --enable-pfring --with-libcap_ng-libraries=/usr/local/lib --with-libcap_ng-includes=/usr/local/includea
02 make
03 make install

01 svn --force export https://svn.ntop.org/svn/ntop/trunk/PF_RING/ PF_RING
02 cd /kernel
03 make && make install
04 sudo insmod ./pf_ring.ko
05 cd ../userland
06 make && make install
07 cd /lib
08 ./configure && make && make install
09 cd ../libpcap
10 ./configure && make && make install
11 echo "options pf_ring transparent_mode=0 min_num_slots=32768 enable_tx_capture=0" > /etc/modprobe.d/pf_ring.conf

Wer Cuda und PF_Ring nicht benötigt, lässt einfach die entsprechenden Optionen in der »configure« -Zeile 1 weg. Jetzt gilt es noch, die Verzeichnisse »/etc/suricata« und »/var/log/suricata« zu erzeugen und zu füllen. »/var/log/suricata« weist der Administrator die Rechte »775« und den Besitzer »root« sowie die Gruppe »suricata« zu. Anschließend kopiert er die Dateien »suricata.yaml« , »classification.config« und »reference.config« aus dem Quelltextverzeichnis in das Verzeichnis »/etc/suricata« .

Konfiguration

Im nächsten Schritt geht es darum, die Konfiguration anzupassen. Hierzu muss der Admin Variablen korrigieren, deren Namen vor allem Snort-Kennern bekannt sein dürften. Die Kommandos befinden sich allerdings im Gegensatz zur Snort-Konfiguration nicht am Anfang, sondern am Ende der Konfigurationsdatei »suricata.yaml« . Die wichtigsten Variablen sind:

• »HOME_NET« : zu überwachende eigene Netzwerke
• »EXTERNAL_NET« : externe Netzwerke außerhalb des LAN
• »HTTP_SERVERS« : Webserver, in der Regel identisch mit »HOME_NET«
• »HTTP_PORTS« : zu überwachende Ports

Weitere Variablen definieren die Parameter für DNS-, SMTP-, SQL- und Telnet-Server. Weil die Signaturen diese Variablen auslesen, empfiehlt es sich, sie so spezifisch wie nur möglich zu setzen. Denn je genauer der Administrator die Variablen definiert, desto genauer und besser erkennt Suricata Angriffe. Alle Parameter der Konfigurationsdatei erläutert das Suricata-Wiki [9].

Erdmännchen am Start

Schließlich startet der Administrator Suricata mit dem folgenden Befehl:

suricata -c /etc/suricata/suricata.yaml --pfring-int=eth0 --pfring-cluster-id=99 --pfring-cluster-type=cluster_flow

Wer auf PF_Ring verzichtet, dem reicht:

suricata -c /etc/suricata/suricata.yaml -i eth0

Den Benutzer und die Gruppe für den Betrieb von Suricata spezifizieren in beiden Fällen die Optionen »–user suricata« und »–group suricata« , existierende User und Groups vorausgesetzt. Die Optionen für die Netzwerkkarte und die PF_Ring-Parameter kann der Administrator aber auch in der Konfigurationsdatei hinterlegen. Leider stellt das Quelltextpaket bisher kein Startskript zur Verfügung. Das Suricata-Wiki hält jedoch eine Beispielkonfiguration für Ubuntu-Upstart bereit (siehe Listing 3 und [10]).

01 # Suricata - intruder detection system daemon
02 # Example upstart script
03 # Suricata is an intruder detection system description "intruder detection system"
04 start on runlevel [2345]
05 stop on runlevel [!2345]
06 exec suricata -D -c /etc/suricata/suricata.yaml -i eth1

Intrusion Prevention System

Ähnlich wie Snort kann Suricata auch als Inline-IDS oder als IPS dienen. Dabei arbeitet Suricata wie eine Firewall und entscheidet, ob es die Pakete verwerfen oder zustellen lässt. Suricata nutzt hierzu die Netfilter-Queueing-Funktion [11], derer sich auch schon ältere Snort-Versionen (vor 2.9.0) bedienten. Moderne Schnüffelschweine verwenden hier bereits das wesentliche schnellere AF_Packet-Interface [12]. PF_Ring stellt Suricata hier leider nicht zur Auswahl.

Um Suricata im Inline-Modus zu verwenden, muss der Administrator vor der Übersetzung die entsprechende Netfilter-Bibliothek »libnetfilter-queue-dev« installieren. Anschließend gibt er bei dem Configure-Aufruf für Suricata die Option »–enable-nfqueue« zusätzlich an, bevor er Suricata übersetzt. Beim Start fügt er die Option »-q Netfilter-Queue« der Kommandozeile hinzu. Damit Iptables dann die Pakete auch tatsächlich an Suricata liefert, muss er entsprechende Iptables-Regeln erzeugen, zum Beispiel mit »iptables -I FORWARD -j NFQUEUE« .

Wer von Suricata erwartet, dass es HTTP-Verkehr nicht mehr allein am Port 80 erkennt, sondern dafür den kompletten TCP-Traffic analysiert, muss in der Suricata-Regel das Schlüsselwort »tcp« durch »http« ersetzen. Suricata unterstützt aktuell fünf Protokolle: HTTP, FTP, SMB, TLS und SSL. Damit das klappt, sind jedoch Regeln notwendig, die nicht mehr Snort-kompatibel sind. Das folgende Beispiel zeigt dies anhand der Emerging-Threats-Suricata-Regeln [13].

Die Regel aus Listing 4 analysiert jeden HTTP-Verkehr unabhängig von dem entsprechenden Port, also auch HTTP-Verkehr auf Port 10000. Snort kann zwar eine ähnliche Funktion mit Hilfe der Host-Attribute-Tabelle vorweisen, erstellt sie jedoch nicht automatisch. Der Admin muss diese Tabelle erzeugen und Snort mitteilen, dass das HTTP-Protokoll auch auf ungewöhnlichen Ports vorkommt. Erst dann analysiert auch Snort HTTP-Traffic abseits der Standardports.

01 #by Kevin ross and mike cox
02 #
03 alert http $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ET WEB_SERVER Possible 3Com OfficeConnect Router Default User Account Remote Command Execution Attempt"; flow:established,to_server; uricontent:"/utility.cgi?testType="; nocase; uricontent:"IP="; nocase; uricontent:"|7C 7C|"; pcre:"/\x7C\x7C.+[a-z]/Ui"; reference:url,securitytracker.com/alerts/2009/Oct/1023051.html; reference:url,www.securityfocus.com/archive/1/507263; reference:url,www.securityfocus.com/bid/36722/info; reference:url,doc.emergingthreats.net/2010159; classtype:attempted-admin; sid:2010159; rev:4;)

Tuning

Administratoren, die das letzte aus ihrer Installation herauskitzeln wollen und über entsprechend CPU- und RAM-Ressourcen verfügen, können zusätzlich die Detection Engine tunen. Vorher sollten sie jedoch prüfen, ob sie nicht auf einzelne Regeln (Signaturen) verzichten können. Je weniger Prüfungen pro Paket erforderlich sind, desto schneller arbeitet Suricata. Weil es oft jedoch schwer fällt zu entscheiden, welche Regeln nötig sind, versucht auch Suricata die Zahl der Regeln zu reduzieren, die es für jedes Paket abarbeitet. So ist es zum Beispiel unsinnig, für ein ICMP-Paket auch die TCP-Regeln zu analysieren.

Ähnlich wie Snort baut Suricata daher interne Regelgruppen in einem hierarchischen Baum. Der Admin überlässt die Parameter für diese Gruppen entweder Suricata oder bestimmt sie selbst. Im zweiten Fall wählt er als Profil für die Detection Engine »custom« und kann dann die Parameter festlegen (Listing  5). Das Beispiel ist dem Suricata-Wiki entnommen und benötigt etwa 32 GByte Arbeitsspeicher für die Regelgruppen bei einem normalen Regelsatz.

01 detect-engine:
02 - profile: custom
03 - custom-values:
04 toclient_src_groups: 100
05 toclient_dst_groups: 100
06 toclient_sp_groups: 100
07 toclient_dp_groups: 100
08 toserver_src_groups: 100
09 toserver_dst_groups: 100
10 toserver_sp_groups: 100
11 toserver_dp_groups: 100
12 - sgh-mpm-context: full
13 - inspection-recursion-limit: 3000

Der Regelgruppen-Baum wird zunächst aufgeteilt in die Protokolle (TCP, UDP, IP, HTTP). Anschließend erfolgt eine Einteilung entsprechend der Richtung des Pakets (»toclient« , »toserver« ). Nun teilt Suricata die Regeln in bis zu 100 Gruppen für die Source-Adressen und 100 Gruppen für die Destination-Adressen auf (Listing  5), ebenso die Regeln für die Source- und Destination-Ports.

Bei jedem Paket lässt sich so durch Prüfen dieses Baums sehr schnell ermitteln, welche Signaturen anzuwenden sind. Hier ist Sorgfalt geboten: Je geringer die Granularität bei der Aufteilung der Signaturen, desto mehr Signaturen muss Suricata je Paket analysieren.

Was die neue Version bringt

Administratoren, die bereits Suricata 1.0 oder ältere Versionen betreiben, sollten unbedingt ein Update auf die Version 1.1 in Erwägung ziehen. Zum einen haben die Entwickler den Pattern-Matching-Algorithmus überarbeitet. Endlich ist damit auch der Aho-Corasick-Algorithmus [14], der bei Snort bereits seit über acht Jahren Standard ist, nun auch in Suricata verfügbar. Alternativ ist der Cuda-basierte Algorithmus »b2g_cuda« interessant, dessen Dokumentation sich in den Quelltexten zu finden ist.

Im Inline-Modus lässt sich auch der Stream-Präprozessor besser nutzen, der die Zustände von TCP-Verbindungen und deren Re-Assemblierung überwacht. Auch die Unterstützung für PF_Ring präsentiert sich in Version 1.1.1 überarbeitet und deutlich verbessert. Suricata kann nun auch mit mehreren Netzwerkkarten gleichzeitig umgehen, wobei der Administrator für jede Netzwerkkarte die Anzahl der Threads definiert, die er startet lassen will.

Suricata 1.1.1 kommt auch mit einer modernisierten Protokollierung. Die neue Version nutzt das moderne Unified2-Format, das der Admin mit Barnyard2 [15] auswerten kann. Doch nur wenige Administratoren möchten für die Auswertung der gemeldeten Angriffe Protokolldateien durchforsten. Hier bietet sich vielmehr die grafische Oberfläche Snorby [16] an. Diese Oberfläche kann Snort-Meldungen und auch Suricata-Ereignisse, die per Barnyard2 in eine Datenbank geschrieben wurden, grafisch auswerten und anzeigen (Abbildung 1).

Abbildung 1: Das grafische Snort-Frontend Snorby zeigt mit Barnyard2 auch Suricata-Ereignisse an.

Fazit

Suricata bringt viele interessante Funktionen, zum Beispiel PF_Ring und Multithreading. Da es in der Regelsyntax kompatibel zu Snort ist, können Administratoren sämtliche Snort-Regeln weiternutzen. Die automatische Protokollerkennung ist ein Feature, das von Snort aktuell und wahrscheinlich auch in naher Zukunft nicht geboten wird. Das allein schon rechtfertigt die Mühe, sich eingehender mit dem wachsamen Erdmännchen zu beschäftigen.