XServerからUpdraftPlusについての緊急通知が来た。AIと復元テスト環境を調べて、撤去するまで 【ChatGPT LOG】
XServerから、UpdraftPlusに関する緊急のメールが届きました。運営元への不正アクセスで、UpdraftCentralの接続キーが流出したというものです。
こういうの心臓に悪いですよね（汗）
ただ、対象として書かれていたのは本番ブログではなく、バックアップからの復元を試すために作ったテストサイト。そこに残っていたUpdraftPlusを、XServerが先に停止してくれていました。
もう使わない環境なら、丸ごと消せばいいのでは？ そう聞いたところから、AIと一緒に中を調べて、後片づけすることになりました。そのチャットログを残しておきます。
通知が来たのは、復元テスト用のサイトだった
このテストサイトは以前にブログのバックアップなど、ブログ保全台帳を作成する際に、実際のバックアップからの復元を試したときに作ったテストサイトでした。
https://www.donpy.net/standard-entry/ds-dairy/91599.htmlUpdraftPlusはWordPressのバックアップ用プラグイン。
一方のUpdraftCentralは、離れたところからサイトを管理する仕組みです。今回問題になったのは、その遠隔管理に使う接続キーでした。XServerの注意喚起にも、この件が掲載されています。
https://business.xserver.ne.jp/news/detail.php?view_id=19722メールによると、XServerは10月20日に対象プラグインのパーミッションを「000」に変更。読み書きや実行の権限を止める措置を取っていました。
ただ、停止されたという通知だけで、私のサイトが侵入されたと決まったわけではありません。そこは調べてみないとわからない。
AIも、不要なテストサイトなら削除する方針に賛成でした。ただし、消す前に確認しておきたいことがあると。
なるほど。削除してからでは、何があったのかも調べにくくなるわけですね。
せっかくなので全部調べてから消すことにしました。
画面を見せながら、ひとつずつ確認する
まずはファイルマネージャーを開き、テストサイトのフォルダやプラグインの一覧をAIに見せていきました。名前と更新日時を確認し、見覚えのないものが増えていないかを探します。
通常のプラグインとは別に、自動で読み込まれるMUプラグインのフォルダも確認。そこにあったファイルについては、AIは復元テスト用のメール送信停止などを行うものだと説明していました。
続いて、勝手に管理者が追加されていないかを見るため、WordPressへログインしようとしたのですが。
データベースの確認も挟みつつ、ようやくログインできました。
ユーザー一覧は、全部見覚えのある名前でした。
プラグイン一覧についても、AIからは見覚えのない追加は見当たらないという返答。画面を一枚ずつ見せながら、確認を進めていきます。
接続キーが空でも、ログの確認は続ける
次は、そもそもこのテストサイトがUpdraftCentralと接続されていたのか。データベースではキーそのものを表示せず、設定項目と値の長さを調べました。このあたりの phpmyadmin とかの操作は私にはまったくわからなかったので、AI の指示通り調べていきました。
結果は、接続キーの項目が空。現在はキーが登録されていないという材料が得られました。
続いてログイン履歴を調べると、対象期間の結果は0件でした。これで終わりかと思いきや、AIはそこを安心材料にはしませんでした。
ただし「不正ログインが絶対になかった」と断定する材料にはできない
という扱いになります。
今ログインした自分の記録もないなら、0件という数字だけでは判断できない。そこで、今度はサーバー側のアクセスログを見てもらうことにしました。
10月16日から21日まで、6日分のファイルをダウンロードしてAIへ渡します。返ってきた報告はこうでした。
10月17〜21日の対象アクセスは25件だけ
25件すべて GET
25件すべてHTTP認証で 401 Unauthorized
AIの解析報告では、対象として抽出したアクセスはすべて認証で拒否されていたとのこと。接続キーやユーザー一覧の確認と合わせ、調べた範囲では侵害の痕跡は見つからない、というところまで来ました。
消したはずなのに、残っている？
ログを確保できたので、いよいよテストサイトを削除します。ところが、削除ボタンを押したあともフォルダが残っていました。
再読み込みしても消えず、操作ログを見ると削除に失敗していました。原因候補になったのは、最初にXServerが「000」に変更したUpdraftPlusの権限です。
途中でAIは、残ったフォルダを「削除できなかった残骸」と説明したのですが、実際の画面にはずいぶん残っています。
といって、ファイルマネージャーに大量に残っているフォルダのスクショを見せました。
ただ、原因候補ははっきりしています。updraftplus だけ権限が 000 です。
ここでは、プラグインを使い直すためではなく、削除を進めるために権限を戻すことになりました。対象のUpdraftPlusフォルダを削除してから、テストサイト全体を再度削除します。
今度は消えました。
続いて、データベース内のサイトURLがテストサイトのものだと確認してから、専用データベースを削除。サブドメインの設定も削除しました。
これで大体の作業は終了しました。あとは確認作業だけ。
最後に、本番のバックアップも確認
テスト環境は撤去できましたが、本番で使っているUpdraftPlusも確認しておきます。
ただし、更新済みかどうかと、流出対象の接続キーを使っていたかは別の確認です。
UpdraftCentralの設定画面には、このサイトをコントロールできるダッシュボードはない、という表示。私自身も利用していませんでした。
今回の調査では侵害の痕跡は見つからず、通知対象だったテスト環境のファイル・専用データベース・サブドメイン設定も撤去できました。本番のUpdraftPlusは、バックアップ用として引き続き使うことにしました。せっかく細かく設定したものなので。
なお、これは今回調べた範囲での確認です。接続がないという現在の表示だけで、過去の被害まで否定できるわけではありません。運営元の案内でも、利用している製品やアカウントの有無によって対応が分かれています。
おわりに
今回の作業を通してわかったことは、
「バックアップのために作ったテスト環境も、残している限りは管理対象になる」
ということです。
9月にはブログの資産を守るために復元テストを実施した。そのときは、復元できることを確認して目的達成しました。ところが10月になって、そのテスト環境がまさかのセキュリティ通知の対象になってしまいました。
要するに「ブログを守るために作ったものが、今度は管理すべきリスク」になったわけですね。
テスト環境も慎重に扱わないといけないなぁと強く思った次第です。だけど、ほんとにちょっと安心できました。やってよかったです。
こういう記録は積極的に残していきたいと思います。
ではまた。
ディスカッション
コメント一覧
まだ、コメントがありません