Interview mit Fyodor, dem Macher von Nmap

Die Auseinandersetzung zwischen dem Newcomer Portbunny und dem Titelverteidiger Nmap schwappt von den einschlägigen Mailinglisten über auf öffentliche Konferenzen. Nun geben sowohl Nmaps Chefentwickler Fyodor als auch die Herausforderer FX und Fabs dem Linux-Magazin Interviews .

Das zehn Jahre alt gewordene Nmap muss sich derzeit eines frechen Herausforderers erwehren: Portbunny (siehe vorigen Artikel). Im Interview mit dem Linux-Magazin im “Peninsula Creamery Fountain and Grill” in Palo Alto, Kalifornien (Abbildung 1), äußert sich Fyodor, amerikanischer Sicherheitsexperte und Projektleiter von Nmap, zu Stilfragen beim Promoten von OSS-Projekten, zur Entwicklung im Linux-Kernel und zur Konkurrenz zwischen Scannern. Den Gegenpart gibt’s im Kasten “Interview mit den Portbunny-Entwicklern”.

Linux-Magazin: Auf dem 24c3 in Berlin haben FX und Fabs von den Labs Recurity ihren neuen Scanner Portbunny vorgestellt. Hast Du die Präsentation gesehen?

Fyodor: Ja, ich habe sie gesehen. Gut, dass die Organisatoren den Konferenzmitschnitt online gestellt haben. Ich war allerdings etwas enttäuscht, dass FX und Fabs daraus so einen Anti-Nmap-Vortrag gemacht haben, anstatt ihr eigenes Projekt vorzustellen.

“Sie mussten lange suchen”

Linux-Magazin: Konntest Du neue Ideen oder Anregungen aus ihrer Arbeit schöpfen?

Fyodor: Vieles von dem, was sie als neu vorgestellt haben, macht Nmap schon seit Jahren. Dazu zählen auch die Trigger, die Nmap Port Scan Pings nennt. Sie suchen sich einen erreichbaren Port und pingen ihn regelmäßig an.

Den einzigen unabhängigen Vergleich, den ich bislang gesehen habe, hat Computerdefense durchgeführt. Dort waren sie der Meinung, dass Nmap mit seinen Standardeinstellungen sowohl schneller als auch präziser als Portbunny war. Es spricht Bände, wenn man dies mit ihren Aussagen aus der Präsentation vergleicht, in der sie vorgeben, dass sie lange nach einem Gerät suchen mussten, auf dem Nmap schneller als Portbunny läuft.

Am Anfang der Präsentation sprachen sie davon, bislang unbrauchbare Software neu schreiben zu wollen. Auf der Folie nennen sie zwar Nmap nicht direkt, aber im Rest des Vortrags ging es nur noch um einen Vergleich dazu.

Ich stimme ihnen durchaus zu, dass es einen breiten Raum für weitere Forschung nach Portscan-Algorithmen gibt, aber andere Entwickler von Scannern wie Unicornscan oder Scanrand haben es einfach viel besser verstanden, für ihren eigenen Code zu werben.

Linux-Magazin: Eine andere Frage: Portbunnys Ansatz ist, direkt in den Kernel …

Fyodor: (lacht)

Linux-Magazin:… den Scanner einzubauen. Kannst Du diesen Entschluss nachvollziehen?

Fyodor: Manchmal denken Entwickler, sie seien etwas Besonderes, wenn sie in Assembler statt in C schreiben, obgleich es gar nicht auf Geschwindigkeit ankommt. Ich denke, FX und Fabs haben ihr Projekt für den Kernel entwickelt, weil sie dachten, das wäre cool. Ja, der Ansatz hat tatsächlich ein paar nette Aspekte, aber aus praktischer Sicht ist er einfach nur ein ziemliches Desaster. Mehrere Leute auf unserer Mailingliste haben Portbunny getestet und berichten, dass ihr komplettes System gecrasht sei, statt dass das Programm nur mit einem Segmentation Fault abbricht.

Zudem mussten sie jegliche Portabilität aufgeben. Das Programm läuft nur auf genau dieser Kernelrelease. Sobald sich seine Datenstrukturen ändern, müssen sie diese auf alle Varianten anpassen. All dies bringt ihnen fast keine Vorteile. Nmap schickt so gut wie nie Pakete so schnell los, wie es kann. Die Algorithmen geben die Geschwindigkeit der Congestion-Kontrolle vor. Sie versuchen verlorene Pakete und Verzögerungen zu erkennen und entsprechend zu drosseln.

Abbildung 1: Nmap-Entwickler Fyodor (rechts) im Gespräch mit Linux-Magazin-Redakteur Nils Magnus: „Portbunny wird nie eine ernsthafte Konkurrenz zu Nmap, solange Anwender Kernelmodule laden müssen.“

“Ich sehe stattdessen die riesigen Nachteile”

Linux-Magazin: Vielleicht hat der Kernelspace Vorteile im Timing?

Fyodor: Die Entwickler sagen zwar, dass das für das Timing nützlich sei, aber wir bekommen unser Timing bei Nmap von der Libpcap. Daher kennen wir ohnehin die Ankunftszeiten im Kernel. FX und Fabs haben an einer Stelle der Präsentation sogar zugegeben, dass sie den Scanner als Userland-Anwendung hätten schreiben können. Sie hätten herausgefunden, dass das erwartete Mehr an Geschwindigkeit sich nicht einstellt.

Ich sehe keine ernsthaften Vorteile, aber stattdessen nur diese riesigen Nachteile. Ich glaube, dass dadurch, dass Portbunny ein Kernelmodul benötigt, es niemals ein ernsthafter Wettbewerber zu Nmap wird. Benutzer wollen einfach keine Kernelmodule laden, um einen Portscan zu machen.

“Benutzer stört es nicht, wenn sich etwasverzögert”

Linux-Magazin: Kannst Du Dir vorstellen, dass ein Portscanner ohne Realtime-Unterstützung mit Einschränkungen leben muss?

Fyodor: Es ist immer nett, solche Eigenschaften zur Verfügung zu haben. Ist das nicht der Fall, verzögern sich die Ergebnisse vielleicht ein klein wenig. Besonders unter Linux macht das aber kaum etwas aus, da wir die Empfangszeiten sowieso vom Kernel bekommen. Nmap erhält also selbst in einem preemptiven Kernel die Pakete einfach etwas später, weiß aber, wann sie angekommen sind. Auf diese Weise kann es die Round Trip Time berechnen. Auf Windows funktioniert das allerdings nicht. Dort greifen wir auf die Zeiten zurück, zu denen wir das Paket vom Kernel erhalten.

Benutzer stört es nicht, wenn sich etwas um wenige Millisekunden verzögert. Ein klein wenig Geschwindigkeit kostet es, keine Unterstützung für Realtime zu haben, besonders wenn es darum geht, Pakete zu versenden. Wir schicken allerdings kaum einmal Pakete mit einer Geschwindigkeit, die an die Grenzen der Hardware stößt. Das stellt also keine nennenswerte Einschränkung dar.

Linux-Magazin: Das betrifft ja nicht zuletzt auch Raw Sockets. Sind die Operationen auf ihnen zeitkritisch?

Fyodor: Nicht in dem Maße wie etwa bei Mediaplayern, bei denen es nervtötend ist, wenn die Verzögerung eine gewisse Zeitspanne übersteigt. Anwender kümmert es kaum, ob ein einzelner Scan 3,0 oder 3,1 Sekunden dauert. Was sie jedoch interessiert, ist, ob ihre Scans sehr lange bei Systemen dauern, die beispielsweise stark durch eine Firewall geschützt sind. In solchen Fällen verhält sich jeder Durchlauf fast wie ein UDP-Scan, bei dem eine Solaris-Box jede Sekunde ein ICMP Port Unreachable sendet. Das bedeutet, dass bei über 65000 Ports ein Scan im Grunde genommen einen ganzen Tag lang dauert. Nmap macht so etwas dann intelligenter und parallel.

Den Originalton des Interviews stellt Linux-Magazin Online unter [https://www.linux-magazin.de/news/interview_mit_nmap_entwickler_fyodor] bereit.

Interview mit den Portbunny-Entwicklern FX und Fabs
Das Linux-Magazin hat die Entwickler von Portbunny um eine Stellungnahme zu ihrem Design gebeten. Per E-Mail antworteten Felix “FX” Lindner und Fabian “Fabs” Yamaguchi: Linux-Magazin: Was hat Euch dazu bewogen, einen neuen Scanner zu entwerfen? FX: Wir bei Recurity benötigten einen Scanner, der für unsere Kunden Vorhersagbarkeit und effiziente Zeitnutzung schafft. Fabs: Außerdem brauchten wir einen Scanner, der sich dynamisch an das Zielnetz anpasst, ohne viele Flags zu konfigurieren. Timing sollte Sache des Portscanners und nicht Sache des Pen-Testers sein. Nmap anzupassen erschien uns da aufwändiger als eine Neuentwicklung. Linux-Magazin: Wieso läuft Portbunny im Kernel und wie habt Ihr das implementiert? Fabs: Wir haben so einen effizienten Zugriff auf alle Ethernet-Frames und können etwa mittels hochaufgelöster Timer auf sie reagieren. Doch die Probleme beim Portscanning sind in erster Linie algorithmischer und weniger technischer Natur. Zwar ist es wünschenswert, effizient Pakete zu verschicken, aber das macht nicht den Löwenanteil des Zeitgewinns aus. Kniffliger ist, dynamisch die sich ändernde optimale Geschwindigkeit anhand der Reaktionen des Netzes zu bestimmen. Anders als die Fluss- und Congestion-Kontrolle haben wir ja nur Einfluss auf den Sender. Der Kernelspace ist genau auf diese Bedürfnisse zugeschnitten. Linux-Magazin: Ist der preemptive Scheduler da ein Problem? Nutzt Ihr Realtime-Features? Fabs: Er kann eines sein, aber in der Praxis liegt der Hund hier nicht begraben. Natürlich wäre Realtime geeignet, aber wir sind diesen Schritt noch nicht gegangen. Linux-Magazin: Wie greift Ihr auf das Netz zu? FX: Ich habe viel Erfahrung mit Raw Sockets gesammelt. Beim Senden ist wichtig, dass der Kernel sich nicht einmischt, etwa der Connection-Tracker von IPtables Pakete verbiegt. Wir wollten ein klares Interface im Kernelspace. Linux-Magazin: Was unterscheidet Eure Trigger von den Port Scan Pings von Nmap? Fabs: Der Grundgedanke ist ähnlich, aber unser Timing benutzt gar nicht erst Probe-Responses, da nie sicher ist, ob sie Antworten hervorrufen. Portbunny verschickt mit hoher Rate Trigger und variiert sein Timing danach. Nmap verschickt Scanproben, wenn es innerhalb von fünf Sekunden kein Lebenszeichen vom Host empfängt. Der Unterschied führt zu mehr Geschwindigkeit bei gefilterten Hosts. Linux-Magazin: Wie bewertet Ihr die bisher veröffentlichten Vergleichstests? Arbeitet Ihr weiter an Verbesserungen von Portbunny? FX: Einige Tests sind nicht wirklich unabhängig, aber wir betonen, dass wir nicht das Ziel haben, immer die Schnellsten zu sein. Lokale Scangeschwindigkeiten spielen für den Profi kaum eine Rolle, denn er benötigt Rate-Limits, um nicht Netz und Server lahmzulegen. Fabs entwickelt Portbunny kontinuierlich weiter. Der nächste Release-Termin und die Version stehen aber noch nicht fest. Geplante Features sind noch bessere Scanzeiten und Verlässlichkeit in jedem Szenario. Mehr Funktionen wird es nicht geben, vielleicht aber andere Tools, die auf Portbunny aufsetzen. Eine klare Trennung von Scan-Engine und nachgelagerten Funktionalitäten bleibt unser oberstes Gebot.

Interview mit den
Portbunny-Entwicklern FX und Fabs

Das Linux-Magazin hat die Entwickler von Portbunny um eine Stellungnahme zu ihrem Design gebeten. Per E-Mail antworteten Felix “FX” Lindner und Fabian “Fabs” Yamaguchi:

Linux-Magazin: Was hat Euch dazu bewogen, einen neuen Scanner zu entwerfen?

FX: Wir bei Recurity benötigten einen Scanner, der für unsere Kunden Vorhersagbarkeit und effiziente Zeitnutzung schafft.

Fabs: Außerdem brauchten wir einen Scanner, der sich dynamisch an das Zielnetz anpasst, ohne viele Flags zu konfigurieren. Timing sollte Sache des Portscanners und nicht Sache des Pen-Testers sein. Nmap anzupassen erschien uns da aufwändiger als eine Neuentwicklung.

Linux-Magazin: Wieso läuft Portbunny im Kernel und wie habt Ihr das implementiert?

Fabs: Wir haben so einen effizienten Zugriff auf alle Ethernet-Frames und können etwa mittels hochaufgelöster Timer auf sie reagieren. Doch die Probleme beim Portscanning sind in erster Linie algorithmischer und weniger technischer Natur. Zwar ist es wünschenswert, effizient Pakete zu verschicken, aber das macht nicht den Löwenanteil des Zeitgewinns aus. Kniffliger ist, dynamisch die sich ändernde optimale Geschwindigkeit anhand der Reaktionen des Netzes zu bestimmen. Anders als die Fluss- und Congestion-Kontrolle haben wir ja nur Einfluss auf den Sender. Der Kernelspace ist genau auf diese Bedürfnisse zugeschnitten.

Linux-Magazin: Ist der preemptive Scheduler da ein Problem? Nutzt Ihr Realtime-Features?

Fabs: Er kann eines sein, aber in der Praxis liegt der Hund hier nicht begraben. Natürlich wäre Realtime geeignet, aber wir sind diesen Schritt noch nicht gegangen.

Linux-Magazin: Wie greift Ihr auf das Netz zu?

FX: Ich habe viel Erfahrung mit Raw Sockets gesammelt. Beim Senden ist wichtig, dass der Kernel sich nicht einmischt, etwa der Connection-Tracker von IPtables Pakete verbiegt. Wir wollten ein klares Interface im Kernelspace.

Linux-Magazin: Was unterscheidet Eure Trigger von den Port Scan Pings von Nmap?

Fabs: Der Grundgedanke ist ähnlich, aber unser Timing benutzt gar nicht erst Probe-Responses, da nie sicher ist, ob sie Antworten hervorrufen. Portbunny verschickt mit hoher Rate Trigger und variiert sein Timing danach. Nmap verschickt Scanproben, wenn es innerhalb von fünf Sekunden kein Lebenszeichen vom Host empfängt. Der Unterschied führt zu mehr Geschwindigkeit bei gefilterten Hosts.

Linux-Magazin: Wie bewertet Ihr die bisher veröffentlichten Vergleichstests? Arbeitet Ihr weiter an Verbesserungen von Portbunny?

FX: Einige Tests sind nicht wirklich unabhängig, aber wir betonen, dass wir nicht das Ziel haben, immer die Schnellsten zu sein. Lokale Scangeschwindigkeiten spielen für den Profi kaum eine Rolle, denn er benötigt Rate-Limits, um nicht Netz und Server lahmzulegen.

Fabs entwickelt Portbunny kontinuierlich weiter. Der nächste Release-Termin und die Version stehen aber noch nicht fest. Geplante Features sind noch bessere Scanzeiten und Verlässlichkeit in jedem Szenario. Mehr Funktionen wird es nicht geben, vielleicht aber andere Tools, die auf Portbunny aufsetzen. Eine klare Trennung von Scan-Engine und nachgelagerten Funktionalitäten bleibt unser oberstes Gebot.