Intrusion Detection mit Snort, Snorby, Open FPC und Pulled Pork

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.