33.3 Nmap: Der wichtigste Portscanner

Nachdem wir mit Nagios eine Möglichkeit, die Netzwerksicherheit passiv zu überwachen, vorgestellt haben, wollen wir uns mit entsprechenden aktiven Methoden beschäftigen.

Vorgehen eines Hackers

Dabei geht man oft so ähnlich vor, wie ein Hacker es in einem ihm unbekannten Netzwerk tun würde. Schließlich kann auch der beste Administrator nicht immer an alles denken, und eine solche Verifikation der Sicherheit entspricht auch unserem Prinzip von IT-Security.

33.3.1 Prinzip eines Portscanners

Der erste Schritt beim Hacken ist natürlich immer das Sammeln von Informationen. Auch wir wollen sehen, was unsere Server über sich verraten werden und welche Dienste noch laufen, die wir vielleicht nicht benötigen und die damit ein Sicherheitsrisiko darstellen.

Dazu schreiben viele Hacker Programme, die sich mit allen oder einigen ausgewählten Ports des Zielsystems zu verbinden versuchen. Aus der Kenntnis der offenen Ports sowie der dazugehörigen Dienste [Fn. Es gibt die sogenannten well known ports, die laut Standarddefinition eigentlich für gewisse Dienste reserviert bleiben sollten. So laufen Webserver meistens auf Port 80 oder FTP-Server auf Port 21. Findet man nun einen offenen Port 21 auf einem System, so ist es sehr wahrscheinlich, dass dieser zu einem FTP-Server gehört.] können die Hacker sich ein recht gutes Bild des Zielrechners – oder auch eines ganzen Netzwerks – machen.

Ein Portscanner untersucht, welche Ports auf einem entfernten System geöffnet sind. Aus diesen Informationen kann gefolgert werden, welche Dienste auf dem Rechner laufen.

Mehr als Scannen

Der populärste Portscanner schlechthin ist Nmap. Mit der auf insecure.org beheimateten Software kann man nicht nur scannen, sondern auch viele andere interessante Features nutzen:

• Remote OS Detection via TCP/IP Fingerprinting
• Stealth Scanning
• dynamische Delay- und Retransmissionsberechnungen
• paralleles Scanning
• Decoy Scanning
• Erkennung gefilterter Ports
• direktes RPC-Scanning
• Fragmentierungsscanning

Auch für Windows

Dies alles macht Nmap, der dazu auch noch sehr schnell ist, zu dem meistgenutzten Portscanner überhaupt. Die Software kommt ursprünglich, wie so oft bei guten sicherheitsrelevanten Lösungen, aus dem Linux/Unix-Umfeld. Mittlerweile existieren auch Portierungen für so ziemlich jedes Betriebssystem einschließlich Windows, aber in diesem Buch wollen wir in den Beispielen die Unix-Variante nutzen.

Aber bevor wir den Nutzen der Software näher erläutern, wollen wir die Prinzipien und Techniken des Portscannens erklären.

33.3.2 Techniken des Scannens

Natürlich gibt es viele verschiedene Scanmethoden, die alle mehr oder weniger »unsichtbar«, schnell oder effektiv sind. Auch wenn für die Überprüfung des eigenen lokalen Netzwerks die einfachste Art ausreicht, so kann entsprechendes Hintergrundwissen nie schaden.

Exkurs zu TCP: TCP ist ein sogenanntes verbindungsorientiertes Netzwerk-Protokoll und versucht, Daten zuverlässig von A nach B zu transportieren. Gehen Netzwerkdaten unterwegs verloren, versucht TCP diese erneut zu senden. TCP baut Verbindungen über einen Handshake auf, bei dem Netzwerkpakete, die vom Empfänger empfangen wurden, bestätigt werden. Dadurch weiß auch der Sender, dass seine Daten beim Empfänger angekommen sind. Dabei werden verschiedene Bits (Flags) im TCP-Header gesetzt. Für dieses Kapitel ist es wichtig, zu wissen, dass es ein SYN-Flag und ein ACK-Flag gibt. Außerdem ist es nützlich, das FIN- und das RST-Flag zu kennen.

Das SYN-Flag wird gesetzt, um dem Empfänger zu sagen, dass eine neue Verbindung aufgebaut werden soll. Ein Paket mit gesetztem ACK-Flag bestätigt hingegen empfangene Pakete. Des weiteren gibt es noch das FIN-Flag, das das Ende einer Verbindung bestimmt (auch ein Paket zum Beenden einer Verbindung wird wieder mit einem zusätzlich gesetzten ACK-Flag bestätigt). Ein RST-Flag (Reset-Flag) unterbricht eine Verbindung ohne eine ordentliche Beendigungs-Sequenz.

TCP-Connect-Scan

Einfache Verbindung

Die einfachste Möglichkeit zu scannen bietet der connect()-Systemcall. Mit ihm versucht man sich einfach über den bekannten TCP/IP-3-Wege-Handshake mit einem Port zu verbinden. Klar ist, dass dies gelingt, wenn der Port offen ist, und fehlschlägt, wenn der Port geschlossen ist.

Der Vorteil dieser Scanmethode gegenüber vielen anderen ist, dass auch nicht privilegierte Benutzer diesen Scan ausführen können. Bei anderen Methoden benötigt man zum Beispiel unter Linux root-Rechte, da dafür auf die Raw-Socket-API zugegriffen werden muss.

Nachteilig wirkt sich dagegen oft die fehlende Geschwindigkeit bei einer langsamen Verbindung und vor allem die Auffälligkeit des Scans aus. So taucht man meist mit seiner IP-Adresse in den Logfiles entsprechender Server auf, oder entsprechende Intrusion-Detection-Systeme können einen sehr einfach aufspüren.

TCP-Syn/Half-Open-Scan

Der SYN- oder Half-Open-Scan ist gegenüber dem Connect Scan schon komplizierter. Man öffnet nämlich die Verbindung zum Port nicht ganz, sondern schickt nur das erste SYN-Paket des Handshakes. Erhält man eine Antwort, in der das SYN- und das ACK-Flag gesetzt sind, so ist der Port offen (siehe TCP-3-Wege-Handshake), erhält man dagegen eine Antwort mit gesetztem RST-Flag, ist der Port geschlossen.

Weniger Logging

Der Vorteil dieses Scans ist die geringere Wahrscheinlichkeit eines Loggings, auch wenn natürlich mittlerweile jedes gute IDS diesen Scantyp erkennt.

Allerdings benötigt man für diesen Scan bereits administrative Rechte. Wenn man jedoch als Administrator für ein Netzwerk verantwortlich ist, sollte das kein Problem sein. Und Hacker haben sowieso ihre eigenen Systeme.

TCP-Fin-Scan

Manchmal ist es auch ganz sinnvoll, Pakete nur mit einem gesetzten FIN-Flag zum Scannen zu nutzen. Zum Beispiel dann, wenn eine Firewall nur SYN-Pakete auf entsprechende Ports blockt oder man genau weiß, dass ein spezieller Logger für SYN-Pakete zum Einsatz kommt.

Der TCP/IP-Standard schreibt nun vor, dass geschlossene Ports auf ein FIN mit einem Paket mit gesetztem RST-Flag antworten müssen, wohingegen offene Ports ein FIN zu ignorieren haben. Allerdings ist die TCP/IP-Implementierung von Windows so mangelhaft, dass Windows unabhängig vom Portstatus immer ein RST sendet. Auch blocken richtig konfigurierte Firewalls »heimatlose«, also zu keiner Verbindung gehörende Pakete einfach ab.

Aus diesem Grund kann ein FIN-Scan nicht immer eingesetzt werden, aber trotzdem helfen, die Funktionsweise einer Firewall zu erkennen, oder auch beim Erraten des Betriebssystems helfen.

TCP-Null- und XMAS-Scan

Ähnlich wie beim FIN-Scan soll auch beim XMAS- und Null-Scan entsprechend ein geschlossener Port mit einem RST antworten, wohingegen ein offener Port das Paket ignorieren soll.

Ein Paket beim XMAS-Scan hat dazu die FIN-, URG- und PUSH-Flags gesetzt, [Fn. Der Scan heißt auch deswegen XMAS-Scan, weil die Pakete »wie ein Weihnachtsbaum behängt« sind.] während beim Null-Scan keine Flags gesetzt sind.

[»]Noch ein paar Worte zu verletzten Standards: Sie sind definitiv kein Sicherheitsmerkmal, sondern vielmehr oft der Grund, wieso eigentlich kompatible Geräte unterschiedlicher Hersteller nicht zusammen funktionieren und die Benutzer in den Wahnsinn treiben. Wenn man sich vor Portscans »schützen« will – falls es da überhaupt etwas zu schützen gibt, schließlich handelt es sich nicht um einen Angriff --, kann man immer noch eine Firewall entsprechend konfigurieren. Aber offene Ports werden immer offene Ports bleiben, und wenn ein System ordentlich konfiguriert ist, wird man selbst mit dem besten Portscanner der Welt keine »vergessenen« Dienste finden – weil sie nicht installiert sind.

Fragmentierungsscan

Diese Scanmethode kann in Kombination mit anderen Scantechniken genutzt werden. Beim Fragmentierungsscan wird nämlich das TCP-Paket, das einen Port überprüfen soll, in mehrere kleine IP-Fragmente unterteilt. Das soll es eventuellen Firewalls erschweren, diese Pakete als Portscanversuch zu identifizieren und zu blocken.

Allerdings gibt es in Bezug auf Fragmente einige Nachteile, und so ist diese Scanmethode nicht immer wirksam. So manche Software – wie zum Beispiel diverse einfache Sniffer – stürzt nämlich ab, wenn sie Fragmente erhält.

Immer defragmentieren

Eine Firewall kann so ein Problem dagegen recht einfach umgehen: Unter Linux zum Beispiel kann man über die CONFIG_IP_ALWAYS_DEFRAG- Option vor der Kernelübersetzung einstellen, dass alle Pakete immer defragmentiert werden sollen, bevor sie weitergeleitet werden. Oder man blockt Fragmente einfach komplett durch die Firewall.

TCP-Reverse-Ident-Scanning

Das ident-Protokoll (RFC 1314) erlaubt es herauszufinden, unter welchen Rechten ein bestimmter Prozess läuft, sofern man mit ihm über TCP verbunden ist. Dazu benötigt man einen entsprechenden Ident-Server auf dem zu scannenden System, der einem dann eventuell eine entsprechende Auskunft geben kann.

Ist auf einem entfernten Rechner also der ident-Port 113 offen, so kann man, wenn man gleichzeitig auf Port 80 verbunden ist, herausfinden, unter welchen Rechten der Webserver läuft.

Für diesen Scan benötigt man natürlich eine vollständig aufgebaute Verbindung, daher ist er eigentlich nur in Verbindung mit einem TCP-Connect-Scan möglich und sinnvoll.

TCP-Idle-(IPID-)Scan

Unsichtbares Scannen

Eine recht neue und vielversprechende Methode des Portscannings ist der Idle-Scan. Mit dieser Methode kann man einen Rechner »unsichtbar«, also ohne dass dieser die eigene IP-Adresse zu Gesicht bekommt, scannen. Außerdem kann man eventuell Ports aufspüren, die für den eigenen Rechner eigentlich geblockt sein sollten.

Bevor wir auf diesen Fakt näher eingehen, wollen wir kurz ein Wort zum Verstecken von IP-Adressen verlieren. über dieses Thema ranken sich im Netz viele Legenden, und die eine oder andere Software verspricht sogar das Blaue vom Himmel, indem sie vorgibt, dieses Feature zu implementieren.

Meist fängt man sich bei einer solchen Installation nur Viren oder auch Spyware ein, ohne auch nur irgendein nützliches Feature zu bekommen. Und jeder, der TCP/IP auch nur ansatzweise verstanden hat, weiß auch, warum: Wenn man die Absenderadresse eines IP-Pakets fälscht, bekommt ein anderer Rechner die Antwort.

Handshake

Mit anderen Worten: Man kann nicht einmal einen 3-Wege-Handshake ordentlich aufbauen, da man das SYN-ACK-Paket nicht erhält. Früher [Fn. Die Betonung liegt wirklich auf: früher!] war es möglich, die Sequenznummer beziehungsweise die Acknowledgementnummer zu erraten, da diese Nummern einfach hochgezählt wurden. Heute werden diese bei jeder aktuellen TCP/IP-Implementierung beim Verbindungsaufbau zufällig gesetzt, so dass man keine Chance hat, »blind« eine Verbindung aufzubauen.

Aus diesem Grund wird bei jeder vom eigenen Rechner ausgehenden Verbindung auch die eigene IP-Adresse benutzt. Ansonsten könnte das Internet auch nicht funktionieren. Eine Ausnahme bilden natürlich Proxyserver und verwandte Methoden. Aber diese Art, im Netz unterwegs zu sein, ist meist langsam und vom Administrator des Proxys aus gutem Grund oft auf Port 80 als Ziel beschränkt. Außerdem wird er jeden Verbindungsaufbau mitloggen, und so ist jeder Angreifer, der den Proxy für illegale Aktivitäten missbraucht, eindeutig identifizierbar.

Daher kocht auch der Idlescan – trotz der tollen Features – nur mit Wasser. Eine genaue Beschreibung samt einiger weiterer interessanter Techniken finden Sie übrigens auf http://www.insecure.org/nmap/idlescan.html. Auch wenn die Funktionsweise vielleicht kompliziert wirken wird, im Prinzip brauchen wir nur folgende Theorie:

• Handshake
  Ein offener Port sendet auf eine SYN-Verbindungsanfrage ein SYN-ACK zurück, während ein geschlossener Port ein RST schickt.
• Verlorene Pakete
  Bekommt ein System ein SYN-ACK-Paket, obwohl keine SYN-Anfrage geschickt wurde, antwortet es mit einem RST-Paket. Ein RST ohne Bezug wird schlicht ignoriert.
• IPID-Feld
  Im IP-Header ist für jedes Paket ein Feld zur »Fragmentation Identification« vorgesehen, um eventuell fragmentierte Pakete zuordnen zu können. Dieses Feld wird von vielen Betriebssystemen einfach für jedes gesendete Paket inkrementiert.

Mit dieser Methode kann man also über Probing herausfinden, wie viele Pakete seit der letzten Probe von dem überprüften Host versendet wurden.

Mit etwas Fantasie kann man aus diesen Fakten folgenden Scan konstruieren:

Zombies

• Finden eines geeigneten Zombie-Hosts
  Zuerst benötigt man einen geeigneten Zombie-Host, der später den Scan ausführen soll. Die komische Bezeichnung rührt von der Eigenschaft her, dass der Rechner möglichst keinen Traffic haben sollte.
• Probing des Zombies
  Dazu schicken wir dem Zombie ein Paket mit gesetztem SYN- und dem ACK-Flag und erhalten, wie in der Ausführung oben ersichtlich ist, ein RST-Paket als Antwort. Aus diesem Paket merken wir uns die IPID-(Fragmentation ID-)Nummer.
• Sessionrequest des Zombies
  Als Nächstes fälschen wir einen Sessionrequest des Zombies, indem wir ein TCP-Paket mit dem SYN-Flag und der Absenderadresse des Zombies auf den zu überprüfenden Port schicken.
• Reaktion des Zielrechners
  Die Reaktion des Zielrechners ist nun abhängig vom Status des Ports: Ist dieser offen, so antwortet der Zielrechner dem Zombie mit einem SYN+ACK-Paket, ansonsten mit einem RST.

Der Zombie wiederum wird ein eventuelles SYN+ACK vom Zielrechner mit einem RST quittieren, ein RST jedoch ignorieren. Mit anderen Worten: Er wird ein Paket schicken, falls der Port auf dem Zielrechner offen ist, und keines schicken, falls dieser geschlossen ist.

• Erneutes Probing
  Wenn wir nun den Zombie wieder mit einem SYN+ACK-Paket auffordern, uns ein RST zu schicken, sehen wir die Änderung des IPID-Wertes.

Wenn sich der Wert nur um eins gegenüber dem alten Probing erhöht hat, so hat der Zombierechner offensichtlich zwischendurch kein Paket versendet, da er wohl vom Zielrechner nur ein RST bekommen hat – und der betreffende Port geschlossen ist.

Ist der Wert dagegen um zwei erhöht, so hat der Zombierechner zwischen den Probes ein Paket versendet, das sehr gut das RST auf eine SYN+ACK-Antwort vom Zielrechner sein könnte, die auf einen offenen Port hindeuten würde.

Dieser Scan hat, wie bereits angedeutet, sehr viele Vorteile, die allerdings in einem Satz zusammengefasst werden können: Der Zombie scannt den Zielrechner – und nicht wir.

Restriktionen umgehen

Das bedeutet, dass wir die offenen Ports aus der Sicht des Zombies sehen und damit eventuell firewall-bedingte Restriktionen umgehen können. Außerdem wird ein IDS auf dem Zielrechner einen Portscan des Zombies melden, da der eigentliche Angreifer nicht direkt in Kontakt mit ihm tritt.

Natürlich gibt es auch einige Probleme, zum Beispiel wenn der Zombierechner zwischendurch doch Traffic hat oder man das Scannen beschleunigen will. Allerdings sind dies Implementierungsdetails, die hier nicht weiter interessieren sollen.

[»]Als Fazit sollte bleiben, dass nicht immer der Rechner, der in den Logs des IDS als Verursacher eines Portscans auftaucht, auch wirklich der Schuldige ist.

UDP-Scan

Natürlich kann man nicht nur mit dem TCP-, sondern auch mit dem UDP-Protokoll scannen. Die Schwierigkeit bei diesem Scan besteht allerdings in der Verbindungslosigkeit des Protokolls.

Nutzen von ICMP

Wenn man nämlich ein Paket auf einen Port sendet, dann muss es keine Antwort geben. Allerdings senden die meisten Systeme ein »ICMP Port Unreachable« zurück, falls der Port geschlossen ist. Aber natürlich muss man immer damit rechnen, dass ein Paket während der Übertragung verloren geht.

Außerdem beschränken viele Betriebssysteme die ICMP-Fehlermeldungen nach einem Vorschlag in RFC 1812, Abschnitt 4.3.2.8. Dadurch wird das Scannen natürlich extrem langsam ... aber es gibt ja auch Systeme, die sich bekanntermaßen recht selten an Standards halten.

33.3.3 Weiterer Informationsgewinn

Wenn Hacker ein System angreifen wollen, dann reicht eine Liste der offenen Ports bei Weitem noch nicht aus. Man braucht eigentlich detaillierte Informationen über das anvisierte Ziel.

Zu diesen Informationen gehört auf jeden Fall:

• das Betriebssystem samt Version sowie die Architektur (beispielsweise »Linux 2.6.36, i386«)
• Serversoftware samt Versionen (beispielsweise »OpenSSH 3.4p1«)
• eventuell angewendete Patches (beispielsweise »Windows XP SP2«)
• Firewall-Einsatz: das Ruleset und die Features der Firewall (beispielsweise stateful Firewall – blockt alle SYNs aus dem Internet)
• IDS-Einsatz: Software und Regelwerk (beispielsweise Snort mit Standardregeln)
• Logging: Was wird geloggt und wann?

Die Liste könnte man beliebig fortsetzen, aber im Folgenden wollen wir auf die Punkte eingehen, die auch ein Scanner realisieren kann.

Bannerscanning

Software herausfinden

Um herauszufinden, welche Serversoftware auf einem bestimmten Port läuft, genügt oft schon ein einfaches connect() – und die Software stellt sich vor.

Listing 33.36 Bannerscanning bei Mailservern

ploetner:\~{}# telnet xxx.xxx.xxx.xxx 25
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
220 xxx.xxx.xxx.xxx ESMTP Server (Microsoft Exchange \
  Internet Mail Service 5.5.2650.21) ready
QUIT
221 closing connection

Bei anderen Diensten muss man erst einen speziellen Request senden, um an die gewünschten Informationen zu gelangen:

Listing 33.37 Bannerscanning bei Webservern mit dem HEAD-Befehl

# echo 'HEAD / HTTP/1.0\r\n\r\n' | nc www.debian.org \
  80 | egrep '^Server:'
Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1

Meistens verraten die Dienste schon sehr viel über das eingesetzte Betriebssystem. Manchmal braucht man jedoch etwas Glück, um so die genaue Version zu erfahren:

Listing 33.38 Klassisches OS-Fingerprinting

playground\~{}> telnet hpux.u-aizu.ac.jp
Trying 163.143.103.12 ...
Connected to hpux.u-aizu.ac.jp.
Escape character is '^]'.

HP-UX hpux B.10.01 A 9000/715 (ttyp2)

login:

Bei anderen Systemen wie dem folgenden FTP-Server wiederum kann man sogar genauer nachfragen:

Listing 33.39 Bannerscanning mit OS-Erkennung

payfonez> telnet ftp.netscape.com 21
Trying 207.200.74.26 ...
Connected to ftp.netscape.com.
Escape character is '^]'.
220 ftp29 FTP server (UNIX(r) System V Release 4.0)  \
  ready.
SYST
215 UNIX Type: L8 Version: SUNOS

Eine Alternative bei klassischen FTP-Servern war auch oft der Download von intern benötigten Dateien wie /bin/ls und die lokale Untersuchung des Dateiaufbaus.

OS-Fingerprinting

Alternativ beziehungsweise ergänzend dazu steht das sogenannte OS-Fingerprinting, dessen einzig brauchbare Implementierung derzeit nmap bietet.

Unterschiede bei der Implementierung

Bei diesem Fingerprinting werden die bereits erwähnten Besonderheiten der TCP/IP-Implementierung verschiedener Betriebssysteme herangezogen. Dank sehr feinen Unterscheidungsmerkmalen lässt sich nicht nur das Betriebssystem angeben, oft lassen sich auch recht präzise Angaben zur Version und zu eventuellen Patchleveln machen.

33.3.4 Nmap in der Praxis

Nachdem wir recht viel Theorie erklärt und damit die Basis des Themas gelegt haben, wollen wir nun den – in unseren Augen – richtigen Umgang mit nmap erläutern.

Den Quellcode zu Nmap finden Sie auf insecure.org und – sofern Sie Unix beziehungsweise Linux einsetzen – mit ziemlicher Sicherheit im Umfang Ihres Derivats beziehungsweise Ihrer Distribution. Unter Debian-GNU-Linux reicht zum Beispiel ein einfaches

Listing 33.40 Nmap unter Debian installieren

# apt-get install nmap

aus, um die Software komplett lauffähig zu installieren. Zum Starten ruft man dann nmap von der Kommandozeile mit dem zu scannenden Rechner oder Netz auf.

Es gibt zwar auch eine Nmap-Version für Windows, aber da die Software ursprünglich von Linux kommt und die wichtigen Innovationen auch in diesem Bereich gemacht werden, wollen wir uns auf diese Version konzentrieren.

Adminrechte nötig

Prinzipiell sollte man Nmap immer als root-User benutzen, da nur hier die interessanten Features zur Verfügung stehen, auch wenn man als normaler User immer noch den connect()-Scan nutzen kann:

Listing 33.41 Nmap unter einem normalen Benutzeraccount

$ nmap 192.168.1.1

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) \
  at 2004-09-16 11:44 CEST
Interesting ports on cyrus (192.168.1.1):
(The 1647 ports scanned but not shown below are in   \
  state: closed)
PORT      STATE SERVICE
9/tcp     open  discard
13/tcp    open  daytime
22/tcp    open  ssh
25/tcp    open  smtp
37/tcp    open  time
80/tcp    open  http
111/tcp   open  rpcbind
113/tcp   open  auth
139/tcp   open  netbios-ssn
389/tcp   open  ldap
443/tcp   open  https
617/tcp   open  sco-dtmgr
10000/tcp open  snet-sensor-mgmt

Nmap run completed – 1 IP address (1 host up) scanned \
  in 1.215 seconds

33.3.5 Angabe der Scanziele

Netze angeben

Außer mit einer »puren« IP-Adresse kann man die Ziele auch noch anders spezifizieren, zum Beispiel durch die bekannte Angabe von ganzen Netzwerken über die Subnetzmaske oder die Wildcard »*«:

• 192.168.1.0/24
  Diese Angabe bezeichnet alle Rechner im Netzwerk 192.168.1.x.
• 192.168.*.1
  Mit diesem Ausdruck spricht man alle Rechner im IP-Bereich 192.168 an, deren letztes Byte gleich 1 ist. Es würden also nur die Rechner 192.168.1.1, 192.168.2.1, ... gescannt.
• 192.168.1.1-10
  Man kann auch wie in diesem Fall Bereiche angeben, so dass in diesem Beispiel die ersten 10 Rechner im 192.168.1.0/24-er Netz gescannt würden.

Zur Angabe der Scanziele gehört natürlich auch die Angabe der zu scannenden Ports. [Fn. Außer dem zu scannenden Ziel sind natürlich alle weiteren Parameter optional, wie man auch im Beispiel sehen konnte.] Normalerweise werden alle Ports zwischen 1 und 1024 sowie die Ports in der nmap-services-Datei gescannt. Allerdings kann man unter anderem durch folgende Optionen genauer spezifizieren, welche Ports zu scannen sind:

Die wichtigsten Scantypen

Die wichtigsten Scantypen wählt man nun wie folgt:

Daneben gibt es noch eine Reihe wichtiger Optionen, die zusätzlich zu den normalen Scantypen, sozusagen als Ergänzung, aktiviert werden können:

Eine für alle

Eine nette Option ist übrigens -A, die alle üblichen und wichtigen Optionen zusammenfasst: zurzeit nämlich die Versions- sowie die OS-Erkennung. Der Autor von Nmap, der bekannte Hacker fyodor, behält sich aber vor, diese Option später noch um andere Flags zu erweitern.

Ein abschließendes Beispiel

Zum Schluss dieses Abschnitts soll mit einem Beispiel noch einmal der Funktionsumfang sowie die »Macht« von Nmap verdeutlicht werden. Nicht umsonst handelt es sich um den Portscanner, der mittlerweile sogar als Referenz dient.

In diesem Beispiel soll ein einfacher Linux-Fileserver darauf überprüft werden, ob er nicht gewisse Sicherheitslücken enthält:

Listing 33.42 Verifikation der Serverfunktion

# nmap -A fileserver

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) \
  at 2004-09-17 13:53 CEST
Interesting ports on fileserver (xxx.xxx.xxx.xxx):
(The 1649 ports scanned but not shown below are in   \
  state: closed)
PORT      STATE SERVICE     VERSION
9/tcp     open  discard?
13/tcp    open  daytime
22/tcp    open  ssh         OpenSSH 3.8.1p1          \
  (protocol 2.0)
25/tcp    open  smtp        Exim smtpd 3.36
37/tcp    open  time
111/tcp   open  rpcbind     2 (rpc #100000)
113/tcp   open  ident       OpenBSD identd
139/tcp   open  netbios-ssn Samba smbd 3.X           \
  (workgroup: TEST)
445/tcp   open  netbios-ssn Samba smbd 3.X           \
  (workgroup: TEST)
699/tcp   open  status      1 (rpc #100024)
10000/tcp open  http        Webmin httpd
MAC Address: 00:60:97:8F:79:8C (3com)
Device type: general purpose
Running: Linux 2.4.X|2.5.X|2.6.X
OS details: Linux 2.4.18 – 2.6.4 (x86)
Uptime 1.979 days (since Wed Sep 15 14:25:00 2004)

Nmap run completed – 1 IP address (1 host up)       \
  scanned in 108.304 seconds

Zu viele unnötige Dienste

An diesem Beispiel kann man sehr deutlich sehen, dass mehr Ports offen sind, als für die Funktion als Fileserver nötig ist. Aus diesem Grund sollte man dringend die nicht benötigten Dienste – wie den Mailserver (Exim), das Remote-Administrationstool (Webmin) oder den Ident-Server – deinstallieren beziehungsweise die Ports durch eine auf dem System zu installierende Firewall blocken, falls man die Dienste lokal brauchen sollte.

Und so kann man sehen, wozu einem ein vermeintliches »Hackertool« wie Nmap nutzen kann. Schließlich werden so gut wie alle Systeme mit einer gewissen Vorkonfiguration installiert, die oft mehr Zugriff bietet, als nötig ist.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.