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.