Nmap – Portscanner, Hacking-Tool, Alleskönner [Teil II]
Im ersten Teil der Nmap-Serie haben wir mit Hilfe der grundlegenden Portscans schon viele wichtige Informationen über unsere Zielsysteme erhalten. Doch Nmap macht da noch lange nicht Schluss. Eigentlich geht es jetzt erst richtig los. Für einen erfolgreichen Angriff benötigen wir oftmals genauere Informationen: Welches Betriebssystem läuft auf dem Zielsystem, welche Software mit welchem Versionsstand wird auf dem Zielsystem eingesetzt und andere, ähnliche Fragen.
Hierzu können wir die in Nmap direkt eingebauten Mechanismen nutzen oder über die Nmap Scripting Engine (NSE) weitere Funktionalität über externe Skripte einbauen. Im zweiten Teil unsere Artikel-Serie betrachten wir zunächst die fortgeschrittenen Portscans und werden uns dann mit der Analyse der Dienste und des Betriebssystems auf dem Zielhost befassen.
Neben den normalen Portscans, mit denen Nmap offene Ports entdeckt und den gängigen Anwendungen zuordnen kann, bietet das Tool auch Spezial-Portscans an, die in bestimmten Szenarien nützlich sind. Sie kommen z. B. dann zum Einsatz, wenn der direkte Weg des Portscans durch eine Firewall versperrt ist oder wir aus anderen Gründen spezielle Reaktionen provozieren wollen, die Rückschlüsse auf den Port-Status erlauben.
TCP-ACK-Scan
Einen dieser Scan-Typen haben wir bereits früher im Rahmen des Ping-Scans kennengelernt: den TCP-ACK-Scan. Dabei haben wir versucht, über ein TCP-ACK-Paket eine Antwort des Zielhosts zu provozieren, um dessen Status festzustellen. Doch dieser Scan-Typ kann auch für den Port-Scan genutzt werden.
Er wird über –sA aktiviert und setzt für jede Anfrage an einen Port das ACK-Flag. Damit können Sie nicht feststellen, ob ein Port offen ist, da das ACK-Flag regulär nur gesetzt wird, als Antwort im Rahmen eines Verbindungsaufbaus oder bei einer bestehenden Kommunikation. Da das Zielsystem allerdings keine Verbindung mit Ihrem lokalen System über den angesprochenen Port in seiner Sitzungstabelle hat, wird es grundsätzlich mit einem RST-Paket antworten. Dies gilt sowohl für offene als auch geschlossene Ports!
Warum also sollten wir an einem TCP-ACK-Scan interessiert sein? Im Grunde geht es hier darum, einfache Firewall-Systeme auszutricksen und den Status eines Ports zumindest näherungsweise zu bestimmen: Einfache, statuslose Firewalls (z. B. ACLs auf Cisco-Routern oder auch einfache Linux-Firewall-Implementationen mit iptables ohne Stateful-Modul) filtern ggf. von außen eingehende SYN-Pakete, aber oftmals keine ACK-Pakete.
Im Beispiel oben wird ein TCP-SYN-Paket an den Destination-Port 80 des Zielsystems gesendet. Dies wird allerdings verworfen, da die Firewall dieses blockiert. Ein TCP-ACK-Paket kommt jedoch durch und erwirkt eine Rückmeldung des Zielsystems.
Damit wäre ein TCP-SYN-Scan erfolglos – ein TCP-ACK-Scan kann dagegen ein (eigentlich ungültiges) TCP-ACK-Paket an der Firewall vorbei zu einem Port auf dem Zielsystem leiten und erhält vom Zielsystem im besten Fall ein RST-Paket zurück.
Somit kann der Status des Ports von filtered auf unfiltered gesetzt werden. Für Nmap bzw. den Anwender bedeutet dies, dass der Port erreichbar ist, aber nicht bestimmt werden kann, ob er den Status open oder closed hat. Dies ist aber immerhin schon ein Schritt weiter als der Status filtered, bei dem gar nichts klar ist.
TCP-Window-Scan
Sind Sie mit dem Ergebnis eines TCP-ACK-Scans nicht zufrieden, bringt Sie der TCP-Window-Scan unter Umständen weiter. Er verfeinert den Ansatz des ACK-Scans um die Analyse der TCP-Fenstergröße, engl. Window Size genannt. Erinnern wir uns: Der Wert im Feld Window im TCP-Header gibt die Empfangs-Puffergröße des Senders an.
Das Spannende ist, dass einige Betriebssysteme bei einem offenen Port auch für ein TCP-RST-Paket eine positive Window-Größe zurückliefern. In diesem Fall listet Nmap den Port als open auf. Dagegen setzen sie die Window-Größe eines geschlossenen Ports immer auf Null. Dieser wird dementsprechend als closed angezeigt.
Beachten Sie, dass dies lediglich bei einer Minderheit der Systeme in der beschriebenen Form gehandhabt wird – Sie können sich also nicht unbedingt darauf verlassen! Es ist durchaus möglich, dass ein solcher Scan dazu führt, dass sämtliche getesteten Ports als closed angezeigt werden, wenn das Zielsystem die Window-Größe nicht in der oben beschriebenen Art festlegt:
Listing 1: Der Scan eines Home-Office-Routers
root@kali:~# nmap -sW 192.168.8.1 Starting Nmap 7.40 ( nmap.org ) at 2017-05-21 01:08 CEST Nmap scan report for router.movistar (192.168.8.1) Host is up (0.00049s latency). All 1000 scanned ports on router.movistar (192.168.8.1) are closed MAC Address: 00:AB:CD:EF:AF:FE (Gulugulu Technologies) Nmap done: 1 IP address (1 host up) scanned in 14.47 seconds
In diesem Fall ist der TCP-Window-Scan leider nicht von Wert. Es gibt jedoch andere Szenarien, die verschiedene Ergebnisse produzieren, die nicht ganz eindeutig sind.
Hier ist ggf. ein wenig Interpretation notwendig: Falls alle Ports als open angezeigt werden, bis auf 25, 80 und 445, die als closed klassifiziert werden, kann das Ergebnis durchaus genau im Gegenteil interpretiert werden. Schauen Sie also bei diesem Scan-Typ genau hin und machen Sie einen Plausibilitätscheck!
TCP-NULL-, -FIN- und –XMAS-Scan
Aufgrund der Festlegungen im RFC 793 (Transmission Control Protocol) werden bestimmte Flag-Kombinationen für die Provokation einer RST-Reaktion oder deren Ausbleiben genutzt:
- Bei einem NULL-Scan (-sN) werden keine Flags gesetzt.
- Bei einem FIN-Scan (-sF) wird nur das FIN-Flag gesetzt.
- Bei einem XMAS-Scan (-sX) werden die Flags FIN, PSH und URG gesetzt. Sinngemäß wird das Paket wie ein Weihnachtsbaum beleuchtet (engl. Xmas=Weihnachten)
Alle drei Scan-Typen stellen keine regulären Pakete dar und führen zu einem Fehler auf dem Zielsystem. Grundsätzlich haben alle drei exakt dasselbe Verhalten: Wird ein RST-Paket empfangen, so wird der Port als geschlossen (closed) betrachtet. Bleibt die Antwort dagegen aus, wird er als open|filtered klassifiziert. Dahinter steckt, dass nach RFC 793 die oben angegebenen Flag-Kombinationen als unzulässig erkannt und vom empfangenden System verworfen werden sollen. Als filtered wird ein Port hingegen markiert, falls ein ICMP-Typ 3 mit einem der Codes 1, 2, 3, 9, 10 oder 13 empfangen wird.
Natürlich implementieren bei weitem nicht alle Systeme RFC 793 exakt und in der geforderten Form (und das aus gutem Grund!). Das bedeutet, Sie können sich nicht darauf verlassen, dass die Interpretation von Nmap akkurat ist. Eine Reihe von Betriebssystemen – unter anderem diverse Cisco-Geräte und Windows – antwortet generell mit RST-Paketen, unabhängig davon, ob der Port offen ist oder nicht. Bei anderen – dazu zählen diverse Unix-artige Systeme – funktioniert dieser Scan und liefert recht zuverlässige Ergebnisse. Testen Sie es also ggf. selbst aus.
TCP-Maimon-Scan
Obwohl schon sehr alt (von 1996), kann dieser Scan-Typ bei einigen von der Betriebssystemfamilie BSD abgeleiteten Betriebssystemen unter Umständen auch heute noch eine interessante Reaktion provozieren: Es wird ein FIN/ACK-Paket an das Zielsystem geschickt, das, falls die Bedingung erfüllt ist, das Paket schlicht verwirft, wenn der Port offen ist. Ist der Port geschlossen, reagiert das System mit einem TCP-RST-Paket. Der Scan ist nach seinem Erfinder Uriel Maimon benannt und wird mit der Option –sM aktiviert.
Eigene Flags festlegen
Bisher haben wir Nmap die Auswahl der zu setzenden Flags im TCP-Header überlassen. Der nächste Schritt ist, seine eigenen Flags für Ihren TCP-Scan zu definieren. Dazu dient --scanflags <Flags>. Sie können die Flags SYN, ACK, FIN, RST, PSH und URG setzen. Ein möglicher Scan könnte folgendermaßen aussehen:
nmap –sA --scanflags SYNACKPSH 192.168.8.1
Dabei definiert in diesem Fall –sA, wie die Antworten interpretiert werden sollen: Konkret werden alle Ports, auf deren Anfragen mit einem RST-Paket geantwortet wurde, als unfiltered klassifiziert. Die Anfrage-Pakete haben die Flags SYN, ACK und PSH gesetzt (s. Abb. 3).
In welchen Szenarien wird dies sinnvoll? Nun, falls Sie damit rechnen müssen, dass der Hersteller eines im Zielnetzwerk eingesetzten Intrusion Detection Systems (IDS) die Dokumentation von Nmap gelesen und entsprechende Regeln erstellt hat, so können Sie das IDS-Regelwerk austricksen, indem Sie eigene Regeln für den Portscan erstellen. Im Zweifel bringt diese Vorgehensweise neue Erkenntnisse, die Ihnen nützlich sind.
Idle-Scan (IP-ID-Scan)
Zumindest für echte Angreifer ist es von elementarer Bedeutung, unentdeckt zu bleiben. Die bisher vorgestellten Scan-Typen sind ziemlich geradlinig und leicht zurückzuverfolgen. Der Idle-Scan, auch IP-ID-Scan genannt, stellt eine fortgeschrittene Scan-Technik dar, mit der ein System indirekt über einen sogenannten "Zombie-Host" gescannt werden kann. Hier folgen die Details: Beim Idle-Scan senden wir kein einziges Paket zum Zielsystem mit unserer echten IP-Adresse als Absenderadresse. Daher bleiben wir perfekt getarnt. Der Trick ist, dass wir die Fragmentation Identification Number im IP-Header nutzen, die für jedes IP-Paket gesetzt wird. Viele Systeme setzen die ID für jedes nachfolgende IP-Paket schlicht um eins hoch.
Nachfolgend beschreiben wir Ihnen im Detail, wie wir uns das beim Idle Scan zunutze machen können.
Idle-Scan eines offenen Ports
Im ersten Schritt senden wir an das Zombie-System ein TCP-SYN-ACK-Paket, also Nummer zwei im Drei-Wege-Handshake. Das Zombie-System reagiert mit einem TCP-RST-Paket, da es keinen Verbindungsaufbau erwartet. Die Identification Number (ID) im IP-Header wird notiert (s. Abb. 4).
Im zweiten Schritt senden wir an das Zielsystem direkt im Anschluss ein SYN-Paket, fälschen aber die Absenderadresse und tun so, als wären wir das Zombie-System. Dies wird als IP-Spoofing bezeichnet. Das Zielsystem antwortet natürlich direkt dem Zombie. Ist der Port offen, folgt ein SYN-ACK-Paket. Da der Zombie auch vom Zielsystem keinen Verbindungsaufbau erwartet, antwortet er erneut mit einem RST, wobei die IP-ID um eins erhöht wird (s. Abb. 5).
Nun senden wir erneut an den Zombie ein TCP-SYN-ACK-Paket, um ein weiteres RST-Paket zu provozieren. Die IP-ID sollte sich nun wiederum um eins erhöhen (s. Abb. 6).
Jetzt wird verglichen: Ist die IP-ID um zwei gestiegen, handelt es sich um einen offenen Port. Voilà!
Idle-Scan eines geschlossenen oder gefilterten Ports
Die IP-ID ist wieder 17910, wie in Abb. 4 ermittelt. Merken wir uns diese Zahl. Was passiert nun, wenn wir einen geschlossenen Port auf dem Zielsystem ansprechen, nachdem wir die IP-ID vom Zombie in Schritt eins erhalten haben? Das Zielsystem antwortet mit einem RST-Paket an den Zombie, der das Paket gemäß RFC-Standards verwirft (s. Abb. 7).
Wenn wir nun erneut ein TCP-SYN-ACK-Paket an den Zombie senden, wird die IP-ID nur um eins erhöht sein (s. Abb. 8). Im Ergebnis wissen wir, dass zwei Zustände möglich sind:
- Der Port ist geschlossen und der Zombie hat das RST-Paket verworfen.
- Der Port wird gefiltert und es ist keine Antwort erfolgt.
Szenario Nummer zwei stellt sich folgendermaßen dar (s. Abb. 9): Auch in diesem Szenario erhöht sich die IP-ID nur um eins bei der anschließenden Kontaktaufnahme des Angreifers über das TCP-SYN-ACK-Paket und ist somit im Beispiel wieder 17911.
Idle-Scan in der Praxis
Einen Idle-Scan aktivieren Sie mit den folgenden Angaben:
-sI <Zombie-host> [:<Probe-Port>]
Dabei ist die Angabe des Probe-Ports optional, standardmäßig wird Port 80 verwendet. Dies könnte also z. B. folgendermaßen aussehen:
nmap –Pn –sI 192.168.8.101:81 192.168.8.1
Dabei ist der Zombie die 192.168.8.101, welchen wir auf Port 81/tcp ansprechen und 192.168.8.1 das Zielsystem für den Portscan. Außerdem verzichten wir auf einen Ping-Scan mit –Pn (oder –PN), um auch wirklich kein Paket an das Ziel von unserer eigenen, echten Absenderadresse zu schicken.
Allerdings stellen sich einige Hindernisse in den Weg. So könnte sich die Antwort von Nmap folgendermaßen darstellen:
Listing 2: Falsche Zombie-Wahl
root@kali:~# nmap -Pn -sI 192.168.8.101:80 192.168.8.1 Starting Nmap 7.40 ( nmap.org ) at 2017-05-21 23:16 CEST Idle scan zombie 192.168.8.101 (192.168.8.101) port 80 cannot be used because IP ID sequence class is: Randomized. Try another proxy. QUITTING!
In diesem Fall ist die IP-ID-Sequenz zufällig und nicht aufsteigend. Dies erkennt Nmap übrigens durch das Versenden mehrerer TCP-SYN-ACK-Pakete, auf die eine Antwort erwartet wird. Der Vergleich der IP-IDs zeigt, ob die IDs systematisch erhöht werden. Eine weitere Antwort von Nmap, die Sie häufig sehen werden, ist die folgende:
Listing 3: Keine Antwort vom Zombie
Starting Nmap 7.40 ( nmap.org ) at 2017-05-21 23:05 CEST Idle scan zombie 1.2.3.4 (1.2.3.4) port 80 cannot be used because it has not returned any of our probes -- perhaps it is down or firewalled. QUITTING!
Damit fällt auch dieses System heraus, da es keine Antworten auf unsere Pakete sendet. Mitunter ist es gar nicht so leicht, ein passendes System zu finden, das Sie als Zombie nutzen können. Mittlerweile sind die meisten Systeme entsprechend geschützt. Falls Sie dieses Szenario jedoch einmal (erfolgreich) nachstellen wollen, können Sie z. B. einen Windows 7-Host als VM in Ihrer Laborumgebung installieren und als Zombie nutzen.
Portscan-Typen im Überblick
Nachfolgend fassen wir noch einmal die wichtigsten Portscan-Typen und die entsprechenden Optionen zusammen:
Tabelle 1: Wichtige Portscan-Typen und -Optionen
| Option | Bedeutung |
|---|---|
| -sS | TCP-SYN-Scan (Standardscan), auch: Half-Open-Scan, kein kompletter Handshake |
| -sT | TCP-Connect-Scan, kompletter Handshake |
| -sU | UDP-Scan |
|
-p |
Schränkt die zu scannenden Ports ein, TCP-Ports mit T: |
|
--exclude-ports | Schließt explizit die angegebenen Ports aus |
|
--top-ports | Legt die Anzahl der zu scannenden Ports fest, wobei die Ports gemäß nmap-services Ihrer Priorität nach von Nmap ausgewählt werden |
| -sA | TCP-ACK-Scan (ACK-Flag gesetzt) |
| -sW | TCP-Window-Scan (untersucht Window-Feld im TCP-Header) |
| -sN | TCP-NULL-Scan (kein Flag gesetzt) |
| -sF | TCP-FIN-Scan (FIN-Flag gesetzt) |
| -sX | TCP-XMAS-Scan (FIN, PSH und URG gesetzt) |
| -sM | TCP-Maimon-Scan (FIN/ACK gesetzt) |
|
--scanflags | Legt eigene Flags für TCP-Scans fest, möglich sind: SYN, ACK, FIN, RST, PSH, URG |
|
-sI | Idle-Scan (IP-ID-Scan), indirekter Scan mit Zombie-Host |
Dienst- und Versionserkennung
Nmap teilt uns im Rahmen der normalen Portscans in der Regel mit, zu welchem Dienst ein Port gehört, z. B. 25/tcp zu SMTP oder 80/tcp zu HTTP. Allerdings ist das lediglich eine Port-Konvention, die meistens – aber nicht immer – richtig ist. Es ist durchaus möglich, einen Mailserver auch auf Port 80/tcp laufen zu lassen und stattdessen den Webserver auf Port 25/tcp. Hier sollten wir mehr Klarheit bekommen, indem die jeweiligen Ports auch entsprechend getestet werden, um den tatsächlichen Dienst zu ermitteln.
In diesem Zusammenhang ist es auch wichtig, welches Produkt in welcher Version auf dem Zielsystem läuft. Dies ermöglicht es uns, Schwachstellen zu ermitteln, die für bestimmte Versionen von Produkten bekannt sind. Daher schauen wir uns im Folgenden an, wie Nmap uns dabei unterstützen kann, an die Informationen zu gelangen.
Versionserkennung aktivieren
Mit der Versionserkennung (engl. Version Detection) können Sie feststellen, welche konkrete Software mit welchen Features an einem offenen Port gebunden ist.
Mit –sV aktivieren Sie die Versionserkennung. Sie greift auf die Datei /usr/share/nmap/nmap-services-probes zu. Diese Datei enthält für alle bekannten Dienste spezielle Tests, um die jeweilige Version einer Software zu ermitteln. Dies beruht darauf, dass jede Software bestimmte Eigenheiten in der Kommunikation hat, die sie mehr oder weniger eindeutig identifiziert. Das nutzt Nmap aus, um eine entsprechende Reaktion zu provozieren und damit die Version bestimmen zu können.
Tipp:Halten Sie Nmap auf dem aktuellen Versionsstand!
Dateien wie die oben genannte werden häufig angepasst, da neue Versionsstände und andere Informationen hinzugefügt werden müssen. Daher sollten Sie Nmap und andere Tools, wie z. B. Vulnerability-Scanner oder Exploiting-Software, möglichst regelmäßig und in kurzen Abständen aktualisieren.
Kommen wir zurück zur Versionserkennung. Schauen wir uns das einmal in der Praxis anhand eines Beispiels an:
Listing 4: Ein Scan mit Versionserkennung
root@kali:~# nmap -sV scanme.nmap.org Starting Nmap 7.40 ( nmap.org ) at 2017-05-22 21:28 CEST Nmap scan report for scanme.nmap.org (45.33.32.156) Host is up (0.24s latency). Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f Not shown: 996 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.7 ((Ubuntu)) 9929/tcp open nping-echo Nping echo 31337/tcp open tcpwrapped Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 38.41 seconds
Nun wissen wir schon einiges mehr über unser Zielsystem, insbesondere Folgendes:
- Es läuft OpenSSH Version 6.6.1p1 mit der Protokollversion 2.0 auf dem System (auf Port 22/tcp).
- Ein Apache-Webserver in der Version 2.4.7 stellt HTTP-Dienste bereit (auf Port 80/tcp).
- Es wird ein Ubuntu-Linux verwendet.
Gönnen wir uns an dieser Stelle erst nochmal ein paar schwarze Flecken in der Interpretation der obigen Ausgabe. Insbesondere die Zeile Service Info klären wir später noch auf.
Optionen für die Versionserkennung
An dieser Stelle wollen wir noch einmal auf einige Optionen im Rahmen der Versionserkennung eingehen.
Mit --version-intensity <0-9> legen Sie die Intensität des Version-Scans fest. Dabei sind den einzelnen Tests Seltenheitswerte (Rarity) zwischen 1 und 9 zugeordnet. Die Tests mit kleineren Werten sind den häufigeren Diensten zugeordnet und damit bei einer größeren Anzahl von Systemen wirkungsvoll. Dagegen sind Tests mit einem Seltenheitswert von 8 oder 9 nur sehr selten erfolgreich.
Je mehr Tests Sie durchführen lassen, desto länger dauert der Scan. Die obige Option lässt Sie über den Seltenheitswert selbst entscheiden, wie viele der verfügbaren Tests involviert werden sollen. Der Default-Wert liegt bei 7. Mit --version-all lassen Sie alle verfügbaren Tests durchlaufen, dies ist ein Alias für --version-intensity 9.
Möchten Sie genauere Informationen haben, was genau Nmap gerade tut, können Sie dazu die Option –v nutzen. Dies zeigt Ihnen die Scanschritte sehr viel genauer an, als die normale Übersicht. Mit --version-trace erhalten Sie darüber hinaus umfangreiche Debugging-Informationen darüber, was Nmap gerade in Bezug auf die Versionserkennung und andere Prozesse tut. Möchten Sie also hinter die Kulissen schauen, bietet sich diese Option an.
OS-Fingerprinting aktivieren
Im obigen Beispiel haben wir schon einmal grundsätzlich das Betriebssystem Linux identifiziert. Nmap kann allerdings noch deutlich mehr ins Detail gehen und weiterführende Informationen zusammentragen. Dazu wird die Betriebssystemerkennung (engl. OS-Detection oder OS-Fingerprinting) aktivert. Die Option hierzu ist –O. Dies aktiviert das TCP/IP-Stack-Fingerprinting.
Dabei prüft Nmap die Antworten des Zielsystems auf eine Reihe spezieller TCP- und UDP-Pakete sehr detailliert und vergleicht diese mit den Einträgen in seiner Datenbank /usr/share/nmap/nmap-os-db. Diese enthält über 1.000 bekannte Betriebssystem-Fingerprints. Die Einträge enthalten diverse Informationen über das identifizierte Betriebssystem, wie z. B. Klassifikation, Herstellername, Betriebssystem als solches, Version und ggf. den Gerätetyp (z. B. Router oder Spielkonsole, etc.).
Wie prüft Nmap das Betriebssystem? Es gibt eine ganze Reihe von Kriterien, anhand derer das Betriebssystem oder auch bestimmte Dienste geprüft und identifiziert werden können. So verhalten sich Betriebssysteme teilweise sehr unterschiedlich hinsichtlich der TTL-Werte im IP-Header oder der Größe des Empfangspuffers im Window-Feld des TCP-Headers. Diese und andere Kriterien nutzt Nmap, um die jeweilige Software und deren Version zu identifizieren.
Basisscan mit der Option –O
Schauen wir uns das Ergebnis anhand eines Systems im lokalen Netzwerk an, wenn wir die Option –O involvieren:
Listing 5: Die Betriebssystem-Erkennung in Aktion
root@kali:~# nmap -O 192.168.8.112 Starting Nmap 7.40 ( nmap.org ) at 2017-05-22 22:27 CEST Nmap scan report for 192.168.8.112 Host is up (0.0038s latency). Not shown: 999 closed ports PORT STATE SERVICE 62078/tcp open iphone-sync MAC Address: BC:6C:21:00:AF:FE (Apple) OS details: Apple Mac OS X 10.7.0 (Lion) - 10.11 (El Capitan) or iOS 4.1 - 9.3.3 (Darwin 10.0.0 - 15.6.0) Network Distance: 1 hop OS detection performed. Please report any incorrect results at nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 55.95 seconds
Das sind doch mal recht akkurate Angaben. Wir haben hier ein Apple Mac OS X 10.7.0 (Lion) vor uns. Damit könnten wir schon einmal im Detail recherchieren, ob für dieses Betriebssystem die eine oder andere Schwachstelle bekannt ist, die wir uns zunutze machen können. Aber so weit gehen wir an dieser Stelle noch nicht, dieses Thema betrachten wir später.
Spielverderber Firewall – Falls Nmap Ihnen zum Betriebssystem gar keine Informationen liefert, kann es durchaus sein, dass eine Firewall auf dem Zielsystem aktiviert ist, die die passenden Antworten verweigert. Sollten Sie das Problem z. B. mit einem Windows-System in Ihrer Laborumgebung haben, deaktivieren Sie doch testweise einmal die Windows-Firewall, um zumindest ein Ergebnis zu erhalten. In der Praxis ist dieses Problem für den Angreifer nicht so einfach zu lösen, zeigt jedoch auch gleich, wie Sie sich effektiv gegen derartige Scans schützen können.
Während die Analyse im Beispiel oben recht eindeutig ist, kann Nmap in anderen Szenarien unter Umständen nur näherungsweise die Details des Betriebssystems bestimmen. So kann es z. B. passieren, dass ein Linux-System eindeutig identifiziert werden kann, aber unter Umständen nicht genau die Kernel-Version. Details präsentieren wir Ihnen nachfolgend.
Tuning des OS-Fingerprinting
Sie können die Betriebssystemerkennung modifizieren. Möchten Sie sowohl Versionserkennung als auch die Betriebssystemerkennung aktivieren, hilft die weitreichende Option –A weiter, die unter anderem die Optionen –sV und –O beinhaltet. Sie kann natürlich auch mit diversen anderen Optionen, Scan-Typen und Parametern verwendet werden, umfasst aber über die Versions- und Betriebssystemerkennung hinaus auch Script-Scanning (mittels NSE) sowie die Option --traceroute, um den Routing-Pfad nachzuvollziehen.
Die Option --osscan-limit beschränkt die Betriebssystemerkennung auf die vielversprechendsten Ziele. Das Kriterium hierfür ist, dass mindestens ein offener und ein geschlossener Port auf einem System gefunden werden muss – ansonsten wird die OS-Detection ausgelassen. Dies ist insbesondere beim Scannen von vielen Zielen bzw. ganzer Subnetze nützlich.
Die Optionen --osscan-guess und --fuzzy sind äquivalent und dienen dazu, das Betriebssystem aggressiver zu erraten, wenn die Ergebnisse nicht eindeutig sind. Standardmäßig führt Nmap bereits eine Schätzung durch, wenn die Wahrscheinlichkeit sehr hoch ist. Die obenstehenden Optionen lassen Nmap aggressiver schätzen, auch wenn die Wahrscheinlichkeit nicht so hoch liegt. Bei Schätzungen liefert Nmap einen Vertrauensgrad in Prozent, damit der Benutzer das Ergebnis bewerten kann:
Listing 6: Aggressive Schätzung des Betriebssystems
root@kali:~# nmap -O --osscan-guess scanme.nmap.org Starting Nmap 7.40 ( nmap.org ) at 2017-05-23 05:17 CEST Nmap scan report for scanme.nmap.org (45.33.32.156) Host is up (0.22s latency). Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2 f Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 9929/tcp open nping-echo 31337/tcp open Elite Aggressive OS guesses: Linux 3.10 - 4.2 (92%), Linux 3.13 (92%), Linux 3.13 or 4 .2 (92%), Linux 4.4 (92%), Linux 3.16 - 4.6 (91%), Linux 3.16 (90%), Linux 3.2 - 4.6 (90%), Linux 4.2 (90%), Linux 3.12 (89%), Linux 3.18 (89%) No exact OS matches for host (test conditions non-ideal). Network Distance: 23 hops OS detection performed. Please report any incorrect results at nmap.org/ submit/ . Nmap done: 1 IP address (1 host up) scanned in 42.56 seconds
Eine weitere Option ist --max-os-tries <Anzahl>. Normalerweise wiederholt Nmap nicht erfolgreiche Erkennungsversuche erneut nach einem bestimmten Schema. Insgesamt fünf Versuche werden unternommen. Dies kann unter Umständen viel Zeit in Anspruche nehmen. Mit der obigen Option können Sie die Anzahl der Versuche anpassen.
Die folgende Befehlszeile verdeutlicht, wie die Optionen eingesetzt werden können, um einen umfangreichen, aber optimierten Scan durchzuführen:
root@kali:~# nmap -A --osscan-limit --osscan-guess --max-os-tries 2 192.168.8.0/24
Das Ergebnis kann – je nach Anzahl der aktiven Hosts im angegebenen Subnetz – recht umfangreich ausfallen, da die Option –A diverse Scans und Tests enthält. Neben den zahlreichen Angaben zu identifizierten Komponenten auf dem jeweiligen Zielsystem kann es auch vorkommen, dass Nmap keinen Erfolg bei der Identifikation hatte. In diesem Fall wird ein kryptischer Fingerprinting-Block ausgegeben, wie nachfolgend auszugsweise dargestellt:
Listing 7: Fingerprint eines unbekannten Systems oder Services
2 services unrecognized despite returning data. If you know the service/version, please submit the following fingerprints at nmap.org/cgi-bin/submit.cgi : ==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)============== SF-Port80-TCP:V=7.40%I=7%D=5/22%Time=5923569D%P=x86_64-pc-linux-gnu%r(HTTP SF:Options,1C9,"HTTP/1\.1\x20501\x20Not\x20Implemented\r\nServer:\x20webse SF:rver\r\nDate:\x20Thu,\x2001\x20Jan\x201970\x2000:00:00\x20GMT\r\nCache- SF:Control:\x20no-cache,no-store\r\nContent-Type:\x20text/html;\x20charset SF:=iso-8859-1\r\nContent-Length:\x20250\r\nConnection:\x20close\r\n\r\n<H SF:TML>\n\x20<HEAD><TITLE>501\x20Not\x20Implemented</TITLE></HEAD>\n\x20<B SF:ODY\x20BGCOLOR=\"#cc9999\"\x20TEXT=\"#000000\"\x20LINK=\"#2020ff\"\x20V SF:LINK=\"#4040cc\">\n\x20<H4>501\x20Not\x20Implemented</H4><br>\n\x20<HR> […] SF:mented</TITLE></HEAD>\n\x20<BODY\x20BGCOLOR=\"#cc9999\"\x20TEXT=\"#0000 SF:00\"\x20LINK=\"#2020ff\"\x20VLINK=\"#4040cc\">\n\x20<H4>501\x20Not\x20I SF:mplemented</H4><br>\n\x20<HR>That\x20method\x20is\x20not\x20implemented SF:\.</HR>\n\x20<ADDRESS>webserver</ADDRESS>\n\x20</BODY></HTML>\n");
Falls Sie das System bzw. den Dienst eindeutig identifizieren können, sind die Nmap-Entwickler Ihnen dankbar, wenn Sie diesen Fingerprint auf die angegebene Seite hochladen und entsprechende Angaben machen. Ansonsten bleibt Ihnen zunächst nichts anderes übrig, als diesen Block in der Ausgabe so hinzunehmen und zu ignorieren.
Common Platform Enumeration
Kommen wir noch einmal auf die Zeile zu sprechen, die wir vorhin so geflissentlich ignoriert haben:
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Diese Zeile zeigt zunächst das gefundene Betriebssystem (OS). Hier handelt es sich um ein Linux-System. Danach folgt eine CPE-Angabe. CPE steht für Common Platform Enumeration und ist ein Standard zur Angabe von Software-Anwendungen, Betriebssystemen und Hardware. Die grundsätzliche Syntax stellt sich folgendermaßen dar:
cpe:/<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>
Dabei nimmt <part> einen der folgenden Werte an:
- a für Anwendungen (Applications),
- h für Hardware-Plattformen und
- o für Betriebssysteme (Operating Systems).
Wie im Beispiel oben zu sehen, werden nicht immer alle Informationen angegeben, sondern nur die, die ermittelt werden konnten. Um die CPE brauchen Sie sich normalerweise keine Gedanken zu machen. Diese Standardisierung dient hauptsächlich für die maschinelle Weiterverarbeitung der bereitgestellten Informationen.
Zusammenfassung und Ausblick
In diesem zweiten Teil unsere Nmap-Artikel-Serie haben wir uns mit einigen erweiterten Funktionen von Nmap auseinandergesetzt. Mit diesem Rüstzeug ist Nmap bereits ein sehr leistungsfähiger Scanner und liefert viele wertvolle Informationen für die Netzwerk- und Sicherheitsanalyse.
Doch auch damit ist noch lange nicht das Ende der Fahnenstange erreicht: im nächsten Teil der Serie werden wir uns anschauen, wie wir die fortgeschrittenen Funktionen von Nmap nutzen können. Hierzu gehören das Tuning, die Umgehung von Firewalls und IDS/IPS sowie die Nmap Scripting Engine (NSE), die aus Nmap eine Eierlegende Wollmilchsau macht.
