序章

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

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

前提条件

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

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

テストするサーバーと評価するターゲットができたら、このガイドを続けることができます。

警告

このガイドで概説されているアクティビティは、セキュリティ監査の目的で、管理しているインフラストラクチャでのみ実行する必要があります。 ポートスキャンを取り巻く法律は、多くの法域で不確実です。 ISPやその他のプロバイダーは、ポートスキャンが見つかったユーザーを禁止することが知られています。

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

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

パケットアナライザ

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

ガイドの目的で、 tcpdump 道具。 これは、強力で柔軟性があり、Linuxシステムに広く普及しているため、優れたオプションです。 後で分析するためにトランスクリプトが必要になった場合に備えて、テストを実行するときに、これを使用して生のパケットをキャプチャします。 他の人気のあるオプションには、Wireshark(または tshark、そのコマンドラインのいとこ)と tcpflow これにより、TCP会話全体を整理された方法でまとめることができます。

ポートスキャナー

パケットアナライザがキャプチャするトラフィックと応答を生成するために、ポートスキャナーを使用します。 ポートスキャナーを使用して、サーバーが受け入れるトラフィックの種類を検出するために、さまざまな種類のパケットを作成してリモートホストに送信できます。 悪意のあるユーザーは、これをエクスプロイトする脆弱なサービスを見つけるための検出ツールとして使用することが多いため(最初にファイアウォールを使用する理由の一部)、攻撃者が何を検出できるかを確認するためにこれを使用します。

このガイドでは、 nmap ネットワークマッピングおよびポートスキャンツール。 使用できます nmap さまざまなタイプのパケットを送信して、ターゲットマシン上にあるサービスと、それを保護するファイアウォールルールを特定しようとします。

監査マシンのセットアップ

始める前に、上記のツールがあることを確認する必要があります。 私たちは手に入れる tcpdump Ubuntuのリポジトリから。 私たちも得ることができます nmap この方法では、リポジトリのバージョンが古くなっている可能性があります。 代わりに、ソフトウェアのコンパイルを支援するためにいくつかのパッケージをインストールし、ソースから自分でビルドします。

ローカルパッケージインデックスを更新し、ソフトウェアがまだ利用できない場合はインストールします。 また、パージします nmap 競合を回避するためにすでにインストールされている場合は、システムから:

  1. sudo apt-get update
  2. sudo apt-get purge nmap
  3. sudo apt-get install tcpdump build-essential libssl-dev

コンパイルツールとSSL開発ライブラリができたので、最新バージョンの nmap 公式サイトのダウンロードページから。 Webブラウザでページを開きます。

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

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

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

  1. cd ~
  2. wget https://nmap.org/dist/nmap-6.49BETA4.tar.bz2

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

  1. tar xjvf nmap*
  2. cd nmap*

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

  1. ./configure
  2. make

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

  1. sudo make install

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

  1. nmap -V

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

Output
Nmap 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

次に、スキャン結果を保存できるディレクトリを作成します。

  1. mkdir ~/scan_results

クリーンな結果を確実に得るには、監査システムとターゲットシステムの間で開いている可能性のあるセッションをすべて終了します。 これには、SSHセッション、Webブラウザで確立した可能性のあるHTTP(S)接続などが含まれます。

ターゲットをスキャンして開いているTCPポートを探します

サーバーとファイルの準備ができたので、まずターゲットホストをスキャンして開いているTCPポートを探します。

実際には、いくつかのTCPスキャンがあります nmap 方法を知っています。 通常、最初に使用するのに最適なのは、SYNスキャンです。これは、実際には完全なTCP接続をネゴシエートすることがないため、「ハーフオープンスキャン」とも呼ばれます。 これは、完全なハンドシェイクを完了しないため、一部の侵入検知システムに登録できないため、攻撃者によってよく使用されます。

パケットキャプチャの設定

スキャンする前に、 tcpdump テストによって生成されたトラフィックをキャプチャします。 これは、必要に応じて、後で送受信されるパケットをより詳細に分析するのに役立ちます。 内にディレクトリを作成しましょう ~/scan_results これにより、SYNスキャンに関連するファイルをまとめて保持できます。

  1. mkdir ~/scan_results/syn_scan

始めることができます tcpdump 結果をキャプチャして、 ~/scan_results/syn_scan 次のコマンドを使用してディレクトリを作成します。

  1. 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:

  1. 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 :これにより出力の冗長性が向上します。
  • -理由:これは nmap ポートの状態が特定の方法で報告された理由を提供するため。
  • -oN :これは、後で分析するために使用できるファイルに結果を書き込みます。

ノート

覚えておくべきことの1つは、IPv6をチェックするには、IPv6を追加する必要があるということです。 -6 コマンドにフラグを立てます。 前提条件のチュートリアルのほとんどはIPv6トラフィックを受け入れないため、このガイドではIPv6をスキップします。 ファイアウォールがIPv6トラフィックを受け入れる場合は、このフラグを追加します。

まとめると、コマンドは次のようになります。

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

タイミングテンプレートが4に設定されている場合でも、スキャンは65,535ポートを実行するため、かなりの時間がかかる可能性があります(私のテスト実行は約40分続きました)。 次のような結果が印刷され始めます。

Output
Starting 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 フォアグラウンドに戻って処理し、停止します。

次のように入力して、背景から外します。

  1. fg

コントロールキーを押しながら「c」を押して、プロセスを停止します。

CTRL-C

結果の分析

これで、2つのファイルが作成されます。 ~/scan_results/syn_scan ディレクトリ。 と呼ばれるもの packets、によって生成されます tcpdump 実行し、によって生成されたもの nmap と呼ばれる nmap.results.

見てみましょう nmap.results 最初のファイル:

  1. 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、 このような:

  1. sudo tcpdump -nn -r ~/scan_results/syn_scan/packets | less

このファイルには、2つのホスト間で行われた会話全体が含まれています。 さまざまな方法でフィルタリングできます。

たとえば、ターゲットに送信されたトラフィックのみを表示するには、次のように入力します。

  1. sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'dst target_ip_addr' | less

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

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

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

  1. sudo tcpdump -nn -r ~/scan_results/syn_scan/packets 'src target_ip_addr and tcp[tcpflags] & tcp-syn != 0' | less

これにより、成功したSYN応答のみが表示され、で表示されたポートと一致する必要があります。 nmap 走る:

Output
reading 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ポートをスキャンできます。

パケットキャプチャの設定

もう一度、結果を保持するディレクトリを作成しましょう。

  1. mkdir ~/scan_results/udp_scan

開始 tcpdump もう一度キャプチャします。 今回は、ファイルを新しいファイルに書き込みます ~/scan_results/udp_scan ディレクトリ:

  1. sudo tcpdump host target_ip_addr -w ~/scan_results/udp_scan/packets

プロセスを一時停止し、バックグラウンドに置きます。

CTRL-Z
  1. bg

UDPスキャンを実行します

これで、UDPスキャンを実行する準備が整いました。 UDPプロトコルの性質上、このスキャンは通常、SYNスキャンよりも大幅に長くかかります。 実際、システムのすべてのポートをスキャンしている場合は、1日以上かかる可能性があります。 UDPはコネクションレス型プロトコルであるため、応答を受信しない場合は、ターゲットのポートがブロックされているか、受け入れられたか、パケットが失われたことを意味する可能性があります。 これらを区別するために、 nmap 応答を得るために、追加のパケットを再送信する必要があります。

ほとんどのフラグは、SYNスキャンに使用したものと同じになります。 実際、新しいフラグは次のとおりです。

  • -sU :これは nmap UDPスキャンを実行します。

UDPテストの高速化

このテストにかかる時間が心配な場合は、最初にUDPポートのサブセットのみをテストすることをお勧めします。 を除外することで、最も一般的な1000個のポートのみをテストできます。 -p- 国旗。 これにより、スキャン時間を大幅に短縮できます。 ただし、全体像が必要な場合は、後で戻ってポート範囲全体をスキャンする必要があります。

独自のインフラストラクチャをスキャンしているため、UDPスキャンを高速化するための最良のオプションは、ターゲットシステムでICMPレート制限を一時的に無効にすることです。 通常、LinuxホストはICMP応答を1秒あたり1に制限します(これは通常は良いことですが、監査には適していません)。つまり、完全なUDPスキャンには18時間以上かかります。 次のように入力して、ターゲットマシンでこの設定を確認できます。

  1. sudo sysctl net.ipv4.icmp_ratelimit
Output
net.ipv4.icmp_ratelimit = 1000

「1000」は、応答間のミリ秒数です。 次のように入力することで、ターゲットシステムでこのレート制限を一時的に無効にできます。

  1. sudo sysctl -w net.ipv4.icmp_ratelimit=0

テスト後にこの値を元に戻すことは非常に重要です。

テストの実行

必ず結果を ~/scan_results/udp_scan ディレクトリ。 まとめると、コマンドは次のようになります。

  1. sudo nmap -sU -Pn -p- -T4 -vv --reason -oN ~/scan_results/udp_scan/nmap.results target_ip_addr

ターゲットでICMPレート制限を無効にしても、このスキャンにはテスト実行中に約2時間45分かかりました。 スキャンが完了したら、ターゲットマシンのICMPレート制限(変更した場合)を元に戻す必要があります。

  1. sudo sysctl -w net.ipv4.icmp_ratelimit=1000

tcpdumpパケットキャプチャを停止します

持って来ます tcpdump 次のように入力して、監査マシンのフォアグラウンドに戻ります。

  1. fg

コントロールを押しながら「c」を押して、パケットキャプチャを停止します。

CTRL-c

結果の分析

これで、生成されたファイルを確認できます。

結果として nmap.results ファイルは、前に見たものとかなり似ているはずです。

  1. 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要求に一致させる必要があるため、出力は非常に困難です。

どのように見ることができます nmap として報告されたポートに多くのパケットを送信する必要がありました open|filtered 報告されたポートの1つへのUDPトラフィックを確認するように依頼する。

  1. sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets 'udp and port 22'

次のようなものが表示される可能性があります。

Output
reading 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つから見た結果と比較してください。

  1. sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets 'udp and port 53'
Output
reading 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)

プロセスを手動で再構築することを試みることができます nmap 最初に、UDPパケットを送信するすべてのポートのリストを次のようなものを使用してコンパイルします。

  1. 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パケットを確認できます。

  1. 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パケットを確認できます。

  1. comm -3 outgoing response

これは、ほとんどの場合、 nmap 報告されました(失われたリターンパケットからの誤検知が含まれている可能性があります)。

ホストとサービスの発見

ターゲットに対していくつかの追加のテストを実行して、それが可能かどうかを確認できます。 nmap 実行中のオペレーティングシステムまたはサービスバージョンのいずれかを識別するため。

バージョン管理の結果を保持するディレクトリを作成しましょう。

  1. mkdir ~/scan_results/versions

サーバー上のサービスのバージョンの検出

フィンガープリントと呼ばれるプロセスを通じて、ターゲットで実行されているサービスのバージョンを推測することができます。 サーバーから情報を取得し、データベース内の既知のバージョンと比較します。

A tcpdump このシナリオではあまり役に立たないので、スキップできます。 とにかくキャプチャしたい場合は、前回使用したプロセスに従ってください。

The nmap 使用する必要のあるスキャンは、 -sV 国旗。 すでにSYNおよびUDPスキャンを実行しているため、確認したい正確なポートを渡すことができます。 -p 国旗。 ここでは、22と80(SYNスキャンで表示されたポート)を確認します。

  1. sudo nmap -sV -Pn -p 22,80 -vv --reason -oN ~/scan_results/versions/service_versions.nmap target_ip_addr

結果のファイルを表示すると、サービスの「おしゃべり」やサービスの応答の一意性に応じて、実行中のサービスに関する情報が得られる場合があります。

  1. 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」)。 完全なコマンドは次のようになります。

  1. sudo nmap -O -Pn -vv --reason -oN ~/scan_results/versions/os_version.nmap target_ip_addr

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

  1. 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: ライン。

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

結論

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

ファイアウォールのポリシーの改善点については、このガイドをご覧ください。