前書き

インフラストラクチャにファイアウォールを設定することは、サービスに基本的なセキュリティを提供する優れた方法です。 満足できるポリシーを作成したら、次のステップはファイアウォールルールをテストすることです。 ファイアウォールルールが想定どおりに機能しているかどうかを把握し、インフラストラクチャが外の世界にどのように見えるかを把握することが重要です。

このガイドでは、ファイアウォールルールを検証するために使用できるいくつかの簡単なツールとテクニックについて説明します。 これらは、悪意のあるユーザーが使用する可能性のある同じツールの一部であるため、サーバーの要求を行うことで、ユーザーが見つけられる情報を確認できます。

前提条件

このガイドでは、少なくとも1つのサーバーにファイアウォールが構成されていることを前提としています。 これらのガイドの1つ以上に従って、ファイアウォールポリシーの構築を開始できます。

このガイドでは、*ターゲット*をテストするファイアウォールポリシーを含むサーバーを呼び出します。 ターゲットに加えて、ファイアウォールで保護されているネットワークの外部にある、テストするサーバーにアクセスする必要もあります。 このガイドでは、監査マシンとしてUbuntu 14.04サーバーを使用します。

テストするサーバーと評価するターゲットを作成したら、このガイドに進みます。

警告

ファイアウォールポリシーのテストに使用するツール

ファイアウォールポリシーをテストするために使用できるツールはかなり多数あります。 それらの一部には重複する機能があります。 すべての可能なツールを網羅しているわけではありません。 代わりに、監査ツールの一般的なカテゴリをいくつか取り上げ、このガイドで使用するツールについて説明します。

パケットアナライザー

パケットアナライザーを使用して、インターフェイスを通過するすべてのネットワークトラフィックを詳細に監視できます。 ほとんどのパケットアナライザーには、リアルタイムで動作する、送信または受信されるパケットを表示する、またはパケット情報をファイルに書き込んで後で処理するオプションがあります。 パケット分析を使用すると、ターゲットマシンがオープンネットワーク上のホストに返送する応答の種類を詳細なレベルで確認できます。

このガイドでは、 `+ 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開発ライブラリが用意できたので、https://nmap.org/download.html [公式サイト]のダウンロードページから `+ nmap +`の最新バージョンを入手できます。 Webブラウザーでページを開きます。

「ソースコードの配布」セクションまでスクロールします。 下部には、最新バージョンの `+ nmap +`のソースコードへのリンクが表示されます。 この記事の執筆時点では、次のようになっています。

image:https://assets.digitalocean.com/articles/firewall_testing/nmap_latest.png [Nmap最新バージョン]

リンクを右クリックして、リンクアドレスをコピーします。

監査マシンに戻り、ホームディレクトリに移動し、「+ wget +」を使用して貼り付けたリンクをダウンロードします。 以下のリンクを更新して、サイトからコピーした最新バージョンを反映してください。

cd ~
wget https://nmap.org/dist/.tar.bz2

次のように入力して、ダウンロードしたファイルを解凍し、結果のディレクトリに移動します。

tar xjvf nmap*
cd nmap*

次のように入力して、ソースコードを構成およびコンパイルします。

./configure
make

コンパイルが完了したら、次のように入力して、システムに結果の実行可能ファイルとサポートファイルをインストールできます。

sudo make install

次を入力して、インストールを確認します。

nmap -V

出力は、 + nmap + Webサイトからダウンロードしたバージョンと一致する必要があります。

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  -w ~/scan_results/syn_scan/packets

デフォルトでは、 `+ tcpdump `はフォアグラウンドで実行されます。 同じウィンドウで「 nmap 」スキャンを実行するには、「 tcpdump +」プロセスを一時停止してからバックグラウンドで再起動する必要があります。

`+ CTRL-Z +`を押すことで実行中のプロセスを一時停止できます:

CTRL-Z

これにより、実行中のプロセスが一時停止します。

Output^Z
[1]+  Stopped                 sudo tcpdump host  -w ~/scan_results/syn_scan/packets

これで、 `+ bg +`を入力してバックグラウンドでジョブを再開できます:

bg

同様の出力行が表示されるはずです。今回は「Stopped」ラベルがなく、最後にアンパサンドが付いており、プロセスがバックグラウンドで実行されることを示しています。

Output[1]+ sudo tcpdump host  -w ~/scan_results/syn_scan/packets &

現在、コマンドはバックグラウンドで実行されており、監査マシンとターゲットマシンの間を通過するパケットを監視しています。 これで、SYNスキャンを実行できます。

SYNスキャンを実行する

トラフィックをターゲットマシンに記録する「+ tcpdump 」で、「 nmap 」を実行する準備ができました。 次のフラグを使用して ` nmap +`を取得し、必要なアクションを実行します。

  • * + -sS + *:これはSYNスキャンを開始します。 これは技術的には、スキャンタイプが指定されていない場合に `+ nmap +`が実行するデフォルトのスキャンですが、ここでは明示するために含めます。

  • * + -Pn + *:これは、ホストがpingに応答しない場合、テストを早期に中止するホスト検出ステップをスキップするように+ nmap + `に指示します。 ターゲットがオンラインであることはわかっているため、これはスキップできます。

  • * + -p- + *:デフォルトでは、SYNスキャンは最も一般的に使用される1000個のポートのみを試行します。 これは、利用可能なすべてのポートをチェックするように「+ nmap +」に指示します。

  • * + -T4 + *:これにより、 `+ nmap +`のタイミングプロファイルが設定され、結果の精度がやや低下するリスクを伴いながらテストを高速化するように指示されます。 0が最も遅く、5が最速です。 すべてのポートをスキャンしているため、これをベースラインとして使用し、誤って報告された可能性のあるポートを後で再確認できます。

  • * + -vv + *:これにより、出力の詳細度が上がります。

  • * +-reason + *:これは、ポートの状態が特定の方法で報告された理由を提供するように「+ nmap +」に指示します。

  • * + -oN + *:これは結果をファイルに書き込み、後で分析するために使用できます。

Note

一緒に、コマンドは次のようになります。

sudo nmap -sS -Pn -p- -T4 -vv --reason -oN ~/scan_results/syn_scan/nmap.results

タイミングテンプレートを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つのファイルがあるはずです。 ` tcpdump `の実行によって生成される ` packets `と呼ばれるものと、 ` 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






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 ' | less

同様に、応答トラフィックのみを表示するには、「dst」を「src」に変更できます。

sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src ' | less

開いているTCPポートは、これらの要求にSYNパケットで応答します。 次のようなフィルターを使用して、このタイプの応答を直接検索できます。

sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src  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  -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

ターゲットの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 +」は、応答の欠如がサービスがトラフィックを受け入れることを意味したのか、それとも配信パスに沿ったファイアウォールまたはフィルタリングメカニズムによってドロップされたのかを判断できなかったことを意味します。

接続フラグがなく、ICMP応答をUDP要求に一致させる必要があるため、「+ tcpdump +」出力の分析も非常に困難です。

報告されたポートの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

結果のファイルを表示すると、「チャット」の程度や、サービスの応答の一意性に応じて、実行中のサービスに関する情報を取得できます。

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
80/tcp open  http    syn-ack ttl 63
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

出力ファイルを表示すると、次のようなものが表示される場合があります。

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:+`行の下にあるターゲットから受け取った指紋の署名を見ることができます。

オペレーティングシステムの識別は、攻撃者がシステム上でどのエクスプロイトが有用かを判断するのに役立ちます。 少ない照会に応答するようにファイアウォールを構成すると、これらの検出方法の一部の精度を妨げる可能性があります。

結論

ファイアウォールをテストし、外部の攻撃者に内部ネットワークがどのように見えるかを認識させることで、リスクを最小限に抑えることができます。 独自のインフラストラクチャを調査して得た情報は、セキュリティを強化するためにポリシーの決定を再検討する必要があるかどうかについての会話を開く場合があります。 また、誤ったルールの順序付けやテストポリシーの忘れによって発生した可能性のあるセキュリティのギャップを明らかにすることもあります。 現在のセキュリティレベルを改善する、または少なくとも維持するために、最新のスキャンデータベースの規則性でポリシーをテストすることをお勧めします。

ファイアウォールのポリシーの改善点については、https://www.digitalocean.com/community/tutorials/how-to-choose-an-effective-firewall-policy-to-secure-your-servers [このガイド]。