NmapとTcpdumpを使用してファイアウォールの設定をテストする方法

紹介

インフラストラクチャーのためにファイアウォールを設定することは、サービスのセキュリティを確保する素晴らしい方法です。設定ポリシーが完成したら、次のステップはファイアウォールのルールをテストすることです。ファイアウォールのルールが期待通りに機能しているかどうかを把握し、自分のインフラストラクチャーが外部の世界にどのように映っているかを把握することは重要です。

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

前提条件

このガイドでは、少なくとも1つのサーバーにファイアウォールが設定されていると仮定します。次のガイドのいずれかを1つ以上参考にして、ファイアウォールポリシーの構築を始めることができます。

• IptablesIptables Essentials: Common Firewall Rules and Commands
• UFWHow To Set Up a Firewall with UFW on Ubuntu 22.04
  UFW Essentials: Common Firewall Rules and Commands
• FirewallDHow To Set Up a Firewall Using FirewallD on Rocky Linux 9

あなたは、デジタルオーシャンのインフラストラクチャ上でサーバーの外部レイヤーとして動作するデジタルオーシャンのクラウドファイアウォールも設定することができます。これにより、サーバー自体にファイアウォールを設定する必要がありません。

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

サーバーテスト用に使用できるサーバーと評価したい対象があれば、このガイドを進めることができます。

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

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

パケット解析ツール

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

このガイドでは、tcpdumpツールを使用します。これは、Linuxシステムで強力で柔軟性があり、至る所で使用されているため、良い選択肢です。後の分析のためにトランスクリプトが必要になる場合に、テストを実行している間生のパケットをキャプチャするために使用します。他の人気のある選択肢には、Wireshark（またはそのコマンドラインの相互作用であるtshark）や、整理された形式で完全なTCP会話を組み立てることができるtcpflowがあります。

ポートスキャナー

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

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

監査機械の設定

始める前に、必要なツールがインストールされていることを確認してください。tcpdumpとnmapはUbuntuのリポジトリから入手できます。ローカルパッケージリストを更新するためにapt updateを実行し、apt installを使用してそれらをインストールしてください。

1. sudo apt update
2. sudo apt install tcpdump nmap

 

次に、スキャン結果を保存できるディレクトリを作成してください。

1. mkdir ~/scan_results

 

クリーンな結果を確保するためには、監査システムとターゲットシステムの間に開いているセッションを終了させてください。これには、SSHセッション、ウェブブラウザで確立したHTTP(S)接続などが含まれます。

オープンなTCPポートをスキャンして、ターゲットを調べてください。 (Ōpun na TCP pōto o sukyan shite, tāgetto o shirabete kudasai.)

サーバーとファイルが準備できたので、まずはターゲットホストのオープンなTCPポートをスキャンします。

実際には、nmapが知っているいくつかのTCPスキャンがあります。通常は最初に行うのは、SYNスキャンと呼ばれるもので、実際には完全なTCP接続の交渉を行いませんので「半開スキャン」とも呼ばれます。これはしばしば攻撃者によって使用されるため、完全なハンドシェイクを完了させないため特定の侵入検知システムに登録されず、検知されないことがあります。

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

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

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」を押すことで、実行中のプロセスを一時停止することができます。

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

今、背景で仕事を再開するために「bg」と入力することができます。

1. bg

 

同様の出力行を受け取るべきですが、今回は「Stopped」というラベルはなく、プロセスがバックグラウンドで実行されることを示すために末尾にアンパサンドがつきます（つまり、ターミナルをブロックしなくなります）。

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

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

SYNスキャンを実行してください。

対象のマシンへのトラフィックをtcpdumpで記録し、nmapを実行する準備ができました。以下のフラグを使用してnmapを実行できます：

• -sS: This starts a SYN scan. This is technically the default scan that nmap will perform if no scan type is given, but we will include it here to be explicit.
• -Pn: This tells nmap to skip the host discovery step, which would abort the test early if the host doesn’t respond to a ping. Since you know that the target is online, you can skip this.
• -p-: By default, SYN scans will only try the 1000 most commonly used ports. This tells nmap to check every available port.
• -T4: This sets a timing profile for nmap, telling it to speed up the test at the risk of slightly less accurate results. 0 is the slowest and 5 is the fastest. Since you’re scanning every port, you can use this as your baseline and re-check any ports later that might have been reported incorrectly.
• -vv: This increases the verbosity of the output.
• –reason: This tells nmap to provide the reason that a port’s state was reported a certain way.
• -oN: This writes the results to a file that you can use for later analysis.

一緒に、コマンドはこんな感じになります。

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

 

タイミングテンプレートを4で設定しても、65,535のポートを走査するためかなりの時間がかかる可能性があります。このような形で結果が印刷され始めます。

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2022-12-19 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コマンドを実行してください。

1. fg

 

Ctrl+Cを押して、実行中のプロセスを停止してください。

結果の分析

今、~/scan_results/syn_scanディレクトリには2つのファイルがあるはずです。1つはtcpdump実行によって生成されたpacketsという名前のファイルであり、もう1つはnmapによって生成されたnmap.resultsという名前のファイルです。

最初にnmap.resultsファイルを見てみましょう。

1. less ~/scan_results/syn_scan/nmap.results

 

# Nmap 6.49BETA4 scan initiated Mon Dec 19 17:05:13 2022 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 2022-12-19 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 Mon Dec 19 17:44:10 2022 -- 1 IP address (1 host up) scanned in 2336.85 seconds

上記のハイライトされた範囲には、スキャンの主な結果が含まれています。スキャン対象のホストでは、SSHおよびHTTPトラフィックを許可するため、ポート22およびポート80が開いていることが推測できます。また、閉じられているポートは65,533個あることも確認できます。別の可能な結果は「フィルタリングされた」となります。フィルタリングされたとは、これらのポートがネットワーク経路上の何かによってブロックされたことを意味します。対象のファイアウォールであるかもしれませんし、監査機と対象機の間の中間ホストのいずれかにおけるフィルタリングルールである可能性もあります。

実際に送受信されたパケットトラフィックを確認するには、次のようにパケットファイルをtcpdumpに読み込むことで可能です。

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

 

このファイルには、二人のホスト間で行われた全ての会話が含まれています。様々な方法で絞り込むことができます。

例えば、ターゲットに送信されるトラフィックのみを表示するには、次のように入力することができます:

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

 

SYN パケットによって、オープンな TCP ポートはこれらのリクエストに応答します。このタイプの応答を直接検索するには、次のようなフィルターを使用できます。

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

 

これにより、成功したSYN応答のみが表示され、nmap実行時に見たポートと一致するはずです。

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ポートのスキャンを行うことができます。

パケットキャプチャの設定を行う

もう一度、結果を保持するためのディレクトリを作成してください。 (Mōichido, kekka o hoji suru tame no direkutori o sakusei shite kudasai.)

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 を入力してバックグラウンドに移動させてください。その後、bgコマンドを実行してください。

1. bg

 

UDPスキャンを実行する

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

SYNスキャンと同じく、ほとんどのフラグが同じであることが予想されます。実際、新しいフラグはたった一つのみです。

• -sU: This tells nmap to perform a UDP scan.

UDPテストの速度を向上させる

もしテストにかかる時間が心配なら、最初はあなたのUDPポートのうちの一部をテストすることをお勧めします。-p-フラグを省略することで、よく使われる1000のポートだけをテストできます。これにより、スキャン時間をかなり短縮することができます。ただし、完全な情報を得たい場合は、後で全ポートをスキャンする必要があります。

自分自身のインフラストラクチャをスキャンしているため、UDPスキャンを高速化するためには、ターゲットシステムで一時的にICMPのレート制限を無効にするのが最善の選択肢かもしれません。通常、LinuxホストはICMPの応答を1秒ごとに制限しています（これは通常は良いことですが、監査の場合はそうではありません）。これにより、完全なUDPスキャンには18時間以上かかる可能性があります。ターゲットマシンの設定を確認するには、以下のコマンドを入力してください。

1. sudo sysctl net.ipv4.icmp_ratelimit

 

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 のレートリミットを元に戻してください（変更した場合）。

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

 

tcpdumpのパケットキャプチャを停止してください。

監査マシン上で実行中のtcpdumpプロセスを前面に戻すために、fgを実行してください。

1. fg

 

では、Ctrl+Cでパケットのキャプチャを停止してください。

結果の分析

今、生成されたファイルをご覧いただけます。

生成されるnmap.resultsファイルは、前回の結果に似ているはずです。

1. less ~/scan_results/udp_scan/nmap.results

 

# Nmap 6.49BETA4 scan initiated Mon Dec 19 12:42:42 2022 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 2022-12-19 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 Mon Dec 19 15:28:39 2022 -- 1 IP address (1 host up) scanned in 9956.97 seconds

この結果と以前のSYN結果との主な違いは、おそらくオープン/フィルタされたポートの数です。つまり、nmapが応答がないことがトラフィックを受け入れるサービスであるか、それとも配信経路上のファイアウォールやフィルタリングメカニズムによってドロップされたかを判断できなかったことを意味します。

tcpdumpの出力を分析することは、接続フラグがないために著しく難しくなりますし、またICMPの応答をUDPのリクエストに一致させる必要があるためです。

オープン|フィルターされたと報告されたポートへのUDPトラフィックを表示することで、nmapが送信しなければならなかったパケットの数を確認することができます。

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

 

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

スキャンされたポートのうち、”closed” とマークされた結果と比較してください。

1. sudo tcpdump -nn -Q out -r ~/scan_results/udp_scan/packets ‘udp and port 53’

 

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)

このような方法で、最初にUDPパケットを送信する全ポートのリストを作成し、nmapが経過するプロセスを手動で再構築してみることができます。

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

 

サーバー上のサービスのバージョンを発見する

ターゲット上で実行されているサービスのバージョンを推測することができます。これは「フィンガープリント」として知られるプロセスによって行われます。サーバーから情報を取得し、それを私たちのデータベース内の既知のバージョンと比較します。

このシナリオでは、tcpdumpはあまり役に立たないので、スキップしても構いません。それにも関わらず、キャプチャーしたい場合は、前回と同じプロセスに従ってください。

必要な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

 

If you check the generated file, you might obtain details about the running service depending on the level of communication in the service’s response.

1. less ~/scan_results/versions/service_versions.nmap

 

# Nmap 6.49BETA4 scan initiated Mon Dec 19 15:46:12 2022 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 2022-12-19 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 Mon Dec 19 15:46:21 2022 -- 1 IP address (1 host up) scanned in 8.81 seconds

こちらでは、テストがSSHサーバーのバージョンやそれにパッケージ化されたLinuxディストリビューション、またSSHプロトコルのバージョンを特定することができました。また、Nginxのバージョンも認識し、Ubuntuパッケージと一致することも判明しました。

ホストオペレーティングシステムを発見する

次のように日本語で言い換えます：
ホストのオペレーティングシステムをnmapにソフトウェアの特徴と応答に基づいて推測させることができます。これはサービスバージョン識別と同じ方法で機能します。もう一度言いますが、このテストではtcpdumpの実行は省略しますが、お好みで実行することができます。

To detect the operating system, you should use the flag -O in your command. The letter “O” should be capitalized. A complete command example could be:
「オペレーティングシステムの検出には、フラグとして-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

 

# Nmap 6.49BETA4 scan initiated Mon Dec 19 15:53:54 2022 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 2022-12-19 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 Mon Dec 12 14:32:23 2022)
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 Mon Dec 12 15:54:24 2022 -- 1 IP address (1 host up) scanned in 30.94 seconds

この場合、Nmapは、見たシグネチャに基づいてオペレーティングシステムに関する推測を持っていないことがわかります。より多くの情報を受け取った場合、Nmapはおそらく、ターゲットマシンのシグネチャがデータベース内のオペレーティングシステムのシグネチャとどの程度一致するかを示すさまざまなパーセンテージが表示されるでしょう。ターゲットからNmapが受け取ったフィンガープリントシグネチャは、TCP/IPフィンガープリントの下に表示されています。

オペレーティングシステムの識別は、攻撃者がシステム上で役立つ可能性のあるエクスプロイトを特定するのに役立ちます。ファイアウォールの設定を変更して、問い合わせに対する応答を減らすことで、これらの検知方法の正確性を妨害することができます。

結論

ファイアウォールのテストや内部ネットワークが外部攻撃者にどのように見えるかを把握することは、リスクを最小限に抑えるのに役立ちます。自社インフラの調査から得られる情報は、セキュリティを向上させるために政策の見直しが必要かどうかの議論のきっかけを作るかもしれません。また、誤ったルールの順序やテストポリシーの忘れが原因で発生したセキュリティのギャップが明らかになるでしょう。最新のスキャンデータベースを使用して定期的にポリシーをテストすることは、現在のセキュリティレベルを改善または維持するために推奨されます。

ファイアウォールの方針改善のアイデアを得るために、このガイドを参考にしてください。