☰

¿Por qué nmap envía dos paquetes para probar un solo puerto?

tag-icon • tag-icon nmap
¿Por qué nmap envía dos paquetes para probar un solo puerto?

Ejecuto nmap con privilegios de root usando sudo, así que supongo que tiene acceso completo para crear sockets sin formato. Wireshark muestra dos paquetes utilizados para probar un solo puerto cuando usé el comando

sudo nmap 192.168.110.153 -p21

¿Es ese un comportamiento normal? ¿por qué?

ingrese la descripción de la imagen aquí

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

Respuesta1

Parece un libpcapproblema al poner en cola los paquetes antes de entregarlos a Nmap. Observe la diferencia en el orden de los paquetes entre Wireshark y Nmap; aunque las marcas de tiempo son las mismas, el orden de las líneas impresas muestra que los paquetes fueron entregados a Nmapdespuésse envió el segundo paquete SYN. Recientemente tuvimos/tenemos unproblema con libpcap 1.5.3(y posiblemente la rama 1.6, no se ha probado) en kernels de Linux más nuevos relacionados con la interfaz de anillo de paquetes/TPACKET que no entrega los paquetes cuando llegan. ¿Cuál es la salida de nmap --version?

El problema subyacente es un error en Linux, que fueya arreglado pero no respaldado. Resolvimos este problema en desarrollo actualizando libpcap a la versión 1.7.3, que tiene algunas soluciones.

Respuesta2

Dada su captura de pantalla, parece que los [R.]paquetes se filtran antes de llegar a la máquina desde la que está escaneando y nmap usó su función de retransmisión ya que el primer [S]paquete no recibió ninguna respuesta.

Puedes desactivar esto usando --max-retries 0.

Respuesta3

¿Por qué nmap envía dos paquetes para probar un solo puerto?

Normalmente: debido al protocolo de enlace de tres vías necesario paraestablecer una conexión TCP... enviar SYN -> recibir SYN-ACK -> enviar ACK

En este caso: porque la respuesta del 192.168.110.153 es RST, ACK o lo que es lo mismo: se rechaza una conexión al puerto 21. Probablemente nmap sea un poco persistente y lo intente dos veces antes de aceptar un no como respuesta.

información relacionada