☰

Почему nmap отправляет два пакета для проверки одного порта?

tag-icon • tag-icon nmap
Почему 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

решение1

Похоже, libpcapпроблема с очередями пакетов перед доставкой в ​​Nmap. Обратите внимание на разницу в порядке пакетов между Wireshark и Nmap; хотя временные метки одинаковы, порядок напечатанных строк показывает, что пакеты были доставлены в Nmapпослевторой пакет SYN был отправлен. Недавно у нас был/естьпроблема с libpcap 1.5.3(и, возможно, ветка 1.6, не проверял) на новых ядрах Linux, связанных с пакетным кольцом/интерфейсом TPACKET, не доставляющим пакеты по прибытии. Каков вывод nmap --version?

Основная проблема — это ошибка в Linux, которая былауже исправлено, но не портировано. Мы решили эту проблему в процессе разработки, обновив libpcap до версии 1.7.3, в которой есть некоторые обходные пути.

решение2

Судя по вашему снимку экрана, похоже, что [R.]пакеты фильтруются перед тем, как попасть на машину, с которой вы сканируете, и nmap использует функцию повторной передачи, поскольку первый [S]пакет не получил никакого ответа.

Вы можете отключить это с помощью --max-retries 0.

решение3

Почему nmap отправляет два пакета для проверки одного порта?

Обычно: из-за трехстороннего рукопожатия, необходимого дляустановить TCP-соединение... отправить SYN -> получить SYN-ACK -> отправить ACK

В этом случае: потому что ответ от 192.168.110.153 — RST, ACK или, другими словами: соединение с портом 21 отклонено. Вероятно, nmap немного настойчив и пытается дважды, прежде чем принять ответ «нет».

Связанный контент