Intrusion Detection am Beispiel von Snort (Teil 1)
Diese Ausarbeitung entstand nicht ohne Grund. Erstens mal trifft sie im Ganzen das Interessengebiet der beiden Autoren und zweitens gibt es kaum deutsche Ausarbeitungen zum Thema Intrusion Detection im Allgemeinen und zu Snort im Besonderen.
Sollte nun ein Angreifer versuchen, in einen Computer oder ein Netzwerk einzudringen, auf dem ein solcher Packet Analyser installiert ist, so schlägt dieser Alarm, protokolliert den Angriff und kann ihn eventuell abwehren. Letzteres zählt aber eher zur Aufgabe von Intrusion Response Systemen, auf welche hier nur in beschränktem Maße eingegangen werden soll. Hier ist aber noch erwähnenswert, dass manche ID Systeme gewisse Möglichkeiten bieten, um auf einen Angriff zu reagieren und so auch eine gewisse Intrusion Response Möglichkeit bieten.

Generell kann man ein Intrusion Detection System als eine Art Alarmanlage ansehen. Sollte ein Einbruch vom System entdeckt werden, wird der Administrator benachrichtigt (über Pager, SMS, eMail, WinPopup-Message, etc.) und kann dann entscheiden, wie er mit dem Problem umgeht. Im Extremfall wird er sich entscheiden, das System herunterzufahren oder in den Single-User-Mode bringen, um es keinem weiteren Missbrauch auszusetzen und sich ungestört der Behebung des ausgenutzten Fehlers widmen zu können.
Die Konfiguration solcher Systeme ist sehr vielfältig und kann je nach Ausführung auch sehr umfangreich werden. Die größten Unterschiede liegen wohl darin, ob man ein solches IDS für einen einzelnen Rechner einsetzen möchte oder ein ganzes Netz absichern will. Bei der Konfiguration ist es wichtig, dass die Integrität der Konfigurationsdaten gesichert ist und das im Falle eine Einbruchsmeldung selbige auch garantiert wird, das heißt, dass es sich um einen echten Angriff handelt und nicht etwa um einen Fehlalarm, der als Folge einer Fehlkonfiguration entstand. Nach der Installation eines IDS im Netzwerk wird der Administrator die ersten Wochen nach der Installation mit der Analyse des Netzwerkverkehrs verbringen, um die normale Kommunikation des zu sichernden Netzes von Gefährdungen desselben zu unterscheiden. Tut er dies nicht und verläßt sich der Einfachheit halber auf frei erhältliche Konfigurationen oder auf die Standardkonfiguration, kann es zu sogenannten False Positives oder auch False Negatives kommen. Die Gefahren einer Fehlkonfiguration werden in Abschnitt 4 genauer beschrieben.
1.2Funktionalität eines IDS

Im Allgemeinen erledigt ein IDS seine Arbeit in drei Schritten, wie Abbildung 2 veranschaulicht. Im Nachfolgenden werden die Schritte im Einzelnen erläutert.
1.2.1Datensammlung
Im ersten Schritt werden Daten gesammelt. Am Beispiel eines Network Intrusion Detection Systems handelt es sich hierbei um die Pakete, die das Netzwerk passieren. Somit verfolgen solche Systeme einen präventiven Ansatz, da sie einen Angriff erkennen können, während er stattfindet und gegebenenfalls Gegenmaßnahmen treffen können. Aber auch Protokolldaten, die sowohl vom Betriebssystem als auch von der auf dem Host laufenden Software abgelegt werden, können als Grundlage für die Entdeckung von Einbrüchen dienen. Sie bieten aber nur Informationen der Applikationsebene und lassen im Idealfall nur auf Angriffe auf bestimmte Programme schließen. Dieses Vorgehen wird als reaktionäres Intrusion Detection bezeichnet, da es einen Angriff nur im Nachhinein erkennen läßt und der Administrator nur für die Zukunft präventive Maßnahmen treffen kann. Außerdem ist in gewissem Maße auch die Vergabe von Betriebsmitteln durch das Betriebssystem an die laufenden Prozesse zur Auswertung interessant. Hierzu zählen mitunter die Auslastung der CPU, belegter Speicher, aktive Netzwerkverbindungen, usw.
1.2.2Datenanalyse
Im zweiten Schritt werden diese Daten vom System analysiert, um dem Administrator in einem dritten Schritt Angriffe benutzergerecht aufzuzeigen. Für die Technik des Erkennungsprozesses existieren zwei Möglichkeiten. Die erste ist die Missbrauchserkennung, die anhand vordefinierter Muster Einbrüche zu erkennen versucht. Hier werden etwa Netzwerkpakete mit Hilfe von vorgegebenen Signaturen überprüft und mit Pattern-Matching Angriffe erkannt. Mit dieser Methode arbeitet auch Snort. Über das Internet kann man auf eine große Anzahl von Konfigurationen für eine Unmenge an Angriffssignaturen zurückgreifen. In Abschnitt 2.2 wird darauf näher eingegangen. Daraus läßt sich schließen, dass die Voraussetzung für die Missbrauchserkennung eine für den stattfindenden Angriff passende Signatur ist und dass das IDS selbstverständlich Zugriff auf diese Signatur hat.
Exkurs: Der letzte Abschnitt führte den Begriff der Signatur ein. Hier bezog sich der Begriff auf den Fingerprint eines Angriffs. Jeder Angriff erzeugt bestimmte Pakete, die sich entweder durch einen String auf Applikationsebene, wie z.B. /cgi-bin/phf für ein CGI-Probe, durch eine bestimmte Konstellation gesetzter TCP-Flags, wie z.B. der XMas-Tree-Scan, bei dem alle Flags gesetzt sind, oder ähnliche Merkmale auszeichnen. So kommt die Signatur zustande, die jeden Angriff auszeichnet. Ähnliche Bedeutung hat die Signatur, anhand derer ein IDS einen Angriff erkennt. Eigentlich stellt diese Signatur nur das Ebenbild des Fingerprints eines Angriffs dar, allerdings in der Form, in der sie das IDS verarbeiten kann. Ähnlich den Regeln eines Paketfilters, anhand der er Pakete passieren läßt oder nicht, benötigt ein IDS eine Reihe von Signaturen, d.h. Regeln, um die entsprechenden Angriffe zu erkennen. Für perfekte Verwirrung sorgt hier noch die digitale Signatur, auf die aber erst später eingegangen wird.
Eine andere Technik der Analyse ist die Anomalieerkennung. Sie stellt eine Art Heuristik dar und versucht, auch unbekannte Angriffe zu erkennen. Eine Anomalie wäre am Beispiel eines Network Intrusion Detection Systems eine Abweichung vom normalen Netzwerkverkehr. Natürlich stellt eine Anomalie nicht immer eine Gefahr dar, weswegen eine längere Einlaufzeit für das System wie weiter oben schon erwähnt von elementarer Bedeutung ist, um ihm den normalen Netzwerkverkehr »beizubringen«. In einem anderen Umfeld sind hier natürlich auch Dinge wie die Auslastung der CPU von Bedeutung, da das System auf Dauer von einem Durchschnittswert ausgehen können muss, um eine Anomalie zu erkennen. Dieses Vorgehen verfolgt somit statistische Ansätze. Wenn ein zu überwachender Parameter außerhalb der definierten Akzeptanzschwellen liegt, wird Alarm ausgelöst.
Eine zweite Herangehensweise der Anomalieerkennung verfolgt logische Ansätze. Hierbei wird im Gegensatz zum statistischen Ansatz die zeitliche Abfolge von Ereignissen in Betracht gezogen. Dieser logische Ansatz betrachtet bestimmte Ereignisfolgen als typisch. Beobachtet das System den Anfang einer solchen Ereignisfolge, erwartet es, dass auch der Rest dieser Ereignisfolge abläuft. Passiert dies nicht, schlägt das System Alarm.

