-sA (TCP-ACK-Scan)
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.
-sW (TCP-Window-Scan)
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.
-sM (TCP-Maimon-Scan)
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.
--scanflags (Benutzerdefinierter TCP-Scan)
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.
-sI <zombie host>[:<probeport>] (Idle-Scan)
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
http://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).
-sO (IP-Protokoll-Scan)
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.
-b <FTP relay host> (FTP-Bounce-Scan)
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.
