Intrusion Detection am Beispiel von Snort (Teil 2)
An dieser Stelle sollen nicht die Vorteile von Open-Source-Software diskutiert werden. Dieser oftmals aussichtslose K(r)ampf hat schon Freundschaften gespalten und zu sinnlos langen Diskussionen geführt. Vielmehr ist die freie Verfügbarkeit von Snort in Bezug auf Intrusion Detection-Systeme ein wichtiger Kostenfaktor. Hier bietet Snort gegenüber kommerziellen Intrusion Detection-Systemen einen klaren Vorteil, nämlich die Tatsache, dass nur die Kosten für die Installation, Konfiguration und Pflege des Systems zu beachten sind. Kommerzielle Systeme bringen zusätzlich noch den Kostenfaktor des Kaufs mit sich.
3.2Alarmierungs- und Logmöglichkeiten
Snort bietet diverse Möglichkeiten, auf einen erkannten Einbruch aufmerksam zu machen. Sie lassen sich entweder einzeln oder kombiniert nutzen, aber mehr dazu in Abschnitt 6.1.1 und Abschnitt 6.2.2. Die erste Möglichkeit, quasi der Klassiker, ist die Benachrichtigung über syslog. Soll Snort Alarmmeldungen in seinem eigenen Logfile protokollieren, so kann es dies auf zwei Arten tun, entweder schnell oder vollständig. Die erste Methode empfiehlt sich bei hohem Netzaufkommen, da hier nicht alle Paketheader gesichert werden. Daraus ergibt sich schon, was die zweite Methode tut, nämlich alle Meldungen samt kompletten Paketheadern sichern. Die letztere Methode ist allerdings dadurch auch erheblich langsamer, da hier ein nicht zu verachtender Aufwand für die Formatierung der entsprechenden Daten betrieben werden muss.
So man als Administrator ein Fan von WinPopup-Messages ist, kann man auf die Alarmierung per SMB-Message zurückgreifen und sich so über einen Angriff oder Einbruch benachrichtigen lassen. Dies bietet sich vor allem dann an, wenn der Administrator unter Windows zu Hause ist, aber auch mit Samba lassen sich diese Nachrichten sinnvoll auswerten.
Ein noch experimentelles Feature ist die Benachrichtigung über einen Unix-Socket. Hierfür erstellt Snort einen Socket, aus dem andere Programme dann entsprechend die Daten auslesen und auswerten können.
Neben den Alarmierungsmöglichkeiten bietet Snort noch diverse Möglichkeiten, in denen es Paket-Informationen sichern kann. Dies kann im tcpdump-Format geschehen. Hier besteht der Vorteil in den vielen Programmen, die dieses Format verstehen und auswerten können. Eine andere Variante ist das Formatieren mit Hilfe von XML. Am CERT wurde die sogenannte SNML10 entwickelt, mit deren Hilfe Snort die Daten formatiert in eine Datei oder eine Datenbank sichern kann.
Weiterhin kann Snort in eine Datenbank wahlweise loggen oder seine Alarmmeldungen absetzen. Mehr dazu folgt in Abschnitt 3.3.
3.3Visualisierung der Ergebnisse
Nach einem erfolgten Angriff ist es elementar, die gesammelten Daten zu sichten, um sie für etwaige Maßnahmen auszuwerten. Mit diversen Zusatzprogrammen ist es möglich, die Daten grafisch aufzuarbeiten. Hier stehen ACID und SnortSnarf an erster Stelle. ACID greift auf Daten zurück, die Snort in eine Datenbank loggt. Bis dato bietet Snort Unterstützung für Oracle, MySQL, PostgreSQL oder ODBC11. ACID basiert auf PHP12 und bereitet die gesammelten Daten grafisch auf. SnortSnarf wurde von der Firma Silicon Defense ([7]) entwickelt und besteht aus einer Reihe von Perl-Skripten. Prinzipiell bereitet es die Daten auch auf, aber trotzdem ist der Output teilweise noch sehr kryptisch. Hier hat ACID die Nase vorn.
Neben der grafischen Aufbereitung steht dem Administrator natürlich nichts im Weg, wenn er selbst Einblick in die Logdateien nehmen will. Snort sammelt seine Daten in einem Verzeichnis und diversen Unterverzeichnissen, die nach der IP-Adresse benannt werden, von der der Angriff ausging. Daten über Portscans werden in einer gesonderten Datei gesichert.
3.4Gegenmaßnahmen
Snort bietet in beschränktem Maße Möglichkeiten der Intrusion Response. Über die libnet läßt sich die sogenannte Flexible Response nutzen. Somit kann man über die Rules von Snort Reaktionen auf Angriffe auslösen. Die Möglichkeiten erlauben eine explizite Beendigung der TCP-Verbindung über ein RST-Paket oder über ICMP. Bei letzterem besteht die Wahl zwischen »Net unreachable«, »Host unreachable«, ein »Port unreachable« oder allen dreien auf einmal.
Prinzipiell sei aber auch noch einmal in Frage gestellt, ob eine Response vonnöten ist. Mehr dazu findet sich in Abschnitt 1.6.
4Gefahren einer Fehlkonfiguration
Wie schon in Abschnitt 1.5 erwähnt, erfordert es einen gewissen Aufwand, das System in das lokale Netzwerk einzuarbeiten. Setzt man kein Network Intrusion Detection System, sondern ein Host Based Intrusion Detection System ein, so erfordert dies nichtsdestotrotz eine gewisse Einarbeitung in die Umstände des zu überwachenden Hosts. Daten, die den Standardbetrieb des Systems ausmachen, wollen gesammelt und Akzeptanzschwellen definiert werden. Je nach Art der Analyse sind unterschiedliche Methoden der Einarbeitung vonnöten. Für Missbrauchserkennung muss der Administrator entweder den Netzwerkverkehr, der normalerweise das Netzwerk passiert, kennen oder selbigen vor der Konfiguration des Intrusion Detection Systems analysieren, um eine möglichst effiziente Zusammenstellung von Signaturen zu finden. Anomalieerkennung erfordert eine quasi Eingewöhnung in die lokalen Umstände, um zu erkennen, welcher Netzverkehr sich in normalen Schranken bewegt und welcher vom normalen Verkehr abweicht. Hier ist eine relativ lange Eingewöhnungsphase nötig, da auch Verkehr, der vielleicht nur einmal im Monat stattfindet, etwa durch ein Netzwerkbackup o.ä, berücksichtigt werden muss. Bei einem Intrusion Detection System, welches mit Missbrauchserkennung arbeitet, ist ein Fehlalarm nicht unbedingt dramatisch, da der Administrator schnell noch eine oder mehrere weitere Signaturen hinzufügen kann. Löst ein System, welches mit Anomalieerkennung arbeitet, einen Fehlalarm aus, kann es aufwendig sein, dem IDS den neuen Umstand, den es als normal erkennen soll, beizubringen.
Die schon erwähnten Fehlalarme werden in der Praxis mit dem Anglismus False Positives bezeichnet. Ein Angriff, der dem Intrusion Detection System verborgen geblieben ist, heißt demnach False Negative. Auf beide wird nachfolgend kurz eingegangen, da sie im Zusammenhang mit Intrusion Detection auf keinen Fall unter den Tisch fallen gelassen werden dürfen.
4.1False Positives
Wie schon erwähnt handelt es sich bei den False Positives um Fehlalarme. Diese können die Folge einer nicht ausreichenden Konfiguration in Form der entsprechenden Signaturen sein oder dadurch entstanden sein, dass sich der Administrator auf ein Paket im Internet verfügbarer, auf bestimmte Netzwerkumstände angepasste Signaturdatenbanken verlassen hat.
