2

I run nmap with root privileges using sudo so I assume it has full access to creat raw sockets. Wireshark shows two packets used to test a single port when I used the command

sudo nmap 192.168.110.153 -p21

Is that normal behavior? why?

enter image description here

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
Matka
  • 107
  • 1
  • 12

3 Answers3

2

It looks like a libpcap problem with queuing packets before delivering them to Nmap. Notice the difference in ordering of packets between Wireshark and Nmap; even though the timestamps are the same, the order of printed lines shows that the packets were delivered to Nmap after the second SYN packet was sent. We recently had/have a problem with libpcap 1.5.3 (and possibly the 1.6 branch, haven't tested) on newer Linux kernels related to the packet ring/TPACKET interface not delivering packets when they arrive. What's the output of nmap --version?

The underlying problem is a bug in Linux, which was already fixed but not backported. We solved this issue in development by upgrading libpcap to version 1.7.3, which has some workarounds.

bonsaiviking
  • 4,420
  • 17
  • 26
  • Nmap version 6.40 ( http://nmap.org ) Platform: x86_64-pc-linux-gnu Compiled with: liblua-5.2.3 openssl-1.0.1f libpcre-8.31 libpcap-1.5.3 nmap-libdnet-1.12 ipv6 Compiled without: Available nsock engines: epoll poll select – Matka May 19 '15 at 23:37
  • 1
    @Matka Yes, that exactly matches what I'd expect to see from this bug. You can try compiling from source yourself, since our included libpcap seems to be unaffected. – bonsaiviking May 20 '15 at 01:35
  • compiling from source solved that! Thank you very much – Matka May 20 '15 at 10:31
1

Given you screenshot, it seems that [R.] packets are filtered before hitting the machine you are scanning from and nmap used its retransmission feature since the first [S] packet didn't received any answer.

You can disable this using --max-retries 0.

Xavier Lucas
  • 13,095
  • 2
  • 44
  • 50
0

Why does nmap send two packets in order to test a single port?

Normally: because of the three-way handshake required to establish a TCP connection ... send SYN -> receive SYN-ACK -> send ACK

In this case: because the response from 192.168.110.153 is RST, ACK or in other words: a connection to port 21 is rejected. Probably nmap is slightly persistent and tries twice before taking no as an answer.

HBruijn
  • 77,029
  • 24
  • 135
  • 201