SANSインターネットストームセンターのハンドラであるRob VandenBrinkが、Nmap 5.21の新機能について報告している。（掲載日：米国時間　2010年2月1日）

問題に取り組む前に、UDPポートスキャンが通常どのように行われているかを論じておこう。

UDPパケットを受信した端末は、そのポートがオープンしていないと、ICMP Port Unreachable(ICMP Type 3, Code 3)で応答する。ポートがオープンしている場合には、データが該当のアプリケーションに渡され、処理が行われる。アプリケーションが、データを理解できない場合は、エラーを応答する場合もあるが、パケットはドロップされ全く応答されないことが多い。 ホスト上、あるいはネットワークの経路で、ファイアウォールが介入した場合は、まず全く応答がない。

つまり、ポートがオープンしている場合と、ファイアウォールがドロップする場合は、ポートスキャナーにとって同じに見えるのだ。これは、UDPポートスキャンを行った場合に問題となる。サービスが起動されポートがオープンしていても、ファイアウォールでドロップされている場合と区別がつかないからだ。

ここで問題に戻ろう。UDPプロトコルを認識できると、例えばUDP/DNSのポートスキャンを行った場合は、実際のDNSリクエストになる。UDP/NTPのポートスキャンを行った場合は、NTPタイムスタンプやタイムリクエストになる。ポートがオープンしていると、アプリケーションは有効なデータを受信するため、ポートスキャナーは応答が得られ、該当ポートがオープンしているということに確信が持てる。

実演してみよう。NTPサーバのUDP/NTPポートに、古いバージョンのNmap(5.0)でポートスキャンを行う。この動作は、多くのポートスキャナーに共通するものだ。

# nmap -sU -p 123 172.17.130.122
Starting Nmap 5.00 ( http://insecure.org/ ) at 2010-02-05 15:45 JST
Interesting ports on 172.17.130.122:
PORT    STATE         SERVICE
123/udp open|filtered ntp
Nmap done: 1 IP address (1 host up) scanned in 0.379 seconds

御覧のように、ポートはopen/filteredと表示される。下記のパケットトレースから、データを含まないパケット(有効なNTPデータを含まない)がUDP/123に送信され、NTPサーバがパケットをドロップしていることが分かる。実際に、NTPサーバは稼働しているのだが、このスキャン手法では、それが分からない。

2010-02-05 15:45:19.093351 172.17.104.147 -> 172.17.130.122 NTP [Malformed Packet]
2010-02-05 15:45:19.203174 172.17.104.147 -> 172.17.130.122 NTP [Malformed Packet]

今度は、UDPプロトコルを認識するNmap 5.2を使用して、同様のスキャンを行ってみる。

# nmap -sU  -p 123 172.17.130.122
Starting Nmap 5.21 ( http://nmap.org/ ) at 2010-02-05 15:54 JST
Stats: 0:00:00 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan
UDP Scan Timing: About 100.00% done; ETC: 15:54 (0:00:00 remaining)
Nmap scan report for 172.17.130.122
Host is up (0.00025s latency).
PORT    STATE SERVICE
123/udp open  ntp

違いは明らかだ。open/filteredではなく、openと表示される。パケットをトレースし、詳細を調べてみよう。

2010-02-05 15:54:40.575404 172.17.104.147 -> 172.17.130.122 NTP NTP client
2010-02-05 15:54:40.575645 172.17.130.122 -> 172.17.104.147 NTP NTP server

Network Time Protocol
    Flags: 0xe3
        11.. .... = Leap Indicator: alarm condition (clock not synchronized) (3)
        ..10 0... = Version number: NTP Version 4 (4)
        .... .011 = Mode: client (3)
    Peer Clock Stratum: unspecified or unavailable (0)
    Peer Polling Interval: 4 (16 sec)
    Peer Clock Precision: 0.015625 sec
    Root Delay:    1.0000 sec
    Root Dispersion:    1.0000 sec
    Reference Clock ID: NULL
    Reference Clock Update Time: NULL
    Originate Time Stamp: NULL
    Receive Time Stamp: NULL
    Transmit Time Stamp: Nov 24, 2004 15:12:11.4441 UTC

御覧のように、Nmapは有効なNTPクライアントタイムスタンプをNTPサーバへ送信し、NTPサーバから応答を受けている。サーバの該当ポートはオープンしており、NTPサービスが有効になっているということが分かるはずだ。

なお、現状Nmap 5.21は下記のUDPプロトコルをサポートしている。
udp/7           echo
udp/53        domain
udp/111      rpcbind
udp/123      ntp
udp/137      netbios-ns
udp/161      SNMP
udp/177      xdmcp
udp/500      ISAKMP
udp/520      route
udp/1645 and udp/1812   RADIUS
udp/2049    NFS
udp/5353    zeroconf
udp/10080 amanda
  
これは素晴らしい進歩だ。以前よりも、ずっと正確なスキャンが特定のポートに対し実行できるようになる。

原文：http://isc.sans.org/diary.html?storyid=8110

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Nmapの開発が引き続き活発のようだ。前回リリースされたNmap 5.0では、cat(NmapプロジェクトによるNetcatの再実装)、Ndiff(Nmapスキャンの結果比較ツール)の新規ツール追加や、大幅なパフォーマンスの改善等が行われたが、今回のNmap 5.2でも多くの機能強化が行われているようだ。

詳細に関しては、下記のリリースノートを参照してほしい。

http://seclists.org/nmap-hackers/2010/0