不要アカウントを削除し、認証情報を変更した。ここで「もう大丈夫」と思いたくなるが、侵害対応ではその後の総点検が欠かせない。
攻撃者は、元の入口とは別に、再ログイン用の仕組みを残すことがある。これを一般にバックドア、または永続化の仕組みと呼ぶ。復旧後の確認では、設定変更が正しく反映されたかと、不要な入口が残っていないかの両方を見る。
総点検チェックリスト
アカウントと権限
- 想定外のOSユーザーが存在しない
- 管理権限を持つユーザーが必要最小限になっている
- 削除・無効化したアカウントでログインできない
- 各ユーザーのSSH公開鍵が把握できている
SSHとネットワーク
- rootの直接ログインが無効になっている
- パスワード認証を無効化、または厳格に管理している
- ファイアウォールで必要なポートだけを公開している
- 予期しない待受ポートや外向き通信がない
自動実行とサービス
- cron設定に見覚えのない処理がない
- systemdサービス・タイマーに不要なものがない
- 再起動後にも不審なプロセスが復活しない
- アプリケーションの起動定義が管理対象のファイルと一致する
Webアプリケーションとコンテナ
- CMS、テーマ、プラグインが更新済みで、不要なものがない
- アップロード領域に実行可能ファイルが置かれていない
- コンテナ名・イメージ・公開ポート・マウント先が想定どおり
- 管理対象外のコンテナ、イメージ、ボリュームがない
外部サービス
- SMTP、API、分析基盤などの古い認証情報が失効済み
- 新しい認証情報で正常に動作する
- サービスアカウントの権限が最小限になっている
- 認証情報がソースコードや公開ディレクトリに置かれていない
「削除した」ことと「残っていない」ことは違う
この違いを意識することが重要だ。たとえば、サービスアカウントを新設しても古い鍵が有効なら、攻撃者にとっては入口が残る。SSH鍵を追加しても、古い鍵やパスワードログインが有効なら、切り替えは完了していない。
同じように、不審なファイルを消しても、それを復元する定期実行があれば意味がない。確認は必ず「入口」「実行経路」「外部連携」の三方向で行う。
数日〜数週間の監視を行う
一度の点検で安全を証明することはできない。復旧後は、少なくとも数日から数週間、次を定期確認する。
- 新しい管理者アカウントやSSH鍵が増えていないか
- CPU、メモリ、ネットワーク、ディスクが不自然に増えていないか
- エラーログや認証ログに異常な試行がないか
- メール送信量や外部API利用量に異常がないか
今回も、復旧後にサイト表示、管理画面、メール送信、外部連携、サーバ負荷を順に確認し、変更した認証情報だけで正しく動くことを確かめた。
次回は最後に、こうした対応を毎回の緊急作業にしないための、現実的な再発防止策をまとめる。