前書き
インフラストラクチャにファイアウォールを設定することは、サービスに基本的なセキュリティを提供する優れた方法です。 満足できるポリシーを作成したら、次のステップはファイアウォールルールをテストすることです。 ファイアウォールルールが想定どおりに機能しているかどうかを把握し、インフラストラクチャが外の世界にどのように見えるかを把握することが重要です。
このガイドでは、ファイアウォールルールを検証するために使用できるいくつかの簡単なツールとテクニックについて説明します。 これらは、悪意のあるユーザーが使用する可能性のある同じツールの一部であるため、サーバーの要求を行うことで、ユーザーが見つけられる情報を確認できます。
前提条件
このガイドでは、少なくとも1つのサーバーにファイアウォールが構成されていることを前提としています。 これらのガイドの1つ以上に従って、ファイアウォールポリシーの構築を開始できます。
-
Iptables
-
UFW
-
FirewallD
このガイドでは、targetをテストするファイアウォールポリシーを含むサーバーを呼び出します。 ターゲットに加えて、ファイアウォールで保護されているネットワークの外部にある、テストするサーバーにアクセスする必要もあります。 このガイドでは、監査マシンとしてUbuntu 14.04サーバーを使用します。
テストするサーバーと評価するターゲットを作成したら、このガイドに進みます。
警告
[.warning]＃セキュリティ監査の目的で、管理するインフラストラクチャでこのガイドに概説されているアクティビティのみを実行する必要があります。 ポートスキャニングを取り巻く法律は、多くの管轄区域で不明確です。 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開発ライブラリができたので、official siteのダウンロードページから最新バージョンの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スキャンがいくつかあります。 通常最初に開始するのに最適なのは、完全なTCP接続を実際にネゴシエートしないため、「ハーフオープンスキャン」とも呼ばれるSYNスキャンです。 これは、完全なハンドシェイクを完了できないため、一部の侵入検知システムに登録できないため、攻撃者によってよく使用されます。
パケットキャプチャのセットアップ
スキャンする前に、テストによって生成されたトラフィックをキャプチャするようにtcpdumpを設定します。 これは、必要に応じて、後で詳細に送受信されるパケットを分析するのに役立ちます。 SYNスキャンに関連するファイルをまとめて保持できるように、~/scan_results内にディレクトリを作成しましょう。
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：これにより、後で分析するために使用できるファイルに結果が書き込まれます。
Note
[.note]＃覚えておくべきことの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つはtcpdumpの実行によって生成されたpacketsと呼ばれ、もう1つはnmap.resultsと呼ばれるnmapによって生成されます。
最初に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個のポートが閉じられていることもわかります。 別の可能な結果は「フィルタリング」されます。 フィルタ済みとは、これらのポートがネットワークパス上の何かによって停止されていると識別されたことを意味します。 ターゲットのファイアウォールの場合もありますが、監査マシンとターゲットマシンの間の中間ホストのフィルタリングルールの場合もあります。
ターゲットとの間で送受信された実際のパケットトラフィックを確認したい場合は、次のようにpacketsファイルをtcpdumpに読み戻すことができます。
sudo tcpdump -nn -r ~/scan_results/syn_scan/packets | lessこのファイルには、2つのホスト間で行われた会話全体が含まれています。 さまざまな方法でフィルタリングできます。
たとえば、ターゲットへのトラフィックsentのみを表示するには、次のように入力します。
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_scantcpdumpキャプチャを再度開始します。 今回は、ファイルを新しい~/scan_results/udp_scanディレクトリに書き込みます。
sudo tcpdump host target_ip_addr -w ~/scan_results/udp_scan/packetsプロセスを一時停止し、バックグラウンドに配置します。
CTRL-ZbgUDPスキャンを実行する
これで、UDPスキャンを実行する準備が整いました。 UDPプロトコルの性質上、このスキャンは通常、SYNスキャンよりもsignificantly秒長くかかります。 実際、システムのすべてのポートをスキャンしている場合、1日以上かかる可能性があります。 UDPはコネクションレスプロトコルであるため、応答を受信しなかった場合、ターゲットのポートがブロックされているか、受け入れられているか、パケットが失われている可能性があります。 これらを区別するために、nmapは、応答を取得するために追加のパケットを再送信する必要があります。
ほとんどのフラグは、SYNスキャンで使用したものと同じです。 実際、唯一の新しいフラグは次のとおりです。
-
-sU：これはnmapにUDPスキャンを実行するように指示します。
UDPテストの高速化
このテストにかかる時間が心配な場合は、最初にUDPポートのサブセットのみをテストすることをお勧めします。 -p-フラグを省略すると、最も一般的な1000個のポートのみをテストできます。 これにより、スキャン時間が大幅に短縮されます。 ただし、完全な画像が必要な場合は、後で戻ってポート範囲全体をスキャンする必要があります。
独自のインフラストラクチャをスキャンしているため、UDPスキャンを高速化する最適なオプションは、ターゲットシステムでICMPレート制限を一時的に無効にすることです。 通常、LinuxホストはICMP応答を1秒間に1回に制限します（これは通常は良いことですが、監査には適していません）。つまり、完全なUDPスキャンには18時間以上かかります。 次のように入力して、ターゲットマシンでこの設定を確認できます。
sudo sysctl net.ipv4.icmp_ratelimitOutputnet.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=1000tcpdumpパケットキャプチャを停止する
次のように入力して、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は、検出したシグニチャに基づいてオペレーティングシステムを推測していないことがわかります。 より多くの情報を受信した場合、ターゲットマシンの署名がデータベース内のオペレーティングシステムの署名とどのように一致するかを示すさまざまな割合を表示する可能性があります。 TCP/IP fingerprint:の行の下に、ターゲットからnmapが受信した指紋署名が表示されます。
オペレーティングシステムの識別は、攻撃者がシステム上でどのエクスプロイトが有用かを判断するのに役立ちます。 少ない照会に応答するようにファイアウォールを構成すると、これらの検出方法の一部の精度を妨げる可能性があります。
結論
ファイアウォールをテストし、外部の攻撃者に内部ネットワークがどのように見えるかを認識させることで、リスクを最小限に抑えることができます。 独自のインフラストラクチャの調査から得た情報は、セキュリティを強化するためにポリシーの決定を再検討する必要があるかどうかについての会話を開く場合があります。 また、誤ったルールの順序付けやテストポリシーの忘れが原因で発生した可能性のあるセキュリティのギャップも明らかになります。 現在のセキュリティレベルを改善するか、少なくとも維持するために、最新のスキャンデータベースの規則性でポリシーをテストすることをお勧めします。
ファイアウォールのポリシーの改善点については、this guideを確認してください。