Portscanner Nmap: erweiterte Scans nutzen

Nmap ist ein populärer Portscanner, mit dem du schon mit seinen grundlegenden Funktionen ermitteln kannst, welche Server, Clients und andere Systeme in deinem Netzwerk aktiv sind, welche Betriebs­systeme dort laufen und welche Ports von außen erreichbar sind. Schon deshalb ist Nmap nicht nur ein Werkzeug für Hacker, sondern auch für Penetrations-Tests. Dass Nmap aber noch viel mehr Informationen über deine Systeme liefern kann, die auch ein Hacker für einen erfolgreichen Angriff benötigt, verrät dieser Beitrag.

Passende Schulungen

CCSP Certified Cloud Security Professional (ISC)²

CCSP Certified Cloud Security Professional (ISC)²: Die perfekte Vorbereitung auf die CCSP Zertifizierung

(ISC)² SSCP Systems Security Certified Practitioner

(ISC)² SSCP Systems Security Certified Practitioner: Die perfekte Vorbereitung auf die (ISC)² SSCP Zertifizierung

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

Um die im Grundlagen-Beitrag erläuterten und weitere in der Tabelle aufgeführten TCP-Port-Scan-Methoden besser zu verstehen, solltest du elementare Konzepte des TCP-Protokolls kennen, wie z. B. den TCP-Verbindungsaufbau. Im Wesentlichen gibt es dabei zwei „reguläre“ Szenarien:  

Bei einem Szenario mit offenem Port lauscht eine Anwendung auf dem Server auf einem bestimmten Port auf eingehende Verbindungen vom Client. Der Port gilt somit als offen, d. h. er befindet sich im Status „TCP LISTEN“. Beim Empfang einer eingehenden Verbindungsanfrage – in Form eines Synchronisationspakets (SYN) – antwortet das Zielsystem (Server) mit einem SYN/ACK-Paket (Acknowledge), um die Synchronisation zu bestätigen. Sobald der Client von dem die Verbindungsanfrage ausging mit einem ACK-Paket antwortet, ist die Verbindung auf beiden Seiten hergestellt. Das ist der klassische TCP-3-Way-Handshake.

Die Sequenznummern spielen für die weiteren Erläuterungen erstmal keine Rolle. Details dazu findest du in meinem Artikel zu Wireshark (Link).

Bei einem zweiten möglichen Szenario (geschlossener Port) lauscht eben gerade keine Anwendung auf eingehende Verbindungen auf einem bestimmten Port auf dem Server. Daher gilt der Port als geschlossen, d. h. der Status ist „TCP CLOSED“. Kommt es dann zu einer eingehenden Verbindungsanfrage weist der Server die Verbindungsanfrage mit einem RST- oder Reset-Paket zurück.

Passende Schulungen

AZ-500 – Microsoft Azure Security Technologies (AZ-500T00)

AZ-500 – Microsoft Azure Security Technologies (AZ-500T00): Kenntnisse zur Sicherung von Microsoft Azure-Umgebungen

CCSA: Check Point Certified Security Administrator R81.20

CCSA: Check Point Certified Security Administrator R81.20: Werde zum Security Administrator

Im Zusammenhang mit einer Firewall ergibt sich ein drittes mögliches Szenario. Die an den Server gesendete Pakete werden hierbei einfach verworfen – entweder auf einer dedizierten Firewall oder dem Ziel-Server selbst, bzw. von dessen Paketfilter. In Folge davon antwortet der Server nie. Weil aber das Zielsystem nicht antwortet, wenn nmap ein Testpaket an den Port sendet, gilt der Port als „gefiltert“. Der Paketfilter lässt sich aber in einigen Fällen so konfigurieren, dass die verworfenen Pakete durch ICMP-Fehlermeldungen (Internet Control Message Protocol) signalisiert werden.

Bei Ports mit dem Status „FILTERED“ musst du dir in der Rolle „Angreifers“ zwei Fragen stellen: erfolgt auf ein Testpaket keine Antwort, weißt du noch nicht genau, ob der Port gefiltert wird oder ob das Testpaket z. B. wegen eines überlasteten Netzwerks verworfen wurde. Selbst wenn Letzteres auszuschließen ist, warte auf jeden Fall länger auf eine Antwort, als bei „open“ oder „closed“ (was ja eindeutig wäre) und kannst dadurch zu dem Ergebnis kommen, dass der Port „filtered“ ist.

Spezialisierte Portscans mit Nmap

Mit Hilfe des im Teil 1 erläuterten, „gewöhnlichen“ Portscans ermittelt nmap im Wesentlichen offene Ports und weiß in der Regel auch, zu welchen Anwendungen diese gehören.

Spezialisierten Portscans dagegen helfen in spezifischen Situationen weiter, wenn z. B. eine Firewall umgangen werden soll. Hier provozierst du absichtlich Reaktionen, die dir tiefergehende Erkenntnisse über den Portstatus liefern, wie z. B. der bereits erläuterte Ping-Scan. Dieser provoziert eine Antwort des Ziel-Systems mit Hilfe eines TCP-ACK-Pakets, um weitere Rückschlüsse auf den Port-Status ziehen zu können, denn einfach gestickte statuslose Firewalls wie Linux-iptables (ohne Connection Trackingfiltern filtern zwar meist eingehende SYN-Pakete, aber keine (streng genommen eigentlichen nicht zulässigen) ACK-Pakete.

Genau das provoziert eine Rückmeldung des Ziels etwa in Form eines RST-Pakets. Der Status des betroffenen Ports ist dann eben nicht mehr „filtered“ (also durch Firewall blockiert), sondern „unfiltered“. Letztes heißt dann für den Angreifer, dass der Port doch erreichbar ist, aber nicht weiter bestimmt werden kann, ob er offen oder geschlossen ist. Aktivieren kannst du den TCP-ACK-San mit „-sA“.

Scan-Timings

Möchtest du deine Firewall testen, bietet sich der TCP-ACK-San durchaus an. Allerdings solltest du das System auf jeden Fall mit unterschiedlichen Timings scannen. Hierzu stellt Nmap den Schalter -Tx zur Verfügung. Für x kannst du eine Ziffer von 0 bis 5 verwenden. Die Ziffern stehen für:

0 paranoid

1 sneaky

2 polite

3 normal

4 aggresive

5 insane

So kannst du z. B. mit ..

nmap -T4 -F

einen aggressiven Scan starten. Du musst nicht unbedingt alle sechs Timings ausprobieren, aber 2 oder 3 unterschiedliche sind ratsam, um eventuell verschiedene Reaktionen deiner Firewall (oder der Firewall des „Angriffsziels“ zu provozieren:

Übrigens zeigt dir z. B. Zenmap im Reiter „Ports / Rechner“ Detailinformationen zu den ermittelten Ports:

Da manche Systeme Pings blockieren, kannst du mit dem Schalter -PN jedes System scannen, egal ob dieses ping blockiert oder nicht.

TCP-Window-Scan

Sollte das Ergebnis eines TCP-ACK-Scans unbefriedigend sein, hilft unter Umständen der TCP-Window-Scan weiter (siehe Tabelle). 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 Empfangs-Puffers des Senders. Das Feld hat 2 Byte (16 Bit).

Die TCP-Fenstergröße ist eine der in TCP definierten Optionen für die Netzwerkfehlerbehebung. Die TCP-Fenstergröße, auch TCP-Empfängerfenstergröße gibt an, wie viele Daten (in Bytes) das empfangende Gerät zu jedem Zeitpunkt zu empfangen bereit ist. 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, wie z. B. ein Drucker, der ja gewisse „mechanische“ Einschränkungen mitbringt 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 Fenster-Größe eines geschlossenen Ports wird von einem solchen System auf Null gesetzt, sodass dieser von nmap als „closed“ angezeigt wird. Das gilt aber in der Praxis nur bei einer Minderheit der Systeme, so dass du dich darauf nicht verlassen kannst. 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. Den TCP-Windows-Scan leitest du mit dem Parameter „-sW“ ein.

Hier hilft also der TCP-Window-Scan nicht weiter. Als guter „Hacker“ hast du allerdings auch Spielraum zu Spekulationen.

FIN-, NULL- und XMAS-Scan

In den offiziellen TCP-Spezifikation sind Verarbeitungsregeln von Paketen für alle denkbaren Szenarien enthalten, sogar für solche, die zwar theoretisch denkbar sind, in der Praxis aber so gut wie nie vorkommen. Du kannst einige dieser Szenarien für TCP-Port-Scanning-Zwecke provozieren. So steht z. B. in den TCP-Spezifikation Folgendes: 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 (Server) 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.

Du kannst die Tatsache, dass abhängig vom Status des entsprechenden Ports ein bestimmtes Paket zwei unterschiedlichen Antworten provozieren kann, für TCP-Port-Scanning-Zwecke nutzen. So kannst du  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. Den Null-Scan, d. h. beim Testpaket ist überhaupt kein TCP-Flag gesetzt, haben wir bereits im Teil 1 des Beitrags genutzt, beim so genannten  TCP-NULL-Scan.  Ist beim Testpaket lediglich das FIN- (Finish-Bit) gesetzt, redet man vom so genannten TCP-FIN-Scan. Sind beim Testpaket 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 Verfahren 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. Allerdings erkennt das Zielsystem auch hierbei nicht, ob die empfangenen Testpakete von einer gefälschten Quelladresse kommen.

Auf der anderen Seite kann das Ergebnis dieser Methoden auch zu einer falschen Interpretation des Port-Status führen. Da ja eines der zwei möglichen Ergebnisse ein verworfenes Testpaket für einen offenen Port ist, könnte ein aufgrund eines überlasteten Netzwerks verworfenes Paket als offener Port und damit falsch interpretiert werden. Um so ein verworfenes Paket zuverlässig zu erkennen, muss nmap aber auch 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 das Tool in der Regel mit Superuser-Rechten ausgeführt werden. Einen Fin-Scan leitest du z. B. mit „nmap -sF ….“ ein.

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 sind aber recht einfach rückverfolgbar. Anders beim Idle-Scan, auch als IP-ID-Scan bezeichnet. Hierbei kann der Angreifer ein Zielsystem indirekt über einen sogenannten “Zombie-Host” scannen. Beim Idle-Scan wird nämlich kein einziges Paket direkt an das Zielsystem mit der eigenen echten Absenderadresse geschickt. Der Trick dazu besteht darin, die so genannte „Fragmentation Identification Number“ (IP-ID) im IP-Header nutzen. Diese wird für jedes IP-Paket gesetzt. Viele Systeme setzen die ID für jedes nachfolgende IP-Paket einfach nur um 1 nach oben.

Grundsätzlich besteht ein Idle-Scan aus drei Schritten, die für jeden Port wiederholt werden: Die Macher von Nmap beschreiben den Ablauf eines Idl-Scans ausführlich auf der https://nmap.org/book/idlescan.html Nmap-Seite.

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 Portstatus 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 Zielports wird dann bestimmt, indem diese neue IP-ID mit der in Schritt 1 aufgezeichneten verglichen wird.

Im Anschluss an diesen Vorgang sollte sich die IP-ID des Zombies um eins oder zwei erhöht haben. Eine Erhöhung um eins 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.

Ein Anstieg um zwei 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 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 Idl-Scan zu tun hat.

Obwohl also ein Unterschied zwischen geschlossenem Port und einem gefilterten Port besteht, misst der Angreifer in beiden Fällen das gleiche Ergebnis: eine Erhöhung der IP-ID um 1. Der Idle-Scan kann also nicht zwischen geschlossenen und gefilterten Ports unterscheiden. Daher markiert nmap den Port dann als „geschlossen|gefiltert“.

Einen Idle-Scan kannst du mit dem Schalter „-sI <Zombie-host> [:<Probe-Port>]“. Das Angeben des Probe-Ports ist optional. Per Default wird Port 80 verwendet. Dies könnte also z. B. so aussehen:

nmap –Pn –sI 192.168.1.200:85 192.168.1.254

Hierbei ist  192.168.1.200 der Zombie-Host, den du hier über den TCP-Port 85 ansprichst; 192.168.1.254 ist das Ziel-System. Die Angabe „-Pn“ sorgt dafür, dass du auf einen Ping-Scan verzichtest, damit du ganz sicher kein Paket von deiner eigenen, echten Absenderadresse schickst.