PR

脆弱性検査での「ペネトレーションテスト」「ポートスキャン（ポートスキャナ）」「ファジング」の使い分け

この記事は約8分で読めます。

本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。

1. 導入：3手法は「目的」と「成果物」が別物になります

脆弱性検査の現場で混乱しやすい点は、同じセキュリティテストでも、狙うリスクと出力（成果物）が違うことです。特に次の3つは名前だけが一人歩きしやすいです。

  • ポートスキャン（ポートスキャナ）：外部から見える入口を列挙し、攻撃面（attack surface）を確定します
  • ペネトレーションテスト：攻撃者の目的（例：権限奪取、重要データへの到達）が達成できるかを検証します
  • ファジング：未知の不具合（クラッシュ、例外、ハング）を引き起こす入力を大量生成し、未知脆弱性の芽を見つけます

この違いを押さえると、見積もり（工数・期間）、前提条件（許可・停止条件）、報告書の粒度（再現手順・証跡）の設計が破綻しにくくなります。(GitHub)

2. 用語の定義：脆弱性検査の中での位置づけ

2.1 重要用語

  • 脆弱性診断：既知の脆弱性や設定不備を中心に、対象にどんな問題があるかを広く洗い出す検査（自動化比率が高いことが多い）
  • ポートスキャン：TCP/UDPなどのポートに対して到達性や状態を確認し、公開サービスを特定する行為（例：サービス/バージョン推定まで含む）(nmap.org)
  • ペネトレーションテスト（Penetration Test）：明確な攻撃者像と目的を置き、一定期間内に目的を達成できるかを検証するセキュリティテスト(GitHub)
  • ファジング（Fuzzing）：大量の入力データ（ファズ）を生成・投入し、クラッシュ等を起点に未知の脆弱性を検出する技術(情報処理推進機構)

2.2 上下関係ではなく役割分担で考えます

典型的には次の順で組み合わせます。

flowchart LR A[資産/範囲の確定] --> B[ポートスキャン: 公開サービス列挙] B --> C[既知脆弱性/設定診断: 広く洗い出し] C --> D[ペネトレーションテスト: 目的達成可否の検証] A --> E[ファジング: 開発/QAで未知不具合探索]

※実務では、ペネトレーションテスト中にもポートスキャン相当の探索を行います（入口が分からないと侵入経路を組めないためです）。(NIST CSRC)

3. ポートスキャン（ポートスキャナ）：攻撃面を確定します（代表例：Nmap）

3.1 重要になる理由

インターネット／社内ネットワークの境界が複雑化すると「開いているポートが把握できていない」状態が頻発します。
この状態で脆弱性診断や侵入テストをしても、見ていない入口が残るため、評価の信頼性が落ちます。

3.2 代表的な実施手順（実務の最小セット）

  1. 対象範囲の確定：IPレンジ、FQDN、クラウドLB配下など
  2. ホスト発見（必要なら）：ICMPが落ちる環境もあるため、設計に合わせる
  3. ポートスキャン：TCP中心＋必要に応じてUDP
  4. サービス/バージョン推定：後続の診断・リスク判定の精度が上がる
  5. 結果の棚卸し：想定外の公開（例：管理ポート、検証用サービス）を検知して是正につなげる

(nmap.org)

3.3 コマンド例（検証環境・許可取得済みを前提）

※無許可のスキャンは不正アクセスや迷惑行為になり得ます。

# 例: TCPの代表的なスキャン + サービス推定 + 出力保存
nmap -sS -sV -p- --reason -oN nmap_result.txt 192.0.2.10

# 例: よく使うポート帯だけを高速に（状況に応じて調整）
nmap -sS -sV --top-ports 1000 -oN nmap_top1000.txt 192.0.2.10

Nmapのオプション体系（スキャン方式、状態判定、サービス検出など）は公式マニュアルが一次情報として有用です。(nmap.org)

4. ペネトレーションテスト：目的達成の可否を示す

4.1 ペネトレーションテストが答える質問

脆弱性診断が「問題の有無と数」を答えるのに対し、ペネトレーションテストは次を答えます。

  • 「攻撃者が この目的（例：管理者権限、顧客情報、決済フローの改ざん）を達成できるか」
  • 「達成できる場合に どの経路（侵入→横展開→権限昇格→目的到達）を取れるか」
  • 「検知・封じ込め・復旧まで含め、組織の耐性（レジリエンス）がどの程度か」

この位置づけは、ISOG-J と OWASP Japan の公開ドキュメントで明確化されています。(GitHub)
また、経済産業省の手引きでも、運用面の弱点を含めて顕在化する点が述べられます。(経済産業省)

4.2 典型的な進め方（工程と成果物）

工程目的成果物（例）
事前合意範囲・禁止事項・停止条件・連絡系統を決めるRoE（Rules of Engagement）、許可書面
探索侵入の足場を集める入口一覧、攻撃仮説
侵入（Exploitation）経路を作る侵入点の証跡、再現手順
権限昇格/横展開影響を拡大できるか確認影響範囲、権限遷移の証跡
目的達成ビジネス上の重要資産に到達できるか目的到達の証跡、ログ
報告/改善再現と改善ができる形にする最終報告書、優先度付き対策

※侵入工程はシステム影響が出やすいため、停止条件（例：CPU高騰、ログ肥大、業務影響の兆候） を事前に書面化します。(NIST CSRC)

4.3 どんなときに採用するか（判断軸）

  • 重要資産がある（個人情報、決済、医療、製造制御など）
  • 境界が複雑（クラウド＋SaaS＋委託先＋ゼロトラスト移行中）
  • 対策できているかの検証が必要（運用監視、EDR/SIEM、権限設計）

5. ファジング：未知の不具合を量であぶり出す

5.1 ファジングが刺さる領域

ファジングは「仕様に沿う入力」よりも「壊れやすい入力」を大量に与えます。
そのため、次のような層で成果が出やすいです。

  • パーサ（JSON/XML/画像/動画/独自バイナリ）
  • ネットワークプロトコル実装
  • 暗号・圧縮・変換（境界条件が多い）
  • 組込み・ミドルウェア（入力面が限定されがちなので集中しやすい）

IPAの資料は、ファジングが未知脆弱性検出の技術であり、開発ライフサイクルやQAに組み込める点を整理しています。(情報処理推進機構)
また、FAQでは既知脆弱性スキャナやペネトレーションテストとの違いが明示されています。(情報処理推進機構)

5.2 代表的なファジングの型

  • ブラックボックスファズ：外部I/Fにランダム入力（導入しやすいが到達率が下がりやすい）
  • カバレッジガイドファズ：コードカバレッジ（到達率）を見ながら入力を進化させる（成果が出やすいが環境整備が必要）

5.3 実装例（Goの標準ファズを使う最小例）

※ここでは「自分が管理するコード」に対する品質/安全性テストとして書きます（第三者システムに投入しません）。

package parse

import (
    "strconv"
    "testing"
)

// 例: 文字列→整数変換の境界を狙う（実際は自作パーサ等で効果が出やすい）
func FuzzAtoi(f *testing.F) {
    // シード（最初に試す入力）
    f.Add("0")
    f.Add("-1")
    f.Add("999999999999999999999")
    f.Add("  42")

    f.Fuzz(func(t *testing.T, s string) {
        _, _ = strconv.Atoi(s)
        // ここに「落ちてはいけない」「panicしてはいけない」等の性質を書く
    })
}

ファジングの要点は「クラッシュ等の現象 → 最小化（再現しやすい入力に縮約） → 修正 → 回帰防止（コーパス化）」です。IPAの実践資料は、ツール利用や再現の考え方をまとめています。(情報処理推進機構)

6. 3手法の比較表：成果物・コスト・リスクで切る

観点ポートスキャン（ポートスキャナ）ペネトレーションテストファジング
主目的公開サービス（入口）の列挙目的達成可否の検証未知不具合の検出
典型の成果物ポート/サービス一覧、想定外公開の指摘攻撃経路、証跡、ビジネス影響クラッシュ入力、再現手順、修正PR
対象範囲ネットワーク境界が中心システム全体（運用含む場合あり）コード/コンポーネント単位が中心
自動化高い中（人の判断が主）中〜高（環境整備次第）
失敗パターン範囲漏れ、誤検知の放置目的不明確、停止条件なし再現不能、ノイズだらけ
代表一次情報Nmapマニュアル(nmap.org)ISOG-J/OWASP Japan資料(GitHub)IPA資料(情報処理推進機構)

7. 注意点・よくある誤り

  1. 許可と範囲が曖昧
    • ペネトレーションテストやポートスキャンは業務影響や法務リスクが出ます。契約（委託先を含む）と社内規程の整備は 分野ごとに確認が必要 です。(GitHub)
  2. 脆弱性の件数だけで意思決定する
    • 重要なのは「どの資産に、どの経路で、どの程度の影響を与えられるか」です。ペネトレーションテストはこの問いに寄せます。(GitHub)
  3. ファジングが回せないまま放置
    • コーパス、時間枠、クラッシュのトリアージ（優先度付け）がないとノイズが増えます。IPA資料の運用観点（開発/QAへの組み込み）は先に読む価値があります。(情報処理推進機構)
  4. ポートスキャン結果が資産管理に戻らない
    • 発見した入口をCMDB/台帳に反映しないと、次回も同じ棚卸しを繰り返します。

8. まとめ：選定基準は「目的→成果物→停止条件」

  • ポートスキャン（ポートスキャナ） は入口の棚卸し（攻撃面の確定）で使います
  • ペネトレーションテストは「目的を達成できるか」を示します（経路と証跡が成果物になります）
  • ファジングは未知不具合を量で探し、開発/QAに組み込むと効果が出やすくなります

3つは競合しません。むしろ、相互に前提を補完します（入口→仮説→検証、コード品質→未知バグ低減）。

A. 参考サイト

1) NIST SP 800-115 (Information Security Testing and Assessment)
2) ISOG-J / OWASP Japan（ペネトレーションテストについて：公開ページ）
3) ペネトレーションテストについて（公開ドキュメント：GitHub）
4) Nmap リファレンスガイド（日本語）
5) IPA：ファジング活用の手引き（PDF）
6) IPA：ファジング FAQ

B. 関連書籍

実践 Metasploit ―ペネトレーションテストによる脆弱性評価
行政機関や企業に対するサイバー攻撃が世界中で深刻な問題になっています。攻撃者の脅威に対抗するための最も有効な手段はペネトレーションテストです。本書では、ペネトレーションテストのやり方を、Metasploitを主軸に説明しています。そうするこ...
www.amazon.co.jp

コメント