Thomas.will am 21. Juni 2026 um 10:04 Uhr

2026-06-21T10:04:45Z

Thomas.will: 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…“

2026-06-21T09:51:09Z

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…“

Neue Seite

=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

[[Kategorie:Nmap]]
[[Kategorie:Pentest]]
[[Kategorie:Scanning]]

Nmap Packet-Trace - Versionsgeschichte

Thomas.will am 21. Juni 2026 um 10:04 Uhr

Thomas.will: 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…“