氷山ビュー
PHPログに残らないもの

「うちのログ」は、何を見ていないか

アクセスログを MongoDB に貯めて、そこそこのことができるようになっていました。 セッションを束ねて訪問者を数え（PVからセッションへ）、 パターンから攻撃者を浮かび上がらせ（攻撃者は、パターンで浮かぶ）、 .htaccess と APCu で実際に止める。

ひととおり揃った気でいたのですが、あるとき素朴な疑問が浮かびました。 遮断した相手は、このログに載っているのだろうか。

載っていませんでした。しかもそれは、設計上そうなるべくしてそうなっていたのです。

盲点は、どこにあったか

うちのログは PHP のモジュールが書いています。つまりPHP が動いたリクエストしか記録できません。 ここに3つの穴がありました。

① 攻撃パスは、記録せずに終了している

モジュールは wp-、.env、admin といった攻撃的なパスを検知すると、 その場で exit します。処理を軽くするための設計ですが、ログを書く前に終わるので記録が残りません。

② .htaccess で弾くと、PHP は起動すらしない

IP や UA による遮断は Apache 層です。403 を返した時点で完結しており、PHP には一切届きません。 遮断が成功しているほど、ログには何も残らないという逆説的な状態でした。

③ 存在しないパスも、PHP を通らない

静的ファイルとして解決できないパスは Apache が 404 を返します。これも PHP の外です。

足りない側から、補う

穴の形が分かれば、埋め方は決まります。Apache のログを集計して足す。 収集の実装は前回の記事に書きました—— 追記分だけを読み、ローテーションに追従し、時間帯単位の集計だけを保存する仕組みです。

2つのログは、担当範囲がきれいに分かれています。

片方だけでは全体になりません。2つを足して、はじめて輪郭が出る。 「氷山ビュー」と呼んでいるのはそのためです。見えていた部分の下に、見えていなかった部分がある。

何が、見えるようになったか

403 — 遮断の実績

これがいちばん嬉しい変化でした。書いた .htaccess のルールが 実際に何件止めているのかが、初めて数字で分かるようになりました。

それまでは「たぶん効いているはず」でしかなかった。ルールを足しても、効果を確認する手段が無かったのです。 403 の件数が見えるようになると、追加した直後に跳ね、相手が諦めると下がっていく—— そういう動きまで追えます。

404 — 攻撃者の辞書

叩かれたパスの一覧は、そのまま相手が何を探しているかの目録です。

/wp-login.php
/.env
/xmlrpc.php
/phpmyadmin/index.php
/.git/config
/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
/actuator/env
/static/..%2f..%2f..%2f..%2froot/.aws/credentials

最後の1行は、パストラバーサルでクラウドの認証情報を直接狙いにきています。 こういう傾向が見えると、ブロックリストを更新する材料になります。 「何を守るべきか」を相手が教えてくれる、という妙な構図です。

ステータスの全内訳

2xx / 3xx / 403 / 404 / その他4xx / 5xx を並べ、合計が総リクエスト数と一致するかを 確認できる形にしました。取りこぼしがあれば自分で気づけます。

そして、自分が映った

攻撃の見えない部分を映すために作った道具でした。最初に画面に出たのは、これです。

7件に1件がサーバエラー。 遮断（1,026）と探索（424）を足した数の、2.4倍です。 攻撃を見るために作った道具が、真っ先に映し出したのは自分のサーバの不具合でした。

この道具が無ければ、error.log に流れる AH00124 は 「気になるけれど原因不明」のまま放置されていたと思います。 可視化とは、相手を見ることであると同時に、自分を見ることでもある——そう実感した一件でした。

視界を、切り替えてみる

同じ1日のトラフィックを、2つの視界で見比べます。 PHPログだけの視界と、Apacheログを足した視界。 切り替えた瞬間に、水面下が立ち上がります。

切り替えると、それまで見えていた棒の下に、遮断と探索とサーバエラーが現れます。 注目してほしいのは攻撃のうち何割が見えていたかという数字です。 うちの場合は6割強でした。氷山は、思ったより小さかった—— これも実際に測ってみるまで分からなかったことです。

ログは、置いた場所しか見ない

当たり前の話に落ち着きました。ログは、それを仕掛けた層のことしか知らない。 アプリ層に置けばアプリに届いたものを、Web サーバー層に置けばそこを通ったものを記録します。 どちらが正しいかではなく、自分のログがどの層にいるのかを把握しているかが問題でした。