Die 7 W's zu IDS


WER & Wann?
Mit James Andersons 1980, fing alles an. Mit bekannt werden seines Textes für eine Regierungs Organisation tauchte das Konzept "detection" von Fehlanwendung und von spezifischen Benutzerfällen auf. Dieses führte zu enormen Verbesserungen in den Sicherheitsüberwachungen auf nahezu jedem Betriebssystem. Seine Arbeit war des Anfangs "Host-based Intrusion Detection" und IDS allgemein.

WAS?
Das Ziel der Intrusion Detection ist die automatische Erkennung von Angriffen auf Rechnersysteme, Fehlanwendungen und unregelmäßiges Verhalten .

WO?
Network-based Intrusion Detection:
Diese erkennt Angriffe auf beliebige Hosts im zu überwachenden Netzwerk oder auch vom entsprechenden Host ausgehende Angriffe auf andere Netzwerke bzw. Hosts. Neben dem Vorteil, dass man in Netzwerken oftmals nur noch ein einzelnes Intrusion Detection System zur Überwachung benötigt, bringen modernere Netzwerke aber auch Probleme für die Network-based Intrusion Detection mit sich. In einem geswitchten Netzwerk, wie man es heutzutage sehr häufig antrifft, kann ein Intrusion Detection System seine Arbeit nicht zuverlässig nachgehen, da es nicht mehr den gesamten Netzverkehr analysieren kann. Hier gibt es zwei Möglichkeiten, die diesem Problem entgegenwirken. Die erste sind sogenannte Monitoring-Ports, die moderne Switches zur Verfügung stellen, an die sämtlicher das Gerät passierender Netzverkehr weitergeleitet wird. Wird diese Möglichkeit im zu überwachenden Netz geboten, sollte sie genutzt werden.

Host-based Intrusion Detection:
Diese Art der Einbruchserkennung hat den Zweck, Einbrüche auf einem bestimmten Host festzustellen. Die Weiterentwicklung der Host-based Intrusion Detection Systeme sieht Mechanismen zur Beschränkung der Rechte selbst für Administratoren vor. Beispielsweise beschränkt das Linux Intrusion Detection System die Kommandogewalt des System-Administrators oder auch anderer Benutzer auf klar definierte Aktionen und vermindert so bei einem kompromittierten Administrator-Account den Schaden, der angerichtet werden kann.

Distributed Intrusion Detection Systeme:
Diese analysieren mit Hilfe von vielen verteilten Sensoren den Netzwerkverkehr bestimmter Subnetze. Häufig wird Distributed Intrusion Detection auch zur Analyse der verschiedenen Netzwerkprotokolle verwendet, umso das Datenaufkommen in sehr großen Netzwerken zu bewältigen.

WIE?
Ein Intrusion Detection System setzt sich aus drei Komponenten zusammen. Innerhalb der ersten Komponente, der Datensammlung, werden sämtliche Daten über System-Zustand, Betriebsmittelvergabe, usw. gesammelt, um sie mit der Komponente der Datenanalyse auf mögliche Angriffe zu untersuchen. Die dritte Komponente stellt schließlich die gesammelten Daten visuell dar.
Auf dieser Basis aufbauend werden zwei Konzepte der Intrusion Detection realisiert.
Eines ist die Signatur-basierte Einbruchserkennung, jeder Angriff zeichnet sich durch einen eigenen markanten Fingerabdruck ab. Das System verfügt über eine möglichst aktuelle und oftmals speziell auf die Bedürfnisse des zu überwachenden Netzwerkes zugeschnittene Datenbank von Angriffssignaturen, die stets auf dem neuesten Stand gehalten werden sollte, um auch neue Angriffe zuverlässig erkennen zu können.
Ein anderes Konzept, die Anomalie-Erkennung, arbeitet nach einem statistischen Prinzip. Es geht davon aus, dass bestimmte Objekte, seien es Benutzer oder Netzwerkverkehr, ein Verhalten aufweisen, welches prinzipiell gleich bleibend ist und bestimmte Muster und Merkmale aufweist. Die Anomalie- Erkennung sucht nach Änderungen oder Abweichungen des ihm bekannten Verhaltens.

WARUM?
Die Gründe, warum man sein Netzwerk oder auch nur einen Einzelrechner, der wichtige Aufgaben im Firmenumfeld hat, mit einem Intrusion Detection System absichern sollte, liegen heutzutage auf der Hand. Kaum ein Tag vergeht, an dem man nicht von neuen Hackversuchen oder Einbrüchen in Firmennetzwerken hört (hier ein Beispiel: Zone-h). So manche Kreditkartennummer hat durch Einbruchsversuche schon den Weg in die Finger böswilliger Cracker gefunden. Die Ursachen für einen möglichen Einbruch können sehr vielfältig sein. Der Angreifer kann zum Beispiel über Fehler in der Implementierung des TCP/IP-Stacks Zugriff auf das System oder dessen Ressourcen erhalten.
Ein Profi findet anhand einer Untersuchung des TCP/IP-Fingerprints, welchen ein System hinterlässt, heraus, um welches System es sich handelt und kann daraus auf etwaige Fehler in der Implementierung schliessen, um diese dann letzten Endes auszunutzen. Ein Einbruch kann aber auch über Fehler in der auf dem System verwendeten Software erfolgen. Häufige Ursache für solche Fehler sind die sogenannten Buffer Overflows. In letzter Zeit sind immer mehr Fehler in Programmen, seien es Buffer Overflows oder Fehler, durch die ein normaler Benutzer root-Rechte erlangen kann, bekannt geworden.
Letztenendes ist eine Kette immer nur so stark wie ihr schwächstes Glied, was zum Benutzer des Systems führt. Oftmals sind Einbruchsversuche auf falsch gewählte Passwörter zurückzuführen, was einen Einbruch in ein Rechnersystem erheblich erleichtert.
Hat ein Einbrecher erstmal einen Zugang zum System, ist es ein leichtes, zu noch höheren oder gar den absoluten, den root-Rechten auf einem Rechner zu gelangen. Läuft auf einem System beispielsweise der finger-Dämon, besteht schonmal die Möglichkeit, an etwaige Benutzerkennungen zu kommen, um mit deren Hilfe mit einem Dictionary bekannte Passwörter zu überprüfen.
Der Angreifer kann natürlich auch über Social Engineering versuchen, an das Passwort des Benutzers zu kommen. Man hört immer wieder von Fällen, in denen dreiste Personen unter einem Vorwand oder mit einer falschen Identität versucht haben, einen Benutzer zur Herausgabe seines Passwortes zu bewegen.
Ein Intrusion Detection System kann einen Login eines normalen Benutzer nicht als Angriff erkennen, auch wenn eine andere Person dahintersteckt. Das IDS kann hier nur noch etwaige ungewöhnliche Aktivitäten erkennen, die in nächster Zukunft von diesem Login ausgehen würden.
Ein Intrusion Detection System wird oftmals mit einer Firewall in Verbindung gebracht oder gar mit selbiger verwechselt. So hat ein Intrusion Detecion System nicht die Aufgabe, eine Firewall zu ersetzen, sondern stellt eine sehr sinnvolle Ergänzung zu ihr dar. Im Zusammenhang mit einem Netzwerk stellt sich oftmals die Frage, an welcher Stelle das Intrusion Detection System greifen soll. Wird es vor der Firewall positioniert, kann es den hereinkommenden Verkehr auf etwaige Angriffe überprüfen. Heutzutage stellt aber nicht mehr nur der Verkehr, der von aussen in ein Netzwerk dringt, eine Gefahr für selbiges dar, sondern auch der Verkehr im Innern des Netzwerkes. Oftmals sind es die eigenen Mitarbeiter, Fremde, die sich Zugang zum Netz verschafft haben oder Würmer, Trojaner o.ä., die eine Gefahr für das Netz darstellen. Daraus ergibt sich ein weiterer Faktor, der bei der Positionierung des IDS zu beachten ist. Folgich sollte man überlegen, jeweils vor und hinter der Firewall das IDS zum Einsatz zu bringen, mit dieser Konstellation können Angriffe sowohl von innen als auch von aussen erkannte werden.

Funktionsweise anhand des Beispiel "Snort":
Sollte ein Angreifer versuchen, in einen PC oder ein Netzwerk einzudringen, auf dem ein solcher PacketAnalyser 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 (IRS), auf welche hier nur in beschränktem Masse 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. Ein möglicher Angriff kann dem Administrator über Pager, SMS, eMail, WinPopup-Message, etc. übermittelt werden.


Daten sammeln
Im ersten Schritt werden Daten gesammelt. Am Beispiel eines Network Intrusion Detection Systemes 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 Gegenmassnahmen 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 schliessen. Dieses Vorgehen wird als reaktionäres Intrusion Detection bezeichnet, da es einen Angriff nur im Nachhinein erkennen lässt und der Administrator nur für die Zukunft präventive Massnahmen treffen kann.

Datenanalyse
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. 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 Systemes eine Abweichung vom normalen Netzwerkverkehr. Natürlich stellt eine Anomalie nicht immer eine Gefahr dar, weswegen eine längere Einlaufzeit für das System. In einem anderen Umfeld sind hier natürlich auch Dinge wie die Auslastung der CPU von Bedeutung, da das System hier 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 ausserhalb der definierten Akzeptanzschwellen liegt, wird Alarm ausgelöst. Auch logisch mögliche Rythmen können verfolgt werden zb. eine zeitliche Abfolge von Ereignissen. So muss ein Network Intrusion Detection System zum Beispiel auch einen Portscan erkennen, bei dem die Pakete in längeren Abständen gesendet werden.


Snort und seine Möglichkeiten
Snort arbeitet bei der Analyse der gesammelten Daten nach dem Prinzip der Missbrauchserkennung. Die zahlreichen Optionen von Snort erlauben Zugriff auf alle wichtigen Bestandteile der zu untersuchenden Pakete. Snort kann anhand der Quell- und Ziel-IP-Adressen, Quell- und Zielports, TCP-Flags, des Datenteils und noch diverser anderer Merkmale Pakete analysieren. Welche das im Ganzen sind, zeigt Abschnitt 6. Den Datenteil eines Paketes kann Snort anhand von Binärmustern in Form von Hexadecimal-Code analysieren, oder mit Pattern-Matching auf Strings untersuchen. Sollte man doch nach einer Möglichkeit der Anomalieerkennung suchen, bietet Snort über seine Plugin-Schnittstelle das Plugin Spade. Im allgemeinen bietet die Plugin-Schnittstelle von Snort die Möglichkeit, Pakete zu analysieren und gegebenenfalls zu verändern, noch bevor die eigentliche Analyse von Snort die Pakete untersucht.

Logmöglichkeiten
Die erste Möglichkeit 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 Paket Header gesichert werden. Die zweite: alle Melungen samt kompletten Paket Headern protokollieren. Es besteht weiterhin die Möglichkeit die Paketinformationen im tcpdump-Format zu sichern. Eine andere Variante ist das Formatieren mit Hilfe von XML. Am CERT wurde die sogenannte SNML entwickelt, mit deren Hilfe Snort die Daten formatiert und in eine Datei oder eine Datenbank sichern kann.

Visualisierung der Ergebnisse
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 ODBC. ACID basiert auf PHP und bereitet die gesammelten Daten grafisch auf. SnortSnarf besteht aus einer Reihe von Perl-Scripten. Prinzipiell bereitet es die Daten auch auf, aber trotzdem ist der Output teilweise noch sehr kryptisch. 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.


Gegenmassnahmen
Snort bietet in beschränktem Maße Möglichkeiten der Intrusion Response. Über die libnet lässt 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'', ein ``Host unreachable'', ein ``Port unreachable'' oder allen dreien auf einmal.

Fazit:
Ursprünglich wurde Snort für die verschiedenen Varianten von Linux/UNIX geschrieben, ist nun aber auch auf Windows übertragen worden. Es verfügt mittlerweile auch über eine solide grafische Benutzeroberfläche. Alles in allem ist, bei den immer häufiger werden fortschreitenden Angriffen, dieses kostenlose Intrusion Detection System eine gute Wahl, wenn es um Sicherheit geht. Die neueste Version kann von der Snort Website oder von SiliconDefense.com kostenlos heruntergeladen werden.


Der Ausblick in die Zukunft
Für die zukünftige Entwicklung der Intrusion Detection gibt es viele Ansätze, die die unterschiedlichsten Bereich umfassen, angefangen bei biologischer Forschung bis hin zur Hardware-Implementierung der Erkennungslogik. In der Biologie findet die Intrusion Detection eine Methodik, die den selben Zweck verfolgt: Die Erkennung von Fremdkörpern bzw. Eindringlingen im menschlichen Körper. Der Körper unterscheidet diese durch die Kategorisierung ihrer Attributen. Die Ergebnisse dieser Untersuchungen können sowohl das Verständnis der Funktionsweise der Einbruchserkennung fördern als auch bei der Weiterentwicklung der Intrusion Detection behilflich sein. Eine weitere Möglichkeit, die Einbruchserkennung noch effektiver zu gestalten, bieten Neuronale Netze. Sowohl in der Missbrauchs- als auch in der Anomalie-Erkennung können sie dienlich sein. Unabhängig von den verwendeten Methoden oder Algorithmen wäre ein Ansatz denkbar, die Intrusion Detection Logik oder die Algorithmen in Hardware umzusetzen, um die Prozessor-Last zu minimieren. Hierbei sollte die Konfiguration des Systems natürlich softwareseitig zu realisieren sein, um stets eine gewisse Aktualität des Systems gewährleisten zu können.

IDS: Honeynets
Insbesondere Personen, die sich beruflich aber auch privat mit der Abwehr von Angriffen auf Computersysteme befassen, kennen zumindest den Begriff Honeypot, von dem auch der neue Begriff Honeynet abgeleitet wurde. Hierunter versteht man grundsätzliche jene Systeme, die als Zielsysteme für potenzielle Angreifer (Blackhats oder Hacker genannt) installiert werden. Allerdings ist das Ziel, das mit solchen Honeypots verfolgt wird je nach Einsatzzweck und Einsatzumgebung unterschiedlich. So sollen diese System in manchen Netzwerkumgebungen neben einem IDS (Intrusion Detection System) als Frühwarnsysteme agieren, den Hacker binden und den verantwortlichen Administratoren mehr Zeit zum reagieren verschaffen. In der Regel sind diese Honeypots in ihrer Funktionalität stark eingeschränkt und erlauben dem Angreifer nicht viel Interaktion. Man kann basierend auf dieser Idee jedoch auch Honeypots oder ganze Honeynets aufbauen, die eine reale Systemumgebung darstellen und dem Hacker erlauben mit dem Betriebssystem zu interagieren. Aus Sicherheitsgründen werden auch hier Massnahmen getroffen, die den Hacker in seinem Handlungsspielraum einschränken - aber nach Möglichkeit so, dass er es nicht merkt und trotzdem auf dem System arbeitet wie er es auf einem echten Zielsystem auch tun würde.
Es soll hierbei kein dediziertes Netzwerk geschützt, sondern Hacker vom ersten Versuch an im System erfasst, beobachtet und anschliessend ihre Vorgehensweise ausgewertet werden um Rückschlüsse auf die Taktiken, Tools und Motive zu ziehen und die Ergebnisse zu veröffentlichen. Um eine globale Trendanalyse zu ermöglichen wurde durch das Honeynet Project zudem die sogenannte Research Alliance ins Leben gerufen. Diese Alliance ermöglicht es die Daten von weltweit verteilten Honeynets zusammenzuführen und einer zentralen Auswertung zuzuführen. Die Weiterentwicklung sind HoneyNets, die ein ganzes Netzwerk simulieren. Tatsächlich existiert aber nur ein Rechner, auf dem in virtuellen Maschinen mehrere Instanzen ein Betriebssystems über virtuelle Netzwerkverbindungen kommunizieren.

Zum logging

Logfiles sind wertlos, wenn man sich nicht auf ihre Richtigkeit verlassen kann. Das erste was viele Angreifer versuchen zu tuen, sind Logfiles auf einem kompromitierten System zu verändern. Es gibt eine ganze Reihe von Tools (z.B. cloak), die jegliche Anwesenheit aus den Logs herauslöschen oder gleich das ganze Logging verändern. Der erste Schritt zum Auswerten der Logs muß also deren Sicherung sein. Das bedeutet, das man einen Remote-Logserver verwenden mußt. Egal wie sicher das System ist, kann man Logs auf einem kompromitiertem System nicht vertrauen. Der Angreifer könnte ein rm -rf /* ausführen und die Festplatte komplett löschen. Um sich dagegen zu schützen, sollten alle Systeme doppelt gelogged werden: lokal und auf einem Remote-Logserver. Empfehlenswert ist es hier, eine eigene Maschine als Logserver abzustellen, d.h. dieser Rechner macht nichts anderes, als die Logs von anderen Systemen zu sammeln. Der Server sollte bestmöglich gesichert werden, mit so wenig laufenden Diensten wie möglich und Zugriff nur von der Konsole aus. Außerdem sollte sichergestellt sein, dass der UDP-Port 514 geblockt oder von einer Firewall an der Internetverbindung gesichert ist. Das schützt den Server vor falschen oder nicht autorisierten Logginginformationen aus dem Internet.
Wenn man das ganze noch etwas verschärfen will, kompiliert man einfach neu, sodaß eine andere Konfigurationsdatei eingelesen wird, z.B. /var/tmp/.conf. Auf diese Weise weiß der Angreifer nicht, wo die wahre Konfigurationsdatei liegt. Die Änderung ist durch einfaches editieren des Eintrags /etc/syslog.conf im Sourcecode auszuführen. Außerdem wird in die neue Konfigurationsdatei eingetragen, sowohl lokal als auch auf dem Remote-Logserver, zu loggen. Trotz alledem sollte man eine Standardkonfigurationsdatei /etc/syslogd.conf behalten, auf der das Logging ausschließlich lokal zu sein scheint. Diese Datei ist zwar jetzt nutzlos, wird den Angreifer aber von dem Remote-Logging ablenken. Eine andere Methode Systeme zu schützen, ist das verwenden einer sicheren Logmethode. Eine Möglichkeit wäre es, die syslogd-Binary gegen etwas auszutauschen, was einen eingebauten Integritätscheck und eine größere Auswahl an Optionen hat, z.B. syslog-ng, zu finden auf Balabit.hu.
Die meisten Logs die genutzt werden, liegen auf einem Remote-Logserver. Wie vorher erwähnt, kann auf die Integrität dieser Dateien vertraut werden, da sie auf einem Remote und gut gesichertem System liegen. Darüberhinaus ist es wesentlich leichter, bestimmte Muster in den Logs zu erkennen, da alle Systeme auf einen zentralen Rechner schreiben. Man kann mit einem Blick sehen, was auf allen Systemen geschieht. Die einzige Gelegenheit, bei der man die lokalen Logfiles ansehen muß, ist um zu vergleichen, ob sie mit den Serverlogs identisch sind. So läßt sich einfach herausfinden, ob sie verändert worden sind oder nicht.
Einmal abgesichert, kann man eventuelle Muster in den Logdateien erkennen. Basierend auf diesen Mustern und Logeinträgen kann man erkennen wonach der Angreifer sucht und welche Tools er wahrscheinlich verwendet. Aufbauend auf diesem Wissen kann man die Systeme besser schützen und sichern.

WOHER?
Hier sind ein paar andere ausgewählte Anbieter für Intrusion Detection System's:
LANguard, BlackIceProtection, ISS.net, Kobelt Development Inc., Intrusion Inc.


Änderungen/Zusammenfassung (mm)

Quellen: zeus.fh-brandenburg.de, pl-forum.de, Securityfocus, KoSIB, project.honeynet.org