NmapとTcpdumpを使用してファイアウォール構成をテストする方法
序章
インフラストラクチャにファイアウォールを設定することは、サービスに基本的なセキュリティを提供するための優れた方法です。 満足のいくポリシーを作成したら、次のステップはファイアウォールルールをテストすることです。 ファイアウォールルールが実行していると思うことを実行しているかどうかを把握し、インフラストラクチャが外の世界にどのように見えるかを把握することが重要です。
このガイドでは、ファイアウォールルールの検証に使用できるいくつかの簡単なツールと手法について説明します。 これらは悪意のあるユーザーが使用する可能性のある同じツールの一部であるため、サーバーにリクエストを送信することで、悪意のあるユーザーがどのような情報を見つけることができるかを確認できます。
前提条件
このガイドでは、少なくとも1台のサーバーにファイアウォールが構成されていることを前提としています。 次のガイドの1つ以上に従うことで、ファイアウォールポリシーの作成を開始できます。
- Iptables
- UFW
- FirewallD
このガイドでは、targetをテストするファイアウォールポリシーを含むサーバーを呼び出します。 ターゲットに加えて、ファイアウォールが保護するネットワークの外部にある、テスト対象のサーバーにアクセスする必要もあります。 このガイドでは、監査マシンとしてUbuntu14.04サーバーを使用します。
テストするサーバーと評価するターゲットができたら、このガイドを続けることができます。
警告
このガイドで概説されているアクティビティは、セキュリティ監査の目的で、管理しているインフラストラクチャでのみ実行する必要があります。 ポートスキャンを取り巻く法律は、多くの法域で不確実です。 ISPやその他のプロバイダーは、ポートスキャンが見つかったユーザーを禁止することが知られています。
ファイアウォールポリシーのテストに使用するツール
ファイアウォールポリシーをテストするために使用できるツールはかなりたくさんあります。 それらのいくつかは重複する機能を持っています。 考えられるすべてのツールを網羅するわけではありません。 代わりに、監査ツールのいくつかの一般的なカテゴリをカバーし、このガイドで使用するツールについて説明します。
パケットアナライザ
パケットアナライザを使用すると、インターフェイスを通過するすべてのネットワークトラフィックを詳細に監視できます。 ほとんどのパケットアナライザには、リアルタイムで動作するオプション、送受信されたパケットを表示するオプション、またはパケット情報をファイルに書き込んで後で処理するオプションがあります。 パケット分析により、ターゲットマシンがオープンネットワーク上のホストにどのような種類の応答を送り返しているかを詳細なレベルで確認できます。
このガイドでは、tcpdumpツールを使用します。 これは、強力で柔軟性があり、Linuxシステムに広く普及しているため、優れたオプションです。 後で分析するためにトランスクリプトが必要になった場合に備えて、テストを実行するときに、これを使用して生のパケットをキャプチャします。 その他の一般的なオプションには、Wireshark（またはtshark、そのコマンドラインのいとこ）およびtcpflowがあり、TCP会話全体を整理された方法でまとめることができます。
ポートスキャナー
パケットアナライザがキャプチャするトラフィックと応答を生成するために、ポートスキャナーを使用します。 ポートスキャナーを使用して、サーバーが受け入れるトラフィックの種類を検出するために、さまざまな種類のパケットを作成してリモートホストに送信できます。 悪意のあるユーザーは、これをエクスプロイトする脆弱なサービスを見つけるための検出ツールとして使用することが多いため（最初にファイアウォールを使用する理由の一部）、攻撃者が何を検出できるかを確認するためにこれを使用します。
このガイドでは、nmapネットワークマッピングおよびポートスキャンツールを使用します。 nmapを使用してさまざまなタイプのパケットを送信し、ターゲットマシン上にあるサービスと、それを保護するファイアウォールルールを特定することができます。
監査マシンのセットアップ
始める前に、上記のツールがあることを確認する必要があります。 Ubuntuのリポジトリからtcpdumpを入手できます。 この方法でnmapを取得することもできますが、リポジトリのバージョンが古くなっている可能性があります。 代わりに、ソフトウェアのコンパイルを支援するためにいくつかのパッケージをインストールし、ソースから自分でビルドします。
ローカルパッケージインデックスを更新し、ソフトウェアがまだ利用できない場合はインストールします。 また、競合を回避するために、システムがすでにインストールされている場合は、システムからnmapを削除します。
sudo apt-get update sudo apt-get purge nmap sudo apt-get install tcpdump build-essential libssl-dev
コンパイルツールとSSL開発ライブラリができたので、公式サイトのダウンロードページからnmapの最新バージョンを入手できます。 Webブラウザでページを開きます。
「ソースコードの配布」セクションまで下にスクロールします。 下部に、最新バージョンのnmapのソースコードへのリンクが表示されます。 この記事の執筆時点では、次のようになっています。
リンクを右クリックして、リンクアドレスをコピーします。
監査マシンに戻り、ホームディレクトリに移動し、wgetを使用して貼り付けたリンクをダウンロードします。 サイトからコピーした最新バージョンを反映するように、以下のリンクを更新してください。
cd ~ wget https://nmap.org/dist/nmap-6.49BETA4.tar.bz2
ダウンロードしたファイルを解凍し、次のように入力して、結果のディレクトリに移動します。
tar xjvf nmap* cd nmap*
次のように入力して、ソースコードを構成およびコンパイルします。
./configure make
コンパイルが完了したら、次のように入力して、結果の実行可能ファイルとサポートファイルをシステムにインストールできます。
sudo make install
次のように入力して、インストールを確認します。
nmap -V
出力は、nmapWebサイトからダウンロードしたバージョンと一致する必要があります。
OutputNmap version 6.49BETA4 ( https://nmap.org ) Platform: x86_64-unknown-linux-gnu Compiled with: nmap-liblua-5.2.3 openssl-1.0.1f nmap-libpcre-7.6 nmap-libpcap-1.7.3 nmap-libdnet-1.12 ipv6 Compiled without: Available nsock engines: epoll poll select
次に、スキャン結果を保存できるディレクトリを作成します。
mkdir ~/scan_results
クリーンな結果を確実に得るには、監査システムとターゲットシステムの間で開いている可能性のあるセッションをすべて終了します。 これには、SSHセッション、Webブラウザで確立した可能性のあるHTTP（S）接続などが含まれます。
ターゲットをスキャンして開いているTCPポートを探します
サーバーとファイルの準備ができたので、まずターゲットホストをスキャンして開いているTCPポートを探します。
nmapが実行方法を知っているTCPスキャンが実際にいくつかあります。 通常、最初に使用するのに最適なのは、SYNスキャンです。これは、実際には完全なTCP接続をネゴシエートすることがないため、「ハーフオープンスキャン」とも呼ばれます。 これは、完全なハンドシェイクを完了しないため、一部の侵入検知システムに登録できないため、攻撃者によってよく使用されます。
パケットキャプチャの設定
スキャンする前に、テストによって生成されたトラフィックをキャプチャするようにtcpdumpを設定します。 これは、必要に応じて、後で送受信されるパケットをより詳細に分析するのに役立ちます。 ~/scan_results内にディレクトリを作成して、SYNスキャンに関連するファイルをまとめて保持できるようにします。
mkdir ~/scan_results/syn_scan
次のコマンドを使用して、tcpdumpキャプチャを開始し、結果を~/scan_results/syn_scanディレクトリ内のファイルに書き込むことができます。
sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets
デフォルトでは、tcpdumpはフォアグラウンドで実行されます。 同じウィンドウでnmapスキャンを実行するには、tcpdumpプロセスを一時停止してから、バックグラウンドで再起動する必要があります。
CTRL-Zを押すと、実行中のプロセスを一時停止できます。
CTRL-Z
これにより、実行中のプロセスが一時停止します。
Output^Z [1]+ Stopped sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets
これで、bgと入力して、バックグラウンドでジョブを再開できます。
bg
同様の出力行が表示されますが、今回は「Stopped」ラベルがなく、プロセスがバックグラウンドで実行されることを示すために最後にアンパサンドが付いています。
Output[1]+ sudo tcpdump host target_ip_addr -w ~/scan_results/syn_scan/packets &
コマンドはバックグラウンドで実行され、監査マシンとターゲットマシンの間を通過するパケットを監視しています。 これで、SYNスキャンを実行できます。
SYNスキャンを実行します
tcpdumpがターゲットマシンへのトラフィックを記録すると、nmapを実行する準備が整います。 次のフラグを使用して、nmapに必要なアクションを実行させます。
- -sS ：これはSYNスキャンを開始します。 これは技術的には、スキャンタイプが指定されていない場合に
nmapが実行するデフォルトのスキャンですが、明示的に示すためにここに含めます。 - -Pn ：これは、
nmapにホスト検出ステップをスキップするように指示します。これにより、ホストがpingに応答しない場合、テストが早期に中止されます。 ターゲットがオンラインであることがわかっているので、これをスキップできます。 - -p- ：デフォルトでは、SYNスキャンは最も一般的に使用される1000個のポートのみを試行します。 これは、
nmapに使用可能なすべてのポートをチェックするように指示します。 - -T4 ：これは、
nmapのタイミングプロファイルを設定し、結果の精度がわずかに低下するリスクを冒してテストを高速化するように指示します。 0が最も遅く、5が最も速くなります。 すべてのポートをスキャンしているため、これをベースラインとして使用し、誤って報告された可能性のあるポートを後で再確認できます。 - -vv ：これにより出力の冗長性が向上します。
- -reason ：これは、
nmapに、ポートの状態が特定の方法で報告された理由を提供するように指示します。 - -oN ：これは、後で分析するために使用できるファイルに結果を書き込みます。
ノート
覚えておくべきことの1つは、IPv6をチェックするために、コマンドに-6フラグを追加する必要があるということです。 前提条件のチュートリアルのほとんどはIPv6トラフィックを受け入れないため、このガイドではIPv6をスキップします。 ファイアウォールがIPv6トラフィックを受け入れる場合は、このフラグを追加します。
まとめると、コマンドは次のようになります。
sudo nmap -sS -Pn -p- -T4 -vv --reason -oN ~/scan_results/syn_scan/nmap.results target_ip_addr
タイミングテンプレートが4に設定されている場合でも、スキャンは65,535ポートを実行するため、かなりの時間がかかる可能性があります（私のテスト実行は約40分続きました）。 次のような結果が印刷され始めます。
OutputStarting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-08-26 16:54 EDT Initiating Parallel DNS resolution of 1 host. at 16:54 Completed Parallel DNS resolution of 1 host. at 16:54, 0.12s elapsed Initiating SYN Stealth Scan at 16:54 Scanning 198.51.100.15 [65535 ports] Discovered open port 22/tcp on 198.51.100.15 Discovered open port 80/tcp on 198.51.100.15 SYN Stealth Scan Timing: About 6.16% done; ETC: 17:02 (0:07:52 remaining) SYN Stealth Scan Timing: About 8.60% done; ETC: 17:06 (0:10:48 remaining) . . .
tcpdumpパケットキャプチャを停止します
スキャンが完了したら、tcpdumpプロセスをフォアグラウンドに戻して停止できます。
次のように入力して、背景から外します。
fg
コントロールキーを押しながら「c」を押して、プロセスを停止します。
CTRL-C
結果の分析
これで、~/scan_results/syn_scanディレクトリに2つのファイルが作成されます。 1つはpacketsと呼ばれ、tcpdumpの実行によって生成され、もう1つはnmapによって生成されたnmap.resultsと呼ばれます。
最初にnmap.resultsファイルを見てみましょう。
less ~/scan_results/syn_scan/nmap.results
〜/ scan_results / syn_scan / nmap.results
# Nmap 6.49BETA4 scan initiated Wed Aug 26 17:05:13 2015 as: nmap -sS -Pn -p- -T4 -vv --reason -oN /home/user/scan_results/syn_scan/nmap.results 198.51.100.15 Increasing send delay for 198.51.100.15 from 0 to 5 due to 9226 out of 23064 dropped probes since last increase. Increasing send delay for 198.51.100.15 from 5 to 10 due to 14 out of 34 dropped probes since last increase. Nmap scan report for 198.51.100.15 Host is up, received user-set (0.00097s latency). Scanned at 2015-08-26 17:05:13 EDT for 2337s Not shown: 65533 closed ports Reason: 65533 resets PORT STATE SERVICE REASON 22/tcp open ssh syn-ack ttl 63 80/tcp open http syn-ack ttl 63 Read data files from: /usr/local/bin/../share/nmap # Nmap done at Wed Aug 26 17:44:10 2015 -- 1 IP address (1 host up) scanned in 2336.85 seconds
上の強調表示された領域には、スキャンの主な結果が含まれています。 SSHおよびHTTPトラフィックを許可するために、スキャンされたホストでポート22とポート80が開いていることがわかります。 65,533個のポートが閉じられていることもわかります。 もう1つの考えられる結果は、「フィルタリング」されます。 フィルタ済みとは、これらのポートがネットワークパスに沿った何かによって停止されていると識別されたことを意味します。 ターゲット上のファイアウォールである可能性がありますが、監査マシンとターゲットマシン間の任意の中間ホストでルールをフィルタリングしている可能性もあります。
ターゲットとの間で送受信された実際のパケットトラフィックを確認したい場合は、次のようにpacketsファイルをtcpdumpに読み戻すことができます。
sudo tcpdump -nn -r ~/scan_results/syn_scan/packets | less
このファイルには、2つのホスト間で行われた会話全体が含まれています。 さまざまな方法でフィルタリングできます。
たとえば、ターゲットに送信されたトラフィックのみを表示するには、次のように入力します。
sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'dst target_ip_addr' | less
同様に、応答トラフィックのみを表示するには、「dst」を「src」に変更します。
sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src target_ip_addr' | less
開いているTCPポートは、SYNパケットでこれらの要求に応答します。 次のようなフィルターを使用して、このタイプの応答を直接検索できます。
sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src target_ip_addr and tcp[tcpflags] & tcp-syn != 0' | less
これにより、成功したSYN応答のみが表示され、nmapの実行で表示されたポートと一致する必要があります。
Outputreading from file packets, link-type EN10MB (Ethernet) 17:05:13.557597 IP 198.51.100.15.22 > 198.51.100.2.63872: Flags [S.], seq 2144564104, ack 4206039348, win 29200, options [mss 1460], length 0 17:05:13.558085 IP 198.51.100.15.80 > 198.51.100.2.63872: Flags [S.], seq 3550723926, ack 4206039348, win 29200, options [mss 1460], length 0
必要に応じて、データの分析をさらに行うことができます。 非同期処理と分析のためにすべてキャプチャされています。
ターゲットをスキャンして開いているUDPポートを探します
これらのテストの実行方法を適切に理解できたので、同様のプロセスを完了して、開いているUDPポートをスキャンできます。
パケットキャプチャの設定
もう一度、結果を保持するディレクトリを作成しましょう。
mkdir ~/scan_results/udp_scan
tcpdumpキャプチャを再度開始します。 今回は、ファイルを新しい~/scan_results/udp_scanディレクトリに書き込みます。
sudo tcpdump host target_ip_addr -w ~/scan_results/udp_scan/packets
プロセスを一時停止し、バックグラウンドに置きます。
CTRL-Z
bg
UDPスキャンを実行します
これで、UDPスキャンを実行する準備が整いました。 UDPプロトコルの性質上、このスキャンは通常、SYNスキャンよりも大幅に長くかかります。 実際、システムのすべてのポートをスキャンしている場合は、1日以上かかる可能性があります。 UDPはコネクションレス型プロトコルであるため、応答を受信しない場合は、ターゲットのポートがブロックされているか、受け入れられたか、パケットが失われたことを意味する可能性があります。 これらを区別するために、nmapは追加のパケットを再送信して、応答を取得しようとする必要があります。
ほとんどのフラグは、SYNスキャンに使用したものと同じになります。 実際、新しいフラグは次のとおりです。
- -sU ：これは
nmapにUDPスキャンを実行するように指示します。
UDPテストの高速化
このテストにかかる時間が心配な場合は、最初にUDPポートのサブセットのみをテストすることをお勧めします。 -p-フラグを省略すると、最も一般的な1000個のポートのみをテストできます。 これにより、スキャン時間を大幅に短縮できます。 ただし、全体像が必要な場合は、後で戻ってポート範囲全体をスキャンする必要があります。
独自のインフラストラクチャをスキャンしているため、UDPスキャンを高速化するための最良のオプションは、ターゲットシステムでICMPレート制限を一時的に無効にすることです。 通常、LinuxホストはICMP応答を1秒あたり1に制限します（これは通常は良いことですが、監査には適していません）。つまり、完全なUDPスキャンには18時間以上かかります。 次のように入力して、ターゲットマシンでこの設定を確認できます。
sudo sysctl net.ipv4.icmp_ratelimit
Outputnet.ipv4.icmp_ratelimit = 1000
「1000」は、応答間のミリ秒数です。 次のように入力することで、ターゲットシステムでこのレート制限を一時的に無効にできます。
sudo sysctl -w net.ipv4.icmp_ratelimit=0
テスト後にこの値を元に戻すことは非常に重要です。
テストの実行
結果は必ず~/scan_results/udp_scanディレクトリに書き込んでください。 まとめると、コマンドは次のようになります。
sudo nmap -sU -Pn -p- -T4 -vv --reason -oN ~/scan_results/udp_scan/nmap.results target_ip_addr
ターゲットでICMPレート制限を無効にしても、このスキャンにはテスト実行中に約2時間45分かかりました。 スキャンが完了したら、ターゲットマシンのICMPレート制限（変更した場合）を元に戻す必要があります。
sudo sysctl -w net.ipv4.icmp_ratelimit=1000
tcpdumpパケットキャプチャを停止します
次のように入力して、tcpdumpプロセスを監査マシンのフォアグラウンドに戻します。
fg
コントロールを押しながら「c」を押して、パケットキャプチャを停止します。
CTRL-c
結果の分析
これで、生成されたファイルを確認できます。
結果のnmap.resultsファイルは、前に見たものとかなり似ているはずです。
less ~/scan_results/udp_scan/nmap.results
〜/ scan_results / udp_scan / nmap.results
# Nmap 6.49BETA4 scan initiated Thu Aug 27 12:42:42 2015 as: nmap -sU -Pn -p- -T4 -vv --reason -oN /home/user/scan_results/udp_scan/nmap.results 198.51.100.15 Increasing send delay for 198.51.100.15 from 0 to 50 due to 10445 out of 26111 dropped probes since last increase. Increasing send delay for 198.51.100.15 from 50 to 100 due to 11 out of 23 dropped probes since last increase. Increasing send delay for 198.51.100.15 from 100 to 200 due to 3427 out of 8567 dropped probes since last increase. Nmap scan report for 198.51.100.15 Host is up, received user-set (0.0010s latency). Scanned at 2015-08-27 12:42:42 EDT for 9956s Not shown: 65532 closed ports Reason: 65532 port-unreaches PORT STATE SERVICE REASON 22/udp open|filtered ssh no-response 80/udp open|filtered http no-response 443/udp open|filtered https no-response Read data files from: /usr/local/bin/../share/nmap # Nmap done at Thu Aug 27 15:28:39 2015 -- 1 IP address (1 host up) scanned in 9956.97 seconds
この結果と以前のSYNの結果の主な違いは、open|filteredとマークされたポートの数である可能性があります。 これは、nmapが、応答の欠如がサービスがトラフィックを受け入れたことを意味するのか、それとも配信パスに沿ったファイアウォールまたはフィルタリングメカニズムによってドロップされたのかを判断できなかったことを意味します。
tcpdump出力の分析も、接続フラグがなく、ICMP応答をUDP要求に一致させる必要があるため、非常に困難です。
報告されたポートの1つへのUDPトラフィックを確認するように依頼することで、nmapがopen|filteredとして報告されたポートに多くのパケットを送信する必要があったことがわかります。
sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets 'udp and port 22'
次のようなものが表示される可能性があります。
Outputreading from file /home/user/scan_results/udp_scan/packets, link-type EN10MB (Ethernet) 14:57:40.801956 IP 198.51.100.2.60181 > 198.51.100.15.22: UDP, length 0 14:57:41.002364 IP 198.51.100.2.60182 > 198.51.100.15.22: UDP, length 0 14:57:41.202702 IP 198.51.100.2.60183 > 198.51.100.15.22: UDP, length 0 14:57:41.403099 IP 198.51.100.2.60184 > 198.51.100.15.22: UDP, length 0 14:57:41.603431 IP 198.51.100.2.60185 > 198.51.100.15.22: UDP, length 0 14:57:41.803885 IP 198.51.100.2.60186 > 198.51.100.15.22: UDP, length 0
これを、「閉じた」とマークされたスキャンされたポートの1つから見た結果と比較してください。
sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets 'udp and port 53'
Outputreading from file /home/user/scan_results/udp_scan/packets, link-type EN10MB (Ethernet) 13:37:24.219270 IP 198.51.100.2.60181 > 198.51.100.15.53: 0 stat [0q] (12)
次のようなものを使用して、UDPパケットを送信するすべてのポートのリストを最初にコンパイルすることにより、nmapが通過するプロセスを手動で再構築することができます。
sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets "udp" | awk '{print $5;}' | awk 'BEGIN { FS = "." } ; { print $5 +0}' | sort -u | tee outgoing
次に、ポートに到達できなかったと言って受信したICMPパケットを確認できます。
sudo tcpdump -nn -Q in -r ~/scan_results/udp_scan/packets "icmp" | awk '{print $10,$11}' | grep unreachable | awk '{print $1}' | sort -u | tee response
次に、これら2つの応答を取得し、次のように入力することで、ICMP応答を受信しなかったUDPパケットを確認できます。
comm -3 outgoing response
これは、nmapが報告したポートのリストとほぼ一致するはずです（失われたリターンパケットからの誤検知が含まれている可能性があります）。
ホストとサービスの発見
ターゲットに対していくつかの追加テストを実行して、nmapが実行中のオペレーティングシステムまたはサービスバージョンのいずれかを識別できるかどうかを確認できます。
バージョン管理の結果を保持するディレクトリを作成しましょう。
mkdir ~/scan_results/versions
サーバー上のサービスのバージョンの検出
フィンガープリントと呼ばれるプロセスを通じて、ターゲットで実行されているサービスのバージョンを推測することができます。 サーバーから情報を取得し、データベース内の既知のバージョンと比較します。
tcpdumpはこのシナリオではあまり役に立たないので、スキップできます。 とにかくキャプチャしたい場合は、前回使用したプロセスに従ってください。
使用する必要のあるnmapスキャンは、-sVフラグによってトリガーされます。 すでにSYNおよびUDPスキャンを実行しているため、-pフラグを使用して確認する正確なポートを渡すことができます。 ここでは、22と80（SYNスキャンで表示されたポート）を確認します。
sudo nmap -sV -Pn -p 22,80 -vv --reason -oN ~/scan_results/versions/service_versions.nmap target_ip_addr
結果のファイルを表示すると、サービスの「おしゃべり」やサービスの応答の一意性に応じて、実行中のサービスに関する情報が得られる場合があります。
less ~/scan_results/versions/service_versions.nmap
〜/ scan_results / versions / service_versions.nmap
# Nmap 6.49BETA4 scan initiated Thu Aug 27 15:46:12 2015 as: nmap -sV -Pn -p 22,80 -vv --reason -oN /home/user/scan_results/versions/service_versions.nmap 198.51.100.15 Nmap scan report for 198.51.100.15 Host is up, received user-set (0.0011s latency). Scanned at 2015-08-27 15:46:13 EDT for 8s PORT STATE SERVICE REASON VERSION 22/tcp open ssh syn-ack ttl 63 OpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0) 80/tcp open http syn-ack ttl 63 nginx 1.4.6 (Ubuntu) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Read data files from: /usr/local/bin/../share/nmap Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Thu Aug 27 15:46:21 2015 -- 1 IP address (1 host up) scanned in 8.81 seconds
ここでは、テストでSSHサーバーのバージョンとそれをパッケージ化したLinuxディストリビューション、および受け入れられたSSHプロトコルのバージョンを識別できたことがわかります。 また、Nginxのバージョンを認識し、Ubuntuパッケージと一致するものとして再度識別しました。
ホストオペレーティングシステムの検出
nmapに、ソフトウェアの特性と応答に基づいてホストオペレーティングシステムを推測させることもできます。 これは、サービスのバージョン管理とほとんど同じように機能します。 繰り返しになりますが、このテストではtcpdumpの実行を省略しますが、必要に応じて実行できます。
オペレーティングシステムの検出を実行するために必要なフラグは、-O（大文字の「O」）です。 完全なコマンドは次のようになります。
sudo nmap -O -Pn -vv --reason -oN ~/scan_results/versions/os_version.nmap target_ip_addr
出力ファイルを表示すると、次のようなものが表示される場合があります。
less ~/scan_results/versions/os_version.nmap
〜/ scan_results / versions / os_versions.nmap
# Nmap 6.49BETA4 scan initiated Thu Aug 27 15:53:54 2015 as: nmap -O -Pn -vv --reason -oN /home/user/scan_results/versions/os_version.nmap 198.51.100.15 Increasing send delay for 198.51.100.15 from 0 to 5 due to 65 out of 215 dropped probes since last increase. Increasing send delay for 198.51.100.15 from 5 to 10 due to 11 out of 36 dropped probes since last increase. Increasing send delay for 198.51.100.15 from 10 to 20 due to 11 out of 35 dropped probes since last increase. Increasing send delay for 198.51.100.15 from 20 to 40 due to 11 out of 29 dropped probes since last increase. Increasing send delay for 198.51.100.15 from 40 to 80 due to 11 out of 31 dropped probes since last increase. Nmap scan report for 198.51.100.15 Host is up, received user-set (0.0012s latency). Scanned at 2015-08-27 15:53:54 EDT for 30s Not shown: 998 closed ports Reason: 998 resets PORT STATE SERVICE REASON 22/tcp open ssh syn-ack ttl 63 80/tcp open http syn-ack ttl 63 No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=6.49BETA4%E=4%D=8/27%OT=22%CT=1%CU=40800%PV=N%DS=2%DC=I%G=Y%TM=55 OS:DF6AF0%P=x86_64-unknown-linux-gnu)SEQ(SP=F5%GCD=1%ISR=106%TI=Z%CI=Z%TS=8 OS:)OPS(O1=M5B4ST11NW8%O2=M5B4ST11NW8%O3=M5B4NNT11NW8%O4=M5B4ST11NW8%O5=M5B OS:4ST11NW8%O6=M5B4ST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120 OS:)ECN(R=Y%DF=Y%T=40%W=7210%O=M5B4NNSNW8%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+ OS:%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=) OS:T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A OS:=Z%F=R%O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPC OS:K=G%RUCK=G%RUD=G)U1(R=N)IE(R=N) Uptime guess: 1.057 days (since Wed Aug 26 14:32:23 2015) Network Distance: 2 hops TCP Sequence Prediction: Difficulty=245 (Good luck!) IP ID Sequence Generation: All zeros Read data files from: /usr/local/bin/../share/nmap OS detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Thu Aug 27 15:54:24 2015 -- 1 IP address (1 host up) scanned in 30.94 seconds
この場合、nmapは、見たシグニチャに基づいてオペレーティングシステムを推測していないことがわかります。 より多くの情報を受け取った場合は、ターゲットマシンのシグネチャがデータベース内のオペレーティングシステムのシグネチャとどのように一致するかを示すさまざまなパーセンテージが表示される可能性があります。 nmapがターゲットから受信した指紋署名をTCP/IP fingerprint:行の下に表示します。
オペレーティングシステムの識別は、攻撃者がシステムでどのエクスプロイトが役立つかを判断するのに役立ちます。 より少ない問い合わせに応答するようにファイアウォールを構成すると、これらの検出方法の一部の精度を妨げる可能性があります。
結論
ファイアウォールをテストし、内部ネットワークが外部の攻撃者にどのように見えるかを認識させることで、リスクを最小限に抑えることができます。 独自のインフラストラクチャを調査して見つけた情報は、セキュリティを強化するためにポリシー決定のいずれかを再検討する必要があるかどうかについての会話を開く可能性があります。 また、ルールの順序が正しくないか、テストポリシーを忘れたために発生した可能性のある、セキュリティのギャップを明らかにする場合もあります。 現在のセキュリティレベルを向上させる、または少なくとも維持するために、最新のスキャンデータベースの規則性を使用してポリシーをテストすることをお勧めします。
ファイアウォールのポリシーの改善点については、このガイドをご覧ください。
