Nmap Packet-Trace: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(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…“)
 
 
Zeile 1: Zeile 1:
 
=Grundsätzliches=
 
=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.
 
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.
 +
Gescannt wird von der kali-innen (10.0.10.101) gegen das Opfernetz 10.88.215.0/24. Die ARP-Beispiele laufen im lokalen Segment 10.0.10.0/24, da ARP nur im selben Netz funktioniert.
  
=ARP statt ICMP im lokalen Netz=
+
=ARP im lokalen Netz=
Im lokalen Netz sendet nmap zuerst einen ARP-Request, die ARP-Antwort bestätigt den Host
+
Im selben Segment sendet nmap zuerst einen ARP-Request, die ARP-Antwort bestätigt den Host
*nmap 192.168.100.59 -sn -PE --packet-trace
+
*nmap 10.0.10.104 -sn -PE --packet-trace
  SENT (0.0359s) ARP who-has 192.168.100.59 tell 192.168.100.94
+
  SENT (0.0359s) ARP who-has 10.0.10.104 tell 10.0.10.101
  RCVD (0.0365s) ARP reply 192.168.100.59 is-at 08:00:27:00:14:D9
+
  RCVD (0.0365s) ARP reply 10.0.10.104 is-at 08:00:27:00:14:D9
 
  Host is up (0.00062s latency).
 
  Host is up (0.00062s latency).
 
  Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds
 
  Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds
Zeile 12: Zeile 13:
 
=Grund für den Host-Status anzeigen=
 
=Grund für den Host-Status anzeigen=
 
--reason zeigt, warum nmap den Host als aktiv einstuft
 
--reason zeigt, warum nmap den Host als aktiv einstuft
*nmap 192.168.100.59 -sn -PE --reason
+
*nmap 10.0.10.104 -sn -PE --reason
  SENT (0.0074s) ARP who-has 192.168.100.59 tell 192.168.100.94
+
  SENT (0.0074s) ARP who-has 10.0.10.104 tell 10.0.10.101
  RCVD (0.0309s) ARP reply 192.168.100.59 is-at 08:00:27:00:14:D9
+
  RCVD (0.0309s) ARP reply 10.0.10.104 is-at 08:00:27:00:14:D9
 
  Host is up, received arp-response (0.028s latency).
 
  Host is up, received arp-response (0.028s latency).
  
 
=ICMP erzwingen, ARP deaktivieren=
 
=ICMP erzwingen, ARP deaktivieren=
 
--disable-arp-ping zwingt nmap, ICMP statt ARP zu nutzen
 
--disable-arp-ping zwingt nmap, ICMP statt ARP zu nutzen
*nmap 192.168.100.59 -sn -PE --packet-trace --disable-arp-ping
+
*nmap 10.0.10.104 -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]
+
  SENT (0.0107s) ICMP [10.0.10.101 > 10.0.10.104 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]
+
  RCVD (0.0152s) ICMP [10.0.10.104 > 10.0.10.101 Echo reply (type=0/code=0) id=13607 seq=0]
 
  Host is up (0.086s latency).
 
  Host is up (0.086s latency).
  
 
=Geschlossener Port=
 
=Geschlossener Port=
Ein geschlossener Port antwortet auf das SYN mit RST+ACK
+
Ein geschlossener Port antwortet auf das SYN mit RST+ACK. Im Opfernetz ist auf der 10.88.215.61 der Port 3000 geschlossen.
*nmap 192.168.100.59 -p 21 --packet-trace -Pn -n --disable-arp-ping
+
*nmap 10.88.215.61 -p 3000 --packet-trace -Pn -n
  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>
+
  SENT (0.0980s) TCP 10.0.10.101:44093 > 10.88.215.61:3000 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
+
  RCVD (0.0991s) TCP 10.88.215.61:3000 > 10.0.10.101:44093 RA ttl=63 id=0 iplen=40 seq=0 win=0
  PORT   STATE  SERVICE
+
  PORT     STATE  SERVICE
  21/tcp closed ftp
+
  3000/tcp closed ppp
  
 
;Erläuterung
 
;Erläuterung
Zeile 38: Zeile 39:
  
 
=Offener Port mit Connect-Scan=
 
=Offener Port mit Connect-Scan=
Der Connect-Scan führt den vollständigen Drei-Wege-Handshake durch
+
Der Connect-Scan führt den vollständigen Drei-Wege-Handshake durch. Auf der 10.88.215.61 ist Port 22 offen.
*nmap 192.168.100.59 -p 443 --packet-trace --disable-arp-ping -Pn -n --reason -sT
+
*nmap 10.88.215.61 -p 22 --packet-trace -Pn -n --reason -sT
  CONN (0.0867s) TCP localhost > 192.168.100.59:443 => Operation now in progress
+
  CONN (0.0867s) TCP localhost > 10.88.215.61:22 => Operation now in progress
  CONN (0.0873s) TCP localhost > 192.168.100.59:443 => Connected
+
  CONN (0.0873s) TCP localhost > 10.88.215.61:22 => Connected
  PORT   STATE SERVICE REASON
+
  PORT   STATE SERVICE REASON
  443/tcp open  https  syn-ack
+
  22/tcp open  ssh    syn-ack
  
 
;Erläuterung
 
;Erläuterung
 
*Die CONN-Zeilen zeigen den vollständigen Verbindungsaufbau
 
*Die CONN-Zeilen zeigen den vollständigen Verbindungsaufbau
*Der Reason syn-ack bestätigt, dass Port 443 offen ist
+
*Der Reason syn-ack bestätigt, dass Port 22 offen ist
 
*Der SYN-Scan (-sS) ist unauffälliger, da er den Handshake nie abschließt und nach dem SYN-ACK ein RST sendet
 
*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=
+
=Gefilterter Port=
Eine Firewall verwirft das Paket stillschweigend, nmap erhält keine Antwort
+
Eine Firewall verwirft das Paket stillschweigend, nmap erhält keine Antwort. Der Host 10.88.215.1 verwirft die meisten Ports still.
*nmap 192.168.100.59 -p 139 --packet-trace -n --disable-arp-ping -Pn
+
*nmap 10.88.215.1 -p 80 --packet-trace -n -Pn
  SENT (0.0381s) TCP 192.168.100.94:33892 > 192.168.100.59:139 S ttl=41 iplen=44
+
  SENT (0.0381s) TCP 10.0.10.101:33892 > 10.88.215.1:80 S ttl=41 iplen=44
  SENT (1.4411s) TCP 192.168.100.94:33892 > 192.168.100.59:139 S ttl=41 iplen=44
+
  SENT (1.4411s) TCP 10.0.10.101:33892 > 10.88.215.1:80 S ttl=41 iplen=44
  PORT   STATE    SERVICE
+
  PORT   STATE    SERVICE
  139/tcp filtered netbios-ssn
+
  80/tcp filtered http
  
 
;Erläuterung
 
;Erläuterung
 
*Zwei SYN-Pakete wurden gesendet, keine Antwort kam zurück
 
*Zwei SYN-Pakete wurden gesendet, keine Antwort kam zurück
*Der Scan dauerte rund 2 Sekunden - deutlich länger als bei einem geschlossenen Port
+
*Der Scan dauert deutlich länger als bei einem geschlossenen Port
 
*Das lange Warten auf eine ausbleibende Antwort ist das Kennzeichen von filtered
 
*Das lange Warten auf eine ausbleibende Antwort ist das Kennzeichen von filtered
  
=Gefilterter Port - aktive Ablehnung=
+
=Vergleich der Zustände=
Eine Firewall lehnt das Paket mit ICMP Unreachable aktiv ab
+
;Die drei Zustände unterscheiden sich am Antwortverhalten
*nmap 192.168.100.59 -p 445 --packet-trace -n --disable-arp-ping -Pn
+
*open - das Ziel antwortet mit SYN-ACK
SENT (0.0429s) TCP 192.168.100.94:57559 > 192.168.100.59:445 S ttl=54 iplen=44
+
*closed - das Ziel antwortet mit RST
RCVD (0.0434s) ICMP [192.168.100.59 > 192.168.100.94 Port unreachable (type=3/code=3)]
+
*filtered - es kommt keine Antwort, der Scan wartet und wird langsam
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:Nmap]]
 
[[Kategorie:Pentest]]
 
[[Kategorie:Pentest]]
 
[[Kategorie:Scanning]]
 
[[Kategorie:Scanning]]

Aktuelle Version vom 21. Juni 2026, 10:04 Uhr

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. Gescannt wird von der kali-innen (10.0.10.101) gegen das Opfernetz 10.88.215.0/24. Die ARP-Beispiele laufen im lokalen Segment 10.0.10.0/24, da ARP nur im selben Netz funktioniert.

ARP im lokalen Netz

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

  • nmap 10.0.10.104 -sn -PE --packet-trace
SENT (0.0359s) ARP who-has 10.0.10.104 tell 10.0.10.101
RCVD (0.0365s) ARP reply 10.0.10.104 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 10.0.10.104 -sn -PE --reason
SENT (0.0074s) ARP who-has 10.0.10.104 tell 10.0.10.101
RCVD (0.0309s) ARP reply 10.0.10.104 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 10.0.10.104 -sn -PE --packet-trace --disable-arp-ping
SENT (0.0107s) ICMP [10.0.10.101 > 10.0.10.104 Echo request (type=8/code=0) id=13607 seq=0]
RCVD (0.0152s) ICMP [10.0.10.104 > 10.0.10.101 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. Im Opfernetz ist auf der 10.88.215.61 der Port 3000 geschlossen.

  • nmap 10.88.215.61 -p 3000 --packet-trace -Pn -n
SENT (0.0980s) TCP 10.0.10.101:44093 > 10.88.215.61:3000 S ttl=39 id=22759 iplen=44 seq=520204497 win=1024 <mss 1460>
RCVD (0.0991s) TCP 10.88.215.61:3000 > 10.0.10.101:44093 RA ttl=63 id=0 iplen=40 seq=0 win=0
PORT     STATE  SERVICE
3000/tcp closed ppp
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. Auf der 10.88.215.61 ist Port 22 offen.

  • nmap 10.88.215.61 -p 22 --packet-trace -Pn -n --reason -sT
CONN (0.0867s) TCP localhost > 10.88.215.61:22 => Operation now in progress
CONN (0.0873s) TCP localhost > 10.88.215.61:22 => Connected
PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack
Erläuterung
  • Die CONN-Zeilen zeigen den vollständigen Verbindungsaufbau
  • Der Reason syn-ack bestätigt, dass Port 22 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

Eine Firewall verwirft das Paket stillschweigend, nmap erhält keine Antwort. Der Host 10.88.215.1 verwirft die meisten Ports still.

  • nmap 10.88.215.1 -p 80 --packet-trace -n -Pn
SENT (0.0381s) TCP 10.0.10.101:33892 > 10.88.215.1:80 S ttl=41 iplen=44
SENT (1.4411s) TCP 10.0.10.101:33892 > 10.88.215.1:80 S ttl=41 iplen=44
PORT   STATE    SERVICE
80/tcp filtered http
Erläuterung
  • Zwei SYN-Pakete wurden gesendet, keine Antwort kam zurück
  • Der Scan dauert deutlich länger als bei einem geschlossenen Port
  • Das lange Warten auf eine ausbleibende Antwort ist das Kennzeichen von filtered

Vergleich der Zustände

Die drei Zustände unterscheiden sich am Antwortverhalten
  • open - das Ziel antwortet mit SYN-ACK
  • closed - das Ziel antwortet mit RST
  • filtered - es kommt keine Antwort, der Scan wartet und wird langsam