Почему Nmap отправляет два пакета для проверки одного порта
Я запускаю nmap с правами root с помощью sudo, поэтому я предполагаю, что он имеет полный доступ к созданным необработанным сокетам. Wireshark показывает два пакета, используемых для тестирования одного порта, когда я использовал команду
sudo nmap 192.168.110.153 -p21
Это нормальное поведение? Зачем?
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
Похоже на libpcap проблема с постановкой пакетов в очередь перед их доставкой в Nmap. Обратите внимание на разницу в порядке пакетов между Wireshark и Nmap; хотя метки времени совпадают, порядок выводимых строк показывает, что пакеты были доставлены в Nmap. после второй SYN-пакет был отправлен. Недавно у нас был / есть проблема с libpcap 1.5.3 (и, возможно, ветвь 1.6, не тестировалась) на новых ядрах Linux, связанных с пакетным кольцом / интерфейсом TPACKET, которые не доставляют пакеты, когда они приходят. Какой результат nmap --version?
Основная проблема - ошибка в Linux, которая была уже исправлено, но не поддерживается. Мы решили эту проблему в процессе разработки, обновив libpcap до версии 1.7.3, которая имеет некоторые обходные пути.
Учитывая ваш скриншот, кажется, что [R.] пакеты фильтруются перед попаданием на машину, с которой вы сканируете, и Nmap использовал функцию повторной передачи с момента первого [S] пакет не получил ответа.
Вы можете отключить это, используя --max-retries 0.
Почему Nmap отправляет два пакета для тестирования одного порта?
Обычно: из-за трехстороннего рукопожатия, необходимого для установить TCP-соединение ... отправить SYN -> получить SYN-ACK -> отправить ACK
В данном случае: потому что ответ от 192.168.110.153 RST, ACK или другими словами: соединение с портом 21 отклонено. Возможно, Nmap немного настойчив и пытается дважды, прежде чем принять отрицательный ответ.