1. IDSとIPSの違いは「見つけたあとに止めるかどうか」

セキュリティの勉強を始めると、最初に必ず出てくるのがIDSとIPSです。名前が似ていて混乱しやすいのですが、両者の関係はとてもシンプルです。

米国国立標準技術研究所（NIST）が出しているSP 800-94「Guide to Intrusion Detection and Prevention Systems (IDPS)」（2007年2月、Final）が、この分野の基本になる文書です。ここでは次のように定義されています。

• 侵入検知：コンピュータシステムやネットワークで起きている事象を監視し、インシデントの兆候がないかを分析するプロセス
• 侵入防止：侵入検知を行ったうえで、検知した事象を止めようと試みるプロセス
• IDS：侵入検知のプロセスを自動化するソフトウェア
• IPS：IDSのすべての機能を持ち、加えて事象を止めようと試みることができるソフトウェア

つまりIPSはIDSの上位互換です。まったく別のジャンルの製品ではありません。

日本語の公的な資料でも同じ整理がされています。IPA（情報処理推進機構）の「情報セキュリティ10大脅威 2025」付録『セキュリティ対策の基本と共通対策』では、IDSを「不正侵入検知システム」と呼び、ネットワーク通信を監視して不審な通信が見つかった際に担当者へ通知を行うもので、自動でブロックする機能はないと説明しています。IPSは「不正侵入防止システム」で、通知だけでなく自動でブロックも行うとされています。

IPSが「止める」やり方は3種類ある

NIST SP 800-94は、IPSが取る対応を3つに分類しています。「遮断」と一言で言っても中身が違います。

1. 攻撃そのものを止める：使われている通信やセッションを切断する、攻撃元のIPアドレスやアカウントからのアクセスを遮断する、対象のホストやサービスへのアクセスを全部止める
2. セキュリティ環境を変える：ファイアウォールやルーター、スイッチの設定を変更して攻撃元を遮断する。対象ホストのホスト型ファイアウォールを変更する
3. 攻撃の中身を書き換える：攻撃の悪意ある部分だけを取り除いて無害化する。例として、メールから感染したファイル添付を削除したうえで配送する動きが挙げられています

2. 置き場所で決まる：パッシブとインライン

なぜIDSは止められず、IPSは止められるのか。答えは性能ではなく物理的な置き場所です。

NIST SP 800-94は、センサーの配置を2つに分けています。

パッシブで通信のコピーを取る方法として、同文書はスパニングポート（スイッチの全通信が見えるポート）とネットワークタップを挙げています。

そしてはっきりこう書かれています。センサーが侵入を防止する手法のほとんどはインライン配置を必要とし、パッシブでは実現できない。コピーを見ているだけでは、本物のパケットが宛先に届くのを止める手段がないからです。結論として、防止機能を使うならインライン、使わないならパッシブという指針が示されています。

3. 監視対象で分ける：ネットワーク型とホスト型

次の分け方は「何を見ているか」です。NIST SP 800-94は4種類を挙げています。

学習の入口としては、まずネットワーク型（NIDS）とホスト型（HIDS）の2つを押さえれば十分です。代表的なオープンソース製品は次のとおりです。

この記事では、IDSとIPSの両方を1つのソフトで試せるSuricataを使います。

4. 検知方式の3種類：シグネチャ・アノマリ・プロトコル解析

「どうやって不審だと判断するのか」も、NIST SP 800-94が3つに整理しています。ここは面接や資格試験でもよく問われる部分です。

シグネチャ型

シグネチャとは既知の脅威に対応するパターンのことです。シグネチャ型検知は、そのパターンと観測した事象を突き合わせる方式です。同文書が挙げている例を借りると、ユーザー名 root でのtelnet試行や、特定の件名と添付ファイル名の組み合わせなどが該当します。

この方式は既知の脅威にはとても強く、未知の脅威にはほとんど無力です。理由も明快に書かれています。攻撃者が添付ファイル名を freepics.exe から freepics2.exe に変えただけで、元のシグネチャは一致しなくなるからです。

この弱点は、後ほど実際に手元で再現します。

アノマリ型

アノマリ型検知は、「正常」と定義した状態と観測した事象を比べ、大きなズレを見つける方式です。一定期間ふだんの動きを観測してプロファイルを作ります。同文書の例では、あるネットワークの平日日中のWeb通信が帯域の平均13%を占める、といったプロファイルを作り、統計的に現在の状態と比較します。

未知の攻撃も捉えられる反面、アラートが正しいのか判断しづらいという課題も挙げられています。

ステートフルプロトコル解析

ベンダーが用意した「このプロトコルは本来こう使われるはず」という汎用のプロファイルと比較する方式です。アノマリ型が「その組織にとっての正常」を学ぶのに対し、こちらは「プロトコルとしての正しさ」を見ます。「ステートフル」とは、状態を持つプロトコルの状態を追跡できることを指します。

5. ファイアウォール・WAF・EDRとの守備範囲の違い

似た用語が多くて混乱しやすいので、ここで地図を作っておきます。IPAの前掲資料の説明をもとに整理しました。

IDS／IPSとWAFの関係について、IPAは明確に書いています。IDS・IPSがネットワークレベルの監視を行うのに対して、WAFはアプリケーションレベルの監視であるため、組み合わせて適用することでより強固な防御になる、という整理です。どちらかがあれば足りる、という関係ではありません。

6. 実際に動かす：Suricataで検知ラボを作る

ここからは手を動かします。外部への通信は一切行いません。自分で作った通信記録ファイル（pcap）をSuricataに読ませるだけなので、安全に、何度でも試せます。

手順1：Suricataを入れる

macOSの場合はHomebrewで入ります。

brew install suricata
suricata -V

筆者の環境（Apple Silicon Mac）では以下が表示されました。この記事の実行結果はすべてこのバージョンのものです。

Ubuntu・Debianなら sudo apt install suricata で導入できます。配布元によって入るバージョンは異なるため、同じく suricata -V で確認してください。

手順2：練習用の通信記録（pcap）を作る

本来はネットワークを流れるパケットを捕まえて記録しますが、それには管理者権限と実際の通信が必要です。学習の最初の一歩としては大げさなので、HTTPリクエスト1本ぶんのpcapをPythonで組み立てます。中身が完全にわかっているファイルを使うほうが、検知結果の意味もはっきりします。

以下を make_pcap.py として保存してください。標準ライブラリだけで動きます。

#!/usr/bin/env python3
"""学習用のHTTPリクエストを1本だけ含むpcapを作る。実際の通信は一切行わない。"""
import struct

CLIENT, SERVER = "192.168.10.50", "203.0.113.10"
SPORT, DPORT = 50000, 80

def ip2b(s): return bytes(int(x) for x in s.split("."))

def csum(b):
    if len(b) % 2: b += b"\x00"
    s = sum(struct.unpack("!%dH" % (len(b) // 2), b))
    while s >> 16: s = (s & 0xFFFF) + (s >> 16)
    return (~s) & 0xFFFF

def tcp(src, dst, sport, dport, seq, ack, flags, payload=b""):
    off_flags = (5 << 12) | flags
    hdr = struct.pack("!HHIIHHHH", sport, dport, seq, ack, off_flags, 8192, 0, 0)
    pseudo = ip2b(src) + ip2b(dst) + struct.pack("!BBH", 0, 6, len(hdr) + len(payload))
    c = csum(pseudo + hdr + payload)
    return hdr[:16] + struct.pack("!H", c) + hdr[18:] + payload

def ip(src, dst, payload, ident):
    total = 20 + len(payload)
    hdr = struct.pack("!BBHHHBBH", 0x45, 0, total, ident, 0x4000, 64, 6, 0) + ip2b(src) + ip2b(dst)
    hdr = hdr[:10] + struct.pack("!H", csum(hdr)) + hdr[12:]
    return hdr + payload

def eth(payload):
    return b"\x02\x00\x00\x00\x00\x01" + b"\x02\x00\x00\x00\x00\x02" + b"\x08\x00" + payload

def build(path, uri, user_agent):
    req = ("GET %s HTTP/1.1\r\nHost: example.test\r\nUser-Agent: %s\r\n"
           "Accept: */*\r\nConnection: close\r\n\r\n" % (uri, user_agent)).encode()
    res = (b"HTTP/1.1 200 OK\r\nServer: nginx\r\nContent-Type: text/html\r\n"
           b"Content-Length: 5\r\nConnection: close\r\n\r\nhello")
    cs, ss = 1000, 5000
    frames = [
        (CLIENT, SERVER, cs, 0, 0x002, b""),                      # SYN
        (SERVER, CLIENT, ss, cs + 1, 0x012, b""),                 # SYN,ACK
        (CLIENT, SERVER, cs + 1, ss + 1, 0x010, b""),             # ACK
        (CLIENT, SERVER, cs + 1, ss + 1, 0x018, req),             # リクエスト
        (SERVER, CLIENT, ss + 1, cs + 1 + len(req), 0x018, res),  # レスポンス
        (CLIENT, SERVER, cs + 1 + len(req), ss + 1 + len(res), 0x011, b""),
    ]
    with open(path, "wb") as f:
        f.write(struct.pack("!IHHiIII", 0xA1B2C3D4, 2, 4, 0, 0, 65535, 1))
        for i, (s, d, seq, ack, fl, pl) in enumerate(frames):
            sp, dp = (SPORT, DPORT) if s == CLIENT else (DPORT, SPORT)
            frame = eth(ip(s, d, tcp(s, d, sp, dp, seq, ack, fl, pl), 100 + i))
            f.write(struct.pack("!IIII", 1789984800, i * 1000, len(frame), len(frame)) + frame)
    print("%s を作成（URI=%s, UA=%s）" % (path, uri, user_agent))

if __name__ == "__main__":
    build("attack.pcap", "/admin.php?id=1", "sqlmap/1.8")
    build("evade.pcap", "/admin.php?id=1", "sq1map/1.8")
    build("normal.pcap", "/index.html", "Mozilla/5.0")
    build("falsepositive.pcap", "/blog/admin.php-no-mamorikata.html", "Mozilla/5.0")

python3 make_pcap.py

4つのpcapができます。それぞれの中身は次のとおりです。

手順3：検知ルールを2本書く

local.rules として保存します。

alert http any any -> any any (msg:"LOCAL 管理画面 /admin.php へのアクセス"; flow:established,to_server; http.uri; content:"/admin.php"; sid:1000001; rev:1;)
alert http any any -> any any (msg:"LOCAL 既知のスキャナ sqlmap の User-Agent"; flow:established,to_server; http.user_agent; content:"sqlmap"; nocase; sid:1000002; rev:1;)

Suricataのルールは公式ドキュメントのとおりアクション・ヘッダー・オプションの3つでできています。1行目を分解するとこうなります。

アクションには alert のほか pass、drop、reject、rejectdst、rejectboth があります。drop 以降はIPSモードでしか使えません。この違いは後の章で実際に確かめます。

手順4：実行する

mkdir -p out_attack
suricata -r attack.pcap -S local.rules -l out_attack
cat out_attack/fast.log

-r が読み込むpcap、-S が使うルールファイル（これだけを使う指定）、-l がログの出力先です。管理者権限は不要です。実際の出力がこちらです。

2本のルールが両方とも一致しました。[1:1000001:1] は「ジェネレータID : sid : rev」です。これがシグネチャ型のIDSが動いている状態です。

7. 検知漏れと誤検知を自分で起こす

ここがこの記事でいちばん大事な章です。IDSの限界は、説明を読むより自分で起こしたほうが早く身につきます。

検知漏れ：1文字変えるだけですり抜ける

evade.pcap は、User-Agentを sqlmap/1.8 から sq1map/1.8 に変えただけです。l（エル）を1（数字のいち）に置き換えています。

mkdir -p out_evade
suricata -r evade.pcap -S local.rules -l out_evade
cat out_evade/fast.log

アラートが2件から1件に減りました。URIのルールは一致しましたが、User-Agentのルールはすり抜けています。攻撃の内容はまったく同じなのに、文字を1つ変えただけで検知できなくなりました。

これがNIST SP 800-94の言う、シグネチャ型は変形された既知の脅威に弱いということです。freepics.exe を freepics2.exe に変えると一致しなくなる、というあの説明を、自分の手元で再現したことになります。見つけられなかったこの状態をfalse negative（検知漏れ）と呼びます。

誤検知：無害な記事のURLが引っかかる

逆の失敗も起こしてみます。falsepositive.pcap がアクセスしているのは /blog/admin.php-no-mamorikata.html、つまり「admin.phpの守り方」というブログ記事のページです。攻撃ではありません。

mkdir -p out_fp
suricata -r falsepositive.pcap -S local.rules -l out_fp
cat out_fp/fast.log

無害なページなのにアラートが出ました。URIに /admin.php という文字列がたまたま含まれていたからです。これがfalse positive（誤検知）です。

ちなみに normal.pcap（/index.html へのふつうのアクセス）では、アラートは0件でした。4つの結果をまとめます。

試しに、誤検知のほうを直してみてください。1本目のルールの content:"/admin.php" を content:"/admin.php?" に変えると、記事URLのほうは一致しなくなります。ただしこれで万全ではありません。パラメータなしで /admin.php を直接叩かれたら、今度は検知漏れになります。この行ったり来たりがチューニングの実際です。

8. alertをdropに変えるとIPSになる

最後に、IDSとIPSの違いを同じツール・同じ通信で見比べます。ルールのアクションを alert から drop に変えるだけです。

sed 's/^alert /drop /' local.rules > local-ips.rules
mkdir -p out_ips
suricata -r attack.pcap -S local-ips.rules -l out_ips --simulate-ips
cat out_ips/fast.log

--simulate-ips はSuricataの公式オプションで、エンジンを強制的にIPSモードにします。ヘルプには「QAに便利」と書かれている検証用の指定です。結果がこちらです。

[Drop] という表示が増えました。構造化ログ（eve.json）で比べると違いはもっと明確です。

同じソフト、同じ通信、同じ検知ロジックで、違うのは「見つけたあとどうするか」だけ。第1章の定義が、そのまま出力に現れています。

本物のIPSにするには何が要るか

いま試したのは記録済みファイルに対するシミュレーションです。実際のネットワークで遮断するには、第2章で見たとおり通信が必ずSuricataを通る配置が必要になります。公式ドキュメントは、レイヤー2（ブリッジ）ならAF_PACKETやDPDK、レイヤー3（ルーティング）ならNFQueueやIPFWといった取り込み方式を挙げています。

動作の違いもあります。公式のIPS解説によると、IDSモードではTCPの通信はACKを受け取ってから検査されるのに対し、IPSモードでは新しいデータをスライディングウィンドウ方式で即座に検査します。止めるには「届く前に判断する」必要があるためで、そのぶん再走査が発生して性能に影響します。

また、SuricataのIPSは既定ではすべての通信を許可し、drop や reject のルールで止めたいものだけを止める設計です。すべてを遮断してから穴を開けるファイアウォールとは発想が逆になります。

9. よくある質問

10. まとめ

今日やれる最初の一歩は、brew install suricata と、この記事の make_pcap.py を実行することです。4つのpcapを順に読ませて、2件・1件・0件・1件というアラート数が再現できれば、IDSの仕組みと限界を実物で理解できたことになります。

そのうえで alert を drop に書き換えれば、そこからはIPSです。違いは、その1語だけでした。

AIツールを使う場面でのセキュリティの考え方はAI時代のセキュリティ対策｜入力情報・連携権限・公開前の確認リストで、AIにコードを書かせるときの危険と対策はバイブコーディングのセキュリティリスク完全ガイドでそれぞれ解説しています。