Suricata の誤検知は、ルールを丸ごと無効にする前に「どのルールが・どの通信で・なぜ反応したか」を eve.json で確かめ、影響範囲がいちばん狭い方法で抑えるのが基本です。調整の手段は、送信元を限定した suppress、件数を減らす threshold、suricata-update による無効化や書き換え、そして HOME_NET などの変数の見直しの順に検討します。この記事では WordPress サイトを守る環境でよく出る誤検知を例に、アラートの読み方から調整、反映後の確認までを説明します。
誤検知かどうかを判断する
最初に、アラートが本当に誤検知なのかを確かめます。Suricata の詳細ログは既定の設定では /var/log/suricata/eve.json に JSON 形式で出力されます（パスは suricata.yaml の設定によります）。まずは件数の多いルールを把握します。
# アラートが多いルール（sid と名前）を上位から表示
jq -r 'select(.event_type=="alert") | "\(.alert.signature_id)\t\(.alert.signature)"' \
/var/log/suricata/eve.json | sort | uniq -c | sort -rn | head -20気になるルールが見つかったら、そのルールのアラートを1件ずつ見ます。
jq 'select(.event_type=="alert" and .alert.signature_id==2000000)
| {timestamp, src_ip, dest_ip, dest_port, sig: .alert.signature, http: .http}' \
/var/log/suricata/eve.json | head -602000000 は例なので、上位に出た実際の sid に置き換えてください。判断の材料になるのは次の項目です。
- 送信元：自社の監視サービス、バックアップの転送先、社内の固定 IP など、身元の分かる相手か
- 宛先と URL：
/wp-admin/admin-ajax.php、/wp-json/、/wp-cron.phpなど WordPress の正規の処理か - 頻度と時間帯：定期実行のタイミングと一致しているか
- ルールの説明：ルールセットの公開情報で、何を検知する意図のルールかを読む
身元が分からない送信元からの、正規の処理ではない URL への通信は、誤検知と決めつけずに調査を続けます。誤検知の判断は「理由を説明できるもの」に限るのが安全です。
WordPress でよく出る誤検知のパターン
WordPress 環境で比較的よく見かけるのは次のような反応です。
- ブロックエディターの保存：投稿本文に
<script>やコード例、SQL のような文字列が含まれると、REST API への送信が Web 攻撃系のルールに一致することがあります。技術ブログでは特に起きやすいパターンです。 - 管理画面の定期通信：Heartbeat API による admin-ajax.php への定期的なリクエストが、短時間に多数の POST として扱われることがあります。
- 外部監視とスキャナー：死活監視や自社で契約している脆弱性診断の通信が、スキャン検知のルールに当たります。
- ループバック通信：WP-Cron やサイトヘルスがサーバー自身へ送るリクエストが、想定外の送信元として見えることがあります。
なお、HTTPS の通信はそのままでは Suricata から中身が見えません。HTTP の URL や本文に関するアラートが出ているなら、TLS を終端した後ろ（リバースプロキシとアプリの間など）に Suricata を置いている構成か、平文の通信が残っているかのどちらかです。どこで通信を見ているかを把握しておくと、誤検知の原因を追いやすくなります。
調整の手段を狭い順に選ぶ
誤検知と判断できたら、影響が小さい方法から検討します。調整用のファイルは変更前にバックアップを取ってください。
1. suppress：特定の送信元だけ黙らせる
監視サービスなど、送信元がはっきりしている誤検知には suppress が向いています。suricata.yaml の threshold-file で指定したファイル（多くの環境で /etc/suricata/threshold.config）に書きます。
# 外部監視サービスからの通信で出る sid 2000000 を抑制（例）
suppress gen_id 1, sig_id 2000000, track by_src, ip 192.0.2.10
# 社内ネットワークからの通信だけ抑制
suppress gen_id 1, sig_id 2000000, track by_src, ip 198.51.100.0/24同じルールでも他の送信元からの通信は引き続き検知されるため、攻撃を見逃す範囲を小さくできます。track by_dst を使えば宛先側で絞ることもできます。
2. threshold：件数だけ減らす
正規の通信と攻撃の両方で反応するルールで、アラートの量が問題になっている場合は、一定時間内のアラート件数を制限します。
# 送信元ごとに60秒あたり1件まで記録する
threshold gen_id 1, sig_id 2000000, type limit, track by_src, count 1, seconds 60検知そのものは残るので、調査の手がかりを失わずにログの量を抑えられます。
3. suricata-update でルールを無効化・書き換え
どの環境でも役に立たないと判断できるルールは、suricata-update の設定で無効にします。ルールファイルを直接編集すると、次の更新で元に戻ってしまうためです。
# /etc/suricata/disable.conf
2000000
# 正規表現でまとめて指定することもできる
re:ET POLICY .* exampleルールの一部を変えたい場合は modify.conf、IPS モードで遮断させたいルールは drop.conf を使います。設定後に suricata-update を実行してルールファイルを作り直します。無効化は検知を手放すことなので、理由と日付を記録に残し、定期的に見直す対象にしておきます。
4. 変数の見直し
特定のルールではなく全体的に誤検知が多い場合は、suricata.yaml の HOME_NET と EXTERNAL_NET が実際のネットワーク構成と合っているかを確認します。HOME_NET に自社のサーバーが入っていないと、内部の正規の通信が外部からのものとして扱われ、多くのルールが余計に反応します。Docker のブリッジネットワークやクラウドの VPC の範囲を入れ忘れるケースがよくあります。
反映と確認
設定を変えたら、まず構文を確認します。
sudo suricata -T -c /etc/suricata/suricata.yaml -vエラーが無ければルールを読み込み直します。Unix ソケットを有効にしている環境では次のコマンドが使えます。使えない場合は、サービスの再起動やディストリビューションの手順に従ってください。
sudo suricatasc -c reload-rules反映後は、誤検知の原因になっていた通信（監視サービスのアクセスやエディターでの保存など）を再現し、eve.json に該当のアラートが出なくなったことと、他の送信元からの同じ種類の通信では引き続き検知されることを確かめます。後者の確認を省くと、意図より広く抑えてしまったことに気付けません。
IPS モードで遮断されている場合
Suricata をインラインの IPS として使っていると、誤検知はそのまま「正規の通信が止まる」障害になります。WordPress の管理画面で保存できない、決済の戻りが失敗するといった症状が出たら、eve.json で "action":"blocked" のアラートを探します。急ぎの場合は該当ルールを suppress で一時的に外し、原因を調べてから恒久的な調整を決めます。
新しいルールセットを導入するときや大きく構成を変えるときは、いきなり遮断させず、IDS モード（検知のみ）でしばらく運用して誤検知を洗い出してから IPS に切り替える進め方が安全です。ルールセットの内容や更新の頻度は提供元によって変わるため（2026年10月現在）、利用中のルールセットのドキュメントも確認してください。
運用のコツ
- 調整内容（sid・方法・理由・日付・担当者）を表にして残し、半年ごとなどに見直す
- 抑制した通信も、ルール自体の更新（rev の変更）があったときは再確認する
- 誤検知が多いからといってルールカテゴリーごと無効にしない。まず変数と suppress で減らせないかを試す
- WordPress 側のログ（アクセスログや PHP のエラーログ）と時刻を突き合わせると、正規の処理かどうかを判断しやすい
まとめ
- 誤検知の対応は、eve.json で sid・送信元・URL・頻度を確認し、理由を説明できるものだけを誤検知と判断する
- 調整は suppress（送信元限定）→ threshold（件数制限）→ suricata-update での無効化・書き換えの順に、影響の狭い方法から選ぶ
- 全体的に誤検知が多いときは HOME_NET などの変数を疑う
- 反映前に suricata -T で構文を確認し、反映後は誤検知が消えたことと他の通信で検知が残ることを両方確かめる
- IPS モードの導入は IDS モードで誤検知を洗い出してから