☰

Por que o nmap envia dois pacotes para testar uma única porta?

tag-icon • tag-icon nmap
Por que o nmap envia dois pacotes para testar uma única porta?

Eu executo o nmap com privilégios de root usando sudo, então presumo que ele tenha acesso total para criar soquetes brutos. Wireshark mostra dois pacotes usados ​​para testar uma única porta quando usei o comando

sudo nmap 192.168.110.153 -p21

Esse é um comportamento normal? por que?

insira a descrição da imagem aqui

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

Responder1

Parece um libpcapproblema com o enfileiramento de pacotes antes de entregá-los ao Nmap. Observe a diferença na ordem dos pacotes entre o Wireshark e o Nmap; mesmo que os carimbos de data e hora sejam iguais, a ordem das linhas impressas mostra que os pacotes foram entregues ao Nmapdepoiso segundo pacote SYN foi enviado. Recentemente tivemos/temos umproblema com libpcap 1.5.3(e possivelmente a ramificação 1.6, não testada) em kernels Linux mais recentes relacionados à interface anel de pacotes/TPACKET que não entrega pacotes quando eles chegam. Qual é a saída de nmap --version?

O problema subjacente é um bug no Linux, que foijá corrigido, mas não portado. Resolvemos esse problema no desenvolvimento atualizando o libpcap para a versão 1.7.3, que possui algumas soluções alternativas.

Responder2

Dada a captura de tela, parece que [R.]os pacotes são filtrados antes de atingir a máquina da qual você está digitalizando e o nmap usou seu recurso de retransmissão, pois o primeiro [S]pacote não recebeu nenhuma resposta.

Você pode desativar isso usando --max-retries 0.

Responder3

Por que o nmap envia dois pacotes para testar uma única porta?

Normalmente: por causa do handshake de três vias necessário paraestabelecer uma conexão TCP... enviar SYN -> receber SYN-ACK -> enviar ACK

Neste caso: porque a resposta de 192.168.110.153 é RST, ACK ou em outras palavras: uma conexão à porta 21 foi rejeitada. Provavelmente o nmap é um pouco persistente e tenta duas vezes antes de aceitar um não como resposta.

informação relacionada