クライアントのWebサイトで「管理画面には入れるのに、公開サイトが正常に表示されない」という連絡を受けた。

管理画面が開くなら、アプリケーション自体は生きているように見える。しかし公開側には、Webサーバ、リバースプロキシ、コンテナ、ネットワーク、ストレージなど、管理画面とは別の要因が関わる。しかも、このときサーバのCPU・メモリ・ディスク使用量にも通常と異なる兆候があった。

この状況で最も避けたいのは、「とにかく表示を戻そう」と、再起動やファイル削除を先に行うことだ。障害であれば復旧が遅れ、侵害であれば攻撃者の痕跡まで消してしまう。

「感染」と決めつけない。ただし安全側に倒す

不審なプロセスや高負荷があるからといって、直ちにウイルス感染と断定はできない。アクセス急増、アプリケーションの不具合、設定ミス、ディスク枯渇でも似た症状は起こる。

一方で、「断定できないから何もしない」も危険である。今回の対応では、侵害の可能性を残したまま、次の原則で進めた。

原因は調べる。安全性は待たない。

つまり、原因の特定と並行して、被害拡大を防ぎ、再利用されうる認証情報を守る。これが小規模なサーバ運用で現実的な初動になる。

最初の30分で確認したこと

最初に確認したのは、サイトの表示だけではない。サーバ全体の状態だった。

  • CPU、メモリ、ディスク使用率が急増していないか
  • 動いているコンテナとサービスは何か
  • 見覚えのないプロセスや外部向け通信がないか
  • 直近のログイン履歴と管理者アカウントに異常がないか
  • Webサーバ・アプリケーションのエラーログに何が出ているか

ここでの目的は、犯人を見つけることではない。「現在も不正な処理が動いていないか」「正常なサービスを止めずに調査できるか」「先に遮断すべき入口があるか」を判断することだ。

先にやってはいけないこと

緊急時ほど、次の三つは避けたい。

1. 不審なファイルを即削除する

削除すれば安心に見えるが、いつ作られたのか、どのプロセスが使ったのか、外部からアクセスされたのかを追えなくなる。まずはパス、更新日時、所有者、ハッシュ、関連ログを記録する。

2. サーバを勢いで再起動する

メモリ上だけに存在するプロセスや接続先の情報、直近ログが失われることがある。明確な被害拡大を止める必要がある場合を除き、状況を記録してから行う。

3. パスワード変更だけで終える

侵害経路はパスワードだけではない。SSH公開鍵、APIキー、SMTP認証、分析基盤のサービスアカウント、定期実行、Webシェルなどが残っていれば、攻撃者は別の入口から戻れる。

今回の初動で得た教訓

公開サイトの障害は、単なる表示不良として扱わないほうがよい。特に、通常と違うリソース使用率、不明な変更、認証情報の管理に不安がある場合は、セキュリティインシデントとして初動を組み立てるべきだ。

復旧を急ぐことと、雑に復旧することは違う。まず現状を記録し、影響範囲を見極め、再侵入の入口を閉じる準備をする。その順番が、結果的に最短の復旧につながる。

次回は、侵害の痕跡と、再侵入のために残されがちなバックドアをどう確認するかを整理する。