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


    Tags: , ,

    nmap-LogoNmap kann schon mit seinen Basis­funktionen ermitteln, welche Server, Clients und andere Geräte im Netzwerk aktiv sind, welche Betriebs­systeme dort laufen und welche Ports von außen erreichbar sind. Das Tool liefert mit TCP-Window-, FIN-, NULL- und XMAS-Scans aber noch viel mehr Informa­tionen über gefundene Systeme.

    Bevor wir uns den erweiterten Port-Scans zuwenden, hier noch einmal alle von nmap unterstützten Portscan-Typen:

    Schalter Erläuterung
    -sU UDP-Scan
    --scanflags Legt eigene Flags für TCP-Scans fest, möglich sind: SYN, ACK, FIN, RST, PSH, URG
    -sS TCP-SYN-Scan (Standardscan), auch Half-Open-Scan, d. h. kein vollständiger Handshake
    -sT TCP-Connect-Scan, vollständiger Handshake
    -sA TCP-ACK-Scan, d. h. ACK-Flag gesetzt
    -sN TCP-NULL-Scan, d. h. kein Flag gesetzt
    -sW TCP-Window-Scan (untersucht das Window-Feld im TCP-Header)
    -sF TCP-FIN-Scan, d. h. FIN-Flag gesetzt
    -sX TCP-XMAS-Scan, d. h. FIN, PSH und URG gesetzt
    -sM TCP-Maimon-Scan, d. h. FIN/ACK gesetzt
    -sI [:] Idle-Scan (IP-ID-Scan): Indirekter Scan mit Zombie-Host

    TCP-Window-Scan

    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).

    TCP-Window-Size im TCP-Header

    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.

    Der TCP-Windows-Scan in nmap

    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.

    Idle-Scan eines geschlossenen Ports (Quelle: nmap.org)

    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".

    Idle-Scan eines gefilterten Ports (Quellenmap.org)

    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.

     Idle-Scan eines offenen Ports (Quelle: nmap.org)

    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.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Thomas Drilling

    Thomas Drilling arbeitet ist seit fast 30 Jahren selb­ständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehe­malige und aktuelle IT-Magazine sowie Blogs.

    Aktuell bestätigt sich Thomas schwerpunktmäßig als IT-Trainer für Cloud-Computing in den Bereichen Microsoft Azure, Amazon Web Services und VMware.

    Thomas ist zertifizierter Microsoft-Trainer für nahe das gesamte Portfolio an Microsoft Azure Trainings. Thomas ist außerdem zerti­fi­zierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grund­lagenkurse in Cloud Computing mit Azure durch, die sich inhaltlich bewusst von den Microsft-Kursen abheben und vorzuweise als Bootcamp in eine besonderen Lokation stattfinden. Optional kann aber aber auch remote via Microsoft Teams teilgenommen werden.

    Das aktuelle Trainingsprogramm findet sich unter Azure-Trainings. Weitere Infor­mationen und Anmel­dung über sein Azure-Blog.

    Verwandte Beiträge

    Weitere Links