Snort の誤検知は、ルールを丸ごと止めるのではなく「どのルールが・どの通信で・なぜ反応したか」を確かめてから、送信元や宛先を絞った抑制（suppress）や件数の間引き（event_filter）で対処するのが基本です。この記事では、アラートの読み方、誤検知かどうかの判定、Snort 3 と Snort 2 それぞれの抑制の書き方、WordPress サイトでよく起きる誤検知のパターンまでを順に説明します。
誤検知対応の全体像
誤検知（false positive）を見つけたときに、いちばん避けたいのは「うるさいからルールのカテゴリごと無効化する」対応です。これをやると、本物の攻撃が来たときにも黙ってしまいます。作業は次の順で進めます。
- アラートから GID・SID・送信元・宛先・時刻を控える
- ルール本文を読み、何に反応するルールなのかを把握する
- 該当する通信を確認し、正規の通信かどうかを判定する
- 正規なら、影響範囲が最も狭い方法で抑制する
- 設定を検証してから反映し、変更理由を記録する
この順番を守ると、抑制の範囲を説明できるようになり、後から見直すときにも迷いません。
なお、Snort 2 系は新規導入では Snort 3 が推奨されており、2 系のサポート終了も告知されています（2026年10月現在）。本記事は Snort 3 を中心に、2 系の書き方も併記します。設定ファイルの場所はインストール方法によって異なるため、以下のパスは例として読み替えてください。
手順1：アラートから必要な情報を控える
Snort 3 で alert_fast を使っている場合、1 行のアラートは次のような形になります。
10/28-09:12:44.123456 [**] [1:2000001:3] "WEB-APP possible SQL injection attempt" [**] [Classification: Web Application Attack] [Priority: 1] {TCP} 198.51.100.20:51544 -> 192.0.2.10:80[1:2000001:3] は「GID:SID:リビジョン」です。GID が 1 なら通常のテキストルール、それ以外はプリプロセッサ（Snort 3 ではインスペクター）が出したイベントであることが多く、抑制の書き方も GID ごとに指定します。ここを SID だけで覚えていると、別のイベントまで抑制してしまうことがあるので、GID と SID は組で控えてください。
あわせて、送信元 IP・宛先 IP とポート・発生時刻・同じ SID の発生件数を確認します。同じ SID が特定の 1 台からだけ大量に出ているのか、不特定多数から出ているのかで、後の判断が変わります。
手順2：ルール本文を読む
SID が分かったら、ルールファイルから本文を探します。
grep -rn "sid:2000001;" /usr/local/etc/rules/見るべきところは content、pcre、http_uri や http_client_body などのバッファ指定、flow です。「URI に特定の文字列が含まれたら」なのか「POST の本文に SQL らしい語が含まれたら」なのかで、誤検知の起きやすさは大きく違います。Snort 公式のルール文書（Snort.org の Rule Docs）で SID を検索すると、ルールの意図や既知の誤検知が載っていることがあります。
手順3：その通信が正規かどうかを判定する
判定の材料は、ルールが見ている部分と実際の通信の中身です。可能であれば次の情報を突き合わせます。
- Web サーバーのアクセスログ（同じ時刻・送信元 IP の行）
- アプリケーション側の操作記録（誰が何を保存したか）
- パケットキャプチャ（
log_pcapを有効にしている場合、または別途 tcpdump で取得したもの）
キャプチャがあれば、Snort に読み直させて再現できます。設定変更の前後で同じ pcap を流すと、抑制が効いたかを本番に触れずに確かめられます。
snort -c /usr/local/etc/snort/snort.lua -r sample.pcap -A alert_fast判定の目安は次のとおりです。
- 送信元が自社の管理者・監視サーバー・連携サービスで、操作記録と一致する → 誤検知の可能性が高い
- 送信元が不特定で、ペイロードに攻撃文字列の典型パターンが並ぶ → 誤検知ではなく本物の攻撃試行
- 正規利用者だが、送信内容がたまたま攻撃パターンに似ている（記事本文に SQL やスクリプトの説明を書いた等） → 誤検知。ただし抑制範囲は利用者と URL に絞る
迷った場合は抑制せず、しばらくアラートの傾向を観察するほうが安全です。
手順4：影響範囲の狭い方法で抑制する
抑制の方法は、影響範囲が狭い順に選びます。
- 特定の送信元（または宛先）に限って特定の SID を抑制する（suppress + ip）
- 特定の SID のアラート件数を間引く（event_filter）
- 特定の SID を抑制する（suppress、IP 指定なし）
- ルール自体を無効にする
Snort 3 の suppress
Snort 3 では Lua の設定ファイル（snort.lua から読み込む local.lua など）にテーブルとして書きます。
suppress =
{
-- 監視サーバー 192.0.2.50 から出る SID 2000001 だけを抑制
{ gid = 1, sid = 2000001, track = 'by_src', ip = '192.0.2.50' },
-- 社内ネットワーク宛ての SID 2000002 を抑制
{ gid = 1, sid = 2000002, track = 'by_dst', ip = '10.0.0.0/8' },
}track = 'by_src' は送信元、'by_dst' は宛先で照合します。IP は CIDR でも書けますが、広すぎる範囲を指定すると抑制の意味が変わるので、必要な範囲にとどめてください。
Snort 3 の event_filter
通信自体は正規でも、監視ツールの定期アクセスなどで同じアラートが大量に出る場合は、件数を間引きます。
event_filter =
{
-- 送信元ごとに 60 秒で 1 件だけ記録する
{ gid = 1, sid = 2000003, type = 'limit', track = 'by_src', count = 1, seconds = 60 },
}type には limit・threshold・both があります。event_filter は記録を減らすだけで、検知そのものは止めません。攻撃でも 1 件は残るので、suppress より安全側の選択肢です。
Snort 2 系の書き方
Snort 2 系では threshold.conf などに次の形式で書き、snort.conf から読み込みます。
suppress gen_id 1, sig_id 2000001, track by_src, ip 192.0.2.50
event_filter gen_id 1, sig_id 2000003, type limit, track by_src, count 1, seconds 60ルールを無効にする場合
ルール自体がこの環境に合わない（使っていない製品向けのルールなど）と判断した場合のみ、無効化を検討します。ルールファイルを直接編集すると、ルール更新で上書きされて元に戻るので、PulledPork 3 などの更新ツールを使っている場合はそのツールの無効化リストで管理するのが一般的です。設定項目の名前はツールのバージョンで変わることがあるため、使用中のツールの README で確認してください。
手順5：検証してから反映する
設定を変えたら、反映前に構文と読み込みを確認します。
snort -c /usr/local/etc/snort/snort.lua -Tエラーが出なければ、手順3の pcap を流して、狙った SID だけが消え、他のアラートは残っていることを確かめます。その後、運用中のプロセスを再起動（または設定の再読み込み）します。サービス名や再起動方法は環境によって違うため、systemd のユニット名などを事前に確認してください。
変更時には、次の内容を設定ファイルのコメントか変更記録に残しておくと、半年後に見直すときに助かります。
- 抑制した GID:SID と対象 IP
- 誤検知と判断した根拠（どのログと照合したか）
- 変更日と担当者、見直し予定日
WordPress サイトで起きやすい誤検知
WordPress の前に Snort を置いている場合、次のような通信が Web 攻撃系のルールに反応しやすい傾向があります。
- ブロックエディターでの保存（REST API への JSON の POST）。記事本文に SQL 文や
<script>の解説を書くと、SQL インジェクションや XSS のルールに反応することがあります admin-ajax.phpへの頻繁な POST（ページビルダーやフォームプラグイン）- 外部サービスからの Webhook や、監視サービスの定期アクセス
xmlrpc.phpへのアクセス（正規の連携と攻撃の両方があるため、判定は慎重に）
これらは「URL と送信元を絞った suppress」で対処できることが多いですが、wp-admin 以下を丸ごと抑制するのは避けてください。管理画面は攻撃者にとっても重要な標的です。
もう一つの注意点は TLS です。Snort をネットワーク上に置いている場合、HTTPS の通信は暗号化されたまま見えるため、HTTP の中身を見るルールは基本的に反応しません。ロードバランサーやリバースプロキシで TLS を終端した後の平文区間にセンサーを置いている構成でだけ、上記のような誤検知が起きます。「同じ操作なのに環境によってアラートが出たり出なかったりする」場合は、センサーの位置を確認してください。
まとめ
- 誤検知対応は「GID:SID と送信元・宛先を控える → ルール本文を読む → 通信を照合して判定 → 狭い範囲で抑制 → 検証して反映」の順で進めます
- 抑制は suppress（IP 指定あり）、event_filter、suppress（IP 指定なし）、ルール無効化の順に影響範囲が広がります。迷ったら狭いほうを選びます
- Snort 3 は Lua のテーブル、Snort 2 系は
threshold.conf形式で書き、-Tでの構文確認と pcap での再現確認を経てから反映します - WordPress では REST API や admin-ajax.php への正規の POST が誤検知の原因になりやすく、TLS の終端位置によってアラートの出方が変わります
- 抑制には根拠と見直し日を記録し、定期的に棚卸しします