Nmap Packet-Trace

Aus Xinux Wiki
Version vom 21. Juni 2026, 09:51 Uhr von Thomas.will (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „=Grundsätzliches= Mit --packet-trace zeigt nmap jedes gesendete und empfangene Paket an. Damit wird sichtbar, warum ein Port einen bestimmten Zustand hat und…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Grundsätzliches

Mit --packet-trace zeigt nmap jedes gesendete und empfangene Paket an. Damit wird sichtbar, warum ein Port einen bestimmten Zustand hat und welche Technik nmap für die Host-Discovery wählt.

ARP statt ICMP im lokalen Netz

Im lokalen Netz sendet nmap zuerst einen ARP-Request, die ARP-Antwort bestätigt den Host

  • nmap 192.168.100.59 -sn -PE --packet-trace
SENT (0.0359s) ARP who-has 192.168.100.59 tell 192.168.100.94
RCVD (0.0365s) ARP reply 192.168.100.59 is-at 08:00:27:00:14:D9
Host is up (0.00062s latency).
Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds

Grund für den Host-Status anzeigen

--reason zeigt, warum nmap den Host als aktiv einstuft

  • nmap 192.168.100.59 -sn -PE --reason
SENT (0.0074s) ARP who-has 192.168.100.59 tell 192.168.100.94
RCVD (0.0309s) ARP reply 192.168.100.59 is-at 08:00:27:00:14:D9
Host is up, received arp-response (0.028s latency).

ICMP erzwingen, ARP deaktivieren

--disable-arp-ping zwingt nmap, ICMP statt ARP zu nutzen

  • nmap 192.168.100.59 -sn -PE --packet-trace --disable-arp-ping
SENT (0.0107s) ICMP [192.168.100.94 > 192.168.100.59 Echo request (type=8/code=0) id=13607 seq=0]
RCVD (0.0152s) ICMP [192.168.100.59 > 192.168.100.94 Echo reply (type=0/code=0) id=13607 seq=0]
Host is up (0.086s latency).

Geschlossener Port

Ein geschlossener Port antwortet auf das SYN mit RST+ACK

  • nmap 192.168.100.59 -p 21 --packet-trace -Pn -n --disable-arp-ping
SENT (0.0980s) TCP 192.168.100.94:44093 > 192.168.100.59:21 S ttl=39 id=22759 iplen=44 seq=520204497 win=1024 <mss 1460>
RCVD (0.0991s) TCP 192.168.100.59:21 > 192.168.100.94:44093 RA ttl=64 id=0 iplen=40 seq=0 win=0
PORT   STATE  SERVICE
21/tcp closed ftp
Erläuterung
  • SENT zeigt das gesendete Paket mit gesetztem SYN-Flag (S)
  • RCVD zeigt die Antwort mit RA-Flags (RST+ACK)
  • Die RST-Antwort bedeutet: Port ist definitiv geschlossen

Offener Port mit Connect-Scan

Der Connect-Scan führt den vollständigen Drei-Wege-Handshake durch

  • nmap 192.168.100.59 -p 443 --packet-trace --disable-arp-ping -Pn -n --reason -sT
CONN (0.0867s) TCP localhost > 192.168.100.59:443 => Operation now in progress
CONN (0.0873s) TCP localhost > 192.168.100.59:443 => Connected
PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
Erläuterung
  • Die CONN-Zeilen zeigen den vollständigen Verbindungsaufbau
  • Der Reason syn-ack bestätigt, dass Port 443 offen ist
  • Der SYN-Scan (-sS) ist unauffälliger, da er den Handshake nie abschließt und nach dem SYN-ACK ein RST sendet

Gefilterter Port - keine Antwort

Eine Firewall verwirft das Paket stillschweigend, nmap erhält keine Antwort

  • nmap 192.168.100.59 -p 139 --packet-trace -n --disable-arp-ping -Pn
SENT (0.0381s) TCP 192.168.100.94:33892 > 192.168.100.59:139 S ttl=41 iplen=44
SENT (1.4411s) TCP 192.168.100.94:33892 > 192.168.100.59:139 S ttl=41 iplen=44
PORT    STATE    SERVICE
139/tcp filtered netbios-ssn
Erläuterung
  • Zwei SYN-Pakete wurden gesendet, keine Antwort kam zurück
  • Der Scan dauerte rund 2 Sekunden - deutlich länger als bei einem geschlossenen Port
  • Das lange Warten auf eine ausbleibende Antwort ist das Kennzeichen von filtered

Gefilterter Port - aktive Ablehnung

Eine Firewall lehnt das Paket mit ICMP Unreachable aktiv ab

  • nmap 192.168.100.59 -p 445 --packet-trace -n --disable-arp-ping -Pn
SENT (0.0429s) TCP 192.168.100.94:57559 > 192.168.100.59:445 S ttl=54 iplen=44
RCVD (0.0434s) ICMP [192.168.100.59 > 192.168.100.94 Port unreachable (type=3/code=3)]
PORT    STATE    SERVICE
445/tcp filtered microsoft-ds
Erläuterung
  • ICMP type=3, code=3 bedeutet Port Unreachable - aktive Ablehnung durch die Firewall
  • Der Scan ist mit rund 0,05 Sekunden deutlich schneller, da nmap sofort eine Antwort erhält
  • Stiller Verwurf und aktive Ablehnung führen beide zu filtered, unterscheiden sich aber im Timing

UDP - offener Port

Ein offener UDP-Port antwortet mit einer UDP-Antwort

  • nmap 192.168.100.59 -sU -Pn -n --disable-arp-ping --packet-trace -p 137 --reason
SENT (0.4090s) UDP 192.168.100.94:59643 > 192.168.100.59:137 ttl=53 iplen=78
RCVD (0.4101s) UDP 192.168.100.59:137 > 192.168.100.94:59643 ttl=64 iplen=365
PORT    STATE SERVICE    REASON
137/udp open  netbios-ns udp-response ttl 64

UDP - geschlossener Port

Ein geschlossener UDP-Port antwortet mit ICMP Unreachable

  • nmap 192.168.100.59 -sU -Pn -n --disable-arp-ping --packet-trace -p 100 --reason
SENT (0.4095s) UDP 192.168.100.94:60808 > 192.168.100.59:100 ttl=37 iplen=28
RCVD (0.4099s) ICMP [192.168.100.59 > 192.168.100.94 Port unreachable (type=3/code=3)]
PORT    STATE  SERVICE REASON
100/udp closed unknown port-unreach ttl 64

UDP - keine Antwort

Ohne Antwort kann nmap nicht zwischen offen und gefiltert unterscheiden

  • nmap 192.168.100.59 -sU -Pn -n --disable-arp-ping --packet-trace -p 138 --reason
SENT (0.4140s) UDP 192.168.100.94:48404 > 192.168.100.59:138 ttl=38 iplen=28
SENT (1.4144s) UDP 192.168.100.94:48406 > 192.168.100.59:138 ttl=52 iplen=28
PORT    STATE         SERVICE     REASON
138/udp open|filtered netbios-dgm no-response
Erläuterung
  • Zwei Pakete wurden gesendet, keine Antwort kam zurück
  • Da UDP keine Bestätigung kennt, bleibt der Zustand open|filtered
  • Das macht UDP-Scans langsam und unzuverlässig