Login
Newsletter
Werbung

Mo, 17. September 2001, 00:00

Intrusion Detection am Beispiel von Snort (Teil 1)

1.5 Praktischer Einsatz und Effizienz von ID-Systemen

Da das Gebiet der Intrusion Detection noch sehr jung ist, ist es nicht sehr einfach, ausreichend über den praktischen Einsatz zu berichten. Dies gilt vornehmlich für den Einsatz von Systemen auf Basis der Anomalieerkennung. Systeme wie Snort, die mit Missbrauchserkennung arbeiten, sind hingegen schon häufig und auch erfolgreich im praktischen Einsatz zu finden. Beide Systeme unterscheiden sich in der Effektivität der Angriffserkennung. Gibt es beim Einsatz einer Missbrauchserkennung eine zum Angriff passende Signatur, so steigt der Aufwand zur Erkennung exponentiell zum Effektivitätsgrad des Angriffs. Ein System mit Anomalieerkennung verhält sich genau entgegengesetzt. Hier wächst der Aufwand zur Erkennung nur exponentiell zum Effektivitätsgrad des Angriffs. Daraus läßt sich schließen, dass die Anomalieerkennung effektivere Angriffe mit einem geringeren Aufwand als die Missbrauchserkennung registrieren kann.

Ein IDS im allgemeinen und ein Network IDS im besonderen muss natürlich so wenig wie möglich Angriffsfläche bieten. Die Alarmanlage stellt oft das erste Ziel eines Angriffs dar. Ist sie erstmal ausgeschaltet, kann ein Hacker ungestört arbeiten und kann nur noch durch etwaige Aktivitäten ausgemacht werden, die Meldungen in den Protokollen des entsprechenden Systems erzeugen, sofern er sie nicht selbst entfernt hat. Darum heißt es auch bei einem Intrusion Detection System: So viele Dienste wie nötig aber so wenig wie möglich. Je weniger Ports offen sind, je weniger Dienste auf dem IDS-Host laufen und je weniger Benutzerkonten auf dem Host existieren, umso resistenter ist er gegen Angriffsversuche. Eine Absicherung der nötigen Benutzerkonten und vor allem dem des Administrators durch entsprechende Passwörter versteht sich von selbst. Ein Zugriff auf das Benutzerkonto des Administrators ermöglicht es dem Angreifer ohne große Probleme, das IDS zu deaktivieren. Weiterhin muss dem IDS der Zugriff auf seine Konfigurations- und Signaturdateien gewährleistet werden. Vorsicht ist auch geboten beim Protokollieren der Angriffe. Es muss gewährleistet werden, dass sich das IDS nicht durch überlaufende Protokolldateien selbst deaktiviert, was durchaus eine Folge eines gezielten Angriffs auf das IDS sein könnte und so einen Denial of Service als Folge hätte.

Für den effektiven Einsatz eines Systems mit Anomalieerkennung ist es elementar, dass es über Informationen verfügt, wie das zu überwachende System, z.B. ein Netzwerk, im Normalfall funktioniert, d.h. welche Aktivitäten für gewöhnlich stattfinden. Dafür ist eine entsprechende Einarbeitungszeit erforderlich, um das System in die entsprechenden Umstände »einzugewöhnen«, damit es lernt, in welchem Zusammenhang normalerweise Ereignisse stehen, um in Zukunft Abweichungen zu erkennen. Die Vorteile liegen dabei auf der Hand, nämlich dass ein System mit Anomalieerkennung unabhängig davon, welcher konkrete Angriff gerade stattfindet, einen solchen erkennen kann. Ein System auf Basis der Missbrauchserkennung ist auf aktuelle Signaturen angewiesen. Wird die Signaturdatenbank nicht auf einem aktuellen Stand gehalten, nutzt das System auf Dauer wenig. Eine schwellwertgesteuerte Signaturanalyse erfordert zusätzlich zur reinen Signaturdatenbank noch eine Definition der Schwellwerte, die den Akzeptanzbereich definieren.

1.6 Gegenmaßnahmen und rechtliche Aspekte

Sollte es nun irgendwann einmal zu einem Angriff kommen, ist die Frage, wie man mit den gesammelten Daten umgeht. Nutzt man die Daten, um einen Gegenangriff einzuleiten, sollte man sich die Frage stellen. was man letzten Endes damit bewirken wird und ob dies wirklich den Sinn eines Intrusion Detection Systems darstellt. Zieht man nun den Zorn des angreifenden Hackers bzw. Crackers4 auf sich oder erzielt man mit einer Maßnahme gegen den Angreifer tatsächlich eine abschreckende Wirkung? Letzteres dürfte wohl eher selten der Fall sein, denn mit einem Gegenangriff zieht man nur unnötig die Aufmerksamkeit des Angreifers auf das Intrusion Detection System selbst, wenn er selbiges nicht schon angegriffen hat. Im Idealfall zeigt das IDS also überhaupt keine Reaktion nach außen, sondern geht seiner eigentlichen Aufgabe nach, benachrichtigt den Administrator und sammelt entsprechend Daten über den Angreifer für eine spätere Auswertung zum Einleiten etwaiger rechtlicher Schritte.

Sollte eine Einleitung von Gegenmaßnahmen aber dennoch notwendig sein, so sollten diese in einem Maße geschehen, welches dem System oder dem zu überwachenden Netzwerk nicht den Zorn des Angreifers auf sich zieht und diesen zu weiteren Angriffen anstachelt. Hierbei ist eine vorübergehende oder im Extremfall auch dauerhafte Sperrung der IP-Adresse des Angriffsursprungs denkbar. Letzteres macht aber bei dynamisch vergebenen IP-Adressen wenig Sinn. Außerdem kann nicht garantiert werden, dass der Angriff wirklich von der verwendeten Adresse aus stattfindet, da der Angriff durchaus eine Kombination aus IP-Spoofing, der Verfälschung der eigenen IP-Adresse, und der entsprechenden Angriffstechnik sein kann, was die Identifizierung des Angreifers stark erschwert, da es erstens nahezu unmöglich ist, ein IP-Spoofing zu erkennen, und zweitens die Identifizierung des tatsächlichen Ursprungs des Angriffs dadurch nicht mehr gewährleistet werden kann. Andere Möglichkeiten sind z.B. die Sperrung es entsprechenden UDP/TCP-Ports oder die Terminierung des betroffenen Programms.

Diese Aktionen fallen in den Bereich der Intrusion Response-Systeme und sollen hier nicht näher erläutert werden, zumal sie für die Beschreibung von eventuellen Maßnahmen schon genügend Aussagekraft haben. Manche Intrusion Detection Systeme bieten auch die Möglichkeit, mit einem RST-Paket die aktive TCP-Verbindung zu beenden, aber auch dies kann wiederum unnötig die Aufmerksamkeit des Angreifers auf das IDS ziehen, da dieser dann merken könnte, dass etwas anderes als der Host, den er angreifen wollte, die Verbindung beendet hat.

Die gesammelten Auditdaten stellen nach § 416 der Zivilprozessordnung kein rechtsverbindliches Beweismittel dar wie zum Beispiel ein notariell beglaubigtes Schriftstück. Die Daten unterliegen der freien Beweiswürdigung, womit sie den gleichen gerichtlichen Status wie eine Zeugenaussage haben und ihre Beurteilung im Ermessen des Gerichtes liegt. Der Grund für den Status eines nicht rechtverbindlichen Beweismittels liegt in der Tatsache, dass die Auditdaten nachträglich modifiziert und manipuliert werden können. Eine mögliche Umgehung liegt in der digitalen Signierung der Auditdaten durch das IDS, um die Integrität der Daten zu sichern. Doch dafür muss die digitale Signatur5 vertrauenswürdig sein und der entsprechende private Schlüssel sicher aufbewahrt werden. Dieser Umstand muss im Falle eines Falles auch nachgewiesen werden.

1.7 Das IDS als Angriffspunkt

Um seinen Dienst in einem Netzwerk zuverlässig zu verrichten, muss ein Intrusion Detection System auch gewisse Voraussetzungen erfüllen, um nicht selbst Opfer eines Angriffs zu werden. Hiermit sind vornehmlich Probleme gemeint, die das IDS im Zusammenhang mit den im zu überwachenden Netzwerk installierten Hosts haben kann. Hier gibt es allgemein zwei Techniken, die es ermöglichen, das IDS mit falsch erscheinenden Paketen zu verwirren oder Inkonsistenzen zwischen dem IDS und den Endsystemen im lokalen Netzwerk auszunutzen. Erstere Technik wird »Insertion«6 genannt und die letztere »Evasion«7.

1.7.1 Insertion

Insertion basiert darauf, dass ein IDS Pakete akzeptiert, die das Endsystem normalerweise nicht annehmen würde. Das Intrusion Detection System geht also davon aus, dass ein Paket vom entsprechenden Host akzeptiert wird, obwohl der Host das Paket ablehnt. Kein anderer Host im Netzwerk außer dem IDS kümmert sich also um die Pakete. Der Angreifer fügt quasi Daten in das IDS ein. Generell liegt bei vielen Intrusion Detection-Systemen eine große Anfälligkeit gegenüber dieser Angriffstechnik vor. Ein Angreifer könnte Insertion benutzen, um signaturbasierte ID-Systeme zu umgehen und einen Angriff durchführen, ohne dass dieser vom IDS bemerkt würde, da die Pakete vom System als ungefährlich eingestuft wurden und so ungehindert am IDS vorbei zum Zielhost gelangen. Diese Angrifftechnik basiert auf der Tatsache, dass ID-Systeme, die signaturbasiert arbeiten, Pakete mit Pattern-Matching überprüfen. Schafft es der Hacker nun aber, dem IDS einen anderen Strom von Daten zukommen zu lassen als dem Zielsystem, da das IDS Pakete akzeptiert, die das Zielsystem normalerweise nicht akzeptieren würde, könnte er beispielsweise eine Reihe von Paketen mit jeweils nur einem Character schicken, welche zusammengesetzt im IDS einen anderen String ergeben als im Zielsystem. Der Angreifer könnte beispielsweise den String ATTAXCK senden. Der Angreifer hat aber das Paket mit dem Character X so manipuliert, dass der Zielhost es ablehnen wird, die restlichen Pakete aber akzeptiert. Beim Zielhost wird also letzten Endes der String ATTACK eintreffen, das IDS aber findet nur den String ATTAXCK, welcher dann nicht als Angriff erkannt wird, da in der Signaturdatenbank nur der String ATTACK gefunden wird. Der Angreifer hat es also geschafft, Daten einzufügen und einen Angriff ohne Bemerken durch das IDS durchzuführen. Eine Lösung für dieses Probleme wäre die Anpassung des IDS an die Regeln, nach denen das Zielsystem Pakete akzeptiert oder sie fallenläßt.

1.7.2 Evasion

Die zweite Möglichkeit, »Evasion«, basiert auf der Möglichkeit, dass ein IDS Pakete ablehnt, die ein Host im Netzwerk akzeptieren würde. Das Prinzip ist also prinzipiell das gleiche wie bei Insertion: Das IDS sieht einen anderen Strom von Daten als das Zielsystem. Greift man wieder auf Beispiel mit dem String ATTACK zurück, würde das IDS also bei einem Strom aus Paketen mit jeweils nur einem Character bei Manipulation des entsprechenden Paketes mit dem zweiten A den String ATTCK erkennen, wohingegen beim Zielsystem der String ATTACK ankommt. Diese Umgehung des IDS basiert auf der derarten Veränderung des Paketes, welches das entsprechende A enthält, so dass das IDS es ablehnt, das Zielsystem es aber akzeptiert.

Im realen Einsatz stellen Insertion- und Evasion-Attacken keine einfache Lösung dar, um ein IDS zu umgehen. Dafür müsste ein Angreifer die Möglichkeit haben, Pakete in einen Datenstrom einzufügen.

Kommentare (Insgesamt: 0 )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung