Intrusion Prevention Systeme (IPS) galten vor bald 15 Jahren als Weiterführung von Intrusion Detection Systemen (IDS). IDS sollten dabei helfen, Angriffsversuche und erfolgreiche Attacken als solche zu erkennen, um auf diese reagieren zu können. IPS gehen einen Schritt weiter und versuchen laufende Attacken frühestmöglich zu unterbinden. Die gegebene Sicherheit einer Umgebung sollte damit unmittelbar verbessert werden.

Obwohl IDS und IPS seit vielen Jahren bekannt sind und viele Anbieter auf den Markt gekommen sind, ist die Funktionsweise von derlei Systemen nach wie vor für viele Administratoren nicht oder nur schwierig nachzuvollziehen. Klassischerweise werden netzwerkbasierte Lösungen – sogenannte HIDS/HIPS – eingesetzt. Die Möglichkeit eines systematischen Funktionstests soll in diesem Beitrag illustriert werden.

Ziel

Das Ziel des Funktionstests eines IDS/IPS besteht darin herauszufinden, ob die Lösung richtig funktioniert. Die Richtigkeit unterscheidet sich je nach Fall.

In der Regel müssen diese Systeme Angriffsversuche als solche erkennen können. Daraus resultiert eine Action, wie mit der identifizierten Attacke umgegangen werden soll. Dies kann eine passive Action, vorzugsweise durch ein IDS angeboten, sein:

• Logging
• Notification
• Alerting

Es können aber auch aktive Actions, dies ist hauptsächlich Aufgabe eines IPS, ausgelöst werden:

• Unterbinden des Angriffsversuchs
• Unterbinden weiterer Kommunikationen vom Angreifer zum Ziel
• Unterbinden weiterer Kommunikationen vom Angreifer generell

Durch den Funktionstest sollen nun diese Actions bewusst, gezielt, kontrollierbar und nachvollziehbar provoziert werden.

Ausgangslage

Damit ein Funktionstest durchgeführt werden kann, müssen einige Gegebenheiten vorhanden sein. Grundsätzlich muss ein Angriffsszenario geschaffen werden, in dem das IDS/IPS seine Funktionalität erbringen kann. Bei einer hostbasierten Lösung ist erforderlich, dass der Datenverkehr zum Zielsystem das IDS/IPS tangiert (passiver Sensor) bzw. über dieses geleitet wird (Inline-System).

Am einfachsten ist es, wenn ein Zielsystem, das durch das IDS/IPS geschützt wird, definiert wird. Ein Angreifer wird dem möglichst realistischen Szenario entsprechend so positioniert, dass seine Zugriffe auf das Zielsystem durch das IDS/IPS geprüft werden.

Im Idealfall wird der Datenverkehr auf den beiden Endpunkten (Quelle und Ziel) sowie den dazwischenliegenden Systemen – vor allem auf dem IDS/IPS – mitprotokolliert. Dadurch kann der Testverlauf exakt nachvollzogen und bei Problemen detailliert analysiert werden.

Dies ist vor allem dann interessant, wenn eine Sicherheitskomponente direkten Einfluss auf die Kommunikation ausübt. Zum Beispiel, wenn ein Proxy Umformungen von Protokollen vornimmt oder ein IPS mittendrin einen Angriffsversuch stoppt. In diesem Fall kann nämlich die Protokollierung zwischen Quell- und Zielsystem verglichen werden, um den exakten Zeitpunkt und den unmittelbaren Einfluss zu identifizieren.

Durchführung

Nachdem die Vorbindungen für das Testing geschaffen wurden, kann die Durchführung angegangen werden. Dabei werden einzelne Test Cases initiiert, die ihrerseits grundlegende Anforderungen voraussetzen:

• Klar definiert
• Möglichst einfach
• Ohne komplexe Drittsoftware (z.B. Exploits)

Am einfachsten ist es, wenn die für einen Penetration Test üblichen und frei verfügbaren Werkzeuge genutzt werden. Hierzu bieten sich die folgenden beiden Tools an:

• Nmap: Das quelloffene Scanning- und Auswertungsutility kann unkompliziert für eine Vielzahl an Scan-Zugriffen umgesetzt werden.
• hping3: Das Tool zur Generierung von individuellen Paketen kann weiterführend genutzt werden, um spezielle Angriffsmuster zusammenbauen zu können.

Es kann dennoch Situationen geben, in denen man eher komplexe Exploits simulieren möchte. Hier sollte auf standardisierte Frameworks wie Metasploit oder ATK zurückgegriffen werden. Das Nutzen von dedizierten Exploits ist problematisch. Einerseits sind diese nicht immer nachvollziehbar standardisiert und andererseits stammen sie meist aus zweifelhafter Quelle (Gefahr einer Trojanisierung).

Dokumentation

Die einzelnen Test Cases müssen separat dokumentiert werden. Dabei sind einige Grundinformationen zwingend festzuhalten, um das gewünschte Mass an Qualität gewährleisten zu können:

• ID
• Bezeichnung
• Kommando
• Ausgabe
• Mitschnitt (z.B. pcap)
• Resultat

Das Resultat eines relativ kleinen Funktionstests mit einer überschaubaren Anzahl an Test Cases sieht dann zum Beispiel wie folgt aus:

Wenn ein Angriffsversuch korrekt erkannt wurde, kann dies als Erfolg verbucht werden. Sollte hingegen eine Entdeckung ausbleiben, gilt es herauszufinden, was der Grund für diesen Umstand ist. Im “Idealfall” ist dies auf eine Fehlkonfiguration des IDS/IPS bzw. eines der eingesetzten Filter zurückzuführen. Falls die Ursache nicht ausgemacht werden kann – viele kommerzielle Anbieter legen die Funktionsweise ihrer Filter nicht offen (z.B. HP TippingPoint) – sollte der Hersteller um eine Erklärung ersucht werden. Transparenz ist unendlich wichtig, um das Vertrauen in eine Lösung und die gewünschte Qualität erhalten zu können.

Zusammenfassung

IDS und IPS sind wichtige Elemente, die zur Sicherheit einer Umgebung beitragen können. Durch gezielte Funktionstests sollte geprüft werden, ob sie ihren Dienst auch richtig verrichten. Zu diesem Zweck muss ein möglichst realistisches Angriffsszenario geschaffen werden, in dem sie ihre Möglichkeiten entfalten können.

Durch gezielte, nachvollziehbare und möglichst einfache Test Cases kann dann versucht werden, die erwartete Action zu provozieren. Falls diese eintritt, kann von einem Erfolg gesprochen werden. Bleibt sie hingegen aus, muss man der Ursache auf den Grund gehen. Fehlkonfigurationen oder Fehlbarkeiten im eingesetzten Produkt können dafür verantwortlich sein. Für die Sicherheit einer Umgebung und das Vertrauen in die eingesetzten Produkte sind solche Funktionstests unerlässlich.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

• http://nmap.org/
• http://www.hping.org/hping3.html
• http://www.metasploit.com/
• https://www.computec.ch/news.php?item.257
• https://www.computec.ch/projekte/atk/