Tags: Netzwerk, Sicherheit, Monitoring
Nmap kann schon mit seinen Basisfunktionen ermitteln, welche Server, Clients und andere Geräte im Netzwerk aktiv sind, welche Betriebssysteme 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 Informationen ü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).
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 Flusssteuerungsmechanismus verwenden. Einige Betriebssysteme 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 Verarbeitungsregeln 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-Verarbeitungsregeln.
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ändlicherweise 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 Absenderadresse 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:
- Zunächst notiert sich der Angreifer die IP-ID des Zombies.
- 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.
- 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öglicherweise 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-Verarbeitungsregeln 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
Thomas Drilling arbeitet ist seit fast 30 Jahren selbständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehemalige 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 zertifizierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grundlagenkurse 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 Informationen und Anmeldung über sein Azure-Blog.
Verwandte Beiträge
- Nmap: Firewalls umgehen mit Ping- und TCP-ACK-Scans
- Portscanner Nmap: die wichtigsten Funktionen im Überblick
- Netzwerk-Analyse mit Wireshark: Datenströme verfolgen mit Verbindungsfiltern
- Netzwerk-Analyse mit Wireshark: TCP-Handshake beim Aufbau einer Sitzung untersuchen
- Netzwerk-Analyse mit Wireshark am Beispiel von Ping
Weitere Links