ModSecurity の audit log を Grafana で見る理由 – WAF を観測可能な防御点として扱う

WAF は、導入した時点で運用が終わる仕組みではありません。ModSecurity と OWASP Core Rule Set を有効にすれば、不審なリクエストを遮断できる可能性は高まります。しかし、実際の運用では「止めた」という結果だけでは不十分です。どのリクエストを、どのルールやスコアで、どの入口で止めたのかを後から確認できなければ、攻撃の可視化にも、誤検知の調整にもつながりません。

そのため、ModSecurity は通信を止める機能としてだけでなく、境界で発生した判断を記録する観測点として扱うべきです。audit log を Loki に集約し、Grafana でダッシュボード化すると、WAF の動作を「なんとなく効いている」状態から、運用上の判断材料へ変えられます。

この記事では、特定環境のホスト名や IP アドレスには踏み込まず、reverse proxy に置いた ModSecurity の audit log を Grafana で見る方法論を整理します。

WAF はアプリケーションの外側にある観測点である

Web アプリケーションの Pod や PHP プロセスの中だけを見ていると、アプリケーションに到達しなかった通信は見えにくくなります。WAF が reverse proxy に置かれている場合、アプリケーションへ渡す前の段階で、スキャン、認証攻撃、公開すべきではないファイルへのアクセス、異常な HTTP メソッド、ルールに一致したリクエストを観測できます。

この位置で記録する意味は、単に攻撃を数えることではありません。アプリケーションログ、Web サーバーログ、WAF audit log は、それぞれ見ている境界が違います。WAF audit log は、アプリケーションの手前で何が判断されたのかを残すためのログです。

WAF audit log は、アプリケーションログの代替ではありません。むしろ、アプリケーションの外側にある防御点として、別の観測面を提供します。

audit log で見るべき情報

ModSecurity の audit log は情報量が多いため、すべてを人間が毎回読む運用には向きません。Grafana で見る場合は、まず運用判断に使うフィールドを決めます。

重要なのは、WAF のログを「攻撃ログ」と決めつけないことです。403 が出ていても、それが期待通りの遮断なのか、正常な編集画面や API 呼び出しを壊しているのかは、リクエスト内容と判定理由を合わせて見なければ分かりません。

Loki へ JSON として入れる

Grafana で WAF audit log を扱いやすくするには、ログをただの文字列として保存するのではなく、JSON として検索できる状態にしておくことが重要です。Loki に source="modsecurity-audit" のようなラベルを付け、本文を JSON として扱える形にしておくと、LogQL の | json でフィールドを取り出せます。

実装上は、ModSecurity が出力する audit log をファイルとして受け、Grafana Alloy や Promtail などのログ収集エージェントで Loki へ送る構成になります。このとき、ホスト名、サービス名、ログ種別をラベルとして固定しておくと、Grafana のダッシュボードで扱いやすくなります。

ラベルに入れる情報は検索の軸にするものへ絞ります。リクエスト URL や送信元 IP アドレスのように種類が増え続ける値をラベルに入れると、Loki のカーディナリティが増えすぎます。これらは JSON フィールドとして検索する方が扱いやすいです。

Grafana で見るべきパネル

ダッシュボードは、細かいログを読むためだけではなく、状況を短時間で把握するために作ります。最初に見るべきパネルは多くありません。

たとえば、過去 24 時間の status 別件数を見ると、403 が増えているのか、404 の探索が多いのか、500 が混ざっていないかを確認できます。WAF の正常性を見るには、遮断件数だけでなく、成功応答やアプリケーションエラーとの関係も見ます。

sum by (response_status) (
  count_over_time({source="modsecurity-audit", host="proxy-rev.example.local"} | json [24h])
)

遮断されたリクエストの傾向を見る場合は、request_request_line で集計します。これにより、.env、wp-login.php、wp-comments-post.php、未知の HTTP メソッドなど、どの入口にアクセスが集中しているかを確認できます。

topk(10,
  sum by (request_request_line) (
    count_over_time(
      {source="modsecurity-audit", host="proxy-rev.example.local"}
      | json
      | response_status="403"
      [24h]
    )
  )
)

このようなクエリは、単に攻撃者を探すためのものではありません。正常な編集操作や API 呼び出しが WAF に巻き込まれていないかを確認するためにも使います。

403 を攻撃件数として扱わない

WAF のダッシュボードを作ると、どうしても 403 の件数に目が行きます。しかし、403 は攻撃件数そのものではありません。WAF が遮断した通信、Web サーバー側で拒否した通信、認可上拒否された通信が混ざることがあります。さらに、誤検知によって正常な通信が遮断されている可能性もあります。

そのため、403 は「確認すべき判断結果」として扱います。送信元、リクエスト行、Host、WAF の action message、発生時間帯を合わせて見て、期待通りの遮断なのか、ルール調整が必要なのかを判断します。

WAF ログを Grafana で見る価値は、数を眺めることではなく、判断を戻せることにあります。攻撃、誤検知、設定ミス、アプリケーション変更を分けて考えるための材料にします。

WAF ルール調整の流れ

ModSecurity のルール調整は、ログを見ながら例外を増やす作業ではありません。まず遮断結果を観測し、正常通信か不正通信かを分類し、必要な場合だけ範囲を限定した例外に落とします。

例外は広く入れるほど楽になりますが、防御点としての意味は薄くなります。特定の plugin や管理画面に必要な通信だけを許可するなど、観測結果から範囲を絞ることが重要です。

公開してはいけない情報もある

WAF audit log は、公開記事や共有資料へそのまま貼るべきログではありません。実ホスト名、内部 IP アドレス、Cookie、認証ヘッダー、POST body、攻撃元 IP アドレス、WordPress の管理 URL、plugin 名などが含まれる場合があります。

ブログ記事や運用メモにする場合は、実データを匿名化し、クエリ例も proxy-rev.example.local のような仮名に置き換えます。Grafana のスクリーンショットを使う場合も、変数、Host、IP アドレス、request body が写り込まないようにします。

また、WAF ログはセキュリティ運用上の情報です。Grafana の閲覧権限、Loki の保存期間、ログに含まれる個人情報や機微情報の扱いも設計対象になります。可視化することと、誰でも見られるようにすることは別です。

参考資料

• ModSecurity Reference Manual v3.x
• OWASP ModSecurity Core Rule Set
• Grafana Loki documentation: LogQL
• Grafana documentation: Dashboards

参考書籍

関連する記事

まとめ

ModSecurity を導入しても、遮断結果を確認できなければ、WAF はブラックボックスになります。audit log を Loki に集約し、Grafana で可視化すると、WAF が何を見て、どのように判断したのかを運用に戻せます。

見るべきものは、単純な 403 の件数ではありません。送信元、request line、Host、response status、action message、anomaly score を合わせて見て、攻撃、誤検知、設定ミス、アプリケーション変更を分けることが重要です。

WAF は通信を止める装置であると同時に、境界で発生した判断を記録する観測点です。Grafana で ModSecurity の audit log を見ることは、防御を強くするだけでなく、防御の理由を説明できる状態にするための運用設計です。

関連記事

セキュアコーディングとは何か – OWASP / ASVS を使って基準を育てる SELinux と AppArmor は何が違うのか – 無効化されやすい Linux のアクセス制御を設計思想から理解する サーバー要塞化はなぜ古く見えるのか – OS 防御から実行環境の統制へ