Der SYN-Scan ist aus gutem Grund die Standardeinstellung und die beliebteste Scan-Methode. Er kann schnell durchgeführt werden und scannt dabei Tausende von Ports pro Sekunde, wenn das Netzwerk schnell ist und nicht von einer intrusiven Firewall behindert wird. Der SYN-Scan ist relativ unauffällig, da er TCP-Verbindungen niemals abschließt. Außerdem funktioniert er auch bei allen konformen TCP-Stacks und ist unabhängig von spezifischen Eigenarten von Plattformen, wie es bei den FIN-/NULL-/Xmas-, Maimon- und Idle-Scans in Nmap der Fall ist. Er erlaubt auch eine klare, zuverlässige Unterscheidung zwischen den Zuständen offen, geschlossen und gefiltert.

Diese Methode wird oft als halboffenes Scannen bezeichnet, weil keine vollständige TCP-Verbindung hergestellt wird. Sie senden ein SYN-Paket, als ob Sie eine echte Verbindung herstellen würden, und warten dann auf eine Antwort. Ein SYN/ACK zeigt, dass jemand auf dem Port lauscht (dass er offen ist), während ein RST (Reset) anzeigt, dass niemand darauf lauscht. Falls nach mehreren erneuten Übertragungen keine Antwort erhalten wird, wird der Port als gefiltert markiert. Der Port wird auch dann als gefiltert markiert, wenn ein ICMP Unreachable-Fehler (Typ 3, Code 1, 2, 3, 9, 10 oder 13) empfangen wird.

Der TCP-Connect-Scan ist der standardmäßig eingestellte TCP-Scan-Typ, falls der SYN-Scan nicht möglich ist. Das ist dann der Fall, wenn der Benutzer kein Recht hat, rohe Pakete zu senden, oder wenn er IPv6-Netzwerke scannt. Statt rohe Pakete zu schreiben, wie es die meisten anderen Scan-Typen machen, bittet Nmap das darunterliegende Betriebssystem, eine Verbindung mit dem Zielrechner und -port herzustellen, indem es einen Systemaufruf namens connect benutzt. Das ist derselbe Systemaufruf auf höherer Ebene, den Webbrowser, P2P-Clients und die meisten anderen netzwerkfähigen Anwendungen benutzen, um eine Verbindung herzustellen. Er ist Teil einer Programmierschnittstelle, die unter dem Namen Berkeley Sockets-API bekannt ist. Statt Antworten in Form roher Pakete von der Leitung zu lesen, benutzt Nmap diese API, um zu jedem Verbindungsversuch eine Statusinformation zu erhalten.

Wenn der SYN-Scan verfügbar ist, ist er normalerweise die bessere Wahl. Nmap hat weniger Einfluss auf den connect-Systemaufruf als auf rohe Pakete, wodurch es weniger effizient wird. Der Systemaufruf beendet Verbindungen zu offenen Ziel-Ports vollständig, statt sie in halboffenen Zustand zurückzusetzen, wie es der SYN-Scan macht. Das dauert nicht nur länger und erfordert mehr Pakete, um an dieselbe Information zu gelangen, sondern es ist sehr viel wahrscheinlicher, dass die Zielrechner die Verbindung protokollieren. Ein anständiges IDS wird beides mitbekommen, aber die meisten Rechner verfügen nicht über ein solches Alarmsystem. Viele Dienste auf Ihrem durchschnittlichen Unix-System fügen eine Notiz ins syslog hinzu und manchmal eine kryptische Fehlermeldung, wenn Nmap eine Verbindung herstellt und sofort wieder schließt, ohne Daten zu senden. Ganz armselige Dienste stürzen auch ab, wenn so etwas passiert, was aber eher selten ist. Ein Administrator, der in seinen Protokollen einen Haufen Verbindungsversuche von einem einzelnen System aus sieht, sollte wissen, dass er Ziel eines Connect-Scans wurde.

Obwohl die meisten bekannten Dienste im Internet über das TCP-Protokoll laufen, sind UDP-Dienste weitverbreitet. Drei der häufigsten sind DNS, SNMP und DHCP (auf den registrierten Ports 53, 161/162 und 67/68). Weil UDP-Scans im Allgemeinen langsamer und schwieriger als TCP-Scans sind, werden diese Ports von manchen Sicherheitsprüfern einfach ignoriert. Das ist ein Fehler, denn ausbeutbare UDP-Dienste sind recht häufig, und Angreifer ignorieren bestimmt nicht das ganze Protokoll. Zum Glück kann Nmap helfen, diese UDP-Ports zu inventarisieren.

Ein UDP-Scan wird mit der Option -sU aktiviert. Er kann mit einem TCP-Scan-Typ wie einem SYN-Scan (-sS) kombiniert werden, um beide Protokolle im gleichen Durchlauf zu prüfen.

Beim UDP-Scan wird ein leerer UDP-Header (ohne Daten) an alle Ziel-Ports geschickt. Falls ein ICMP Port-unreachable-Fehler (Typ 3, Code 3) zurückkommt, ist der Port geschlossen. Andere ICMP Unreachable-Fehler (Typ 3, Codes 1, 2, 9, 10 oder 13) markieren den Port als filtered. Gelegentlich wird ein Dienst mit einem UDP-Paket antworten, was beweist, das er offen ist. Falls nach einigen erneuten Übertragungen keine Antwort erhalten wird, wird der Port als offen|gefiltert klassifiziert. Das heißt, der Port könnte offen sein, oder aber es gibt Paketfilter, die die Kommunikation blockieren. Man kann eine Versionserkennung (-sV) benutzen, um bei der Unterscheidung der wirklich offenen von den geschlossenen Ports zu helfen.

Eine große Herausforderung beim UDP-Scanning ist Geschwindigkeit. Offene und gefilterte Ports antworten nur selten, wodurch Nmap Zeitbeschränkungen überschreitet und seine Anfragen erneut sendet, für den Fall, dass das Testpaket oder die Antwort verloren ging. Geschlossene Ports sind oftmals ein noch größeres Problem. Sie senden normalerweise eine ICMP Port-unreachable-Fehlermeldung zurück. Aber anders als die RST-Pakete, die von geschlossenen TCP-Ports als Antwort auf einen SYN- oder Connect-Scan geschickt werden, beschränken viele Hosts standardmäßig die Rate der ICMP Port-unreachable-Nachrichten. Linux und Solaris sind dabei besonders streng. Der Linux-Kernel 2.4.20 z.B. beschränkt Destination-unreachable-Nachrichten auf eine pro Sekunde (in net/ipv4/icmp.c).

Nmap erkennt eine Ratenbeschränkung und verlangsamt seinen Betrieb entsprechend, um zu vermeiden, dass das Netzwerk mit nutzlosen Paketen überflutet wird, die vom Zielrechner verworfen werden. Unglücklicherweise führt eine Beschränkung wie in Linux auf ein Paket pro Sekunde dazu, dass ein Scan von 65.536 Ports über 18 Stunden dauert. Um Ihre UDP-Scans zu beschleunigen, können Sie z.B. mehr Hosts parallel scannen, zuerst nur einen schnellen Scan der beliebten Ports durchführen, von hinter der Firewall scannen und die Option --host-timeout benutzen, um langsame Hosts auszulassen.

Diese drei Scan-Typen (noch mehr sind mit der im nächsten Abschnitt beschriebenen Option --scanflags möglich) beuten ein subtiles Schlupfloch im TCP RFC aus, um zwischen offenen und geschlossenen Ports zu unterscheiden. Seite 65 von RFC 793 besagt: „Falls der Zustand des [Ziel-] Ports GESCHLOSSEN ist ... bewirkt ein eingehendes Segment, in dem sich kein RST befindet, dass ein RST als Antwort gesendet wird.“ Die nächste Seite beschreibt dann Pakete, die ohne gesetztes SYN-, RST- oder ACK-Bit an offene Ports geschickt werden, und dort heißt es weiter: „Es ist unwahrscheinlich, dass Sie hierhin kommen, aber wenn doch, dann verwerfen Sie das Segment und springen Sie zurück.“

Beim Scannen von Systemen, die konform zu diesem RFC-Text sind, führt jedes Paket, das kein SYN-, RST- oder ACK-Bit enthält, dazu, dass ein RST zurückgegeben wird, wenn der Port geschlossen ist, bzw. zu gar keiner Antwort, falls der Port offen ist. Solange keines dieser drei Bits gesetzt ist, sind alle Kombinationen der anderen drei (FIN, PSH und URG) okay. Das nutzt Nmap mit drei Scan-Typen aus:

Diese drei Scan-Typen haben exakt dasselbe Verhalten und unterscheiden sich nur in den TCP-Flags ihrer Testpakete. Wenn ein RST-Paket empfangen wird, wird der Port als geschlossen betrachtet, während keine Antwort bedeutet, dass er offen|gefiltert ist. Der Port wird als gefiltert markiert, falls ein ICMP Unreachable-Fehler (Type 3, Code 1, 2, 3, 9, 10 oder 13) empfangen wird.

Der Schlüsselvorteil dieser Scan-Arten ist, dass sie sich an bestimmten zustandslosen Firewalls und paketfilternden Routern vorbeschleichen können. Ein weiterer Vorteil ist, dass diese Scan-Arten ncoh ein wenig unauffälliger sind als ein SYN-Scan. Aber verlassen Sie sich nicht darauf – die meisten modernen IDS-Produkte können so konfiguriert werden, dass sie diese Scans erkennen. Der große Nachteil ist, dass nicht alle Systeme sich ganz genau an RFC 793 halten. Eine Reihe von Systemen sendet RST-Antworten auf die Testpakete, unabhängig davon, ob der Port offen ist oder nicht. Das bewirkt, dass alle Ports als geschlossen markiert werden. Hauptvertreter der Betriebssysteme, die das machen, sind Microsoft Windows, viele Cisco-Geräte, BSDI und IBM OS/400. Aber auf den meisten Unix-basierten Systemen funktioniert dieser Scan. Ein weiterer Nachteil dieser Scans ist, dass sie keine Unterscheidung zwischen offenen und bestimmten gefilterten Ports machen, sondern lediglich das Ergebnis offen|gefiltert ausgeben.

Dieser Scan unterscheidet sich insofern von den bisher hier vorgestellten, als er nie offene (oder auch nur offene|gefilterte) Ports bestimmt. Er wird dazu benutzt, Firewall-Regeln zu bestimmen, festzustellen, ob sie zustandsbehaftet sind oder nicht, und welche Ports gefiltert werden.

Beim Testpaket eines ACK-Scans wird nur das ACK-Flag gesetzt (es sei denn, Sie benutzen --scanflags). Beim Scannen ungefilterter Systeme werden sowohl offene als auch geschlossene Ports ein RST-Paket zurückgeben. Nmap markiert sie dann als ungefiltert, d.h. sie werden vom ACK-Paket erreicht, aber es kann nicht bestimmt werden, ob sie offen oder geschlossen sind. Ports, die nicht antworten oder bestimmte ICMP-Fehlermeldungen zurückgeben (Type 3, Code 1, 2, 3, 9, 10 oder 13), werden als gefiltert markiert.

Der Window-Scan ist genau derselbe wie der ACK-Scan, nur dass er ein Implementationsdetail bestimmter Systeme zur Unterscheidung zwischen offenen und geschlossenen Ports nutzt, statt bei jedem erhaltenen RST immer nur ungefiltert anzugeben. Das geschieht durch Analyse der TCP-Fenstergröße der zurückgegebenen RST-Pakete. Auf manchen Systemen benutzen offene Ports eine positive Fenstergröße (sogar für RST-Pakete), während geschlossene eine Fenstergröße von Null haben. Statt einen Port immer als ungefiltert aufzulisten, wenn von dort ein RST zurückkommt, listet der Window-Scan den Port als offen oder geschlossen auf, je nachdem, ob die TCP-Fenstergröße in diesem Reset jeweils positiv oder Null ist.

Dieser Scan baut auf einem Implementationsdetail einer Minderheit von Systemen im Internet auf, d.h. Sie können sich nicht immer darauf verlassen. Systeme, die es nicht unterstützen, werden normalerweise alle Ports als geschlossen zurückgeben. Natürlich ist es möglich, dass auf dem Rechner wirklich keine offenen Ports sind. Falls die meisten gescannten Ports geschlossen, aber einige Ports mit geläufigen Nummern (wie 22, 25 und 53) gefiltert sind, dann ist das System sehr wahrscheinlich anfällig. Gelegentlich zeigen Systeme auch genau das gegenteilige Verhalten. Falls Ihr Scan 1000 offene und drei geschlossene oder gefilterte Ports anzeigt, dann könnten jene drei sehr wohl die wirklich wahren offenen Ports sein.

Der Maimon-Scan wurde nach seinem Erfinder, Uriel Maimon, benannt. Er hat diese Methode im Phrack-Magazin, Ausgabe #49 (November 1996), beschrieben. Zwei Ausgaben später war diese Methode in Nmap enthalten. Sie macht genau das Gleiche wie der NULL-, FIN- und Xmas-Scan, außer, dass sie ein FIN/ACK-Testpaket verwendet. Laut RFC 793 (TCP) sollte als Antwort auf solch ein Paket ein RST-Paket erzeugt werden, egal ob der Port offen oder geschlossen ist. Allerdings hatte Uriel bemerkt, dass viele von BSD abgeleitete Systeme das Paket einfach verwerfen, wenn der Port offen ist.

Wirklich fortgeschrittene Nmap-Benutzer brauchen sich nicht auf die vorgefertigten Scan-Typen zu beschränken. Mit der Option --scanflags können Sie Ihren eigenen Scan entwerfen, für den Sie beliebige TCP-Flags angeben können. Lassen Sie Ihrer Kreativität freien Lauf und umgehen Sie Intrusion-Detection-Systeme, deren Hersteller einfach die Nmap-Manpage durchgeblättert und spezifische Regeln dafür angegeben haben!

Das Argument für --scanflags kann ein numerischer Flag-Wert wie z.B. 9 (PSH und FIN) sein, aber symbolische Namen sind einfacher zu benutzen. Erstellen Sie einfach eine beliebige Kombination von URG, ACK, PSH, RST, SYN und FIN. So setzt z.B. --scanflags URGACKPSHRSTSYNFIN alle Flags, auch wenn das beim Scannen nicht besonders hilfreich ist. Die Reihenfolge, in der Sie diese Flags angeben, spielt keine Rolle.

Zusätzlich zu den gewünschten Flags können Sie einen TCP-Scan-Typen (z.B. -sA oder -sF) angeben. Dieser Basistyp sagt Nmap, wie es die Antworten interpretieren soll. Ein SYN-Scan z.B. betrachtet das Fehlen einer Antwort als einen Hinweis auf einen gefilterten Port, während ein FIN-Scan das als einen Hinweis auf einenoffen|gefilterten Port ansieht. Nmap verhält sich genauso wie beim Scan-Basistyp, nur mit dem Unterschied, dass es die von Ihnen angegebenen TCP-Flags benutzt. Ohne Angabe eines Basistyps wird ein SYN-Scan benutzt.

Diese fortgechrittene Scan-Methode ermöglicht einen wirklich blinden TCP-Port-Scan des Ziels, d.h. es werden keine Pakete von Ihrer wahren IP-Adresse an das Ziel gesendet. Stattdessen wird mit einem Angriff auf einem parallelen Kanal eine vorhersagbare Erzeugung von Folgen von IP-Fragmentation-IDs auf dem Zombie-Host ausgebeutet, um an Information über offene Ports auf dem Ziel zu gelangen. IDS-Systeme zeigen als Urheber des Scans den Zombie-Rechner an, den Sie angeben (der aktiv sein und einige bestimmte Bedingungen erfüllen muss). Da dieser faszinierende Scan-Typ zu komplex ist, um ihn in diesem Handbuch vollständig zu beschreiben, habe ich einen Artikel mit vollständigen Details dazu geschrieben und unter https://nmap.org/book/idlescan.html veröffentlicht.

Dieser Scan-Typ ist nicht nur extrem unauffällig (wegen seiner Blindheit), sondern erlaubt auch, IP-basierte Vetrauensbeziehungen zwischen Rechnern festzustellen. Die Portliste zeigt offene Ports aus der Sicht des Zombie-Hosts an. Also können Sie versuchen, ein Ziel mit verschiedenen Zombies zu scannen, von denen Sie denken, dass sie vertrauenswürdig sind (über Router-/Paketfilterregeln).

Wenn Sie einen bestimmten Port auf dem Zombie auf IP-ID-Änderungen testen möchten, können Sie einen Doppelpunkt gefolgt von einer Portnummer an den Zombie-Host hinzufügen. Sonst benutzt Nmap den Port, den es standardmäßig bei TCP-Pings benutzt (80).

Der IP-Protokoll-Scan ermöglicht die Bestimmung der IP-Protokolle (TCP, ICMP, IGMP etc.), die von Zielrechnern unterstützt werden. Rein technisch ist das kein Port-Scan, da er über Nummern von IP-Protokollen statt TCP- oder UDP-Ports vorgeht. Dennoch benutzt er die Option -p für die Auswahl der zu scannenden Protokollnummern, gibt seine Ergebnisse im normalen Port-Tabellenformat aus und benutzt sogar dieselbe grundlegende Scan-Engine wie die echten Port-Scanning-Methoden. Damit ist er einem Port-Scan ähnlich genug, um an dieser Stelle beschrieben zu werden.

Abgesehen davon, dass er schon als solcher nützlich ist, zeigt der Protokoll-Scan die Macht von Open-Source-Software. Auch wenn die grundlegende Idee recht simpel ist, hatte ich nicht daran gedacht, ihn hinzuzufügen, und bekam auch keine Anfragen nach einer solchen Funktionalität. Dann, im Sommer 2000, hatte Gerhard Rieger die Idee, schrieb einen exzellenten Patch als Implementation und sendete ihn an die Mailingliste nmap-hackers. Diesen Patch habe ich in den Nmap-Baum aufgenommen und einen Tag später eine neue Version veröffentlicht. Es gibt nur wenig kommerzielle Software, deren Benutzer so enthusiastisch sind, dass sie eigene Verbesserungen dafür entwerfen und beitragen!

Der Protokoll-Scan funktioniert auf ähnliche Weise wie der UDP-Scan. Statt über das Portnummernfeld eines UDP-Pakets zu iterieren, sendet er IP-Paketheader und iteriert über das acht Bit große IP-Protokollfeld. Die Header sind normalerweise leer, enthalten keine Daten und nicht einmal den richtigen Header für das behauptete Protokoll. Die drei Ausnahmen davon sind TCP, UDP und ICMP. Für diese werden richtige Protokoll-Header verwendet, da manche Systeme sie sonst nicht versenden und weil Nmap bereits über die Funktionen verfügt, um sie zu erzeugen. Statt Nachrichten der Art ICMP Port unreachable sucht der Protokoll-Scan nach ICMP Protocol unreachable. Falls Nmap zu irgendeinem Protokoll eine Antwort vom Zielhost erhält, markiert es das Protokoll als offen. Bei einem ICMP Protocol-unreachable-Fehler (Typ 3, Code 2) wird das Protokoll als geschlossen markiert. Bei anderen ICMP Unreachable-Fehlern (Typ 3, Code 1, 3, 9, 10 oder 13) wird das Protokoll als gefiltert markiert (auch wenn sie gleichzeitig beweisen, dass ICMP offen ist). Falls nach einigen erneuten Übertragungen keine Antwort erhalten wird, wird das Protokoll als offen|gefiltert markiert.

Eine interessante Eigenschaft des FTP-Protokolls (RFC 959) ist dessen Unterstützung sogenannter Proxy-FTP-Verbindungen. Damit kann sich ein Benutzer mit einem FTP-Server verbinden und dann verlangen, dass Dateien an einen Server einer dritten Partei gesendet werden. Solch eine Eigenschaft ist auf vielen Ebenen sturmreif für Missbrauch, weswegen die meisten Server sie nicht mehr unterstützen. Ein solcher Missbrauch, den diese Eigenschaft ermöglicht, ist, den FTP-Server für Port-Scans anderer Hosts zu benutzen. Bitten Sie den FTP-Server einfach, eine Datei nacheinander an alle interessanten Ports eines Zielhosts zu senden. Die Fehlermeldung wird beschreiben, ob der Port offen ist oder nicht. Das ist ein guter Weg, Firewalls zu umgehen, weil FTP-Server von Organisationen oft an Orten platziert sind, von denen aus sie besseren Zugriff auf weitere interne Hosts haben, als es jeder alte Internet-Host hätte. Nmap unterstützt den FTP-Bounce-Scan mit der Option -b. Sie erwartet ein Argument der Form <username>:<password>@<server>:<port>. Dabei ist <Server> der Name oder die IP-Adresse eines anfälligen FTP-Servers. Wie bei einer normalen URL können Sie <username>:<password> auch weglassen, wobei dann eine anonyme Anmeldung erfolgt (username: anonymous password:-wwwuser@). Die Portnummer (samt Doppelpunkt davor) können Sie ebenfalls weglassen, wobei dann auf <server> der Standard-FTP-Port (21) benutzt wird.

Als Nmap 1997 veröffentlicht wurde, war diese Schwachstelle weit verbreitet, wurde seitdem aber größtenteils behoben. Aber da es immer noch anfällige Server gibt, lohnt sich ein Versuch, falls alles andere versagt. Wenn Sie eine Firewall umgehen möchten, scannen Sie das Zielnetzwerk nach einem offenen Port 21 (oder sogar nach beliebigen FTP-Diensten, falls Sie alle Ports mit Versionserkennung scannen können), und probieren Sie dann für jeden einen Bounce-Scan aus. Nmap wird Ihnen sagen, ob der Host angreifbar ist oder nicht. Versuchen Sie lediglich, Ihre Spuren zu verwischen, dann brauchen Sie sich nicht (und tatsächlich sollten Sie das nicht einmal) auf Hosts im Zielnetzwerk zu beschränken. Bevor Sie anfangen, zufällige Internet-Adressen nach anfälligen FTP-Servern zu scannen, bedenken Sie, dass Sysadmins keinen Gefallen daran finden werden, dass Sie ihre Server auf diese Weise missbrauchen.