UDP ポートのフィルタリングとオープンポートの区別
Felix のスキャンの場合、3つのopen|filteredポート以外は、closedでした。 しかし、必ずしもそうとは限らない。 例5.5は、フィルタリングの厳しいサイト「Scanme」に対するUDPスキャンを示したものである。 UDPスキャン例
krad# Starting Nmap ( http://nmap.org )All 1000 scanned ports on scanme.nmap.org (64.13.134.52) are open|filteredNmap done: 1 IP address (1 host up) scanned in 5.50 seconds
この場合、スキャンはオープンポートをまったく絞り込めず、すべての1000がopen|filteredである。 表5.3「NmapがUDPプローブに対する応答をどのように解釈するか」は、Nmapが特定のポートに対するUDPプローブからの応答を受信できない場合にopen|filtered状態が発生することを示している。 これらのサービスが頻繁に応答しないのは、Nmapが送信する空パケットが無効とみなされるからである。 残念ながら、UDPサービスは一般に、Nmapが常に送信できるような共通の一般的な形式を守るのではなく、独自のパケット構造を定義している。 SNMPパケットは、SunRPC、DHCP、またはDNSリクエストパケットとはまったく異なる。
すべての一般的なUDPサービスに対して適切なパケットを送信するには、Nmapは、そのプローブフォーマットを定義した大規模なデータベースを必要とする。幸いなことに、Nmapはnmap-service-probesの形でそれを備えており、第7章「サービスおよびアプリケーションのバージョン検出」で説明するサービスおよびバージョン検出サブシステムの一部となっている。
バージョンスキャンが-sV(または-A)で有効になっていると、すべてのopen|filteredポートにUDPプローブ(と、既知のopenポート)が送られることになる。 もし、プローブが open|filtered ポートからの応答を引き出すと、状態が open に変更される。 Felixのスキャンに-sVを追加した結果は、例5.6に示すとおりです。 バージョン検出によるFelixのUDPスキャン結果の改善
krad# Starting Nmap ( http://nmap.org )Nmap scan report for felix.nmap.org (192.168.0.42)Not shown: 997 closed portsPORT STATE SERVICE VERSION53/udp open domain ISC BIND 9.2.167/udp open|filtered dhcpserver111/udp open rpcbind 2 (rpc #100000)MAC Address: 00:02:E3:14:11:02 (Lite-on Communications)Nmap done: 1 IP address (1 host up) scanned in 1037.57 seconds
この新しいスキャンでは、ポート111と53は確実に開いていることがわかります。 この特定のケースでは、ポートは開いているが、NmapはDHCP用の動作するバージョンのプローブを持っていない。もう一つの厳しいサービスはSNMPで、これは通常、正しいコミュニティ文字列が与えられたときにのみ応答する。 この結果は完璧ではないが、テストした3つのポートのうち2つの本当の状態を知ることはやはり有益である。 例5.7に示すように、彼はバージョン検出を再度試みます。 バージョン検出によるScanmeのUDPスキャン結果の改善
krad# Starting Nmap ( http://nmap.org )Nmap scan report for scanme.nmap.org (64.13.134.52)Not shown: 999 open|filtered portsPORT STATE SERVICE VERSION53/udp open domain ISC BIND 9.3.4Nmap done: 1 IP address (1 host up) scanned in 3691.89 seconds
Ereet は結局オープンポートを見つけたものの、最初にNmapバージョンを更新しないミスを犯しています。 Nmapバージョン5.10BETA1およびそれ以降のバージョンには、ポートスキャンまたはホスト発見のために選択された場合、3ダース以上のよく知られたUDPポートに適切なサービスプロトコル要求を送信するペイロードシステムが搭載されている。 バージョン検出ほど包括的ではありませんが、例5.5のオープンポート53をすぐに特定できたでしょう。
この結果は、以前のScanmeスキャンの5秒に対して1時間かかりましたが、この結果は実際に役に立ちました。 Ereetは、彼が妥協したいマシンのISC BINDnameserverがオープンであるこの証拠に、微笑みを広げ目を輝かせている。
Ereetは、53番ポートが開いていることが確認されたので、UDP攻撃に集中するが、open|filteredとしてリストされた他の999ポートを忘れることはないだろう。 Felixのdhcpserverポートで目撃したように、特定のオープンUDPサービスは、Nmapのバージョン検出からさえも隠れることができる。 また、これまでデフォルトのポートしかスキャンしていないが、他にも開いている可能性のあるポートが64529個ある。 ちなみに、ScanmeのUDPポートで開いているのは53だけである。 専門的なトレースルートが役に立つこともある。 NmapやNpingのようなツールを使って、既知のオープンなTCPまたはUDPポートに対してtracerouteを実行できる。 ホップ数の違いにより、オープンポートとフィルタリングされたポートを区別することができる。 例5.8では、EreetがScanmeに対してこれを試みている。 最初のコマンドは、既知のオープンポート53に対してUDPトレースルートを実行する。 2番目のコマンドは、推定されるクローズドポート54に対して同じことを行っています。 431>
例5.8.のように、最初の数ホップはスペースを節約するために省略されています。 TTLが不一致のUDPポートの曖昧さ解消の試み
krad# Starting Nping ( http://nmap.org/nping )SENT (7.0370s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=8 id=4826 iplen=28RCVD (7.1010s) ICMP 4.69.134.222 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=248 id=38454 iplen=56SENT (8.0400s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=9 id=38166 iplen=28RCVD (8.1050s) ICMP 4.68.18.204 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=247 id=39583 iplen=56SENT (9.0420s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=10 id=6788 iplen=28RCVD (9.1080s) ICMP 4.59.4.78 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=246 id=59897 iplen=56SENT (10.0440s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=11 id=366 iplen=28RCVD (10.1100s) ICMP 69.36.239.221 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=243 id=42710 iplen=56SENT (11.0470s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=12 id=63478 iplen=28SENT (12.0490s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=13 id=56653 iplen=28Max rtt: 73.003ms | Min rtt: 0.540ms | Avg rtt: 48.731msRaw packets sent: 13 (364B) | Rcvd: 10 (560B) | Lost: 3 (23.08%)Tx time: 12.02836s | Tx bytes/s: 30.26 | Tx pkts/s: 1.08Rx time: 13.02994s | Rx bytes/s: 42.98 | Rx pkts/s: 0.77Nping done: 1 IP address pinged in 13.05 secondskrad# Starting Nping ( http://nmap.org/nping )SENT (7.0370s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=8 id=56481 iplen=28RCVD (7.1130s) ICMP 4.69.134.214 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=248 id=22437 iplen=56SENT (8.0400s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=9 id=23264 iplen=28RCVD (8.1060s) ICMP 4.68.18.76 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=247 id=50214 iplen=56SENT (9.0430s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=10 id=9101 iplen=28RCVD (9.1070s) ICMP 4.59.4.78 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=246 id=880 iplen=56SENT (10.0450s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=11 id=35344 iplen=28RCVD (10.1110s) ICMP 69.36.239.221 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=243 id=44617 iplen=56SENT (11.0470s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=12 id=53857 iplen=28SENT (12.0490s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=13 id=986 iplen=28Max rtt: 76.488ms | Min rtt: 0.546ms | Avg rtt: 48.480msRaw packets sent: 13 (364B) | Rcvd: 11 (616B) | Lost: 2 (15.38%)Tx time: 12.02908s | Tx bytes/s: 30.26 | Tx pkts/s: 1.08Rx time: 13.03165s | Rx bytes/s: 47.27 | Rx pkts/s: 0.84Nping done: 1 IP address pinged in 13.05 seconds
この例では、Ereetは開ポート、閉ポートともに11番目のホップまでしか到達できなかった。 したがって、これらの結果は、このホストに対するポートの状態を区別するために使用することはできない。 これは試してみる価値があり、かなりの数のケースで機能する。 スクリーニングファイアウォールがターゲットホストの少なくとも1〜2ホップ前にあるような状況では、より効果的であると考えられる。 一方、Scanmeは、Linuxiptableshostベースのファイアウォールを独自に実行しています。
もう1つのテクニックは、一般的なポートに対してアプリケーション固有のツールを試してみることである。 たとえば、ブルートフォースSNMPコミュニティ文字列クラッカーは、ポート161に対して試すことができる。 Nmapのバージョン検出プローブデータベースが大きくなるにつれて、外部の特殊なツールで結果を補強する必要性は低くなっている。 これらは、カスタムコミュニティ文字列を持つSNMPデバイスなどの特殊なケースには、依然として有用である
。