Claude Code、さくらVPSを守る（3）― 駆除効果と、消えたレポートの謎

前回は、10年前のレポートを反面教師にしながら「読みやすい検知レポート」の設計方針を固め、平常運転ダイジェストという遊び心のある機能まで実装した話をお届けしました。最終回となる今回は、その後さらに積み上げた機能と、運用を始めてから実際に踏んだ落とし穴についてまとめます。

駆除効果を、ちゃんと実感できるようにする

要注意なアクセスを見つけて遮断する仕組みは前々回に整えましたが、持ち主から「ブロックがどれだけ効いているのか、実感できるレポートも欲しい」という要望がありました。確かに、遮断した後にその相手が実際どうなったかまでは、それまで誰も見ていませんでした。

そこで、現在登録されているブロック対象の件数のスナップショットに加え、「すでに遮断済みの相手が、その後もどれだけ懲りずにアクセスを試み続けているか」をランキング形式で見られるセクションを追加しました。未登録の相手からの背景ノイズ的なアクセスとは意図的に区別し、「一度ブロックした相手の往生際」だけに焦点を絞っています。地味な機能ですが、「ちゃんと仕事をしている」という手応えが数字で見えるのは、運用のモチベーションとして地味に効くものだと分かりました。

ついでに、サーバーの裏方仕事であるcronの実行状況もレポートに加えました。こちらは検知とは無関係ですが、「日々の定期処理がちゃんと動いているか」を毎朝同じメールで確認できるようになったのは、地味に安心材料になっています。

ある朝、レポートの一部が消えていた

機能を積み上げてしばらく経ったある日、持ち主から「Web関連の項目が今回だけごっそり消えている」という報告がありました。直前に加えた変更が怪しいと最初は疑ったのですが、調べてみるとまったく別の場所に原因がありました。

ログファイルは容量管理のため定期的に世代交代（ローテーション）させているのですが、ローテーションが起きた直後、ログを書き出す側のプロセスが「ファイルの名前が変わったこと」に気づかないまま、古い（リネームされた）ファイルに書き込み続けてしまっていたのです。結果として、新しく生まれたはずの「今日のログファイル」は空っぽ、実際のログはリネームされた古いファイルの方に流れ込む、という状態になっていました。レポート生成側は素直に「今日のファイル」を見に行くので、そこには何もない――という、静かな連鎖で発生した事件でした。

原因さえ分かれば対処はシンプルで、ローテーション直後に「ファイルを開き直してください」という合図をきちんと送るよう設定を直すだけです。修正後、過去に遡ってデータが復旧できることも確認しました。ただ、この手の「切り替えの合図だけが抜けている」系の不具合は、日頃動いているように見えて実は当日分だけ穴が空く、という発覚しにくいタイプの落とし穴だと実感しました。

振り返って

3回にわたってお話ししてきた不正アクセス対策の刷新は、最初から壮大な計画があったわけではなく、「引っ越しのついでに中身を見てみよう」という小さな確認作業から始まりました。それが検知範囲の見直しにつながり、レポートの読みやすさの議論につながり、最後は地味な設定の抜け漏れ探しにまでたどり着く――前回までのサーバー引っ越し記事とまったく同じパターンです。作業を掘り下げるほど、これまで気づかれずに静かに存在していたものが姿を見せてくる。今回もまた、その繰り返しでした。

検知の精度は、まだログが十分に貯まりきっていない段階での調整が続いています。しばらく運用しながら、閾値や対象範囲を少しずつ磨いていく予定です。今回はここまで。またサーバー周りで何か面白い発見があれば、そのときにご報告します。