侵害が疑われるとき、見つけるべきものは「怪しいファイル」だけではない。攻撃者が再び入るための仕組み、つまり永続化の設定まで確認しなければならない。

今回の調査では、OS、SSH、定期実行、Webアプリケーション、コンテナ、外部連携を分けずに確認した。小さなサーバほど、一人の管理者が複数の仕組みを扱う。そのため、入口も残り方も一つとは限らない。

1. 見覚えのないユーザーと権限

最初に確認したのは、サーバ上のユーザーと管理権限だった。

  • 想定していないユーザーが追加されていないか
  • 管理権限を持つグループに不要なユーザーがいないか
  • 最近、権限やログインシェルが変更されていないか
  • アプリケーション専用ユーザーが対話ログインできる状態になっていないか

不要なアカウントは削除対象になる。ただし、いきなり消す前に、所有ファイル、ログイン履歴、実行中プロセスを確認する。正規のバッチ処理用アカウントを誤って削除すると、復旧後に別の障害を起こすからだ。

2. SSH公開鍵は「パスワードより長く残る入口」になる

SSHの公開鍵認証は安全な仕組みだが、知らない鍵が登録されていれば、その鍵を持つ人はパスワード変更後もログインできる。

確認対象は、管理者のホームディレクトリだけではない。

  • 各ユーザーの authorized_keys
  • rootを含む管理用アカウントのSSH設定
  • SSHのパスワードログイン・rootログインの許可状態
  • ログイン履歴と、失敗ログインの急増

今回は、不要なアカウントと認証情報を整理し、必要なものだけを残す方針を取った。鍵は「誰が、何のために、いつ登録したか」を説明できる状態が理想だ。

3. cronとsystemd――攻撃者が自動復活する場所

削除した不審なプログラムが翌日戻ってくる。こうした場合、定期実行やサービス登録が残っている可能性がある。

確認すべき場所は次の通りである。

  • 各ユーザーのcron設定
  • /etc/cron.* と定期実行用の設定ファイル
  • systemdのサービスとタイマー
  • 起動時に実行されるスクリプト
  • 一時ディレクトリやホームディレクトリに置かれた実行ファイル

重要なのは、ファイル名だけで判断しないことだ。正規の処理に見える名前でも、実行先、実行ユーザー、実行頻度、外部通信先が不自然であれば精査する。

4. Webシェルと公開ディレクトリ

WordPressなどのCMSでは、プラグインやテーマ、アップロード領域が確認対象になる。Webシェルは画像やキャッシュに似た名前で置かれることもあるため、拡張子だけでは見抜けない。

見るべき観点は、次の通りだ。

  • 最近更新されたPHPなどの実行可能ファイル
  • 管理対象外のプラグイン・テーマ
  • アップロードディレクトリにある実行可能ファイル
  • 不自然に難読化されたコード
  • Webサーバのアクセスログにある不審なPOSTや管理画面への試行

ただし、調査のために不審なコードを実行してはいけない。内容確認は閲覧にとどめ、必要なら隔離した環境で専門家に解析を依頼する。

5. Dockerを使っているなら、コンテナの外も中も確認する

コンテナ化していても、ホストが安全になるわけではない。想定外のコンテナ、不要なポート公開、怪しいボリュームマウント、特権設定がないかを確認する。

特に、Dockerソケットを操作できるコンテナはホストへの影響が大きい。コンテナ名・イメージ名・起動オプション・環境変数の参照元を、構成管理上の定義と照合することが重要になる。

調査のゴールは「怪しいものを一つ見つける」ことではない

調査の目的は、安心材料を集めることではない。攻撃者が使える入口を、体系的に潰すことだ。

ユーザー、鍵、定期実行、サービス、公開ディレクトリ、コンテナ。これらを横断して確認して初めて、「削除したあとに戻ってくる」リスクを下げられる。

次回は、ログを確認しても侵入経路を断定できないとき、どこまでを被害範囲として扱うべきかを解説する。