☰

nmap が 1 つのポートをテストするために 2 つのパケットを送信するのはなぜですか

tag-icon • tag-icon nmap
nmap が 1 つのポートをテストするために 2 つのパケットを送信するのはなぜですか

私はsudoを使ってルート権限でnmapを実行しているので、rawソケットを作成するための完全なアクセス権を持っていると想定しています。Wiresharkは、次のコマンドを使用したときに、1つのポートをテストするために使用された2つのパケットを表示します。

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

これは、パケットを Nmap に配信する前にキューに入れることに問題があるようですlibpcap。Wireshark と Nmap のパケットの順序の違いに注意してください。タイムスタンプは同じですが、印刷された行の順序から、パケットが Nmap に配信されたことがわかります。後2番目のSYNパケットが送信されました。最近、libpcap 1.5.3 の問題(おそらく 1.6 ブランチも、テストしていません) 新しい Linux カーネルでは、パケット リング/TPACKET インターフェイスがパケットが到着しても配信しないことに関連しています。 の出力は何ですかnmap --version?

根本的な問題はLinuxのバグであり、すでに修正されているがバックポートされていない開発段階では、libpcap をバージョン 1.7.3 にアップグレードすることでこの問題を解決しました。このバージョンにはいくつかの回避策があります。

答え2

スクリーンショットを見ると、[R.]パケットはスキャン元のマシンに到達する前にフィルタリングされ、最初の[S]パケットが応答を受信しなかったため、nmap は再送信機能を使用したようです。

これを無効にするには を使用します--max-retries 0。

答え3

nmap が 1 つのポートをテストするために 2 つのパケットを送信するのはなぜですか?

通常：3ウェイハンドシェイクが必要なためTCP接続を確立する... SYN を送信 -> SYN-ACK を受信 -> ACK を送信

この場合、192.168.110.153 からの応答が拒否されるためRST, ACK 、言い換えると、ポート 21 への接続が拒否されます。おそらく、nmap は少し粘り強く、答えとして「いいえ」を受け取る前に 2 回試行します。

関連情報