web-dev-qa-db-ja.com

Windows 8.1ラップトップでNmap遅いのはなぜですか?

Nmapは非常に遅いため、Windows8.1ラップトップではほとんど使用できません。

Nmap 6.40を使用していますが、同じネットワーク上の他のコンピューターで数分の1秒で実行される簡単なチェックを実行するのに1分以上かかります。他のいくつかのコンピューターを試しました。 Nmapのバージョンが異なる場合でも、ほんの一瞬ですべて同じ結果が得られます。ラップトップで異なるスキャンと異なるターゲットを試しても同じ結果が得られます。一般的に低速のラップトップではありません。コアi7/16GB/SSDなどアプリケーションは十分に高速に実行されます

これはNmapが私のラップトップで言うことです(ホスト名などが変更されました):

C:\Users\colinp>nmap -p4730 target 

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-20 14:28 GMT Standard Time
Nmap scan report for target (192.168.1.1)
Host is up (0.0013s latency).
rDNS record for 192.168.1.1: target
PORT     STATE SERVICE
4730/tcp open  unknown
MAC Address: 2C:76:8A:00:00:00 (Hewlett-Packard Company)

Nmap done: 1 IP address (1 Host up) scanned in 79.92 seconds

C:\Users\colinp>

対同じネットワーク上のUbuntuコンピューターの例:

colin@ubuntu:~$ nmap -p 4730 target 

Starting Nmap 5.21 ( http://nmap.org ) at 2014-03-20 14:29 GMT
Nmap scan report for target (192.168.1.1)
Host is up (0.00044s latency).
rDNS record for 192.168.1.1: target 
PORT     STATE SERVICE
4730/tcp open  unknown

Nmap done: 1 IP address (1 Host up) scanned in 0.03 seconds
colin@ubuntu:~$

編集:私はちょうどかかった時間が別のホストについて疑わしいほど似ていることに気づきました、それが何かを意味するかどうかはわかりません:

C:\Users\colinp>nmap -p4730 target2

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-20 14:47 GMT Standard Time
Nmap scan report for target2 (192.168.1.2)
Host is up (0.00013s latency).
rDNS record for 192.168.1.2: target2
PORT     STATE  SERVICE
4730/tcp closed unknown
MAC Address: 00:25:90:00:00:00 (Super Micro Computer)

Nmap done: 1 IP address (1 Host up) scanned in 79.71 seconds

C:\Users\colinp>

存在しないホストをスキャンしようとすると高速になりますが、3〜16秒の間で大きく異なります。繰り返しますが、ubuntuサーバーでは0.03秒かかります。

私のラップトップでは名前解決は問題ではないようです。nslookupはほぼ瞬時に返されます。


編集:@bonsaivikingによって提案された診断の出力:

C:\Users\colinp>nmap -d -sL target

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-20 16:40 GMT Standard Time
Winpcap present, dynamic linked to: WinPcap version 4.1.2 (packet.dll version 4.
1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008)
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 10, Host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
mass_rdns: Using DNS server 192.168.x.12
mass_rdns: Using DNS server 192.168.x.11
mass_rdns: Using DNS server 192.168.1.254
mass_rdns: Using DNS server 192.168.2.1
mass_rdns: Using DNS server 192.168.x.12
mass_rdns: Using DNS server 192.168.x.11
mass_rdns: Using DNS server 192.168.x.12
mass_rdns: Using DNS server 192.168.x.11
Initiating Parallel DNS resolution of 1 Host. at 16:41
mass_rdns: 52.89s 0/1 [#: 8, OK: 0, NX: 0, DR: 0, SF: 0, TR: 1]
Completed Parallel DNS resolution of 1 Host. at 16:41, 0.00s elapsed
DNS resolution of 1 IPs took 52.90s. Mode: Async [#: 8, OK: 1, NX: 0, DR: 0, SF:
 0, TR: 1, CN: 0]
Nmap scan report for target (192.168.1.1)
rDNS record for 192.168.1.1: target
No data files read.
Nmap done: 1 IP address (0 hosts up) scanned in 53.36 seconds

IPアドレスが再び変更されました。リストされているDNSサーバーのうち、192.168.x.11192.168.x.12は私の実際のDNSサーバーです。他の人がこれに入る場所がわかりません。 ipconfig /allを実行すると、これらはリストされませんが、内部Hyper-Vスイッチへの接続中に次の奇妙なエントリがありました。

   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1

問題がHyper-Vの実行に関連しているかどうかわかりませんか?また、私は積極的にIPv6を無効にしていませんが、それが原因である可能性があるかどうかわかりませんか?


より多くの診断、IPアドレスはまだ隠されており、うまくいけば一貫して...

C:\Users\colinp>nslookup -type=PTR 1.1.168.192.in-addr.arpa
Server:  dns-at-my-company.example.com
Address:  192.168.x.12

1.1.168.192.in-addr.arpa.co.uk
        primary name server = ns1.sedoparking.com
        responsible mail addr = hostmaster.sedo.de
        serial  = 2007021501
        refresh = 86400 (1 day)
        retry   = 10800 (3 hours)
        expire  = 604800 (7 days)
        default TTL = 86400 (1 day)

前のコマンドに.がありませんでした。これは良く見えます:

C:\Users\colinp>nslookup -type=PTR 1.1.168.192.in-addr.arpa.
Server:  dns-at-my-company.example.com
Address:  192.168.x.12

1.1.168.192.in-addr.arpa     name = target
4
Colin Pickard

コメントで解決:Nmapは、並列逆引きDNS解決に使用するDNSサーバーを検出する方法に関する問題です。診断プロセスと最終的な回避策は次のとおりです。

まず、Nmapスキャンのどのフェーズで速度が低下しているのかを判断する必要があります。nmap -p4730 targetはシングルポートTCPスキャンを実行しますが、実行も実行します名前解決(必要な場合)、ホスト検出( "ping")、およびDNS逆引き参照。Nmapはすべてに対して異なるアプローチを使用するため、管理者として実行しているかどうかも知ることが重要です。最良かつ最速のものを使用するための十分な特権がない場合は、これらの手順のうち、次の単一フェーズスキャンを実行して、どのフェーズが遅いフェーズであるかを判別します。

  1. nmap -d -n -Pn -p 4730 target-ポートスキャンフェーズのみ。
  2. nmap -d -n -sn target-ホスト検出フェーズのみ。
  3. nmap -d -sL target-逆引きDNS解決フェーズのみ。

あなたのコメントから、slowpokeは逆DNS解決であると判断しました。 -dフラグを追加すると、Nmapは4つの異なるDNSサーバーを選択していましたが、有効なDNSサーバーは2つだけでした。 Nmapのドキュメント は、--dns-serversオプションを使用して正しいサーバーを指定することを提案していますカンマ区切りのリストで。--system-dnsを使用して、Nmapの並列サーバーの代わりにオペレーティングシステム独自のDNSリゾルバーを使用することもできます。多くのホストのスキャンの場合、これは遅くなる可能性がありますが、ほぼ常に機能することが保証されています。これらのオプションは文書化されています。詳細については、公式 Nmap Network Scanning Gordon "Fyodor" Lyonによる本を参照してください。

最後の回避策は、DNSサーバーのIPアドレスを決定し、それらのサーバーのIPアドレスを使用してNmap with--dns-servers 192.168.X.X,192.168.X.Yを実行することです。

3
bonsaiviking

Windows上のNmapは、Linuxほど効率的ではありません。

Nmapディレクトリにあるnmap_performance.regファイルをダブルクリックすると、接続スキャンのパフォーマンスを向上させることができます。これにより、予約されるエフェメラルポートの数を増やすために3つのレジストリが変更されます。 Nmapなどのアプリケーションの場合は、閉じた接続を再利用できるようになるまでの時間を短縮します。

手作業で変更を加えるには、次の3つのレジストリDWORD値を次のように追加します。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  1. MaxUserPort655340x0000fffeなどの大きな値を設定します)。
  2. TCPTimedWaitDelay:最小値を設定します(0x0000001e)。
  3. StrictTimeWaitSeqCheck1に設定すると、TCPTimedWaitDelayがチェックされます。

nmapサイト から派生した情報。

0
stderr