Fortgeschrittene Techniken mit Nmap: TCP-Window-, FIN-, NULL- und XMAS-Scans

Sollte das Ergebnis eines TCP-ACK-Scans unbefriedigend sein, hilft unter Umständen der TCP-Window-Scan weiter (Parameter -sW). Dieser kann die Idee des ACK-Scans verfeinern, indem er eine Analyse der TCP-Fenstergröße (Window Size) einbezieht. Im TCP-Header gibt das Feld Window die Größe des Empfangspuffers des Senders an. Es hat eine Länge von 2 Byte (16 Bit).

Die TCP-Fenstergröße ist eine definierte Option für die Behebung von Netzwerkfehlern. Sie gibt an, wie viele Daten (in Bytes) die Gegenstelle zu jedem Zeitpunkt bereit ist zu empfangen.

Das empfangende Gerät kann diesen Wert zur Steuerung des Datenflusses oder als Fluss­steuerungs­mechanismus verwenden. Einige Betriebs­systeme verwenden ein Vielfaches ihrer maximalen Segmentgröße (MSS), um die maximale TCP-Fenstergröße zu berechnen.

Beispielsweise beträgt der Standardwert in Microsoft Windows in Ethernet-Netzwerken 17.520 Bytes oder 12 MSS-Segmente mit jeweils 1.460 Bytes.

Es sind auch Situationen denkbar, in denen der Empfänger überfordert ist. Dann wird er eine Fenstergröße von null ankündigen. Das gilt beispielsweise für Drucker, die ja gewisse mechanische Einschränkungen aufweisen, oder ein tatsächlich überlastetes System.

Interessant ist in diesem Zusammenhang, dass einige Betriebssysteme bei einem offenen Port auch für ein TCP-RST-Paket eine positive TCP-Fenster-Größe zurückliefern. Nmap meldet den Port dann als OPEN.

Die Fenstergröße eines geschlossenen Ports wird von einem solchen System auf null gesetzt, so dass dieser von nmap als CLOSED angezeigt wird. Das gilt aber in der Praxis nur bei den wenigsten Systemen, so dass Sie sich darauf nicht verlassen können.

Es kann auch passieren, dass ein TCP-Window-Scan alle getesteten Ports als CLOSED identifiziert, sofern das Zielsystem die Window-Größe nicht in der beschriebenen Weise behandelt.

Hier hilft also der TCP-Window-Scan nicht weiter. Als guter Pentester haben Sie allerdings auch Spielraum für Spekulationen.

NULL-, FIN- und XMAS-Scan

In der offiziellen TCP-Spezifikation sind Verarbeitungs­regeln von Paketen für alle denkbaren Szenarien enthalten, sogar für solche, die in der Praxis aber so gut wie nie vorkommen.

Sie können einige dieser Regeln für TCP-Port-Scanning-Zwecke einsetzen. So schreibt die TCP-Spezifikation zum Beispiel folgendes vor:

Wird ein eingehendes TCP-Paket ohne gesetztes ACK-Bit empfangen und es handelt sich NICHT um ein SYN- oder RST-Paket, dann muss der Empfänger wie folgt reagieren:

• Ist der Port geschlossen, also im Status CLOSED, ist als Antwort ein RST-Segment zu senden.
• Ist der Port geöffnet, also im Status LISTEN, ist das eingehende Paket automatisch zu verwerfen.

So können Sie jedes Paket ohne gesetztes ACK-Bit, bei dem es sich nicht um ein SYN- oder RST-Paket handelt, nutzen, um eine der zwei beschriebenen Reaktionen zu provozieren.

Ist beim Testpaket

• überhaupt kein TCP-Flag gesetzt, dann handelt es sich um einen so genannten TCP-NULL-Scan.
• lediglich das FIN- (Finish-Bit) gesetzt ist, redet man vom so genannten TCP-FIN-Scan (Parameter -sF).
• das FIN-, PSH- (Push-) und das URG- (Urgent-)Bit gesetzt, heißt die Methode XMAS-Scan.

Auch wenn sich die Namen dieser drei Scan-Verfahren abhängig von den im TCP-Testpaket gesetzten Bits unterscheiden, verwenden alle drei die gleichen TCP-Verarbeitungs­regeln.

Gegenüber dem gewöhnlichen Connect- oder SYN-Scan liegt der Vorteil hier darin, dass der Port-Scan sogar dann funktioniert, wenn ein Paketfilter eingehende Verbindungen unterbindet, weil er SYN-Pakete verwirft.

Da ein verworfenes Testpaket aber auch durch ein überlastetes Netzwerk verursacht werden kann, ließe sich dieses Ergebnis fälschlich als offener Port interpretieren. Um ein verworfenes Paket zuverlässig zu erkennen, muss nmap daher länger warten als beim Empfang einer positiven Antwort, die auf einen offenen Port hinweisen würde.

Damit das Scan-Tool beim Einsatz eines FIN-NULL-XMAS-Scans extra zu diesem Zweck erstellte TCP-Pakete senden kann, muss es in der Regel mit Superuser-Rechten ausgeführt werden.

Angriff verschleiern mit Idle-Scan

Für echte Bösewichte ist es in einem Angriffsszenario verständlicher­weise von Bedeutung, unentdeckt zu bleiben. Alle bisher behandelten Scan-Typen lassen sich jedoch recht einfach zurückverfolgen.

Anders sieht es beim Idle-Scan, auch als IP-ID-Scan bezeichnet, aus. Hierbei kann der Angreifer ein Zielsystem indirekt über einen so genannten Zombie-Host scannen. Dabei wird kein einziges Paket direkt an das Zielsystem mit der eigenen echten Absender­adresse geschickt.

Der Trick besteht darin, die so genannte Fragmentation Identification Number (IP-ID) im IP-Header zu nutzen. Diese wird für jedes IP-Paket gesetzt. Viele Systeme erhöhen die ID für jedes nachfolgende IP-Paket einfach nur um den Wert 1.

Grundsätzlich besteht ein Idle-Scan aus drei Schritten, die für jeden Port wiederholt werden:

1. Zunächst notiert sich der Angreifer die IP-ID des Zombies.
2. Dann fälscht er ein SYN-Paket vom Zombie und sendet es an den gewünschten Port des Ziels. Je nach Port-Status kann die Reaktion des Ziels dazu führen, dass die IP-ID des Zombies erhöht wird oder nicht.
3. Dann prüft er die IP-ID des Zombies erneut. Der Zustand des Ziel-Ports wird dann bestimmt, indem er die neue IP-ID mit dem in Schritt 1 aufgezeichneten Wert vergleicht.

Eine Erhöhung um 1 bedeutet, dass der Zombie keine Pakete gesendet hat, abgesehen von seiner Antwort auf die Untersuchung des Angreifers. Der Port ist also nicht geöffnet, denn das Ziel muss dem Zombie entweder ein RST-Paket gesendet haben, das ignoriert wurde, oder eben nichts.

Der Idle-Scan misst allerdings bei einem geschlossenen und bei einem gefilterten Port das gleiche Ergebnis, nämlich eine Erhöhung der IP-ID um 1. Er kann also nicht zwischen diesen beiden Zuständen unterscheiden. Daher markiert nmap den Port dann als "geschlossen|gefiltert".

Ein Anstieg um 2 bedeutet hingegen, dass der Zombie ein Paket zwischen den beiden Prüfungen gesendet hat.

Dieses zusätzliche Paket ist in der Regel ein Indikator, dass der Port offen ist, denn das Ziel hat dem Zombie vermutlich ein SYN/ACK-Paket als Antwort auf das gefälschte SYN geschickt, das wiederum ein RST-Paket vom Zombie ausgelöst hat.

Erhöhungen größer als zwei sind dagegen ein Anzeichen für einen schlechten Zombie als Wirt, der möglicher­weise keine vorhersagbaren IP-ID-Nummern hat oder an einer Kommunikation beteiligt ist, die nichts mit dem Idle-Scan zu tun hat.

Einen Idle-Scan führen Sie mit dem Schalter

nmap -sI <Zombie-host> [:<Probe-Port>]

aus. Das Angeben des Probe-Ports ist optional. Per Voreinstellung wird Port 80 verwendet. Dies könnte also beispielsweise so aussehen:

nmap –Pn –sI 192.168.1.200:85 192.168.1.254

Hierbei ist 192.168.1.200 der Zombie-Host, den Sie hier rüber den TCP-Port 85 ansprechen; 192.168.1.254 ist das Ziel-System. Mit der Angabe von -Pn verzichten Sie auf einen Ping-Scan, damit Sie ganz sicher kein Paket von ihrer eigenen, echten Absenderadresse zu schicken.

Zusammenfassung

Wenn man mit einem einfachen TCP-ACK-Scan nicht ermitteln kann, ob ein Port offen, geschlossen oder gefiltert ist, kann man ihn um einen TCP-Window-Scan ergänzen. Der Erfolg dieser Methode hängt von der spezifischen Reaktion des Zielsystems ab.

Kommt man damit zu keinem verlässlichen Ergebnis, dann bietet nmap mit NULL-, FIN- und XMAS-Scans weitere Alternativen an. Sie verwenden die gleichen TCP-Verarbeitungs­regeln und unterscheiden sich nur durch die im TCP-Testpaket gesetzten Bits.

Möchte man die Quelle eines Scans verschleiern, dann erlaubt es nmap, einen so genannten Zombie-Host als Zwischenstation für einen Idle-Scan zu nutzen.