Bundesamt für Sicherheit in der Informationstechnik

M 5.71 Intrusion Detection und Intrusion Response Systeme

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Eine der wesentlichen Aufgaben eines Firewall-Administrators ist es, die anfallenden Protokolldaten zu analysieren, um dadurch Angriffe zeitnah erkennen zu können. Aufgrund der Fülle der Daten und der Vielzahl und Komplexität der verschiedenen Angriffsmöglichkeiten entsteht dadurch ein beträchtlicher Arbeitsaufwand. Intrusion Detection ( ID ) und Intrusion Response ( IR ) Systeme können hierbei helfen.

Ziel eines ID -Systems muss es sein, einen durchschnittlichen Administrator soweit zu unterstützen, dass dieser auch ohne tief greifende Kenntnisse im Bereich Internet-Sicherheit in der Lage ist, einen Angriff in einer großen Anzahl von Protokolldaten zu erkennen. IR -Systeme dagegen dienen dazu, automatisch Gegenmaßnahmen einzuleiten, sobald ein Angriff erkannt wurde.

Im Idealfall verfügen diese Programme über ebenso viel Informationen wie ein guter Administrator und sind daher in der Lage, in beliebigen Protokolldaten nicht nur einen Angriff zu erkennen, sondern auch noch Aussagen über die Stärke der Bedrohung und die notwendigen Gegenmaßnahmen zu machen. Zurzeit ist dies allerdings noch ein Gebiet, welches intensiv erforscht wird, sodass wesentliche Verbesserungen an den vorhandenen Programmen jederzeit möglich sind.

Intrusion Detection Systeme lassen sich im wesentlichen in zwei Klassen einteilen: Signaturanalyse und Anomalie-Erkennung.

Die Signaturanalyse beruht auf der Annahme, dass sich viele Angriffe anhand einer bestimmten Abfolge von Protokolldaten erkennen lassen. Ein Beispiel ist das so genannte Portscanning. Als Vorarbeit für einen Angriff wird zunächst festgestellt, welche Dienste auf dem angegriffenen Rechner ansprechbar sind, d. h. zu welchen TCP -Ports eine Verbindung aufgebaut werden kann. Hierzu wird mithilfe eines Programms ein Verbindungsaufbaupaket nacheinander an alle TCP -Ports geschickt. Erfolgt ein Verbindungsaufbau, ist dort ein Dienst installiert und kann angegriffen werden. Die entsprechende Signatur, also Erkennungsmerkmal, dieses Angriffs ist einfach: Verbindungsaufbaupakete, die nacheinander an alle TCP -Ports geschickt werden.

Es zeigen sich aber auch sofort die Probleme bei dieser Art der Angriffserkennung: In welcher Reihenfolge müssen die Ports angesprochen werden und in welchen zeitlichen Abständen, damit ein Angriff von einem normalen Betrieb unterschieden werden kann? Aktuelle Portscanning-Programme arbeiten so, dass nicht nacheinander Port-1, Port-2 bis Port n angesprochen werden, sondern dies in zufälliger Reihenfolge erfolgt. Auch können die Pakete nicht direkt nacheinander verschickt werden, sondern in zufälligen Zeitabständen ( z. B. 1 s, 100 ms, 333 ms, 5 s ...). Dies macht die Erstellung einer Signatur schwierig.

Eine subtile Variante des Portscanning besteht darin, einzelne Pakete von verschiedenen Quelladressen zu senden. In Verbindung mit der oben aufgezeigten zeitlich versetzten Initiierung der Pakete ist die Wahrscheinlichkeit gegenwärtig sehr hoch, dass ein solcher Angriff unerkannt bleibt.

Bei der Anomalie-Erkennung geht man andererseits davon aus, dass sich das normale Verhalten der Benutzer oder Rechner statistisch erfassen lässt und wertet Abweichungen hiervon als Angriff. Ein Beispiel hierfür ist der Zeitraum, in dem eine Benutzerin normalerweise an ihrem Rechner angemeldet ist. Arbeitet sie z. B. fast immer montags bis freitags in der Zeit von 8.00 Uhr bis 17.00 Uhr mit Abweichungen von maximal 2 Stunden, so kann eine Aktivität am Samstag oder um 24.00 Uhr als Angriff gewertet werden. Das Problem bei der Anomalie-Erkennung ist die Festlegung des normalen Verhaltens. Hierfür lassen sich zwar mit Hilfe von Schwellwerten oder Wahrscheinlichkeitsbetrachtungen einige Aussagen machen. Ob es sinnvoll ist, eine Aktivität des Benutzers A am Montag um 19.10 Uhr sofort als Angriff zu bewerten, erscheint fraglich. Auch ändert sich das normale Verhalten eines Benutzers in Regel, sodass eine Anpassung vorgenommen werden muss. Wer aber sagt dem ID -System, dass diese Verhaltensänderung regulär ist und kein Angriff?

Des Weiteren ist eine Unterteilung der ID -Systeme nach der Art der Datenaufnahme sinnvoll. Diese kann entweder mithilfe eines dedizierten Sniffers irgendwo im Netz erfolgen (Netzbasiertes ID -System), oder Teil der normalen Protokollierungsfunktionalität auf einem der angeschlossenen Rechner (Hostbasierte ID -Systeme) sein. Beides hat Vor- und Nachteile. Die netzbasierten Systeme haben zwar die Möglichkeit, einen umfassenden Angriff, der gleichzeitig verschiedene Rechner betrifft, leichter zu erkennen. Es ist aber erheblich schwieriger, komplexe Angriffe ( z. B. über weitere Zwischenstationen) auf einen Rechner zu erkennen. Darüber hinaus können netzbasierte Systeme keine verschlüsselten Daten analysieren. Für die hostbasierten ID -Systeme gilt andererseits, dass für ihren Einsatz u. U. umfangreiche Änderungen an den Protokollierungsfunktionen der Rechner notwendig sind.

Da auch bei der automatischen Auswertung von Protokollinformationen die Datenschutzbestimmungen oder Personalvereinbarungen beachtet werden müssen, kann es unter Umständen notwendig werden, diese Daten pseudonymisiert abzulegen.

Vor der Kopplung von ID -, IR -System und Firewall sollten folgende Aspekte beachtet werden:

  • Ist es möglich, gezielt einen Angriff auf die Firewall zu initiieren, der vom ID -System irrtümlich als echter Angriff gewertet wird? Eine daraufhin vom IR -System ausgelöste Sperrung bestimmter Dienste über die Firewall kann erhebliche Konsequenzen auf die Verfügbarkeit haben.
  • Die Interaktion zwischen ID -, IR -System und Firewall sollte hinreichend transparent dokumentiert sein. Nur so ist es möglich, zu jedem Zeitpunkt abzuschätzen, von wem die Firewall administriert wird: vom IR -System oder vom Administrationspersonal. Im Zweifelsfall sollten Entscheidungen des Administrationspersonals Vorrang haben.

Um Angriffe gegen ein ID -System selbst auszuschließen, sollten diese vom Netz her weitestgehend unsichtbar sein. Einfachste Maßnahme ist die Zuweisung einer IP -Adresse, die im Internet nicht geroutet wird. Empfohlen sei weiterhin die Deaktivierung des Protokolls ARP für das entsprechende Interface, sodass weder auf ARP - noch auf IP -Pakete reagiert wird.

Prüffragen:

  • Erfolgt Einbruchserkennung und Einbruchsabwehr mittels Intrusion Detection oder Intrusion Response Systemen?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK