☰

Warum sendet nmap zwei Pakete, um einen einzelnen Port zu testen?

tag-icon • tag-icon nmap
Warum sendet nmap zwei Pakete, um einen einzelnen Port zu testen?

Ich führe nmap mit Root-Rechten unter Verwendung von sudo aus, daher gehe ich davon aus, dass es vollen Zugriff zum Erstellen von Raw-Sockets hat. Wireshark zeigt zwei Pakete an, die zum Testen eines einzelnen Ports verwendet wurden, als ich den Befehl verwendete

sudo nmap 192.168.110.153 -p21

Ist das normales Verhalten? Warum?

Bildbeschreibung hier eingeben

sudo nmap 192.168.110.153 -p21 --packet-trace

Starting Nmap 6.40 ( http://nmap.org ) at 2015-05-19 19:18 BST
SENT (0.0447s) ARP who-has 192.168.110.153 tell 192.168.110.155
RCVD (0.0450s) ARP reply 192.168.110.153 is-at 00:0C:29:F4:05:E0
NSOCK INFO [0.2450s] nsi_new2(): nsi_new (IOD #1)
NSOCK INFO [0.2450s] nsock_connect_udp(): UDP connection requested to 127.0.1.1:53 (IOD #1) EID 8
NSOCK INFO [0.2460s] nsock_read(): Read request from IOD #1 [127.0.1.1:53] (timeout: -1ms) EID 18
NSOCK INFO [0.2460s] nsock_trace_handler_callback(): Callback: CONNECT SUCCESS for EID 8 [127.0.1.1:53]
NSOCK INFO [0.2460s] nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 27 [127.0.1.1:53]
NSOCK INFO [0.2740s] nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 18 [127.0.1.1:53] (46 bytes): *%...........153.110.168.192.in-addr.arpa.....
NSOCK INFO [0.2740s] nsock_read(): Read request from IOD #1 [127.0.1.1:53] (timeout: -1ms) EID 34
NSOCK INFO [0.2740s] nsi_delete(): nsi_delete (IOD #1)
NSOCK INFO [0.2740s] msevent_cancel(): msevent_cancel on event #34 (type READ)
SENT (0.2751s) TCP 192.168.110.155:45170 > 192.168.110.153:21 S ttl=39 id=28633 iplen=44  seq=3053138125 win=1024 <mss 1460>
SENT (0.3754s) TCP 192.168.110.155:45171 > 192.168.110.153:21 S ttl=46 id=8796 iplen=44  seq=3053072588 win=1024 <mss 1460>
RCVD (0.2759s) TCP 192.168.110.153:21 > 192.168.110.155:45170 RA ttl=64 id=14442 iplen=40  seq=0 win=0 
RCVD (0.3756s) TCP 192.168.110.153:21 > 192.168.110.155:45171 RA ttl=64 id=14443 iplen=40  seq=0 win=0 
Nmap scan report for 192.168.110.153
Host is up (0.00047s latency).
PORT   STATE  SERVICE
21/tcp closed ftp
MAC Address: 00:0C:29:F4:05:E0 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.50 seconds

Antwort1

Es scheint ein libpcapProblem mit der Warteschlangenbildung von Paketen vor der Übermittlung an Nmap zu geben. Beachten Sie den Unterschied in der Reihenfolge der Pakete zwischen Wireshark und Nmap. Obwohl die Zeitstempel gleich sind, zeigt die Reihenfolge der gedruckten Zeilen, dass die Pakete an Nmap übermittelt wurden.nachdas zweite SYN-Paket wurde gesendet. Wir hatten/haben vor kurzem eineProblem mit libpcap 1.5.3(und möglicherweise der 1.6-Zweig, nicht getestet) auf neueren Linux-Kerneln im Zusammenhang mit der Paketring-/TPACKET-Schnittstelle, die Pakete nicht zustellt, wenn sie ankommen. Was ist die Ausgabe von nmap --version?

Das zugrunde liegende Problem ist ein Fehler in Linux, derbereits behoben, aber nicht zurückportiert. Wir haben dieses Problem in der Entwicklung gelöst, indem wir libpcap auf Version 1.7.3 aktualisiert haben, die einige Workarounds bietet.

Antwort2

Ihrem Screenshot zufolge scheinen die [R.]Pakete gefiltert zu werden, bevor sie die Maschine erreichen, von der aus Sie scannen, und nmap hat seine Funktion zur erneuten Übertragung verwendet, da das erste [S]Paket keine Antwort erhielt.

Sie können dies mit deaktivieren --max-retries 0.

Antwort3

Warum sendet nmap zwei Pakete, um einen einzelnen Port zu testen?

Normalerweise: wegen des Drei-Wege-Handshakes, der erforderlich ist, umeine TCP-Verbindung herstellen... SYN senden -> SYN-ACK empfangen -> ACK senden

In diesem Fall: weil die Antwort von 192.168.110.153 lautet RST, ACK oder anders gesagt: eine Verbindung zu Port 21 wird abgelehnt. Wahrscheinlich ist nmap leicht hartnäckig und versucht es zweimal, bevor es „Nein“ als Antwort akzeptiert.

verwandte Informationen