実際のサーバー不正侵入から学ぶ：ホスティングインフラを守る8つの習慣
先日、あるホスティング会社の管理インフラで発生した不正侵入を調査しました。特別なことは何もありませんでした。ゼロデイ脆弱性も、国家レベルの攻撃ツールもありません。それぞれ単独では無害な、ありふれた習慣の連鎖が重なり、攻撃者に1週間以上も気づかれないアクセスを許していたのです。本記事では、侵入の経緯、発覚のきっかけ、そしてほぼすべての段階で侵入を防げたはずの8つの習慣を紹介します。
侵入の経緯
- 共有されたrootパスワード。管理サーバーや踏み台サーバーを含む複数のサーバーで同じrootパスワードが使われ、SSHのパスワードログインも許可されていました。
- 目立たない最初のログイン。攻撃者はそのパスワードで一度ログインし、SSHトンネルを開いたままにしました。トンネルはターミナルを開かないため、
whoには一度も表示されませんでした。このトンネルは9日間開いたままでした。 - 派手な第2段階。1週間以上経ってから、複数のIPが同じパスワードでログインし、自分たちのSSH鍵を追加し、systemdサービスとcronジョブを作成し、Webサイトにウェブシェルを設置しました。
- 痕跡の隠蔽。攻撃者はファイルの更新日時を1週間前に戻して新しいファイルを古く見せかけ、実行後に自身を削除する使い捨てのウェブシェルを使い、
/tmpに隠しPHPファイルを残していました。 - 発覚。オーナーが定期的なセキュリティチェックを依頼したところ、ログインログに誰も見覚えのないIPからのrootパスワードログインが記録されていたことで発覚しました。
連鎖を断ち切る8つの習慣
1. 鍵認証のみにし、パスワードはどこでも使い回さない
SSHのパスワードログインを無効にし、担当者ごとに個別の鍵を発行します。そうすればパスワードが漏れても役に立たず、1つの認証情報が盗まれても全マシンに侵入されることはありません。SSH鍵ログインの設定をご覧ください。
2. 踏み台サーバーと管理サーバーを最重要資産として扱う
踏み台サーバーや管理サーバーは他のすべてのサーバーにアクセスできるため、最も価値の高い標的になります。専用の認証情報、最も厳しいファイアウォール、最も綿密な監視を適用してください。万一侵害された場合は、クリーンアップではなく再構築してください。
3. すべてのログインで通知を受け取る
トンネルが9日間も放置されたのは、ログインを誰にも知らせる仕組みがなかったからです。SSHとパネルのログインごとにTelegramへ通知が届けば、見知らぬIPはすぐに目に留まります。設定は約10分で完了します：Telegram通知によるログイン監査。
4. セッションだけでなく接続を確認する
whoだけでなくss -tnpも確認し、見知らぬIPからの長時間続くSSH接続がないか調べてください。トンネルやSFTPセッションは、通常のコマンドでは見えません。
5. すべてのパネルで二要素認証を有効にする
ホスティングパネル、請求システム、サーバーコントロールパネルは、すべてへの鍵を握っています。二段階認証を有効にし、可能であれば管理画面へのアクセスを既知のIPに限定してください。aaPanel（宝塔パネル）についてはaaPanelセキュリティ強化ガイドをご覧ください。
6. ファイルの日付を信用しない
更新日時は簡単に偽装できます。仕込まれたファイルを探すときは、通常のユーザー空間のプロセスでは巻き戻せない変更日時（ctime）と作成日時（birth time）を使ってください。
find /var/www /tmp /dev/shm -newerct "-14 days" -type f 2>/dev/null
stat /path/to/suspicious.php # compare Modify with Change and Birth7. 公開する必要のないものは閉じる
データベースのポート、パネルのポート、管理用のパスをインターネット全体に公開すべきではありません。自分のIPのみを許可し、Webサイトはオリジンを隠すプロキシの背後に置き、ファイアウォールのデフォルトポリシーは拒否にしてください。CloudflareでオリジンIPを隠す方法をご覧ください。
8. インシデント後はすべてを変更し、証拠を保全する
アクティブなセッションは停止しますが、何かを削除する前にログや不審なファイルを安全な場所にコピーしてください。その後、侵害されたマシンから参照可能だったすべてのパスワード、鍵、APIトークンを変更します。データベースや決済ゲートウェイの認証情報も含みます。完全なクリーンアップのチェックリストはLinuxサーバーが侵害されていないか確認する方法にあります。
問題発生時に優れたインフラがもたらすもの
被害の封じ込めは、問題が起きる前に確保している制御手段にかかっています。IMIDCの専用サーバーでは、他のすべてをファイアウォールで遮断した後でもVNCコンソールでサーバーの画面にアクセスでき、レスキューシステムを起動してディスクをオフラインで調査でき、信頼できなくなったサーバーを再インストールできます。これらはすべてクライアントエリアからお客様ご自身で行えます（専用サーバーコントロールパネルガイドを参照）。第三者の視点が必要なときは、24時間365日対応のサポートチームがログの確認やクリーンアップをお手伝いします。
10分でできるセルフチェック
grep "Accepted password" /var/log/auth.log* | tail # any password logins?
ssh-keygen -lf /root/.ssh/authorized_keys # do you know every key?
ss -tnp | grep sshd # unknown long-lived connections?
crontab -l; ls /etc/cron.d /etc/systemd/system # anything you did not add?
find /tmp /var/tmp /dev/shm -name ".*" -type f # hidden files in temp dirs?見慣れないものがあれば、それ以上変更を加える前に手を止めて調査してください。チケットを作成していただければ、IMIDCのチームが対応をお手伝いします。