© Jens Klingebiel, Fotlia.com

Snort ist der Open-Source-Standard für Netzwerk-Intrusion-Detection-Systeme. Nachdem es um die Entwicklergemeinde in letzter Zeit recht ruhig war, zeigen jüngere Erweiterungen wie Snorby, Open FPC und Pulled Pork, wie Admins mit dem IT-Schnüffelschwein ihr Netzwerk komfortabel und sicher überwachen.

In vielen Rechenzentren wacht das Network Intrusion Detection System (NIDS) Snort über die Sicherheit der Server. Dessen Konfiguration und Betrieb gilt als schwierig und macht Admins häufig zu schaffen. Doch jetzt schicken sich einige Tools an, das sichere IDS einfacher zu gestalten und in einem übersichtlichem Web-GUI zu präsentieren. Dieser Artikel zeigt den Weg zu einem umfangreichen und doch komfortablen Setup.

Altes Schwein

Bereits 1998 begann Marty Roesch mit der Entwicklung des Netzwerkschnüfflers [1]. Seine erste Version bestand aus gerade 1200 Zeilen Code, doch über die Jahre entwickelte er daraus eine der mächtigsten NIDS-Engines. 2001 gründete er die Firma Sourcefire [2], die sich auf den Bau leistungsfähiger NIDS-Appliances spezialisierte und das Snort-Projekt im Gegenzug finanziell unterstützt.

Snort selbst ist nur die Engine, die den Traffic analysiert, normalisiert und dann mit Hilfe von Signaturen nach verdächtigen Paketen sucht. Sie enthält keine Werkzeuge zur Verwaltung der Signaturen, zur Speicherung und Analyse der Meldungen in einer Datenbank oder zur forensischen Aufzeichnung.

In der Vergangenheit haben Admins hier Werkzeuge wie Oinkmaster [3] oder Base [4] genutzt, doch sind diese Projekte verwaist oder eingeschlafen. Jetzt schließen mit Snorby [5], Open FPC [6] und Pulled Pork [7] einige neue Projekte diese Lücke. Dieser Artikel beschreibt die Installation, Konfiguration und Funktion dieser Addons. Wer das ganze Setup schneller testen will, greift zur DELUG-DVD, wo eine virtuelle Maschine auf der Basis von Insta-Snorby ([8], siehe Kasten “Insta-Snorby”) für einen unkomplizierten Einstieg sorgt.

Mit der Version 2.9 haben die Snort-Entwickler die neue Data Aquisition Library (DAQ, siehe Kasten “DAQ”) eingeführt, die die klassische Libpcap-Bibliothek [9] komplett ersetzt. Vor dem Übersetzen bedarf es also installierter DAQ-, aber auch Dnet- und PCRE-Bibliotheken. Mögliche Anpassungen des »./configure« -Skripts für Snort erläutert Tabelle 1. Auch wenn bereits an dieser Stelle zahlreiche Datenbank-Konfigurationen möglich wären, sollte der Admin hier darauf verzichten, denn im weiteren Setup übernimmt Barnyard [10] diese Rolle.

Das Snort-Quelltextarchiv liefert leider nur ein Startskript für Red-Hat- und Fedora-basierte Distributionen. Das muss der Admin entweder für seine eigene Installation anpassen oder er schreibt sein eigenes Startskript rund um den Aufruf von Snort via »/usr/local/bin/snort -c /etc/snort/snort.conf« . Vor dem ersten Start kopiert er noch den Inhalt des »etc« -Verzeichnisses aus dem Quelltextarchiv nach »/etc/snort/« und legt das Verzeichnis »/var/log/snort« an. Bei der Anpassung von »snort.conf« hilft der Kasten “Snort-Konfiguration”.

config daemon
config interface: eth0
config daq: afpacket
config daq_mode: passive
config daq_var: buffer_size_mb=256
ipvar HOME_NET 192.168.0.0/24
var RULE_PATH /etc/snort/rules
var SO_RULE_PATH /etc/snort/so_rules
var PREPROC_RULE_PATH /etc/snort/preprocU
_rules

Signaturen

Jetzt benötigt das Schweinchen noch Signaturen für die Trüffelsuche. Die verschafft ihm der Admin aus diesen drei möglichen Quellen:

• Ruleset des Sourcefire Vulnerability Research Team (VRT)
• Emerging Threats Rules
• GPL Ruleset

Die Regeln wollen aber auch fortlaufend auf dem aktuellen Stand gehalten sein, dafür kommt später (siehe weiter unten) Pulled Pork zum Einsatz. Strebt der Admin den produktiven Betrieb von Snort an, sollte er entweder den VRT- oder den Emerging-Threats-Regelsatz verwenden. Beide sind in einer kommerziellen und einer kostenlosen Version erhältlich. Bei den Rules vom Vulnerability Research Team kann der Admin zwar kostenlos auf den gesamten Regelsatz zugreifen, aber nicht auf den aktuellen, sondern erst nach jeweils 30 Tagen Wartezeit. Bei den Emerging Threats Rulesets enthält die kostenpflichtige mehr Regeln als die Gratisversion.

Das folgende Beispiel verwendet die VRT-Regeln. Mit dem kostenlosen Abonnement oder der bezahlten Subskription versendet Sourcefire einen Oink-Code, den der Admin beim Download im Dateinamen angibt:

wget http://www.snort.org/reg-rules/snortrules-snapshot-2903.tar.gz/Oinkcode -Osnortrules-snapshot-2903.tar.gz

Im VRT-Regelpaket sind vier Unterverzeichnisse enthalten: In »etc« liegen angepasste Konfigurationsdateien, die Snort und Barnyard für diesen Regelsatz benötigen. Die sollte der Admin in das Verzeichnis »/etc/snort« kopieren. »rules« enthält die textbasierten Regeln für Snort, es landet komplett in »/etc/snort/rules« . Unter »preproc_rules« liegen die Regeln für die Präprozessoren. Dieses Directory kopiert der Admin nach »/etc/snort/preproc_rules« .

Zu guter Letzt findet er noch binäre Regeln für Snort in »so_rules« . Daraus kopiert er das Unterverzeichnis für die jeweilige Distribution (zum Beispiel »so_rules/precompiled/Ubuntu-10-4/x86-64/ 2.9.0.3/*« ) nach »/usr/local/lib/snort_dynamicrules« und die enthaltenen ».rules« -Dateien in das Verzeichnis »/etc/snort/so_rules/« .

Das Sourcefire Vulnerability Research Team veröffentlicht einige Regeln nur in binärer Form und gibt dafür zwei Gründe an. Zum einen sei die Snort-Regelsprache zwar eine sehr mächtige Sprache, genüge bei manchen Angriffen aber nicht für die Erkennung verdächtiger Pakete. Hier verbessern binäre Bibliotheken die Erkennung deutlich. Der zweite Fall liegt vor, wenn Dritte Sicherheitslücken nur unter Einhaltung einer Verschwiegenheitspflicht (NDA) an Sourcefire gemeldet haben. Durch die Verbreitung von Klartextsignaturen würde in diesem Fall das VRT-Team unerlaubt Details veröffentlichen.

Updates mit Pulled Pork

Für die Updates der Regelsätze verwendeten die meisten Snort-Anwender Oinkmaster. Nachdem dessen Weiterentwicklung einschlief, übernahm oft Pulled Pork diesen Job. Es verarbeitet auch binäre Regeln und kümmert sich selbstständig um die richtigen Verzeichnisse. In der aktuellen Version 0.5.0 benötigt Pulled Pork Perl und die Module Archive::Tar, Crypt::SSLeay und LWP::Simple, die fast alle Distributionen über die Paketverwaltung erhalten.

Nach der Pulled-Pork-Installation kopiert der Admin das Verzeichnis »etc« nach »/etc/pulledpork« und das Perl-Skript »pulledpork.pl« nach »/usr/local/bin« . Die Konfigurationsdatei »pulledpork.conf« ist weitgehend selbsterklärend. Wichtig sind eigentlich nur die Anpassung der Rule-URL um den Oink-Code und die Pfade für die Regeln, je nach Distribution auch für die Shared Object Rules.

Auf Wunsch passt Pulled Pork schon bei der Installation die Regeln an. Hierzu verwendet es vier weitere Konfigurationsdateien:

• »dropsid.conf« : Pulled Pork verändert alle in dieser Datei aufgeführten Regeln so, dass Snort als IPS die Pakete verwirft.
• »enablesid.conf« und »disablesid.conf« : Pulled Pork schaltet die Regeln in diesen Dateien an oder aus.
• »modifysid.conf« : Pulled Pork modifiziert die Regeln der hier angegebenen Dateien.

Den Start erledigt ein einfaches »pulledpork.pl -c /etc/pulledpork/pulledpork.conf« . Vor dem Download der Regeln prüft das gezogene Schweinchen anhand von Prüfsummen, ob die Regeln auf dem Server neuer sind. Ein täglicher Cronjob erledigt das automatisch.

Barnyard

Ist Snort entsprechend den Vorgaben installiert, dann protokolliert es seine Meldungen im Unified-2-Format in einer binären Datei. Da der Admin diese nicht direkt lesen kann, benötigt er ein weiteres Werkzeug, um die Daten beispielsweise in einer Datenbank zu speichern. Hier kommt Barnyard 2 (“Scheunenvorhof”) ins Spiel. Das Tool entkoppelt die zeitaufwändige Protokollierung in der Datenbank vom Snort-Prozess und entlastet so den Server. Das Sourcecode-Archiv steht auf der Webseite [10], die Installation der Quellen stellt den Admin normalerweise vor keine Probleme.

Barnyard liest die Dateien im Verzeichnis »/var/log/snort« und schreibt deren Inhalte in die Datenbank. Snort legt in dem Verzeichnis die Dateien nach dem Schema »merged.log.Timestamp« an. Mit Hilfe dieses Datums kann Barnyard alte Dateien ignorieren. Wenn es fehlt, sollte der Admin die Option »nostamp« in der Konfigurationsdatei des Unified-Output-Plugin entfernen.

Da die Unified-Logdatei zunächst nur unleserliche Binärinformationen enthält, benötigt Barnyard Zugriff auf weitere Snort-Konfigurationsdateien, um die Daten zu übersetzen. Deren Pfade gibt der Admin in der Konfigurationsdatei »/usr/local/etc/barnyard2.conf« vor und passt die restlichen Einstellungen an, etwa so:

config utc
config daemon
config logdir: /tmp
config waldo_file: /var/log/snort/waldo
#output alert_fast: stdout
output database: log, mysql, user=snort password=snortpw dbname=snortdb host=localhost

Bevor Barnyard2 startet, erzeugt Root noch die Datenbank:

# cat << EOF | mysql -u root -p
create database snortdb;
grant all on snortdb.* to snort@localhostidentified by "snortpw";
EOF
# mysql -u snort --password=snortpw snortdb< schemas/create_mysql

Für automatische Starts sorgt

barnyard2 -d /var/log/snort/ -f merged.log-c /usr/local/etc/barnyard2.conf -n

im Startskript. Mit der Option »-n« prozessiert Barnyard 2 nur neue Meldungen, die Snort an die Protokolldatei angehängt hat. Damit Barnyard auch beim Neustart alte Meldungen ignoriert, speichert es ein Lesezeichen in der Waldo-Logdatei, die die genannte Konfiguration spezifiziert.

Snorby

Nächster Punkt auf der Liste ist das Webfrontend Snorby. Das gibt es zwar offiziell nur über sein Git-Repository, doch unter [12] finden sich auch immer wieder Tarballs. Vor der Installation muss der Admin einige Voraussetzungen erfüllen: Ruby (mindestens 1.8.7), Rubygems und die beiden folgenden Edelsteinchen sind nötig: »tzinfo builder memcache-client rack rack-test erubis mail text-format bundler thor i18n sqlite3-ruby« und »rack-mount rails« ab 3.0.0.

Speziell die Ruby-Anforderungen erzwingen praktisch eine aktuelle Distribution oder die Installation auch dieser Pakete aus den Quellen. Ubuntu ab Karmic und Fedora 14 bringen Ruby in Version 1.8.7 mit, Rails in der Version 3 ist in keiner dieser Distributionen enthalten. Jetzt ruft der Admin im entpackten Snorby-Verzeichnis »bundle install« auf, was noch ein paar Pakete zieht. Mit »rake snorby:setup« installiert er endlich Snorby.

Einige Anpassungen in den weitgehend selbsterklärenden Dateien »snorby/config/snorby_config.yml« und »snorby/config/initializers/mail_config.rb« sind jetzt noch Pflicht, dann steht dem Start von Snorby mit »rails -c« nichts mehr im Wege und das Login grüßt (Abbildung 1). Nach der Anmeldung landet der Anwender im Snorby-Dashboard, einem modernen, übersichtlichen GUI für die eingegangenen Meldungen (Abbildung 2) mit vielen Funktionen.

Abbildung 1: Die Live-Linux-Distribution Insta-Snorby (auf der DELUG-DVD) verlangt die Anmeldung mit snorby@snorby.org und dem Kennwort snorby.

Abbildung 2: Das Snorby-Dashboard bietet grafische Darstellungen und sortiert die Meldungen.

Zu jedem Event kann der Admin hier Details einsehen (Abbildung 3). Snort erkennt die potenziellen Angriffe auf das Netzwerk und protokolliert verdächtige Pakete, die einen Alarm auslösten. Oft ist es da aber schon zu spät, denn leider kann selbst Snort die Zeit nicht zurückdrehen, um vorher übertragene Pakete nachträglich zu protokollieren. Die vollständige forensische Analyse eines erfolgreichen Angriffs auf Netzwerkebene ist so kaum möglich.

Abbildung 3: In der Weboberfläche klassifiziert der Admin Ereignisse, versieht sie mit Notizen und verwaltet Sensoren und Benutzer. Snorby erweist sich dabei als sehr ausführlich und umfangreich.

Open FPC

Dafür gibt es seit Kurzem Open FPC. Das Open-Full-Packet-Capture-Projekt stammt ebenso wie Pulled Pork von Sourcefire-Mitarbeitern, liegt in der jungen Version 0.4 vor und benötigt zur Installation eine ganze Reihe zusätzlicher Pakete. Deren Installation gelingt auf einer Debian-basierten Distribution mit:

aptitude install apache2 daemonlogger tcpdump tshark libarchive-zip-perl libfilesys-df-perl libapache2-mod-php5 mysql-server php5-mysql libdatetime-perl libdbi-perl libdate-simple-perl php5-mysqllibterm-readkey-perl libdate-simple-perl

Nach dem Auspacken des Open-FPC-Quelltextes ruft der Admin das Installationsskript »openfpc-install.sh install« auf und beantwortet die dort gestellten Fragen (zum Beispiel nach Benutzer und Kennwort). Weitere Einstellungen nimmt er in »/etc/openfpc/openfpc-default.conf« vor. Anschließend startet er den Server und prüft die Verfügbarkeit vom Client aus:

openfpc --action start
openfpc-client --action status

Für künftige Starts schon beim Booten finden sich Startskripte in »/etc/init.d« . Für die Integration in Snorby muss der Admin nur noch eine kleine Anpassung über das Web-GUI vornehmen. In der Administrationsoberfläche aktiviert er das Open-FPC-Plugin und gibt den Pfad zu Open FPC an: »https://Open-FPC-Server/openfpc/cgi-bin/extract.cgi« (Abbildung 4). Anschließend kann er direkt von der Alarmmeldung in Snorby eine Pcap-Datei der gesamten Verbindung herunterladen (Abbildungen 5 und 6) und danach mit beispielsweise Wireshark analysieren (Abbildung 7).

Abbildung 4: Im Administrationsmenü von Snorby nimmt der Admin Einstellungen für Reports vor.

Abbildung 5: Für den Datenexport in eine PCAP-Datei präsentiert Snorby dem Admin eine Eingabemaske, in der er jene Pakete spezifiziert, die Open FPC extrahieren soll.

Abbildung 6: Open FPC bietet die PCAP-Datei zum direkten Download und Import in Wireshark an.

Abbildung 7: Mit Tools wie Wireshark analysieren Admins den von Snort als verdächtig erkannten Traffic.

Aus Sicherheitsgründen sollte der Admin Snort keinesfalls mit Root-Rechten betreiben, sinnvoll ist dagegen ein dedizierter Benutzer für Snort, dessen Name und Gruppe in der Konfigurationsdatei von Snort landet:

config set_uid: snort
config set_gid: snort
config chroot: /chroot/snort

Die dritte Zeile zeigt, wie sich Snort in ein Chroot einschließen lässt. Natürlich sind danach noch einige Anpassungen bei den Rechten und der Verzeichnisstruktur vorzunehmen, damit Snort nicht stolpert.

Fragmentierung

Snort beherrscht auch fortgeschrittene Methoden wie die zielbasierte (Target-based) Rekonstruktion des Datenverkehrs. Die Forscher Vern Paxson und Umesh Shankar erkannten 2003, dass Betriebssysteme die IP-Defragmentierung und TCP-Reassemblierung sehr unterschiedlich durchführen. Dies erlaubt es einem Angreifer, eine Attacke so zu verschleiern, dass der Angriff auf dem Zielsystem erfolgreich ist, ohne dass das IDS den Angriff erkennt.

Hierzu fragmentiert der Angreifer zum Beispiel seine Daten. Das Fragment, das anschließend die wesentlichen Komponenten des Angriffs enthält, erzeugt der Angreifer zweimal. Ein Fragment enthält den Angriff, ein zweites harmlose Daten. Werden beide nacheinander losgeschickt, hängt der Erfolg des Angriffs beziehungsweise die Erkennung des IDS davon ab, wie die entsprechenden Systeme reagieren. Bevorzugen sie das erste oder das zweite Fragment bei der Defragmentierung? Durch eine geschickte Wahl der Parameter kann der Angreifer die Attacke durchführen, ohne dass das IDS ihn überhaupt erkennt.

Ähnliche Unterschiede gibt es bei TCP-Segmenten und überlappenden Fragmenten. Damit Snort diese Angriffe immer richtig erkennen kann, muss es die Pakete genauso defragmentieren und reassemblieren, wie es auch das jeweils angegriffene System tun würde. Snort stellt dieser fortgeschrittenen Angriffstechnik eigene Methoden entgegen: Für die Defragmentierung unterstützt es »first« , »last« , »bsd« , »bsd-right« , »linux« , »windows« und »solaris« , der Default ist »bsd« . Die komplexeren Methoden der Reassemblierung zeigt Tabelle 2.

Für Linux- und Windows-Setups ist die Konfiguration in »snort.conf« einfach:

preprocessor frag3_engine: policy linux bind_to [10.1.1.12/32,10.1.1.13/32] detect_anomalies
preprocessor frag3_engine: policy windows bind_to 10.2.1.0/24 detect_anomalies

Diese Konfiguration reicht für ein Windows-Netzwerk mit zwei Linux-Rechnern. Mit der gleichen Vorgehensweise lässt sich der Stream-5-Präprozessor anpassen. Weitere Details finden sich in der Datei »README.stream5« aus dem Dokumentationsverzeichnis des Snort-Quelltextes.

Bei vielen verschiedenen Systemen im LAN ist eine solche Verwaltung zu aufwändig. Hier hilft eine Host Attribute Table, die die Informationen in einer XML-Datei definiert. Die ist in »snort.conf« mit »attribute_table filename /Pfad_zur_Datei« angegeben und enthält die Informationen über die einzelnen Rechner (Listing 1). Diese XML-Datei erzeugt der Admin zum Beispiel direkt aus einem Nmap-Scan mit Hogger ([14], bedeutet etwa Mast- oder Schlachtschwein).

01 <SNORT_ATTRIBUTES>
02 <ATTRIBUTE_TABLE>
03  <HOST>
04  <IP>10.1.2.3</IP>
05  <OPERATING_SYSTEM>
06   <NAME>
07   <ATTRIBUTE_VALUE>Windows</ATTRIBUTE_VALUE>
08   </NAME>
09   <FRAG_POLICY>Windows</FRAG_POLICY>
10   <STREAM_POLICY>Win XP</STREAM_POLICY>
11  </OPERATING_SYSTEM>
12  <SERVICES>
13   <SERVICE>
14    <PORT>
15     <ATTRIBUTE_VALUE>80</ATTRIBUTE_VALUE>
16    </PORT>
17    <IPPROTO>
18     <ATTRIBUTE_VALUE>tcp</ATTRIBUTE_VALUE>
19    </IPPROTO>
20    <PROTOCOL>
21     <ATTRIBUTE_VALUE>http</ATTRIBUTE_VALUE>
22    </PROTOCOL>
23   </SERVICE>
24  </SERVICES>
25  </HOST>
26 </ATTRIBUTE_TABLE>

Rennschwein?

Bei intelligenter Kombination der schweinischen Komponenten lässt sich mit Snort ein sehr mächtiges Netzwerk-Intrusion-Detection-System aufbauen. Natürlich sollte der Admin beachten, dass er für entsprechend schnelle Netze auch entsprechend hochwertige Hardware einsetzen muss. Appliances wie Sourcefire schaffen es, mit Snort 2.9 auf Spezialhardware bis zu 10 GBit/s schnelle Netze zu überwachen. Standardhardware stößt dagegen in der Regel schon bei 1 GBit/s an ihre Grenzen. Hier bestimmen qualitativ hochwertige Netzwerkkarten wie die von Napatech [15], viel Speicher und hohe CPU-Leistung das Maß der Dinge. Außerdem müssen Admins mit solchen Ansprüchen auch die Parameter der Präprozessoren dem zu nutzenden Hauptspeicher anpassen.

Mit Snort 10 GBit/s zu erreichen ist zwar möglich, erfordert aber viel Erfahrung, geeignete Hardware und intensives Feintuning aller Komponenten. Steven Sturges von Sourcefire beantwortet deshalb die Frage nach der größten Snort-Herausforderung kurz und knapp: Speed (Geschwindigkeit). Erklärend fügt er an: “500 MBit/s in Echtzeit zu analysieren ist nicht schwer, die Herausforderung kommt, wenn du das mit 10 GBit/s versuchst!”