ガイドSC

IDS・IPS・NIDS・NIPSと検知方式

公開: 2026-09-26更新: 2026-09-26
受動監視とインライン遮断、シグネチャ・アノマリ検知、暗号化・欠落の限界を一つの通信で学ぶ。

社員端末WS-41からDMZのWebサーバWEB-7へ不審なHTTP要求が流れます。境界のNIDSは警告を出しましたが、WEB-7は応答しました。もし同じルールをNIPSに適用していれば本当に遮断できたのでしょうか。IDS/IPS、NIDS/NIPS、シグネチャ検知・アノマリ検知を一つの通信で比較します。

読む順序は、用語と配置→正常な処理→異常ログ→調査と対策→復旧→演習です。接続・検知・遮断・被害を別々の事実として扱います。以下の構成、時刻、アドレス、ログ、設定値は教材用の架空例です。

1. 用語と役割を構成に結び付ける

用語

この事例での意味と限界

IDS

Intrusion Detection System。監視した通信や端末動作を分析し警告する。検知しただけでは元のパケットを止めない。

IPS

Intrusion Prevention System。適切なインライン配置とdrop/rejectルールなら転送前に遮断できる。警告と実際の阻止結果は区別する。

NIDS/NIPS

NはNetwork。監視点を通るネットワーク通信が対象。暗号化されたTLS本文や監視点外の東西通信を必ず読めるわけではない。

シグネチャ検知

既知のパターン、プロトコル条件、挙動の組合せに一致させる方式。ルールIDと版が重要。未知の変種や対象外の通信は見逃す。

アノマリ検知

通常の通信量や頻度などからの逸脱を検出する方式。通常業務の変化でも警告するため、基準期間と対象範囲が必要。

SPAN/TAP

スイッチのミラー出力または物理分岐で受動センサーへ渡す方法。ミラー欠落や非対称経路があると観測が不完全になる。

2. 構成と信頼境界

外部クライアント203.0.113.41が境界FWを経由し、WEB-7（10.20.8.7:443）へ接続します。NIDS-1はFW後段のミラーポートを監視し、NIPS-1は代替案としてFWとWEB-7の間へインライン配置します。TLS終端はWEB-7なので、これらのセンサーは復号連携なしではHTTPS本文を読めません。

受動監視とインライン遮断の位置同じ経路でNIDSはコピーを受け、NIPSは実通信を通す。外部境界内部DMZ1234外部端末境界FWNIPS-1NIDS-1WEB-7
受動監視とインライン遮断の位置
  1. 1. HTTPS要求
  2. 2. インライン案
  3. 3. ミラーコピー
  4. 4. 許可時のみ転送

同じ経路でNIDSはコピーを受け、NIPSは実通信を通す。

NIDS-1への線はコピーであり、実際の通信はNIDSを通りません。図のNIPS-1はインライン案の経路です。両方を同時に設置したという意味ではなく、導入方式の比較として読んでください。

3. 正常な処理を順に追う

  1. FWがWEB-7:443宛てを許可し、通信がセンサーの観測点へ届く。

  2. NIDS案はコピーされたパケットを検査し、ルールに一致したらアラートを送る。実パケットは既にWEB-7へ進める。

  3. NIPS案は通信をインラインで検査し、dropルールと遮断ポリシーに一致すれば転送を止める。

  4. SOCはアラートID、ルール版、処置結果をWEB-7のアクセスログと突き合わせる。

暗号化通信ではSNIやIP、証明書など取得できたメタデータは使えても、TLS本文中のHTTPパスやペイロードは通常そのままでは見えません。検知ルールが何のフィールドを見たか、終端前後のどこへ置いたかを先に確認します。

4. 設定値・ログの読み方

項目

値の意味と判断の限界

sensor/mode

NIDSのpassiveとNIPSのinlineを区別。inlineと表示されても実経路を通らなければ遮断できない。

sid/rev

シグネチャIDと改訂版。後日同じIDでも条件が変わる場合がある。

flow_id/五つ組

端末・通信・WEB-7ログを結ぶ。NAT前後と時刻を併用する。

action/verdict

alert、drop要求、実際の転送結果を分ける。警告発生は遮断の証拠ではない。

packet_loss

SPANやセンサー過負荷で欠落した場合、警告がないことは正常の証明にならない。

次は架空の受動監視ログとWEB-7側の記録です。NIDSが`alert`を出した直後にWEB-7が200を返しています。

text
10:00:01 NIDS-1 mode=passive sid=42001 rev=3
  src=203.0.113.41:51510 dst=10.20.8.7:443
  action=alert verdict=observed flow=F-41
10:00:02 WEB-7 request=R-41 status=200
  src=203.0.113.41 path=/login

この例では警告後に要求が到達したことが分かります。ただしNIDSがTLS本文を見て`/login`を検知したとは言えません。パスはWEB-7側のログです。別のNIPSログで`drop`が出ても、適用対象のフローとWEB側到達の有無を照合します。

5. 攻撃・障害時の差分

異常・攻撃条件

観測、成立条件、対策の位置

既知パターンの変形

攻撃者がシグネチャ条件から外す。ルール更新と振る舞い・アノマリの併用が必要。

TLS本文の不可視

センサーが終端前にあり復号しない。アプリログ、プロキシ、EDRを合わせて調査する。

インライン故障

NIPS停止時のfail-openは可用性を保つが検査を失い、fail-closedは通信を止める。方針を事前に決める。

誤検知

正規の更新通信がdropに一致する。対象と条件を絞り、監視モードで評価してから段階的に遮断する。

非対称経路

要求だけがセンサーを通り応答は別経路。再構成に必要なパケットが欠けるため経路を直す。

アノマリ検知は通常値からの差を知らせるだけで、差の原因が攻撃とは限りません。昼休みやバックアップ時間、リリース作業などを基準に含め、過剰な例外で本当の侵害を隠さないようにします。

6. 切り分けに必要な証拠

  • FWの許可ログとNAT対応で、203.0.113.41からWEB-7への実経路を確認する。

  • NIDS/NIPSのセンサー状態、時刻同期、ミラー欠落、ルール版、検査対象フィールドを確認する。

  • WEB-7のアクセス・認証・アプリログで、要求が届いたか、業務処理が成功したかを分ける。

  • 同一sidに一致した正規通信を集め、誤検知率と例外対象を評価する。

`drop`は対象パケットを止めた事実に近いものの、同じ攻撃が別経路や再試行で成功していないことは証明しません。検知しなかった場合もセンサーの観測範囲と保持期間を確認します。

6.1 判断を誤りやすい境界と詳しい確認

確認点

具体的な判断

配置と通過

NIDSのSPANは複製を見るだけ。NIPSがinlineでも、対象フローが別の出口へ迂回すれば制御できない。実配線、経路表、FWの転送先を突き合わせる。

ルール動作

sidは検知条件を特定し、revはその版を特定する。alert/drop/rejectは別動作。ルールにdropとあっても、センサーが受動モードならパケットは遮断されない。

パケットの可視性

TLS終端前はHTTPパスや本文を平文で検査できない。復号装置の導入時は証明書、プライバシー、例外、性能を設計し、終端後のアプリログで確認する。

TCP再構成

片方向のパケットしか見えない、SPANが取りこぼす、フラグメントや順序入替がある場合はアプリ層まで復元できない。flow_idが同じでも完全な要求を見たとは限らない。

アノマリの閾値

ベースラインは平日・休日・バックアップ時刻で変わる。逸脱を攻撃と判定する前に、業務イベントと端末数の変化を確認し、偽陽性・偽陰性を測る。

遮断の証拠

NIPSのdropカウンタに加え、対象の五つ組、NAT変換、WEB-7の応答、再試行先を確認する。WEB-7の200は正常処理とは限らず、アプリの認証・操作記録も必要。

障害時の動作

fail-openなら機器障害中に検査なしで通過し、fail-closedなら正規通信も止まる。バイパス機構と切替の実測、監視通知を運用手順に含める。

例えば同じsid=42001が100件あっても、100回の侵害とは限りません。再送、単一要求に対する複数パケット、スキャナの反復、誤検知が混在します。時刻・五つ組・flow_id・WEB-7のrequest IDで束ね、アラート件数と実際の攻撃試行数を分けます。

遮断導入では、まずalertとして対象業務の通常通信を収集し、送信元、宛先、パス、時間帯を確認します。条件を狭めた上で一部の通信だけdropへ移し、アプリ成功率とヘルプデスクへの問い合わせを監視します。重大な漏えいが疑われる場合は、この段階的導入より緊急遮断を優先し、影響を記録します。

センサーが沈黙したときは『攻撃なし』と結論しません。稼働・ルール配布・時刻同期・ミラーの帯域・パケット欠落・NAT後の観測位置を確認します。WEB-7で不審な操作があれば、NIDSで見えなかった理由を経路、暗号化、ルール条件に分けて調べます。

7. 設定変更と例外運用

変更・例外

失敗しやすい点と確認

ルール更新

revと変更時刻を保存し、過去ログの判定に当時のルールを使う。正規通信の影響を先に測る。

暗号化方式変更

TLS終端やECH導入で見えるメタデータが変わる。センサーの検知条件を再検証する。

経路変更

新しいVLANやクラウド直通が監視点を迂回しないか構成図と実トラフィックで確認。

緊急例外

送信元・宛先・期限・承認者を限定し、期限後に戻す。シグネチャ全体を無効化しない。

NIPSは可用性へ直接影響します。重要なWEB-7へ新しいdropルールを即時全量適用する前に、受動モードでの一致数、誤検知、ロールバック手順、SOCとサービス担当の承認を確認します。

8. 封じ込めと復旧条件

  1. 疑わしいフロー、sid、センサー状態とWEB-7ログを保全する。

  2. 攻撃が継続中ならFWやNIPSで対象を絞って遮断し、WEB-7の業務影響を監視する。

  3. 侵入が疑われるWEB-7の認証・ファイル変更・横展開を調査し、原因を修正する。

  4. 遮断ルールを検証し、正規通信と攻撃を模した安全な試験の双方で期待結果を確認する。

  5. センサーの欠落率、監視範囲、ルール版、業務機能が正常であることを復旧条件とする。

NIPSが阻止した一件だけを見て被害ゼロと結論しません。経路外の通信、阻止前の要求、同じ端末からの再試行を調べます。

9. 科目B（午後）での解答手順

設問ではセンサーの配置がパケットのコピーか実経路かを先に読みます。次に検査できるデータ、ルールの種類、actionとverdict、WEB-7の結果を分け、設問にある事実だけから遮断・侵害を判断します。

  • IDSとIPSの置き方を図で区別する。

  • シグネチャ一致とアノマリ逸脱の意味を分ける。

  • 暗号化・ミラー欠落・非対称経路を観測限界として記す。

10. 短答演習

演習1：alertと遮断

条件：NIDSがalert、WEB-7が200。 質問：阻止したか。

解答：阻止していない。 誤答の理由：受動センサーの警告をdropと同一視している。

演習2：TLS本文

条件：NIDSはTLS終端前にあり復号しない。 質問：HTTPパスを読めるか。

解答：通常は読めない。 誤答の理由：IPやSNIなどと本文を混同している。

演習3：NIPSの故障

条件：fail-openでNIPSが停止。 質問：何が続くか。

解答：通信は通るが検査を失う。 誤答の理由：可用性と検知を同一視している。

演習4：sid改訂

条件：同じsidだがrevが変更。 質問：調査時に何を保全するか。

解答：当時のrevとルール内容。 誤答の理由：現在の条件を過去へ当てはめている。

演習5：アノマリ

条件：バックアップ時に通信量が増加。 質問：攻撃と断定できるか。

解答：できない。通常運用と比較する。 誤答の理由：逸脱と悪意を同一視している。

演習6：dropの限界

条件：NIPSがF-41をdrop。 質問：WEB-7に被害なしと断定できるか。

解答：できない。別経路や既往の要求を調べる。 誤答の理由：一件の遮断を全件の成功と誤解している。

11. 一次資料

Suricata公式：インラインIPSと受動IDS

Suricata公式：ルールのaction

Suricata公式：EVEイベント形式

この記事についてAIに深掘り質問する

ChatGPT、Claude、Perplexityにこの記事を参照させ、要点の確認や疑問点を自由に質問できます。

次におすすめの学習

資格学習

SCの学習画面へ

編集・検証について

編集・検証：IT資格ラボ編集部

IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。

編集方針・情報源・訂正方針を見る
この記事を共有する
すべての学習ガイド・記事一覧へ戻る