プローブパケットとは？種類・使い方・注意点までわかりやすく解説！

「プローブパケット」という言葉を聞いたことはあっても、その正体や使い方を正確に理解している人は意外と少ないかもしれません。

ネットワークのトラブルやセキュリティ対策に直面したとき、「もっと早く知っておけば…」と後悔しないためにも、この技術は今や必須の知識です。

本記事では、初心者にもわかりやすく、プローブパケットの基本から応用、注意点、活用事例までを丁寧に解説します。

プローブパケットとは何か

プローブパケットとは、相手に「データを届ける」こと自体が目的ではなく、ネットワークの状態を測る・確かめる・見つけるためにわざと送る小さな確認用パケットです。

つまり、プローブパケットは通信路の温度計のような存在で、遅延や到達可否、経路、ポートの開閉などを知るために使われます。

なぜなら、通常の業務データだけではネットワークの異常原因を切り分けたり、外部からの偵察行為を見抜いたりするのが難しいからです。

1-1. プローブパケットの定義と基本的な役割

プローブパケットの目的は大きく三つに整理できます。順番に見ていきましょう。

1-1-1. ネットワーク診断における位置づけ

プローブパケットは、ネットワークの健全性を可視化するための能動的（アクティブ）計測に使われます。

たとえば以下のような診断が典型です。

• 到達性の確認：ICMP Echo（いわゆる ping）で応答有無と往復時間を知る
• 経路の把握：TTL（生存時間）を段階的に変える traceroute 型のプローブで、通過ルータと遅延を可視化
• 遅延・損失の測定：一定間隔で連続送信し、遅延、ジッター、パケットロス率を算出
• MTU の確認：フラグメント不可（DF）フラグを立て、通過可能な最大パケットサイズ（Path MTU）を推定

これらは、障害時の切り分け（どこで詰まっているか）や、SLA 監視（遅延や損失が許容範囲か）に直結します。

したがって、プローブパケットは日常運用の「体温計」として欠かせません。

1-1-2. セキュリティ運用における位置づけ

一方で、プローブパケットは偵察（リコン）にも用いられます。攻撃者は小さな信号を送り、返ってくる応答から以下を推測します。

• どのホストが生きているか（ホスト探索）
• どのポートが開いているか（ポートスキャン）
• どのサービスや OS が動いていそうか（バナー、応答パターンの差異）

だからこそ、防御側は監視ログから異常なプローブパケット（短時間に多数の宛先・ポートへ飛ぶなど）を素早く検知し、遮断や調査につなげる必要があります。

つまり、プローブパケットは善用も悪用もされる両刃のツールです。

1-1-3. 用語の整理：プローブとスキャンの違い

• プローブ（probe）：個々の確認行為。単発または低頻度で、特定の情報を得るための打診。
• スキャン（scan）：多数のプローブを体系的に繰り返し、面（多ホスト・多ポート）で情報収集する行為。

プローブパケットという言葉は両者を含む広い概念として使われやすい点に注意しましょう。

---

1-2. プローブパケットと一般的な通信パケットとの違い

ここでは、プローブパケットと通常のアプリケーション通信（Web やメールなどの実データを運ぶパケット）の設計思想と挙動の違いを整理します。

まずは表で全体像を掴み、その後にポイントを補足します。

1-2-1. 目的・設計思想の違い

項目	プローブパケット	一般的な通信パケット
主目的	測定・検証・探索（状態把握）	データ転送（コンテンツ配信・業務処理）
成功の定義	応答パターンや到達情報が得られること	アプリ層データの完全・正確な配送
設計の考え方	小さく・制御しやすく・結果が解釈しやすい	スループット・信頼性・セッション維持
使用例	ICMP Echo、TCP SYN、UDP 高番ポート宛て、TTL 変化	HTTP/HTTPS、SMTP、DNS クエリなど（業務通信）

つまり、プローブパケットは「情報を運ぶ」より「状況を引き出す」ために設計されています。

したがって、応答がエラー（たとえば ICMP Port Unreachable や TCP RST）でも、それ自体が有益な観測結果になります。

1-2-2. 典型的なフィールドと挙動の違い

観点	プローブパケットの特徴	一般的な通信の特徴
TTL の使い方	段階的に増やして経路を可視化（traceroute）	通常は固定で経路可視化は目的外
フラグ・サイズ	DF フラグやパケットサイズを変えて MTU 推定	アプリ要件に合わせたサイズ最適化
ポートの選び方	応答を得やすい/得にくいポートを意図的に選択	利用サービスに紐づく固定ポート
送信頻度	測定間隔を明示的に設計（1秒間隔など）	トラフィックはユーザー動作依存
期待する応答	Echo Reply、TTL Exceeded、RST/ACK、Port Unreachable	アプリ層の応答（HTTP 200/404 など）

このように、プローブパケットは制御フィールドを積極的に活用してネットワークのふるまいを「引き出す」点が本質的に異なります。

1-2-3. 誤検知・誤解を防ぐ観点

最後に、運用で混乱しやすいポイントを整理します。

• 正常な監視と攻撃の見分け
  同一宛先へ一定間隔で送る少量のプローブパケットは監視の一環であることが多い一方、短時間に多宛先・多ポートへ拡散するパターンはスキャンの疑いが高まります。したがって、しきい値と例外リストの設計が重要です。
• フィルタリングの影響
  セキュリティ機器やクラウドの制御により、ICMP が抑制されたり、SYN への応答が変化したりします。だから、プローブパケットの結果を鵜呑みにせず、ポリシーの前提を確認しましょう。
• 負荷とプライバシーの配慮
  高頻度のプローブは相手先や経路に負荷を与えます。さらに、外部組織へプローブパケットを送る際は、事前許可や説明責任が求められる場合があります。

プローブパケットの種類とプロトコル

プローブパケットは「ネットワークの状態を引き出すための信号」です。

つまり、どのプロトコルで、どんな形のプローブパケットを送るかによって、分かる情報や届きやすさが変わります。

ここでは、検索意図の強い三つの系統――ICMP、TCP/UDP、そして traceroute 型――を、実務で使える観点で整理します。

---

2-1. ICMP（Echo Request 等）を使ったプローブ

ICMP を使ったプローブパケットは、最も手軽で汎用性があります。

なぜなら、ICMP は到達可否や遅延など「ネットワーク層の健康状態」を素直に返してくれるからです。

2-1-1. 代表的な ICMP プローブの種類

• Echo Request / Echo Reply（いわゆる ping）
  到達性と往復遅延（RTT）を確認する基本のプローブパケット。
• Time Exceeded（TTL 超過）
  traceroute 型で利用。経路上のルータが応答することでホップを特定。
• Destination Unreachable（宛先到達不能）
  経路上や宛先での拒否・不可達の理由を推測。IPv4 では「Fragmentation Needed」によりPath MTUの手がかりにも。
• Timestamp / Timestamp Reply
  時刻照合用。ただし実運用では無効化されていることが多いのが実情。

2-1-2. 何が分かるか（長所と限界）

• 長所
  • 到達性、RTT、経路の大枠が分かる
  • 宛先のサービスに依存せず、準備が要らない
• 限界
  • フィルタリングされやすい（ICMP を落とす組織は少なくない）
  • ルータやファイアウォールは ICMP を低優先度で処理しがちで、遅延が偏ることがある

2-1-3. 設計ポイント（間隔・サイズ・フラグ）

• 送信間隔：1 秒など一定間隔で。短すぎると相手や経路に負荷。
• サイズ調整：ペイロードを増やし、実通信に近いサイズで遅延を測ると現実的。
• DF フラグ：IPv4 で DF を立ててサイズを変えつつ送ると Path MTU 推定に役立つ。

---

2-2. TCP SYN や UDP プローブ

アプリケーションに近い層で「サービスの開閉」を見たいなら、TCP/UDP のプローブパケットが有効です。

したがって、監視やトラブルシュートだけでなく、セキュリティの偵察検知にも直結します。

2-2-1. TCP SYN プローブの意味と読み方

• SYN → SYN/ACK：ポートは開いている可能性が高い（接続試行が成功しうる状態）
• SYN → RST：ポートは閉。ホスト自体は生存している示唆
• 無応答／ICMP：フィルタやドロップの可能性
• 利点
  • 監視対象の特定ポート（例：443/TCP）で可用性を判断できる
  • ICMP が閉じていても、許可ポートなら通りやすい
• 注意
  • 大量・広範囲に送るとスキャン扱いになりやすい
  • SYN クッキーや RST レート制限で結果が歪むことがある

2-2-2. UDP プローブの特徴と落とし穴

• 読み方のコツ
  • ICMP Port Unreachable が返れば、そのポートは閉
  • 無応答でも開いているとは限らない（UDP は応答しない設計が多い）
  • DNS や NTP など、アプリ層応答が得られるプロトコルは明確に判断しやすい
• 利点：UDP ベースのサービス可用性を直接確認できる
• 注意：ファイアウォールやクラウドでICMP レート制限が効くと、閉ポートでも応答が返らず判定が難化

2-2-3. 運用上の注意（倫理・負荷・ログ）

• 頻度を抑える：本番環境や外部組織には低頻度・限定範囲で
• 事前合意：委託先やクラウドに送る場合は合意を取りトラブルを防止
• 記録と可視化：プローブパケットの送信元・対象・目的を台帳化し、誤検知やインシデント対応を容易にする

---

2-3. Traceroute 型プローブパケットの特性

traceroute 型のプローブパケットは、経路の見える化に特化しています。

だから、遅延のボトルネックや経路変更の影響を掴むのに最適です。

2-3-1. 仕組み（TTL/Hop Limit を段階的に増やす）

• TTL=1 から開始して 1 ホップ目のルータから ICMP Time Exceeded を受け取る
• TTL を 1 ずつ増やすことで、各ホップの IP と遅延を順に可視化
• 宛先到達時は、プローブパケットの種類に応じてICMP Port Unreachable（UDP の高番ポート宛）やSYN/ACK/RST（TCP 宛）などで完了を判断

2-3-2. 結果の読み解きと変動要因

• ロードバランシング：フローごとに経路が分岐し、結果がホップごとに揺れる
• パリス tracerouteの考え方：フロー識別子（5 タプル）を固定してハッシュ分岐のブレを抑える
• ICMP 優先度：ICMP 応答が抑制・低優先度だと、RTT が実際より遅く見える
• 非対称経路：往復で道が違うため、片方向障害の切り分けは別途必要

2-3-3. 使い分け：ICMP / UDP / TCP の traceroute

• ICMP traceroute：シンプルで速いが、ICMP フィルタに弱い
• UDP traceroute：宛先直前で Port Unreachable を引き出しやすい
• TCP traceroute：443/TCP など許可された宛先ポートを使えるため、FW 越えの可視化に強い。ただし、誤って監視対象サービスに負荷を与えない設計が必要

プローブパケットが使われる主要な用途

プローブパケットは、ネットワークの「今」を素早く測るための道具です。

つまり、運用ではどの目的で、どのプロトコルのプローブパケットを使うかを決めるだけで、見える情報の質と速さが大きく変わります。

以下では、代表的な三つの用途を実務視点で整理します。

---

3-1. ネットワーク監視と可用性確認

日々の稼働監視では、プローブパケットを最小コストで最大情報が得られるように設計します。

なぜなら、過剰なプローブは相手負荷や誤検知につながる一方、少なすぎると障害の初動が遅れるからです。

3-1-1. 監視の基本設計（KPI とプローブの対応表）

まずは「何を守るか」を決め、その KPI を測れるプローブパケットを選びます。

監視対象	主な KPI	推奨プローブパケット	補足
サーバの生存	到達性、RTT	ICMP Echo（ping）	到達と遅延の大枠を把握
Web サービス	可用性、応答速度	TCP SYN（443/TCP）または HTTP ヘルスチェック	ICMP が閉じられていても観測しやすい
DNS/NTP など	可用性、応答整合性	UDP クエリ	無応答の判定に注意
拠点間回線	RTT、損失、ジッター	小さめの ICMP 連続送信	長期の傾向把握に有効

ポイントは、ICMP で生存確認→サービスごとの TCP/UDP で可用性確認という二段構えです。

したがって、原因切り分けが一気に早くなります。

3-1-2. アラート設計（しきい値と抑制）

• しきい値の考え方：固定値だけでなく移動平均＋偏差やP95を使い、平常時の揺らぎを学習させる。
• バースト抑制：連続 N 回の失敗で通知、短時間の回復では自動クローズ。
• メンテナンス窓口：計画停止時は対象へのプローブパケットを一時停止し、誤アラートを防ぐ。

3-1-3. 運用チップス（現場で効く工夫）

• 送信元の冗長化：複数ロケーションから同一宛先へプローブし、経路依存の誤判定を回避。
• タグ管理：プローブパケットごとに「目的・間隔・宛先」を台帳化。だから、セキュリティ側の例外設定もスムーズ。
• 可視化：ダッシュボードは到達性→遅延→アプリ応答の順で並べ、原因追跡の導線を揃える。

---

3-2. 遅延・ジッター・パケットロスの測定

品質トラブルを見極めるには、プローブパケットで時間のブレを捕まえることが重要です。

つまり、平均値だけでなく分布を観る運用が肝心です。

3-2-1. 指標の定義と読み方

• RTT（往復遅延）：プローブパケットが往復する時間。上昇は回線逼迫や経路変更のサイン。
• ジッター：連続する RTT のばらつき。リアルタイム系（通話・配信）で効く。
• パケットロス：送信数に対する未達数の割合。1 パーセントでも体感が変わることがある。

3-2-2. 測定設計（間隔・窓・サイズ）

• 間隔：通常は 1～5 秒。だから、混雑時間帯の揺らぎも拾える。
• 集計窓：5 分・1 時間など複数の窓で短期ノイズと長期傾向を分離。
• サイズ：実通信に近いペイロードで送ると、現実的な遅延を再現しやすい。
• レート制限対策：ICMP や ICMP エラーは制限されやすいので、必要に応じて TCP/UDP のプローブパケットで補完。

3-2-3. 典型パターンと初動対応

症状	プローブ結果の傾向	考えられる要因	先手の対処
夜だけ遅い	RTT 上昇、ジッター増	輻輳、帯域不足	混雑時間帯のトラフィックを可視化、QoS 見直し
断続的に切れる	ロス増、RTT 乱高下	無線品質、L1/L2 障害	物理層チェック、チャネル変更
サイトだけ遅い	特定宛先で RTT/ロス悪化	経路・CDN 問題	トレーサで経路確認、宛先切替
大きいデータだけ遅い	小サイズ OK / 大サイズでロス	MTU/フラグメント	DF 付きでサイズ検証、Path MTU 調整

したがって、症状→プローブの事実→仮説→検証の順で回すと無駄がありません。

---

3-3. ルーティングや経路調査（Traceroute など）

経路の可視化は、プローブパケットの最も分かりやすい成果が得られる領域です。

だから、障害の「場所」を素早く示せます。

3-3-1. Traceroute の基本と派生

• 基本：TTL（Hop Limit）を 1 から増やして送信し、各ホップの ICMP Time Exceeded を収集。
• 派生：
  • ICMP ベース：軽量で速いが、ICMP フィルタに弱い。
  • UDP ベース：宛先直前で ICMP Port Unreachable を引き出しやすい。
  • TCP ベース：443/TCP など許可ポートで通しやすく、FW 越えの観測に強い。
  • Paris traceroute：フロー識別子を固定し、負荷分散で経路が揺れる問題を低減。

3-3-2. 経路トラブルの見分け方

• 非対称経路：往路と復路が違うため、片方向だけ遅い現象が起きる。したがって、片方向計測や複数地点からの比較が有効。
• ブラックホール（黒穴）：特定サイズやフラグのパケットだけ落ちる。DF 付きプローブで切り分け。
• レート制限/優先度：中継ルータが ICMP を低優先度処理し、RTT が実態より大きく見えることがある。
• Anycast/CDN：宛先の位置が動的に変わるため、時間帯で経路が変化する。

3-3-3. 実務ワークフロー（再現→比較→証跡）

1. 再現：障害報告の条件（時間帯、宛先、サイズ）で同等のプローブパケットを送る。
2. 比較：複数地点・複数方式（ICMP/UDP/TCP）でトレーサを取り、差分を抽出。
3. 証跡：結果をチケットに添付し、相手事業者へ伝える。だから、解決までの往復が速い。

セキュリティの視点：攻撃・リスクとの関係

プローブパケットは、ネットワークを健康診断するための便利な信号である一方、攻撃者の偵察にも使われる両刃の剣です。

つまり、運用者は「どのようなプローブパケットが正当で、どのような振る舞いがリスクなのか」を理解し、適切に見分ける必要があります。

以下では、偵察手法、攻撃シナリオ、そして正当な利用との見分け方を、実務の観点で整理します。

---

4-1. プローブパケットを使った偵察行為（プロービング、ポートスキャン）

4-1-1. なぜ偵察にプローブパケットが使われるのか

プローブパケットは、小さな刺激に対する応答からホストの生死、開いているポート、サービスの種類、経路といった重要情報を推測できます。

したがって、目立ちにくい「低速・低量」の送信でも、攻撃の踏み台探しや侵入口の洗い出しが可能です。

4-1-2. 代表的な偵察テクニック

• Ping sweep（ICMP Echo）：生存ホストの粗い把握。
• TCP SYN スキャン：SYN/ACK なら開、RST なら閉と判断。速度と精度のバランスが良い。
• TCP ACK / FIN / XMAS などの変種：フィルタ有無の推測や検出回避を狙う。
• UDP スキャン：ICMP Port Unreachable の有無から閉ポートを推測。無応答は判定が難しい。
• サービス／バナー推定：特定ポートへの軽いアクセスでソフト種別やバージョンを類推。
• 低速スキャン（slow scan）：長時間にわたり少量のプローブパケットを送って検知を回避。
• 分散スキャン：複数の発信元から小分けに送信し、しきい値検知をすり抜ける。

4-1-3. ネットワークに生じるリスク

• 攻撃前段の情報収集：脆弱な入口の特定を助長。
• 可用性への影響：大量・高頻度のプローブパケットは機器の制御プレーンを圧迫。
• 誤警報の増加：監視と偵察が混在すると、セキュリティチームの運用負荷が膨らむ。
• 検知回避の巧妙化：低速・分散・変種フラグを用いることで、シグネチャ依存の検知をすり抜けやすい。

---

4-2. 攻撃者がプローブパケットを使うシナリオ

4-2-1. 侵入前の外部偵察

• アタックサーフェスの棚卸：ドメイン、IP レンジ、公開サービスの洗い出しにプローブパケットを使用。
• 防御の性質テスト：ICMP/TCP/UDP の応答傾向から、ファイアウォールや WAF の挙動を推測。
• クラウド公開ミスの探索：メタデータや管理ポートの開放漏れをポートスキャンで確認。

4-2-2. 侵入後の内部偵察（横展開の前段）

• ホスト探索：ICMP や ARP のブロードキャスト／スキャンで生存端末を把握。
• サービス探索：SMB、RDP、SSH、データベースなど、横展開に有用なポートへプローブパケットを送る。
• 経路把握：traceroute 型や TTL 操作でセグメント境界やボトルネックを特定。

4-2-3. 権限昇格・持続化の補助

• 監視網の穴探し：プローブパケットを点在させ、検知されにくい経路を特定。
• C2（コマンド＆コントロール）の安定化：許可ポート（443/TCP など）に合わせたトラフィックに偽装し、検知を回避。

4-2-4. クラウド／SaaS 特有の状況

• セキュリティグループの設定漏れ確認：意図せぬ外部公開の有無をプローブパケットで検証。
• サーバレス・コンテナ：短命なワークロードからの分散プローブで、発信元の特定を困難化。

---

4-3. 正当な利用との見分け方

4-3-1. ふるまいから見抜く（頻度・多様性・意図）

プローブパケットそのものは同じでも、ふるまいのパターンが違います。

つまり、以下の観点でスコアリングすると、偵察の疑いを早期に高められます。

観点	正当な運用のプローブパケット	攻撃的・不審なプローブパケット
頻度・間隔	一定間隔、業務時間や監視設計に沿う	低速で不規則、または短時間に急増
宛先の広がり	限られた対象（監視対象のみ）	多数ホスト・多数ポートへ面展開
ポートの傾向	443/TCP などサービス可用性に直結	低利用の高番ポートや連番走査
プロトコルの使い分け	ICMP→TCP/UDP→traceroute と段階的	いきなり多方式を混在させる
送信元	監視サーバなど限定・台帳化済み	不明な送信元、地理的に分散
ログ・メタ情報	送信元の説明可能性が高い	逆引き不可・WHOIS 情報が不自然

4-3-2. 検知と防御の実践

• しきい値ベース＋ふるまい検知：短時間のスキャンだけでなく、長時間の低速走査も検出するための時間窓を併用。
• 許可リストの活用：自社の監視発信元やクラウドのヘルスチェック IP を台帳化して例外処理。
• レート制限とターピット：特定宛先／ポートへのプローブパケットが閾値超過なら遅延応答や接続抑制で消耗戦に持ち込む。
• セグメンテーションと最小公開：インターネットから到達可能な面積（アタックサーフェス）を削減。
• ハニーポート／ハニーホスト：通常使わない領域に誘導し、ヒットしたプローブパケットを高優先でアラート。
• ログの相関分析：FW/IDS、エンドポイント、アプリのログを送信元・時刻・ポートで束ね、意図を推定。

4-3-3. 誤検知を減らす運用

• プローブ台帳：目的、宛先、間隔、送信元を一元管理。だから、セキュリティチームと運用チームの調整が早い。
• メンテナンス告知：計画停止や負荷試験では、プローブパケットの一時停止やしきい値変更を事前共有。
• 多視点の観測：社内外の複数拠点から観測し、経路起因の誤判定（片方向障害や ICMP 低優先度）を排除。
• 検証の反復：疑わしいふるまいは、宛先・ポート・プロトコルを変えて再計測し、本当に悪性かを確認。

プローブパケットの実装と運用上の注意点

プローブパケットは、設計しだいで「軽くて役に立つ観測」にも「過剰で誤解されやすい通信」にもなります。

つまり、実装段階で頻度・送信元/宛先・配慮事項を丁寧に決めることが、健全な運用の近道です。

---

5-1. 送信間隔や頻度をどう設計するか

5-1-1. 目的から逆算する頻度設計

まず「何を早く知りたいか」を定義し、その検出スピードに見合う間隔を設定します。

なぜなら、プローブパケットの頻度は検出までの時間とネットワーク負荷を同時に左右するからです。

• 死活監視（到達性）：30～60 秒間隔から開始。障害検知を速めたいときは 5～10 秒へ短縮。
• サービス可用性（特定ポート）：10～30 秒間隔が実務的。負荷が軽いなら 5～10 秒。
• 品質監視（RTT/ロス/ジッター）：1～5 秒間隔で連続計測し、統計的に判断。
• 経路監視（traceroute）：1～15 分間隔など低頻度に留める（制御面への負荷を避けるため）。

5-1-2. バーストを避けるスプレッド配信

同時刻に一斉送信すると瞬間的なスパイクが生まれます。

したがって、送信時刻のランダム化（ジッタ付与）や対象分割（ラウンドロビン）で平準化しましょう。

• 時刻を微小ランダムでばらす
• 監視対象を複数バッチに分け、数秒ずらして送る
• 複数監視サーバ間で対象を均等分配

5-1-3. サンプル数と検出感度のトレードオフ

平均だけでなく分布（P95、P99）を見るには一定のサンプル数が必要です。

だからこそ、短い間隔 × 短い集計窓と長い間隔 × 長い窓を併用すると、瞬間的な揺らぎと恒常的な悪化を両取りできます。

• 短期窓（5 分）：障害の兆候に素早く反応
• 長期窓（1～24 時間）：基準値の自動更新や傾向判定に利用

5-1-4. 実装チェックリスト

• 送信間隔は目的に合致しているか
• バースト回避のスプレッドが入っているか
• 緊急時のみ一時的に頻度を上げられる運用導線があるか
• 統計は平均だけでなく P95 なども可視化しているか

---

5-2. プローブの送信元・宛先と標的範囲の選定

5-2-1. 送信元の設計（観測点と冗長化）

観測はどこから見るかで結果が変わります。

つまり、プローブパケットは複数の送信元から打って、経路やローカル要因の偏りを減らすのが鉄則です。

• 拠点別に観測点を配置：本社、データセンター、クラウド VPC など
• 送信元の冗長化：観測点自体の停止に備える
• 経路差分の把握：同一宛先を複数地点から計測して比較

5-2-2. 宛先と標的範囲の決め方（許可と優先順位）

• 許可前提：自組織外へ継続的にプローブパケットを送る場合は、明示の許可や利用規約の確認が必要。
• クリティカル優先：顧客向けサービス、認証基盤、DNS、CDN 経路など事業影響の大きい宛先を優先。
• 範囲の絞り込み：全サブネットへの広域プローブは避け、対象は必要最小限に。

5-2-3. 台帳とタグ付け（誤検知を防ぐ）

監視とセキュリティを滑らかに連携させるため、プローブパケットの台帳化とタグ付けを徹底します。

• 台帳項目：目的、送信元、宛先、プロトコル、間隔、開始日、担当
• ログ出力：送信元を特定できるホスト名・タグを付与
• セキュリティ機器：許可リストに登録して誤検知を低減

---

5-3. ネットワーク負荷・プライバシーへの配慮

5-3-1. ネットワーク負荷を最小化する設計

プローブパケットは軽量とはいえ積み重なると無視できません。

したがって、以下の工夫で帯域・制御プレーンの負担を抑えましょう。

• ペイロード最適化：目的に必要な最小サイズから始め、必要に応じて調整
• レート制限：インターバル厳守、宛先ごとの上限制御
• 経路意識：traceroute や大きな ICMP は低頻度に、夜間に集中させない
• 段階解像度：平時は粗め、異常時のみ一時的に高頻度（アラート連動）

5-3-2. プライバシーと法的配慮

プローブパケットは対象の挙動データを引き出します。だから、権限や同意の範囲を越えないことが重要です。

• 許諾の取得：外部組織、委託先、クラウド事業者の合意を文書で保管
• 個人情報への配慮：ユーザー端末や個人宅回線を計測対象にしない設計
• 目的外利用の禁止：取得した応答データを二次利用しない
• 保持期間：監視ログの保管期間を定め、不要データは削除

5-3-3. 社内コミュニケーションと告知

• 関係者周知：運用、セキュリティ、ヘルプデスクにプローブ仕様を共有
• 計画停止時の調整：メンテナンスに合わせて一時停止やしきい値変更を事前告知
• 異常時の合意フロー：頻度増加や対象追加の判断基準と承認ルートを明文化

防御策と監視体制

プローブパケットは監視に不可欠ですが、攻撃の偵察にも使われます。

つまり、正当に使う経路は確保しつつ、不審なプローブパケットは早期に抑止・検知・解析する体制が要点です。

以下では、実運用で役立つ具体策を順に示します。

---

6-1. プローブパケットによる不正アクセスをどう防ぐか

6-1-1. 露出面を最小化する（攻撃面積の削減）

まず、プローブパケットを受けても意味がない箇所を公開しないことが肝心です。

なぜなら、見えている面が小さければ、偵察行為の成果が乏しくなるからです。

• 公開サービスの最小化（不要なポート閉鎖、管理ポートはゼロトラスト経由）
• 踏み台になりやすいプロトコル（RDP、SSH、DB）の直公開を避ける
• Anycast/CDN、WAF、リバースプロキシで直接到達を回避
• 外向け DNS ゾーンの情報最小化（TXT/AXFR 抑止、無関係レコード削減）

6-1-2. 入口での制御（許可と速度の管理）

プローブパケットは小さいため、速度と広がりで制御するのが実践的です。

• 許可リスト（Allowlist）：自社・監視ベンダの送信元を登録
• レート制限（Rate Limit）：1 宛先・1 ポート・1 送信元ごとに上限を設定
• ターピット（Tarpit）：異常な連番ポート走査に対し、意図的に遅い応答で攻撃者を消耗させる
• SYN Cookies / Conntrack 調整：半開接続の乱発（SYN flood/偵察）を影響最小化

6-1-3. 欺瞞と早期逸脱検出（ハニーテクニック）

正規トラフィックが来ない宛先にハニーポート/ハニーホストを配置すると、プローブパケットが当たった瞬間に不審度が高まります。

• 未使用サブネット/高番ポートをハニーポート化
• 低偽陽性の高優先アラートとして扱う
• 攻撃者の**探索パターン（順序・間隔・旗）**を記録し、後続の防御に反映

---

6-2. ログとアラート設定：異常プローブの検知方法

6-2-1. ふるまい指標で検知する（静的しきい値＋行動分析）

単発のプローブパケットは正当かもしれません。したがって、行動（広がり、頻度、順序）で判断します。

指標	具体例	解釈の目安
宛先の広がり	短時間で多数のホストへ ICMP/TCP/UDP	面探索＝スキャンの可能性
ポートの広がり	連番ポートへ SYN/UDP を順打ち	サービス発見の疑い
間隔のゆらぎ	不規則な低速プローブが長期継続	検知回避（slow scan）
旗・応答組合せ	FIN/XMAS、RST 応答観測	FW ルールの推定狙い
発信元の分散	地理・ASN がバラバラ	分散偵察・ボットネット

6-2-2. アラート設計（誤検知を抑え、重大事に集中）

• 多窓分析：5 分窓と24 時間窓を併用し、短期スパイクと長期低速を両方検出
• しきい値＋レート変化：件数閾値に加え、増加率でも検出
• 相関ルール：同一発信元がICMP→TCP→UDPと広げる連鎖を高スコア化
• 許可リスト：自社監視の送信元・クラウドヘルスチェックの IP を例外登録

6-2-3. 可視化と一次対応の定型化

• ダッシュボードは到達性→ポート別→経路の順で並べ、原因追跡を短縮
• アラートにはパケット例（五つ程度）と時系列ヒストグラムを添付
• 初動フロー：
  1. 許可リスト照合
  2. 影響面（単一/広域、可用性影響）確認
  3. 一時的ブロック/レート制限適用
  4. 証跡保存（pcap、フロー、対象機器ログ）

---

6-3. プローブ通信の制限／ファイアウォールや IDS / IPS の設定

6-3-1. ファイアウォール基本戦略（最小権限＋段階公開）

プローブパケットを通すべき通信と通さない通信を明確に分けるのが鉄則です。

• デフォルト拒否＋必要最小の許可（宛先/ポート/プロトコル/時間帯で限定）
• ICMP はType/Code を限定（Echo のみ許可、Redirect/Router Advertisement は遮断など）
• 管理系は管理用ネットワーク限定、インターネット直結は禁止
• アウトバウンド規制も実施（内部からの偵察拡大を予防）

6-3-2. IDS/IPS の実践ルール（ふるまいベースを強化）

• スキャン検知シグネチャ：SYN/FIN/XMAS/NULL などの異常フラグ組み合わせ
• 行動分析：多宛先・多ポート・低速継続・分散送信の複合スコアで検知
• レート制御/自動応答：一定スコア超過で一時隔離（Quarantine）やダイナミックブロック
• ネットワーク分離：検知した送信元を一時的に隔離 VLANへ移送

6-3-3. 実装チェックリスト（現場で役立つ確認項目）

• 監視系のプローブパケット送信元はAllowlist 登録済みか
• ICMP の許可は必要タイプのみに限定しているか
• 連番ポート走査や多宛先走査に対するしきい値・相関検知が有効か
• IDS/IPS の低速スキャン検知（長時間窓）は有効か
• ハニーポート/未使用サブネットへのヒットは高優先アラート化しているか
• レート制限・自動ブロックは誤検知時の解除手順が整備されているか