Im professionellen Einsatz stoßen Portscanner wie Nmap zuweilen an Performancegrenzen. Der junge Hüpfer Portbunny verspricht, durch einige kreative Tricks schneller am Ziel zu sein als die alten Hasen. Ein Kurztest offenbart eine Verfolgungsjagd.
Portscannen macht Spaß – wenn es nicht zum beruflichen Alltag gehört. Professionelle Portjäger stellen schnell fest, dass viel Zeit ins Land geht, wenn Werkzeuge wie Nmap eine lange Liste von IP-Adressen auf offene Ports im lokalen Netz scannen. Gerade wenn viele Adressen inaktiv sind, dauert der Scan gefühlte Ewigkeiten.
Die Wartezeit ist nötig, schließlich will Nmap keine Ports verpassen, hinter denen Dienste auf Input lauschen. Dabei muss es einige Hürden überwinden, die Netz- und Systemverantwortliche willentlich oder systemimmanent eingebaut haben. Einige Firewalls filtern beispielsweise Pakete zu bestimmten Ports aus, manches Betriebssystem antwortet auf gewisse Protokollanfragen, etwa über ICMP, nur sehr zögerlich oder stellt sich komplett stumm.
Eigenschaften wie OS-Fingerprinting oder ein halbes Dutzend verschiedener Ausgabemodi in Nmap sind daher nett, haben aber mit der ursprünglichen Idee nur wenig zu tun. Wenn Security-Tester Netze von einigen Tausend Zielhosts als erste Phase eines Penetrationstests scannen, wollen sie damit schnell fertig sein und Ergebnisse bekommen, auf die sie sich verlassen können. Sie nutzen einen Portscan als eine Art Inventur, als notwendigen ersten Schritt für den eigentlichen Sicherheitscheck.
Schnell und korrekt
Die Ansprüche an Geschwindigkeit und Genauigkeit widersprechen einander. Schickt der Scanner zu viele Anfragen als Pakete ins Netz, treten mehrere Effekte auf, die den Scan bremsen. Paketkollisionen sind eine Ethernet-immanente Eigenschaft, die aber erst bei stark ausgelasteten Segmenten zum Problem wird. Router und auch die Netzwerkstacks sendender und empfangender Betriebssysteme sorgen über Rate Limiting für konstanten Datenfluss, indem sie die Verarbeitung bestimmter Pakettypen nach komplizierten Algorithmen etwas verzögern. Ein Scanner sieht sich also der Situation konfrontiert, dass einige seiner Pakete (Probes) verloren gehen oder sehr lange für den Weg zu ihrem Empfänger und zurück brauchen.
Um trotz widriger Umstände den Scan zu beschleunigen, haben die Recurity Labs aus Berlin einen Kernel-basierten TCP-Portscanner namens Portbunny entwickelt [1] und auf dem 24c3 vorgestellt [2]. Sie bedienen sich der technischen Trickkiste und verarbeiten Timing-Informationen direkt im Kernel. Da sie sich auch auf zum Portscannen notwendige Funktionalität konzentrieren, soll das GPLv2-lizenzierte Tool professionellen Ansprüchen besser genügen.
Geschwindigkeitsregler
Die Hauptidee von Portbunny basiert auf den Prinzipien der TCP Congestion Control. Wer einen so genannten TCP-SYN-Portscan durchführt, sendet für jeden angesprochenen Port ein Paket. Je nach Art des Antwortpakets – SYN ACK, RST oder gar nichts – zieht das Programm den Rückschluss, dass der Port offen, geschlossen oder gefiltert ist. Für höhere Geschwindigkeit sendet es mehr Pakete. Doch wenn es die Kapazität des Netzes damit überlastet, gehen Pakete verloren. Dies verfälscht das Ergebnis.
Die Autoren von Portbunny nutzen die Eigenschaften eines TCP-Netzwerks, indem sie statt halboffener Scans, die einen Verbindungsvorgang nach zwei von drei Schritten abbrechen, die klassische SYN-Variante implementieren. Die bedient sich kooperativer Fehlermeldungen des TCP-Protokollstacks.Dabei stellt der Scanner zunächst fest, auf welche Pakete er garantiert eine Antwort erhält. Gute Kandidaten sind in Windows-Netzwerken etwa SYN-Pakete von TCP auf Port 139 oder Port 445, die für typische Microsoft-Dienste stehen.
Danach schickt Portbunny so schnell wie möglich Scans ab, zwischen denen es in festen Abständen zusätzliche Pakete zu den bekannten Ports einfügt. Diese Pakete nennt es Trigger. Erhält es keine Antwort, weiß Portbunny, dass das Netzwerk überlastet ist. Anhand der Round-Trip-Time der Trigger weiß es auch, wie lange ein Paket zum Ziel braucht. Entsprechend passt es sein Verhalten dem Netzwerk an und erreicht im besten Fall eine ideale Auslastung.
Scanner im Kern integriert
Portbunny besteht aus zwei Komponenten: dem Kernelmodul »portbunny.ko« und dem in Python geschriebenen Frontend »portbunny« für die Kommandozeile (Abbildung 1). Das Modul legt ein virtuelles Device unter »/dev/portbunny« an, mit dem Programme auch direkt kommunizieren können. Unterstützt der verwendete Kernel das Entfernen von Modulen, lädt und entlädt Portbunny das Modul selbstständig. Die Entwickler möchten durch das Einbinden des Scanners in den Kernel ein besonders präzises Timing erreichen. Fertige Pakete für gängige Distributionen gibt es noch nicht, die Software lässt sich jedoch schnell aus den Quellen übersetzen. Einzig für Gentoo bieten die Entwickler ein Ebuild auf ihrer Website an.

Abbildung 1: Der Scanner Portbunny führt einen Netzwerkscan auf ein Ziel im lokalen Netzwerk durch. Zwar soll seine Trigger-Technik den Scan beschleunigen, doch gehen manche Informationen mitunter verloren.
Das Konzept hat aber auch Schwächen. Die Implementierung als Kernelmodul bedeutet, dass ein schwerer Fehler im Modul das ganze Betriebssystem in Mitleidenschaft zieht. Auch ist die Methode sehr aggressiv und erzeugt eine signifikante Last im Netz. Die Mailingliste »nmap-dev« [3] hat das Für und Wieder des Ansatzes ausführlich diskutiert. Die Bedienung ist sehr einfach: das installierte Python-Skript »portbunny« ausführen – fertig. Eine Liste zu scannender Ports gibt der Nutzer mit »-p« an. Zwingend ist die Angabe der zu scannenden IP-Adressen oder -Bereiche.
Aus einem kleinen, nicht repräsentativen Test im Labor ging jedoch Nmap siegreich hervor. Nicht weil es mit gut 15 Sekunden Scanzeit um ein Drittel schneller war als Portbunny mit etwa 22 Sekunden, sondern vor allem weil von den sechs angeschlossenen Hosts mit IP-Adressen – und zwar DSL-Modem, Router-Laptop, Wireless-AP, zwei Laptops und einem Desktop – Portbunny einen gar nicht erkannt hat: Ein System unter Windows XP mit aktivierter Firewall hat es übersehen. Nmap führt vor dem eigentlichen Scan ARP-Pingsweeps durch, wenn Ziele im lokalen Netz liegen, Portbunny offenbar nicht.
Für einen größer angelegten Penetrationstest sind Hosts ohne einen einzigen lauschenden Port zwar uninteressant. Doch ist es für einen zusammenfassenden Bericht durchaus relevant, zu zeigen, dass der Scan alle aktiven Hosts gefunden und analysiert hat. Bei diesem Kritikpunkt ist aber zu beachten, dass der ARP-Pingsweep nur im lokalen Netzsegment funktioniert.
Weitere Tests kommen zu ähnlichen Ergebnissen und sehen beim direkten Vergleich weiterhin Nmap in der Spitzengruppe ([4], [5]). Dies liegt nicht zuletzt daran, dass auch Nmap viele Techniken von Portbunny implementiert, wenn auch auf andere Weis. Aber es verlangt vom Anwender einige Kenntnisse.
Für besondere Anlässe
Andere Portscanner, die auf technische Tricks zur Geschwindigkeitssteigerung zurückgreifen, sind übrigens »scanrand« [6] und »unicornscan« [7], die einen Blick wert sind. Portbunny befindet sich noch im Entwicklungsstadium und sollte entsprechend beurteilt werden. Um offene TCP-Ports im Netz zu finden, ist es offenbar geeignet. Dies ist schließlich das Hauptanliegen des Netzmappings. So präsentiert sich das Tool eher als Ergänzung, nicht als Ersatz im Werkzeugkasten der Netzwerkprofis. (mg)
|
Infos |
|---|
|
[1] Portbunny:[http://www.recurity-labs.com/portbunny/] [2] Anika Kehrer, Nils Magnus, “1984@24c3”: Linux-Magazin 03/08, S. 22 [3] Portbunny-Diskussion auf der Mailingliste »nmap-dev«: [http://seclists.org/nmap-dev/2008/q1/0096.html] [4] Tyler Reguly, “Port Scanner Challenge”: [http://computerdefense.org/?p=440] [5] Rober E. Lee, “Port Scanner Challenge Revisited”: [http://loquens-caesu.blogspot.com/2008/01/port-scanner-challenge-revisited-nmap.html] [6] Paketto Keiretsu: [http://doxpara.com] [7] Unicornscan: [http://www.unicornscan.org] |
|
Der Autor |
|---|
|
Thorsten Fischer lebt und arbeitet als Sicherheitsberater und Autor in Berlin und gelegentlich in London. |





