Wazuh の誤検知は、どのルール（rule.id）がどのログに反応したかを確認し、local_rules.xml に「条件を絞った子ルール」を書いてレベルを下げる、という方法で対処するのが基本です。元のルールファイルを直接編集すると更新で上書きされるため避けます。WordPress サーバーでは、ログ解析のルールのほか、ファイル整合性監視（FIM）とプラグイン更新の組み合わせ、Active Response による正規の利用者の遮断も誤検知の原因になりやすい部分です。この記事では、それぞれの確認方法と調整手順を説明します。
まず誤検知の中身を確認する
Wazuh マネージャーは、アラートを /var/ossec/logs/alerts/alerts.json に JSON 形式で記録します。ダッシュボードでも確認できますが、調整に必要な情報をまとめて見るには JSON を直接読むのが早道です。
# 件数の多いルールを上位から表示
sudo jq -r '"\(.rule.id)\t\(.rule.level)\t\(.rule.description)"' \
/var/ossec/logs/alerts/alerts.json | sort | uniq -c | sort -rn | head -20気になるルールが分かったら、該当するアラートの詳細を見ます。
sudo jq 'select(.rule.id=="31101") | {timestamp, agent: .agent.name, rule: .rule, data: .data, full_log}' \
/var/ossec/logs/alerts/alerts.json | head -80ルール番号は例です。確認するのは、どのエージェント（サーバー）で出たか、元のログ（full_log）は何か、送信元 IP や URL などのデコード結果（data）は何か、の3点です。送信元が自社の監視サービスやバックアップの転送先で、内容が WordPress の正規の処理であれば誤検知と判断できます。身元が分からない相手であれば、誤検知と決めつけずに調査を続けます。
wazuh-logtest でルールの当たり方を確かめる
調整の前後で、ログ1行がどのデコーダーとルールに当たるかを確かめるには wazuh-logtest を使います。マネージャー上で起動し、full_log の内容を貼り付けると、どのルールがどのレベルで一致したかが表示されます。
sudo /var/ossec/bin/wazuh-logtestこれを使うと、マネージャーを再起動する前に、新しく書いたルールが意図どおりに当たるかを確認できます。調整は「logtest で確認 → 反映 → 実際のアラートで確認」の順で進めます。
ルールの誤検知を抑える
条件を絞った子ルールで level 0 にする
Wazuh では、既存のルールを親として if_sid で指定し、条件を足した子ルールを書けます。子ルールのレベルを 0 にすると、その条件に当てはまるイベントはアラートとして記録されません。カスタムルールはマネージャーの /var/ossec/etc/rules/local_rules.xml に書き、ID は利用者向けに用意されている 100000 番台を使います。
<group name="local,wordpress,">
<!-- 外部監視サービスからのアクセスで出る 31101 を抑制する例 -->
<rule id="100100" level="0">
<if_sid>31101</if_sid>
<srcip>192.0.2.10</srcip>
<description>Ignore web 400 errors from uptime monitor</description>
</rule>
<!-- 特定の URL に限定して抑制する例 -->
<rule id="100101" level="0">
<if_sid>31101</if_sid>
<url>/wp-json/my-plugin/v1/health</url>
<description>Ignore 400 errors on health check endpoint</description>
</rule>
</group>親ルールの ID、送信元 IP、URL は実際のアラートの内容に置き換えてください。送信元や URL で絞っておけば、同じルールでも他の相手からの通信は引き続き検知されます。ルール全体を黙らせるより影響が小さく、あとから見直すときも理由が分かりやすくなります。
元のルールを書き換える場合
条件の追加では対応できず、ルールそのもののレベルを変えたい場合は、同じ ID のルールを local_rules.xml に overwrite="yes" 付きで書き直す方法があります。元のルールの内容を丸ごと写したうえでレベルだけ変える使い方が安全です。ただし、上書きしたルールは公式の更新が入っても自動では反映されないため、更新時に差分を確認する手間が増えます。まずは子ルールで済ませられないかを検討してください。
反映
設定を保存したら、マネージャーを再起動して読み込みます。XML の書き間違いがあると起動に失敗するため、反映後に状態を確認します。変更前の local_rules.xml はバックアップしておいてください。
sudo systemctl restart wazuh-manager
sudo systemctl status wazuh-manager --no-pagerクラスター構成の場合は、ルールを置くノードと同期の扱いを公式ドキュメントで確認してから作業します。
FIM（ファイル整合性監視）の誤検知
WordPress のサーバーでは、プラグインやテーマの更新、キャッシュプラグインの生成ファイル、アップロード画像の追加によって、ファイル変更のアラートが大量に出ることがあります。これはルールではなく、エージェント側の ossec.conf の syscheck 設定で調整します。
<syscheck>
<directories realtime="yes" check_all="yes">/var/www/html</directories>
<!-- 頻繁に変わり、改ざん検知の対象として意味の薄い場所を除外 -->
<ignore>/var/www/html/wp-content/cache</ignore>
<ignore>/var/www/html/wp-content/upgrade</ignore>
<ignore type="sregex">\.log$</ignore>
</syscheck>除外するときは、攻撃者がファイルを置きやすい場所まで外さないように注意します。たとえば wp-content/uploads を丸ごと除外すると、アップロード経由で置かれた PHP ファイルにも気付けなくなります。除外ではなく、更新作業の時間帯のアラートを作業記録と照らし合わせて確認する運用にする選択肢もあります。
自動更新を有効にしている場合は、更新の時刻とアラートの時刻が一致するかを見れば、正規の変更かどうかを判断しやすくなります。
Active Response で正規の利用者が遮断された場合
Active Response を使って、特定のルールに当たった IP をファイアウォールで遮断している構成では、誤検知がそのまま「正規の利用者や監視サービスが入れない」障害になります。症状が出たら、まずマネージャーの alerts.json で該当 IP が遮断されたときのルールを確認し、エージェント側の active-responses.log で実行記録を確かめます。
sudo tail -n 50 /var/ossec/logs/active-responses.log遮断されては困る IP（自社の固定 IP、監視サービス、決済事業者からの通知など）は、マネージャーの ossec.conf の global セクションにある white_list に登録しておくと、Active Response の対象から外せます。
<global>
<white_list>192.0.2.10</white_list>
<white_list>198.51.100.0/24</white_list>
</global>ルールの誤検知そのものを直すのが本筋で、white_list は遮断による業務停止を防ぐための備えと考えます。
運用のコツ
- 調整したルール ID・条件・理由・日付を記録に残し、定期的に見直す
- 抑制は「送信元」「URL」「エージェント」のどれかで絞り、ルール全体の無効化は最後の手段にする
- 誤検知を減らした結果、メール通知のレベル設定が適切かも見直す。通知が多すぎると本当に重要なアラートが埋もれる
- Wazuh のバージョンによって設定項目やダッシュボードの画面が変わることがあるため（2026年10月現在）、作業前に利用中のバージョンのドキュメントを確認する
まとめ
- まず alerts.json で rule.id・エージェント・full_log・送信元を確認し、理由を説明できるものだけを誤検知と判断する
- ルールの誤検知は local_rules.xml に if_sid で条件を絞った level 0 の子ルールを書いて抑える。元のファイルは編集しない
- wazuh-logtest で当たり方を確かめてから反映し、再起動後に状態を確認する
- FIM の誤検知は syscheck の ignore で調整するが、uploads など攻撃に使われやすい場所は外さない
- Active Response の誤遮断に備え、必要な IP を white_list に登録しておく