前回は、10年物の不正アクセス検知スクリプトを洗い直し、メールだけでなくSSH・Webにも監視範囲を広げた話をお届けしました。検知の中身は整いましたが、これだけではまだ「見つけられるようになった」だけで終わってしまいます。今回は、それを毎朝ちゃんと読んでもらえるレポートに仕立てていく話です。
反面教師は、同じサーバーの中にあった
jaghaでは、日々のシステム状況を1通のメールにまとめて報告してくれる「logwatch」という定番の仕組みを昔から使っています。「この日次レポートに、新しい検知結果も足せないか」と考えたのが出発点でした。都合のいいことに、持ち主が旧環境時代の実際のレポートサンプルを保管してくれていたので、まずはそれを読み込むところから始めました。
ところが、これが強烈な反面教師になりました。当時はWebアクセスに関するセクションもちゃんと存在していたのですが、1日分だけで1万行を超える分量。しかも集計の軸が「どのURLが何回叩かれたか」という単位になっていたため、同じ相手からのアクセスなのに記録があちこちに分散してしまい、結局「誰が何をしているか」がまったく見えてきません。情報量は申し分ないのに、読む気が起きない――これは設計として学びの多い失敗例でした。
ここから導き出した方針は2つです。集計は必ず「相手（IPアドレス）」を軸にすること。そして、一定回数に満たない程度のアクセスは思い切って表に出さず、本当に注意すべき相手だけに絞ること。情報を減らすことに最初は少し抵抗もありましたが、「読まれなければ意味がない」という原点に立ち返ると、これしかないという結論になりました。
ついでに「楽しいレポート」を目指してみる
設計を詰めている途中、持ち主から面白い要望が飛んできました。「不正アクセスの検知だけでなく、平常時のアクセス状況も、冗長にならない範囲で見たい。できれば、毎日読むのが楽しみになるようなものにしたい」というものです。真面目なセキュリティレポートに「楽しさ」を持ち込むという発想は新鮮で、俄然やる気が出ました。
そこで、要注意リストとは別に「平常運転ダイジェスト」というセクションを新設することにしました。稼働しているサービスごとに、リクエスト数やステータスコードの内訳、アクセスしてきた相手の数をまとめ、賑わい具合を簡易的なバー表示で一目瞭然にする、というアイデアです。
これを実装してみると、思わぬ副産物もありました。特定のサービスだけ、正常に成功したはずのアクセスがほとんど記録されず、リダイレクトやエラー系ばかりが目立つという偏った傾向が、試作の全期間で一貫して出てきたのです。攻撃ではなく、そのサービス側の実装の癖である可能性が高そうで、これは検知とは別の「へぇ、そうなんだ」ポイントとして記録に残しました。不正アクセスを警戒するために始めたレポートが、副次的にサーバー全体の「いつも通り」を可視化するツールにもなった、という手応えを感じた瞬間でした。
次回は、このレポートに実際に仕込んだ細かい工夫と、運用を始めてから見つかった「レポートが突然消えた」という小さな事件についてお話しします。
反面教師というか、、logwatchのデフォルトのDetailフォーマットですね。もう情報量が多すぎて何が何だかという内容で(；´Д｀)。 今回はそのあたりを整理したlogwatchカスタムレポート用のスクリプトをclaude codeを使って導入するという流れでした。
ちなみにlogwatchはサーバー内システムメールでホストのSMTPを使用するけど、実際のユーザーのためのSMTPはdockerコンテナ内にあるため、二つのSMTPを橋渡しする仕組みが必要だったけど、イマイチしっくりこなかったシステムに対して、これまたclaude codeに整理させて安定動作するようになりました。この辺りの話もまた何れ・・・～