ウェブサイト検索

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

紹介

インフラストラクチャのためにファイアウォールを設定することは、サービスのセキュリティを提供するための素晴らしい方法です。満足のいくポリシーを開発したら、次のステップはファイアウォールのルールをテストすることです。ファイアウォールのルールが自分が考えている通りに機能しているかどうかの良いアイデアを得ることと、インフラストラクチャが外部の世界にどのように見えるかの印象を得ることが重要です。

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

前提条件

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

  • Iptables

    • iptablesの基本: 一般的なファイアウォールルールとコマンド

  • UFW

    • Ubuntu 22.04でUFWを使ってファイアウォールを設定する方法
    • UFWエッセンシャル: 一般的なファイアウォールルールとコマンド

  • FirewallD

    • Rocky Linux 9でFirewallDを使用してファイアウォールを設定する方法

DigitalOceanのクラウドファイアウォールを設定することもできます。これはDigitalOceanのインフラ上のサーバーに追加の外部レイヤーとして機能します。この方法では、サーバー自体にファイアウォールを設定する必要がありません。

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

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

警告

このガイドに記載されている活動は、セキュリティ監査の目的であなたが管理しているインフラストラクチャ上でのみ実行すべきです。ポートスキャンに関する法律は多くの法域で不確実です。ISPや他のプロバイダーは、ポートスキャンを行っていることが判明したユーザーを禁止することがあります。

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

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

パケットアナライザ

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

このガイドの目的のために、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ポートをスキャンします

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

実際、nmapが実行できるTCPスキャンは数種類あります。通常、最初に試すべき最適なものは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を押すことで一時停止できます:

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

今、bgと入力することでバックグラウンドでジョブを再起動できます:

  1. bg

類似の出力行を受け取るべきです。今回は「停止」といったラベルがなく、プロセスがバックグラウンドで実行されることを示すために最後にアンパサンドが付いています（つまり、もはやターミナルをブロックしていません）:

[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: これは結果をファイルに書き込むもので、後で分析に使用できます。

注意： IPv6を確認するには、コマンドに-6フラグを追加する必要があります…

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

  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ディレクトリには、tcpdumpによって生成されたpacketsというファイルと、nmapによって生成されたnmap.resultsというファイルの2つがあるはずです。

まずは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

上記のハイライトされた領域は、スキャンの主な結果を含んでいます。スキャンされたホストでポート22とポート80がSSHおよびHTTPトラフィックを許可するために開いていることが推測できます。また、65,533のポートが閉じていることも観察できます。別の可能な結果は「フィルタリング中」です。フィルタリング中とは、これらのポートがネットワークパスに沿って何かによって停止されていることを示しています。それはターゲット上のファイアウォールかもしれませんし、監査とターゲットマシンの間にある中間ホストのフィルタリングルールかもしれません。

ターゲットに送信されたおよび受信された実際のパケットトラフィックを見るには、tcpdumpにpacketsファイルを再読み込みすることができます。例えば、次のようにします:

  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

オープン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の実行で見たポートと一致するはずです:

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を入力してバックグラウンドに移動させ、その後bgを実行します:

  1. bg

UDPスキャンを実行します

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

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

  • -sU: これは、nmapにUDPスキャンを実行するよう指示します。

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結果との主な違いは、open|filteredとしてマークされたポートの数である可能性が高いです。これは、nmapが応答の不足がトラフィックをサービスが受け入れたのか、または配信経路のどこかでファイアウォールやフィルタリング機構によってドロップされたのかを判断できなかったことを意味します。

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

報告されたポートに対して open|filtered として報告されたパケットが nmap によってどれだけ送信されたかを確認するには、報告されたポートの一つに対するUDPトラフィックを表示するように依頼します:

  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

これを、“閉じた”とマークされたスキャンされたポートの結果と比較してください。

  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

次に、これら二つの応答を見て、ICMPレスポンスが返されなかったUDPパケットを確認できます。

  1. comm -3 outgoing response

これは主にが報告したポートのリストと一致するはずです（失われた戻りパケットからの誤陽性が含まれる可能性があります）。

ホストおよびサービスの発見

ターゲットに対して追加のテストを実行して、nmapが稼働しているオペレーティングシステムやサービスのバージョンを特定できるかどうか確認できます。バージョン情報を保持するディレクトリを作成してください:

  1. mkdir ~/scan_results/versions

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

ターゲットで実行されているサービスのバージョンを推測するために、フィンガープリンティングと呼ばれるプロセスを試みることができます。サーバーから情報を取得し、それを当社のデータベースにある既知のバージョンと比較します。

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

nmap スキャンは、-sV フラグによってトリガーされます。すでに SYN スキャンと UDP スキャンを実行したので、-p フラグを使用して正確に確認したいポートを指定できます。ここでは、SYN スキャンで表示されたポート 22 と 80 を確認します。

  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



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の実行は省略しますが、必要であれば実行できます。

オペレーティングシステムの検出を行うために必要なフラグは-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は見た署名に基づいてオペレーティングシステムに対する推測を持っていないことがわかります。もしより多くの情報を受け取っていたら、対象マシンの署名がデータベース内のオペレーティングシステムの署名とどのように一致しているかを示すさまざまなパーセンテージが表示されていたでしょう。以下のTCP/IP fingerprint:行には、nmapが対象から受け取ったフィンガープリント署名が表示されています。

オペレーティングシステムの識別は、攻撃者がそのシステムに対してどの脆弱性が有効であるかを把握するのに役立ちます。ファイアウォールの設定を変更して、少ない問い合わせに応じるようにすると、これらの検出方法の精度を低下させるのに役立ちます。

結論

ファイアウォールをテストし、内部ネットワークが外部の攻撃者にどのように見えるかを認識することは、リスクを最小限に抑えるのに役立ちます。自分のインフラを調査することで得られる情報は、セキュリティを向上させるために、ポリシー決定のいくつかを再検討する必要があるかどうかについての議論を開くかもしれません。また、誤ったルールの順序や忘れられたテストポリシーのために発生した可能性のあるセキュリティのギャップも明らかにするかもしれません。現在のセキュリティレベルを改善または維持するためには、最新のスキャニングデータベースを使用してポリシーを定期的にテストすることをお勧めします。

ファイアウォールのポリシー改善のアイデアを得るために、このガイドをチェックしてください。

関連記事: