2.7 Nmap im autorisierten Netz – Hosts, Ports und Dienste untersuchen

Geeignete administrative Aufgaben

Nmap ist nicht geeignet für

• Scans fremder öffentlicher Systeme ohne Erlaubnis;
• unkontrollierte Scans kompletter Unternehmensnetze;
• das Umgehen von Firewalls oder Überwachungssystemen;
• Verschleierungs-, Spoofing- oder Tarntechniken im normalen Administrationsbetrieb;
• Brute-Force-, Exploit- oder Denial-of-Service-Tests;
• den Nachweis, dass ein Dienst fachlich korrekt funktioniert;
• die alleinige Entscheidung, ob ein System sicher ist.

Ein offener Port beweist nur, dass aus Sicht des Scanstandorts eine entsprechende Antwort empfangen wurde. Er beweist nicht, dass:

• die Anwendung vollständig funktioniert;
• die Anwendung korrekt konfiguriert ist;
• eine Benutzeranmeldung möglich ist;
• der Dienst keine Sicherheitslücken besitzt;
• alle Clients denselben Netzwerkpfad verwenden.

Windows

Die offizielle Windows-Installation von Nmap verwendet normalerweise Npcap für Raw-Packet-Funktionen. Für bestimmte Scanarten sollte PowerShell oder die Eingabeaufforderung als Administrator gestartet werden.

Linux und macOS

Scanarten, die Raw-IP-Pakete verwenden, benötigen normalerweise erhöhte Rechte:

[TEST][PRIV][SENS] sudo nmap -sS -p 443 192.0.2.10

Ein TCP-Connect-Scan kann gewöhnlich ohne erhöhte Rechte ausgeführt werden:

[TEST][SENS] nmap -sT -p 443 192.0.2.10

Die tatsächlich verfügbaren Funktionen hängen von Betriebssystem, Nmap-Version, Rechten und Paket-Capture-Treiber ab.

Vor einem Scan sollten mindestens folgende Punkte dokumentiert sein:

Vor dem Start klären

• Befinden sich empfindliche Altgeräte im Zielbereich?
• Sind Drucker, Telefonanlagen, Kameras, Steuerungen oder medizinische Geräte betroffen?
• Gibt es Intrusion-Detection- oder Intrusion-Prevention-Systeme?
• Muss das Security Operations Center informiert werden?
• Gibt es eine maximale Scanrate?
• Darf eine Dienst- oder Betriebssystemerkennung durchgeführt werden?
• Dürfen NSE-Skripte verwendet werden?
• Wie lange dürfen Ergebnisse gespeichert werden?

Die Erlaubnis, einen einzelnen Server zu prüfen, ist keine Erlaubnis zum Scan des gesamten Subnetzes.

Einzelnes Ziel

[TEST][SENS] nmap 192.0.2.10

Kleines, ausdrücklich freigegebenes Netz

[TEST][SENS] nmap 192.0.2.0/28

IPv6-Ziel

[TEST][SENS] nmap -6 2001:db8::10

Ziele aus einer autorisiert erstellten Datei

[TEST][FILE][SENS] nmap -iL targets.txt

Zielbereich nur auflösen und auflisten, ohne Zielpakete zu senden

[RO][SENS] nmap -sL 192.0.2.0/28

-sL führt einen List Scan durch. Dabei werden die Ziele aufgelistet und standardmäßig gegebenenfalls Reverse-DNS-Abfragen durchgeführt. Es findet kein normaler Host- oder Portscan gegen die Zielsysteme statt.

Ohne DNS-Auflösung auflisten

[RO][SENS] nmap -sL -n 192.0.2.0/28

Das Auflisten des Zielbereichs vor dem aktiven Scan hilft, fehlerhafte CIDR-Angaben frühzeitig zu erkennen.

Nur Host-Erkennung, ohne Portscan

[TEST][SENS] nmap -sn 192.0.2.0/28

-sn deaktiviert den anschließenden Portscan. Nmap führt aber weiterhin aktive Host-Erkennungsprüfungen durch.

Ohne Namensauflösung

[TEST][SENS] nmap -sn -n 192.0.2.0/28

Grund für die Bewertung anzeigen

[TEST][SENS] nmap -sn --reason 192.0.2.0/28

Lokales Ethernet-Netz

Im lokalen Ethernet-Netz verwendet Nmap für die Host-Erkennung normalerweise ARP beziehungsweise bei IPv6 Neighbor Discovery. Das ist häufig zuverlässiger als ein einfacher ICMP-Echo-Test.

Gezielte ICMP-Echo-Erkennung

[TEST][PRIV][SENS] sudo nmap -sn -PE 192.0.2.0/28

TCP-SYN-Erkennung auf freigegebenen Ports

[TEST][PRIV][SENS] sudo nmap -sn -PS22,80,443 192.0.2.0/28

TCP-ACK-Erkennung

[TEST][PRIV][SENS] sudo nmap -sn -PA80,443 192.0.2.0/28

UDP-Erkennung auf einem gezielt freigegebenen Port

[TEST][PRIV][SENS] sudo nmap -sn -PU53 192.0.2.0/28

Wichtige Interpretation

Ein fehlender Hosttreffer beweist nicht, dass das System ausgeschaltet ist. Firewalls können die für die Erkennung verwendeten Pakete verwerfen.

Mit -Pn behandelt Nmap die angegebenen Ziele als erreichbar und überspringt die normale Host-Erkennung.

[TEST][SENS] nmap -Pn -p 443 192.0.2.10

Sinnvoller Einsatz

• der Host ist nachweislich aktiv;
• ICMP und andere Discovery-Pakete werden gefiltert;
• ein bestimmter Port soll unabhängig von der Host-Erkennung geprüft werden;
• nur ein einzelnes oder sehr kleines freigegebenes Ziel wird untersucht.

Auswirkung

Ohne erfolgreiche Host-Erkennung würde Nmap möglicherweise melden:

Host seems down.

Mit -Pn wird der Portscan trotzdem durchgeführt.

Risiko bei großen Zielbereichen

nmap -Pn 192.0.2.0/16

Dieser Scan würde jedes Ziel im Bereich als aktiv behandeln und entsprechend prüfen. Das kann sehr lange dauern und erhebliche Netzlast oder Sicherheitsmeldungen verursachen.

-Pn sollte nicht pauschal für große Netze verwendet werden. Es eignet sich hauptsächlich für bekannte, ausdrücklich freigegebene Einzelziele oder kleine Zielgruppen.

Wichtig

filtered bedeutet nicht automatisch:

Eine Firewall auf dem Zielsystem blockiert den Port.

Mögliche Ursachen sind unter anderem:

• Host-Firewall;
• Netzwerk-Firewall;
• Access Control List;
• Routerfilter;
• Security Group;
• Paketverlust;
• asymmetrisches Routing;
• IPS oder Rate Limiting;
• falscher Rückweg;
• unvollständige Scanantwort.

Mit --reason zeigt Nmap an, auf welcher Antwort oder Nichtantwort die Bewertung beruht:

[TEST][SENS] nmap --reason -p 22,80,443 192.0.2.10

Ohne ausdrückliche Portangabe untersucht Nmap standardmäßig die 1.000 häufigsten Ports des jeweiligen gescannten Protokolls. Es handelt sich nicht automatisch um alle 65.535 TCP-Ports.

Bestimmte Ports

[TEST][SENS] nmap -p 22,80,443 192.0.2.10

Portbereich

[TEST][SENS] nmap -p 8000-8100 192.0.2.10

Alle TCP-Ports

[TEST][SENS] nmap -p- 192.0.2.10

-p- steht für die Ports 1 bis 65.535. Ein vollständiger Portscan ist wesentlich umfangreicher als ein Standardscan und muss ausdrücklich freigegeben sein.

Die häufigsten 100 Ports

[TEST][SENS] nmap --top-ports 100 192.0.2.10

Schneller Scan der häufigsten Ports

[TEST][SENS] nmap -F 192.0.2.10

-F reduziert die Anzahl der normalerweise untersuchten Ports. Die genaue Portauswahl hängt von der lokalen Nmap-Dienstdatenbank ab.

Nur offene Ports anzeigen

[TEST][SENS] nmap --open -p 22,80,443,445,3389 192.0.2.10

--open verkürzt die Ausgabe. Für die Fehleranalyse können geschlossene und gefilterte Ports jedoch wichtige Informationen liefern. Die vollständige Ausgabe sollte deshalb häufig bevorzugt werden.

Der TCP-Connect-Scan verwendet die normale connect()-Funktion des Betriebssystems. Er kann gewöhnlich ohne Raw-Packet-Rechte ausgeführt werden.

[TEST][SENS] nmap -sT -p 22,80,443 192.0.2.10

Eigenschaften

Einzelnen HTTPS-Port prüfen

[TEST][SENS] nmap -sT -Pn -p 443 --reason 192.0.2.10

Da bei offenen Ports eine vollständige Verbindung aufgebaut wird, kann der Zielserver den Versuch in seinen Logs erfassen.

Für einen gezielten administrativen Funktionstest ist das nicht grundsätzlich nachteilig: Der Scan soll nachvollziehbar und autorisiert sein.

Beim SYN-Scan sendet Nmap ein TCP-SYN-Paket, ohne bei einem offenen Port eine vollständige Anwendungssitzung aufzubauen.

[TEST][PRIV][SENS] sudo nmap -sS -p 22,80,443 192.0.2.10

Typische Antworten

Eigenschaften

Der Ausdruck „halb offen“ bedeutet nicht, dass der Scan unsichtbar ist. Firewalls, IDS, IPS und Zielsysteme können SYN-Scans erkennen und protokollieren.

UDP ist verbindungslos. Ein fehlendes Antwortpaket lässt deshalb häufig keine eindeutige Entscheidung zu.

Gezielter UDP-Scan

[TEST][PRIV][SENS] sudo nmap -sU -p 53,123,161 192.0.2.10

Mit Begründung und Versionserkennung

[TEST][PRIV][SENS] sudo nmap -sU -sV --reason -p 53,123,161 192.0.2.10

Typische Ergebnisse

Warum UDP-Scans länger dauern

• viele offene UDP-Dienste antworten nur auf gültige Protokollanfragen;
• gefilterte Pakete erzeugen häufig keine Antwort;
• ICMP-Fehlermeldungen können begrenzt werden;
• Nmap muss Zeitüberschreitungen und Wiederholungen abwarten.

Nur die tatsächlich benötigten Ports prüfen

[TEST][PRIV][SENS] sudo nmap -sU -p 53 192.0.2.10

Ein ungeplanter Scan aller 65.535 UDP-Ports kann sehr lange dauern und unnötige Last verursachen.

TCP-SYN- und UDP-Scan können kombiniert werden:

[TEST][PRIV][SENS] sudo nmap -sS -sU -p T:53,80,443,U:53,123 192.0.2.10

Bedeutung

Ohne die Präfixe T: und U: kann die Portzuordnung bei einem kombinierten Scan missverständlich werden.

DNS über TCP und UDP prüfen

[TEST][PRIV][SENS] sudo nmap -sS -sU -p T:53,U:53 192.0.2.10

Ein offener TCP- und UDP-Port bestätigt noch nicht, dass DNS-Anfragen korrekt beantwortet werden. Danach sollte ein protokollspezifischer Test folgen, beispielsweise mit dig, Resolve-DnsName oder nslookup.

Die Versionserkennung sendet zusätzliche, teilweise protokollspezifische Anfragen an offene oder wahrscheinlich offene Ports.

[TEST][SENS] nmap -sV -p 22,80,443 192.0.2.10

Leichtere Versionserkennung

[TEST][SENS] nmap -sV --version-light -p 22,80,443 192.0.2.10

Intensität festlegen

[TEST][SENS] nmap -sV --version-intensity 2 -p 22,80,443 192.0.2.10

Der Wertebereich für --version-intensity reicht von 0 bis 9:

Interpretation

443/tcp open  https  nginx 1.24.0

Dabei sind zu unterscheiden:

Versionsergebnisse können unvollständig oder irreführend sein, beispielsweise durch:

• Reverse Proxies;
• Load Balancer;
• TLS-Termination;
• absichtlich veränderte Banner;
• Backports von Sicherheitskorrekturen;
• herstellerspezifische Builds;
• Protokollweiterleitungen;
• IDS- oder IPS-Antworten.

Ein Nmap-Versionshinweis sollte mit der lokalen Paketverwaltung, der Anwendungskonfiguration oder der Herstelleroberfläche bestätigt werden.

Nmap versucht anhand verschiedener Netzwerkmerkmale, das Betriebssystem des Zielsystems zu bestimmen.

[TEST][PRIV][SENS] sudo nmap -O 192.0.2.10

Nur gezielte Ports und OS-Erkennung

[TEST][PRIV][SENS] sudo nmap -O -p 22,80,443 192.0.2.10

Erkennungsversuche begrenzen

[TEST][PRIV][SENS] sudo nmap -O --osscan-limit 192.0.2.0/28

--osscan-limit beschränkt die OS-Erkennung auf Ziele, bei denen Nmap dafür geeignete Bedingungen erkennt.

Voraussetzungen für gute Ergebnisse

Nmap erzielt bessere Resultate, wenn mindestens:

• ein offener TCP-Port;
• ein geschlossener TCP-Port;
• ausreichende Antworten des Zielsystems

vorhanden sind.

Mögliche Ungenauigkeiten

• Firewall verändert Antworten;
• NAT oder Proxy liegt zwischen Quelle und Ziel;
• mehrere Systeme teilen eine IP-Adresse;
• Netzwerkgerät beantwortet Pakete stellvertretend;
• zu wenige geeignete Ports antworten;
• Betriebssystem-Fingerprint ist nicht eindeutig.

Die Ausgabe ist eine Netzwerkerkennung beziehungsweise Schätzung und kein sicherer Beweis für das installierte Betriebssystem.

Die Nmap Scripting Engine, kurz NSE, erweitert Nmap um Skripte. Diese können von einfachen Informationsabfragen bis zu Sicherheits- und Belastungstests reichen.

Standard-Skripte

[TEST][DISRUPT][SENS] nmap -sC -p 22,80,443 192.0.2.10

-sC entspricht:

--script=default

Auch Standardskripte senden zusätzliche Anfragen an Dienste und sollten nur nach Freigabe verwendet werden.

Bestimmtes, zuvor geprüftes Skript

[TEST][SENS] nmap --script http-title -p 80,443 192.0.2.10

Skriptbeschreibung anzeigen

[RO] nmap --script-help http-title

Mehrere freigegebene Informationsskripte

[TEST][SENS] nmap --script http-title,http-headers -p 80,443 192.0.2.10

Vor einem NSE-Einsatz müssen geprüft werden:

• Skriptname;
• Skriptbeschreibung;
• Kategorie;
• benötigte Argumente;
• mögliche Auswirkungen;
• Zielport;
• Umfang der Autorisierung.

Im normalen Troubleshooting nicht pauschal verwenden

--script vuln
--script exploit
--script brute
--script dos
--script intrusive

Diese Kategorien können Schwachstellenprüfungen, Anmeldeversuche oder belastende Tests enthalten. Sie gehören nicht in eine gewöhnliche Netzwerkdiagnose ohne gesonderten Auftrag.

Auch die Kategorie safe ist keine absolute Garantie für Wirkungslosigkeit. Das konkrete Skript muss vor dem Einsatz geprüft werden.

Die Option -A aktiviert mehrere Funktionen gleichzeitig:

• Betriebssystemerkennung;
• Versionserkennung;
• Standardskript-Scan;
• Traceroute.

[TEST][PRIV][DISRUPT][SENS] sudo nmap -A 192.0.2.10

Für eine gezielte Fehleranalyse ist dieser Befehl häufig zu breit. Er sendet mehr unterschiedliche Prüfungen als ein einfacher Portscan und erzeugt umfangreichere Logs und mögliche Sicherheitsmeldungen.

Besser ist eine schrittweise Auswahl:

[TEST][SENS] nmap -sT -p 443 192.0.2.10

Danach bei Bedarf:

[TEST][SENS] nmap -sV --version-light -p 443 192.0.2.10

Und nur bei begründetem Bedarf:

[TEST][PRIV][SENS] sudo nmap -O -p 22,80,443 192.0.2.10

Dadurch bleibt erkennbar, welche Scanoption welche Reaktion verursacht hat.

Keine DNS-Auflösung durchführen

[TEST][SENS] nmap -n -p 22,80,443 192.0.2.10

DNS-Auflösung für alle Ziele erzwingen

[TEST][SENS] nmap -R -p 22,80,443 192.0.2.10

Bedeutung

Für reproduzierbare Portprüfungen ist -n häufig sinnvoll:

• Scan wird nicht durch DNS verzögert;
• keine zusätzlichen DNS-Abfragen;
• Ergebnisse zeigen die tatsächlichen IP-Adressen;
• DNS- und Portprobleme werden getrennt untersucht.

Wenn die DNS-Zuordnung selbst Teil der Diagnose ist, sollte sie bewusst separat geprüft werden.

Nmap bietet Timing-Vorlagen:

Normale Geschwindigkeit

[TEST][SENS] nmap -T3 -p 22,80,443 192.0.2.10

Rücksichtsvollere Prüfung

[TEST][SENS] nmap -T2 -p 22,80,443 192.0.2.10

Maximale Paketrate begrenzen

[TEST][SENS] nmap --max-rate 50 -p 1-1000 192.0.2.10

--max-rate 50 fordert Nmap auf, im Durchschnitt nicht schneller als 50 Pakete pro Sekunde zu senden. Abhängig von Scanart und Betriebssystem können trotzdem kurzfristige Abweichungen auftreten.

Host-Zeitüberschreitung

[TEST][SENS] nmap --host-timeout 2m -p 22,80,443 192.0.2.10

Wenn ein Ziel nach zwei Minuten nicht vollständig geprüft wurde, beendet Nmap die weitere Bearbeitung dieses Hosts.

Für empfindliche Systeme

• nur einzelne Ziele;
• nur benötigte Ports;
• -T2 oder -T3;
• niedrige --max-rate;
• keine umfassende Versionserkennung;
• keine pauschalen NSE-Skripte;
• System- und Dienstüberwachung parallel beobachten.

Normale Ausgabe speichern

[TEST][FILE][SENS] nmap -sT -p 22,80,443 -oN server-scan.txt 192.0.2.10

XML-Ausgabe

[TEST][FILE][SENS] nmap -sT -p 22,80,443 -oX server-scan.xml 192.0.2.10

Alle Hauptformate

[TEST][FILE][SENS] nmap -sT -p 22,80,443 -oA server-scan 192.0.2.10

Dabei entstehen typischerweise:

server-scan.nmap
server-scan.xml
server-scan.gnmap

Zusätzlich Terminalausgabe mit tee speichern

Linux und macOS:

[TEST][FILE][SENS] nmap -sT -p 22,80,443 192.0.2.10 | tee server-scan.txt

PowerShell:

[TEST][FILE][SENS] nmap -sT -p 22,80,443 192.0.2.10 | Tee-Object -FilePath server-scan.txt

tee beziehungsweise Tee-Object speichert nur die sichtbare Textausgabe. Für strukturierte Verarbeitung sollte -oX oder -oA verwendet werden.

Vor der Änderung

[TEST][FILE][SENS] nmap -n -sT -p 22,80,443 --reason -oA server-before 192.0.2.10

Nach der Änderung

[TEST][FILE][SENS] nmap -n -sT -p 22,80,443 --reason -oA server-after 192.0.2.10

Linux und macOS:

[RO][FILE][SENS] diff -u server-before.nmap server-after.nmap

PowerShell:

[RO][FILE][SENS] Compare-Object (Get-Content .\server-before.nmap) (Get-Content .\server-after.nmap)

Für einen aussagekräftigen Vergleich müssen identisch sein:

• Scanquelle;
• Zieladresse;
• Scanart;
• Portliste;
• Nmap-Version;
• Berechtigungsstufe;
• DNS-Einstellung;
• Timing-Einstellung;
• Netzwerkpfad.

Andernfalls können Unterschiede durch die Testmethode statt durch die eigentliche Änderung entstehen.

Beispiel: HTTPS auf TCP-Port 443.

1. Namensauflösung getrennt prüfen

Windows:

[RO] Resolve-DnsName server.example.com

Linux oder macOS:

[RO] dig server.example.com

2. Host Discovery durchführen

[TEST][SENS] nmap -sn --reason 192.0.2.10

3. Port unabhängig von Host Discovery prüfen

[TEST][SENS] nmap -Pn -n -sT -p 443 --reason 192.0.2.10

4. Dienst vorsichtig identifizieren

[TEST][SENS] nmap -Pn -n -sV --version-light -p 443 192.0.2.10

5. Anwendungsebene prüfen

[TEST][SENS] curl -vkI https://192.0.2.10/

Bei namensabhängigen virtuellen Hosts sollte der korrekte DNS-Name verwendet werden:

[TEST][SENS] curl -vI https://server.example.com/

6. TLS gesondert prüfen

[TEST][SENS] openssl s_client -connect 192.0.2.10:443 -servername server.example.com

Interpretation

Nmap beantwortet hauptsächlich die Frage:

Wie reagiert dieser Port aus Sicht dieses Scanstandorts?

Für die vollständige Fehlerursache sind weitere Werkzeuge erforderlich.

Ein Scan sollte von genau den Standorten erfolgen, deren Erreichbarkeit untersucht wird.

Clientnetz A → Firewall → Servernetz
Clientnetz B → Firewall → Servernetz

Scan aus Netz A

[TEST][FILE][SENS] nmap -Pn -n -sT -p 443 --reason -oN netz-a.txt 192.0.2.10

Scan aus Netz B

[TEST][FILE][SENS] nmap -Pn -n -sT -p 443 --reason -oN netz-b.txt 192.0.2.10

Mögliche Beobachtung

Zusätzlich sollten geprüft werden:

• Quell-IP des Scanhosts;
• Ziel-IP nach NAT;
• Firewall-Logs;
• Routingtabellen;
• Security Groups;
• lokale Host-Firewall;
• Paketmitschnitt auf Client, Firewall oder Server;
• Rückweg zum jeweiligen Clientnetz.

Ein Nmap-Ergebnis allein zeigt nicht, an welchem Gerät ein Paket verworfen wurde.

Folgende Funktionen gehören normalerweise nicht zur alltäglichen Fehleranalyse:

Solche Funktionen werden in diesem Troubleshooting-Buch nicht als Standardbefehle empfohlen. Für einen gesonderten Sicherheitstest sind ein eigener Auftrag, eine genaue Risikoanalyse und abgestimmte Abbruchkriterien erforderlich.

Lokale Listener prüfen

Ein Port kann lokal lauschen und trotzdem aus dem untersuchten Netzsegment nicht erreichbar sein. Umgekehrt kann NAT oder Portweiterleitung einen extern erreichbaren Port zeigen, obwohl auf der Zieladresse selbst kein entsprechender lokaler Listener sichtbar ist.

Vorbereitung

1. Auftrag und Ziel der Prüfung dokumentieren.
2. Zulässige Zieladressen und Ports festlegen.
3. Scanquelle und Netzwerksegment dokumentieren.
4. Empfindliche Systeme identifizieren.
5. Erlaubte Scanarten und maximale Rate festlegen.
6. Ansprechpartner und Abbruchkriterium festlegen.
7. Systemzeit und Speicherort der Ergebnisse prüfen.

Zielkontrolle

8. Zielbereich zuerst mit -sL -n auflisten.
9. CIDR-Präfix und Ausschlüsse kontrollieren.
10. Mit einem einzelnen Testsystem beginnen.

Schrittweise Prüfung

11. Host Discovery mit -sn durchführen.
12. Falls erforderlich einen bekannten Port mit -Pn prüfen.
13. Nur benötigte Ports mit -p angeben.
14. Zunächst TCP Connect oder SYN Scan verwenden.
15. UDP nur für konkret benötigte Ports prüfen.
16. --reason zur Interpretation hinzufügen.
17. Versionserkennung nur bei Bedarf verwenden.
18. NSE-Skripte einzeln prüfen und freigeben.
19. Scanrate und Zielsystemüberwachung beobachten.

Dokumentation

20. Ausgabe mit -oA speichern.
21. Nmap-Version und verwendeten Befehl dokumentieren.
22. Beginn, Ende und Scanquelle festhalten.
23. Ergebnisse als Beobachtung und nicht sofort als Ursache dokumentieren.

Validierung

24. Offene Ports mit einem Protokollwerkzeug prüfen.
25. Gefilterte Ports mit Firewall-Logs und Paketmitschnitten untersuchen.
26. Lokale Listener auf dem Zielsystem prüfen.
27. Nach einer Änderung denselben Scan erneut ausführen.
28. Ergebnisse vergleichen.
29. Zuständige Personen über Abschluss oder Auffälligkeiten informieren.
30. Scanresultate gemäß Schutz- und Löschrichtlinie behandeln.