HP TippingPoint - Analyse der Protection Filter

HP TippingPoint

Analyse der Protection Filter

Marc Ruef
von Marc Ruef
Lesezeit: 11 Minuten

Das Thema Intrusion Prevention-Systeme (IPS) ist bald seit 15 Jahren im Bewusstsein der angewandten Computersicherheit präsent. Genau wie Intrusion Detection-Systeme (IDS) sind sie einige Zeit eher stiefmütterlich behandelt worden. Zu komplex und schwierig handzuhaben schien das Thema.

Mit der Vereinfachung und Professionalisierung dieser Themengebiete wurden sie aber wieder zunehmend salonfähig. Es gibt Hersteller, die mit unterschiedlichen Ansätzen aufwarten. Traditionellerweise wird ein IDS/IPS als Sensor in einem Netzwerk betrieben.

HP TippingPoint ist eines dieser HIDS/HIPS-Systeme (es wird gar als NGIPS betitelt). Das kommerzielle Produkt wird mit über 7’000 Protection Filter ausgeliefert, die anhand einer klassischen Mustererkennung die jeweiligen Angriffsversuche als solche erkennen können soll. Der Benutzer kann diese in Profilen zusammenfassen, an bestimmte Schnittstellen binden (z.B. nur Inbound-Überwachung) und ihnen Actions zuweisen (z.B. Permit, Block, Notify, Trace).

Dieser Beitrag geht auf die Protection Filter von TippingPoint ein. Es wird untersucht, wie diese strukturiert werden und welche Ansätze durch HP verfolgt werden.

Namensgebung

Der Titel eines Filters weist die Struktur ID: Name auf. Die Typischen Filter für das Erkennen von klassischen Anomalien im Bereich ICMP heissen zum Beispiel:

Die ID ist 4-stellig, wird mit jedem neu eingeführten Filter inkrementiert und wird bei Zahlen kleiner als 1000 mit einer voranstehenden Null geführt. Es werden zwar mittlerweile über 7’000 Filter geführt. Es sind jedoch Löcher in den IDs zu beobachten. Wahrscheinlich wurden gewisse Filter nie freigegeben oder wieder zurückgezogen. Filter mit IDs grösser als 10000 gibt es dementsprechend auch. Die Namenskonvention mit der vorangestellten Null hat dies jedoch nicht beeinträchtigt.

Falls eine Schwachstelle via ZDI veröffentlich wurde, wird die entsprechende ID in Klammern angeführt. Andere Quellen, wie zum Beispiel OSVDB oder CVE werden leider nicht genannt. Ebenso existiert keine öffentlich zugängliche Datenbank der Filter, die eine Verlinkung zu anderen Quellen vereinfachen könnte. Die eindeutige Zuweisung von Filter zu expliziten Schwachstellen gestaltet sich also bisweilen sehr schwer. Ein ähnliches Problem ist auch bei Qualys zu beobachten. Dies ist mitunter ein Grund, warum offenen Systemen nach Möglichkeiten Vorrang gewährt werden sollten.

Kategorien

Die Filter werden Kategorien zugewiesen. Diese sind in nachfolgender Tabelle erklärt:

Kategorie Beschreibung
Exploits Verkehr, der durch automatisierte Tools zur Ausnutzung von Schwachstellen generiert wird. In erster Linie sind dies effektive Exploits, die mit eindeutig identifizierbaren Pattern aufwarten. Andererseits werden aber auch klassische Angriffstools wie Loki, DDoS-Tools wie TFN/Stacheldraht und Malware wie Nimda dieser Kategorie zugewiesen.
Identity Theft Relativ kleine Kategorie, die versucht Phishing-Verhalten zu erkennen. Dabei wird sowohl generisches Abgreifen von Kreditkartennummern als auch unternehmensspezifisches Phishing (z.B. PayPal, eBay) angegangen.
Reconnaissance Jegliche Art von Verkehr, die im Rahmen eines Angriffs genutzt wird, um Informationen zur Zielumgebung zu sammeln. Hierbei werden sowohl netzwerkbasierte Auswertungen (z.B. Route-Traceing mit geringen TTL-Werten) als auch anwendungsspezifische Techniken (z.B. Sourcen über ColdFusion auslesen) berücksichtigt.
Security Policy Verkehr, der typischerweise in generischen Richtlinien zugelassen oder verboten wird. Hierzu gehören erweiterte Typen von ICMP, klassische Angriffstechniken auf FTP und spezielle Webzugriffe.
Spyware Software-Komponenten, die eingesetzt werden, um Benutzer breitflächig oder zielgerichtet auszuspähen. Dazu gehören gewisse Backdoors, unter anderem das Zeus Botnet. Aber auch altbekannte Downloader oder Toolbars.
Virus Auflistung diverser Malware, die in erster Linie virale Infektionen vorantreibt. Naturbedingt wird diese ausschliesslich im Rahmen der jeweiligen Propagation innerhalb des Netzwerks erkannt.
Vulnerabilities Umfangreiche Kategorie, die Angriffsversuche erkennen soll. Dabei werden einerseits generischde Merkmale (z.B. Zugriff auf /bin/ps und gcc) berücksichtigt. Aber auch sehr spezifische Eigenheiten, die dedizierten Verwundbarkeiten und den dafür eingesetzten Angriffstechniken zugewiesen werden können.

Die Zuweisung in die Kategorien ist nicht immer einfach nachzuvollziehen. So wird zum Beispiel 0079: ICMP: Echo Reply unter Security Policy geführt obwohl es doch eher in Reconnaissance passen könnte. Gewisse DDoS-Tools und Würmer wären eventuell auch besser in Virus aufgehoben anstatt in Exploits.

Kategorien von HP TippingPoint

Auch bei diesem Produkt findet bisweilen eine marktgetriebene Vermengung von Intrusion Prevention und Malware Detection statt. Dies wird offensichtlich bei der Kategorie Virus. Obwohl es von Vorteil sein kann, wenn auch durch ein IPS entsprechende Malware frühzeitig erkannt wird, ersetzt dies – mindestens zum aktuellen Zeitpunkt – keine echte Antiviren-Lösung. Zu limitiert und knapp ist die Liste der entdeckbaren Schädlinge. Zudem wird sich ausschliesslich auf die Verbreitung fokussiert und nicht auf weiterführende Aktivitäten.

Default Profile

HP propagiert ein sogenanntes Default Profile. Dies ist das empfohlene Profil, das eingesetzt werden soll, um in den meisten Umgebungen einen Grundschutz zu erreichen, ohne den Betrieb negativ zu beeinträchtigen. Grundsätzlich werden damit 32.6% aller Filter aktiv geschaltet. Die restlichen 67.4% sind deaktiviert, da sie zu aggressiv agieren könnten.

ID Titel Angriffsmöglichkeit
0137-0177 ICMP Diverse ICMP-Typen werden nicht berücksichtigt, wodurch sich klassische DoS- und Rerouting-Attacken initiieren lassen.
0291 Invalid TCP Traffic: Possible Recon Scan (FIN no ACK) FIN-Scans können nicht erkannt werden und sollten nach Möglichkeiten anderen Portscan-Methoden vorgezogen werden.
0340-0387 (Unix), 0495-0504 (Win), 0928-0935 (Unix) HTTP: Shell Command Execution Die generischen Regeln für das Erkennen von Command Injection auf Webservern sind inaktiv.
0438-0474 MS-SQL: Access Ebenso sind fast alle generischen Regeln für das Erkennen von erweiterten Zugriffen auf MSSQL-Datenbanken inaktiv. Ausgenommen hiervon sind Zugriffe auf xp_cmdshell.
0559 Invalid TCP Traffic: Source Port 0 Zugriffe mit dem Quellport tcp/0 werden sind gesondert erkannt. Jenachdem können damit gewisse Zugriffe verdeckt umgesetzt werden.
0581-0586, 0597-0628 RPC: Portmap Request Generische RPC Portmap-Anfragen, sowohl für TCP als auch für UDP, werden nicht berücksichtigt. Eine Auswertung ist dementsprechend unentdeckt möglich.
0632-0646 FTP Einige klassische Angriffstechniken für FTP werden gar nicht berücksichtigt. Dazu gehören Zugriffe auf ~root und .rhosts.
0692/0693, 0710/0711 Rservices: Attempted rlogin/rsh Zugriffe auf rlogin/rsh werden ebenfalls nicht berücksichtigt. Dies gilt für erfolgreiche und erfolglose Login-Versuche als auch für klassische Exploits.
1125 HTTP: ../.. Directory Traversal Eine der gängigen Varianten für eine Directory Traversal im Webbreich wird ebenfalls standardmässig nicht erkannt. Dementsprechend sind nicht einmal erweiterte Encodierungs-Versuche erforderlich.
7000-7001 Port Scan Portscans werden – voraussichtlich aufgrund der hohen Performanceeinbussen – standardmässig gar nicht berücksichtigt. Dies gilt sowohl für TCP als auch für UDP.
7002-7016 Host Sweep Gleiches gilt für Suchläufe, die allesamt standardmässig nicht berücksichtigt werden. Dies betrifft TCP, UDP, ICMPv4 und ICMPv6.

Unter anderem werden auch als simpel geltende und mit wenig False-Positives behafteten Filter deaktiviert. Dazu gehören (kurzer Auszug):

Haufenweise anwendungs- bzw. produktspezifische Schwachstellen werden ebenfalls ausgeklammert. Dazu gehören (ebenfalls nur ein kurzer Auszug):

Diese sind aufgrund der hohen Anzahl und Diversität nicht in der vorangegangenen Tabelle aufgeführt. Es ist davon auszugehen, dass die in diesem Zusammenhang deaktivierten Filter entweder eine überdurchschnittlich hohe Rate an False-Positives generieren oder ein Mehr an Ressourcen erfordern. Sie einzuschalten, mit all den damit einhergehenden Nachteilen, bleibt somit Aufgabe des Benutzers.

Deshalb ist es umso wichtiger, dass man sich nicht nur auf die Empfehlungen von HP verlässt. In einer sicheren Umgebung müssen unternehmensspezifische Eigenarten mitberücksichtigt werden. Neue Filter müssen dementsprechend untersucht, getestet und nach Möglichkeiten im eigenen Unternehmen freigegeben werden. Nur so kann der maximale Schutz der Lösung erreicht werden.

Zusammenfassung

HP TippingPoint ist ein interessantes System, das auf manchen Ebenen überzeugen kann. Sowohl performance- als auch sicherheitstechnisch ist es einen Blick wert. Die mitgelieferten Filter können dabei helfen, schnell und effizient eine Grundsicherheit in einem Netzwerk erreichen zu lassen.

Dennoch liess sich aufzeigen, dass gewisse Standardeinstellungen in nahezu fahrlässiger Weise zusätzliche Möglichkeiten für Angreifer einführen. Klassische Angriffstechniken werden so wieder interessant. Und kann sich ein Angreifer auf die entsprechende Konfiguration einstellen, wird er eine Vielzahl an Angriffsversuchen unentdeckt oder gar erfolgreich durchsetzen können.

Die Geschlossenheit des Systems macht es nahezu unmöglich, weitere Details zum Verhalten der Filter eruieren und diese optimieren zu können. Dies ist der grosse Nachteil, dem nur mit offenen – im Idealfall quelloffenen – Systemen entgegnet werden kann. Ein Sachverhalt, der nicht nur auf IDS/IPS angewendet werden kann.

Über den Autor

Marc Ruef

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

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSSv4

Konkrete Kritik an CVSSv4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentisierung

Voice Authentisierung

Marc Ruef

Bug-Bounty

Bug-Bounty

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv