WordPress改ざんの復旧記録 消えたサイトを2日で戻した

この記事には広告が含まれます

この記事の要点

  • 見知らぬファイルが置かれ、数日後にサイトが消えた
  • 気づいたきっかけは、サイトが表示されなくなったことだった
  • 調査から復旧まで2日。いまは週に1度、自動で点検している
何が起きたか
起きた日時期は書いていません
やらせたこと改ざんされたサーバーの調査と復旧
結果サイトが表示されなくなり、サーバー全体に広がっていた
原因見知らぬファイルが置かれ、そこから広がった
対策復旧後に点検を必須とし、週に1度の自動の点検を組んだ

サイトが表示されなくなりました。

私が異変に気づいたのは、この時点です。前触れとして見知らぬファイルが置かれていたのですが、その時点では気づいていませんでした。数日後にサイトが消えています。

調査から復旧までに2日かかりました。作業のほとんどはAIに指示を出して進めています。何が起きていて、何をしたのかを書きます。

気づいたときには、もう消えていた

最初に分かったのは、サイトが開かないという事実だけです。

このとき私が持っていた情報は、それだけでした。原因も、範囲も、いつからかも分かりません。画面が出ないという結果だけがあって、何が起きたのかが分からない状態です。

あとから調べて分かったのは、実際にはその数日前から兆候があったということでした。サーバーの中に、身に覚えのないファイルが置かれていたのです。

そのファイルが置かれた時点では、サイトは普通に表示されていました。表示が正常であることは、何も起きていないことの証明にはなりませんでした。

被害は1つのサイトに留まっていなかった

調べていちばん驚いたのは、範囲でした。

消えたのは1つのサイトですが、同じサーバーの中にあった他の場所にも広がっていました。サーバーの契約を1つ借りて、その中に複数のサイトを置いていた状態です。

このとき知ったのは、1つの契約の中は、思っているほど分かれていないということでした。フォルダは分かれていても、そこに置かれたものは同じ場所から届く範囲にあります。

いま私は、サイトごとにフォルダとデータベースを分けています。データベースを扱う利用者も分けて、他のサイトのデータベースへ接続できない設定にしました。復旧そのものより、この整理のほうが時間がかかっています。

AIに何をやらせたか

調査、原因の特定、復旧の作業。ほぼすべてをAIに指示して進めました。

私はシステム開発の技術者ではありません。サーバーの中で何が起きているかを、自分で読み解く力はありません。それでも作業が進んだのは、AIが状態を読み取って、日本語で説明してくれたからです。

最初にやらせたのは、消さないこと

作業の順番として、最初にやらせたのは復旧ではありませんでした。

いま何が置かれているかを、そのまま記録に残すことです。おかしなファイルを見つけると、すぐ消したくなります。ただ、消してしまうと、何が起きたのかを後から調べられなくなります。

急いで元に戻したい場面で、先に記録を残す。この順番は、事前に決めておかないと守れないと思います。

次にやらせたのは、範囲を確かめること

1つのサイトが消えたとき、被害がそこだけだと考えるのは自然です。

実際には広がっていました。そのため、被害の範囲を先に確かめる作業に時間を使っています。1か所を直しても、他が残っていれば同じことが起きます。

中身を移すのではなく、土台から作り直した

復旧のやり方には、大きく2つの考え方があります。

1つは、おかしなものを取り除いて、いまのサーバーを使い続ける形です。もう1つは、新しい土台を作って、確認したものだけを移す形です。

私は後者を選びました。

理由は単純で、取り残しに気づける自信がなかったからです。取り除く形は、すべてを見つけられていることが前提になります。1つでも残っていれば、また同じことが起きます。

新しい土台に、中身だけを移す。この形なら、移したものが何かをこちらが把握しています。

移すときに気をつけたこと

このとき学んだのは、ファイルを丸ごと移すと、問題も一緒に移るということでした。

土台は新しく作って、記事や画像といった中身だけを移しています。設定ファイルや、動きを作っている部分は、新しく用意し直しました。

サーバーの引っ越しそのものについては、WordPressサーバー移転の実例 338記事を2日で移した記録 に別に書いています。

2日かかった内訳

復旧に2日かかりました。ただ、その大半は作業ではありません。

何が起きたかを調べる時間と、被害の範囲を確かめる時間で、大半が消えています。新しい土台に中身を移す作業そのものは、それほどかかりませんでした。

急いでいるときほど、調べる時間を惜しみたくなります。ただ、範囲が分からないまま直すと、直したつもりの場所が残ります。

いま何をしているか

同じことを繰り返さないために、いま決めているのは次の3つです。

1 点検を必ずやる

新しいサイトを作ったとき、設定を変えたとき、機能を足したとき。そのたびに安全の点検を行うことを、作業の手順に組み込みました。

思い出したときにやる形では続きません。作業の一部として、やらないと終わらない形にしています。

2 週に1度、自動で点検する

人が思い出さなくても回るように、週に1度、自動で点検が走る仕組みを組みました。

私が忙しい週も、忘れている週も、同じように動きます。続けるかどうかを、自分の意志に頼らない形にしたかったのです。

3 サイトごとに分ける

同じ契約の中に複数のサイトを置く場合でも、フォルダとデータベースを分け、他のサイトへ届かない設定にしています。

1つが問題を起こしても、他へ広がらないようにするためです。今回、広がったから決めたことです。

点検が動いていると思っていても

最後に、正直に書いておきたいことがあります。

点検の仕組みを組んだからといって、それが動いている保証はありません。

私は別の作業で、点検の命令そのものが動いていないのに問題なしと報告される、という経験を何度もしています。動いていない点検は、動いていない状態のまま、毎週正常だと報告し続けます。

そのため、点検の仕組みそのものが働いているかを、ときどき確かめるようにしています。わざと引っかかるものを置いて、それが検出されるかを見る形です。

この話は AIの報告を8回信じて8回とも間違っていた 確かめ方の話 に詳しく書いています。

これから同じことが起きた人へ

もしいま、サイトが表示されなくなって、この記事にたどり着いた方がいたら。

急いで直す前に、いまの状態を記録に残してください。消してしまうと、何が起きたのかを調べられなくなります。

そして、被害がそのサイトだけだと決めつけないでください。私の場合、同じ契約の中の他の場所にも広がっていました。

私は技術者ではありませんが、AIに調べさせて2日で戻せました。分からないから何もできない、ということはないと思います。

この記事について

更新履歴

  • 2026-08-25 公開
タイトルとURLをコピーしました