WordPressセキュリティ対策ガイド｜初心者でも安心の守り方と重要ポイント
目次から探す
WordPressでサイトを運営していると、セキュリティ対策の必要性をどこまで真剣に受け止めるべきか、迷うことがあるかもしれません。「うちは小さいサイトだから狙われないだろう」「今のところ何も起きていないし」——そう考えるのは自然です。しかし実際には、世界中のWebサイトの4割以上がWordPressで構築されている現在、あなたのサイトは毎日、機械的な自動攻撃の標的になっています。
私が改ざん被害を調査したとき、一つの侵入口に1日あたり1万件を超えるアクセスが記録されていました。そして最も衝撃的なのが、侵入から被害が完成するまでの速さです。パスワードを突破した攻撃者が不正プログラムを設置し、動作テストまで終えるのに要した時間は、わずか2分半でした。「気づいてから対応すればいい」という考えは成り立ちません。
もし被害に遭えば、サイトの改ざんや個人情報の漏えいだけでは済みません。あなたのサイトが訪問者にとって危険な場所になり、信頼が失われます。
ただし、朗報があります。セキュリティ対策でやるべきことは決まっていて、ほとんどは無料でできます。優先順位さえ間違えなければ、初心者でも十分に自分のサイトを守れます。 この記事では、何から手をつけるべきかを優先順位つきで解説します。危険な設定ミスの防ぎ方から、被害時の対応方法まで、実際の復旧現場で得た知見をもとにまとめました。
なぜWordPressセキュリティ対策が必要なのか？狙われる理由とリスクを解説
WordPressを狙う攻撃は、個別のサイトを標的にした計画的な犯行ではありません。プログラムが世界中のIPアドレスを機械的に回り、WordPressが動いているサイトを見つけたら片っ端から試していく。その程度の感覚で考えてください。
WordPressが狙われやすい3つの理由
なぜそんなことが可能なのでしょうか。理由は3つあります。
まず、圧倒的な数の多さです。世界のWebサイトの4割以上、日本国内ではCMSシェアの8割以上がWordPressで構築されています。攻撃者の視点からすれば、一つの手口を用意すれば、それが世界中の何百万というサイトに使い回せる。個別のサイトの価値は関係なく、「WordPressというプラットフォーム全体」を狙っているのです。
次に、構造が完全に公開されていることです。ログイン画面がどこにあるか、ファイルがどこに置かれているか、どの機能がどのURLで動くか。すべて仕様として誰でも知ることができます。攻撃者にとっては、間取り図が配られている建物のようなものです。
そして最も重要な理由が「自動化されている」という点です。相手はあなたのサイトの中身も規模も見ていません。ただプログラムが自動で動いているだけです。だから「うちみたいな小さいサイトは狙われない」という発想は成り立ちません。機械は区別しないのです。
「更新していれば大丈夫」は誤解です
ここで一つ、この記事の前提としてお伝えしたいことがあります。
WordPressが狙われる理由として「オープンソースだから脆弱性を突かれる」と説明されることが多いのですが、実際の現場では、それだけではありません。私が対応した改ざん事案の原因は、プラグインの脆弱性ではありませんでした。 WordPressに最初から備わっている標準機能を使った、パスワードの総当たりです。
つまり、更新を怠っていなくても破られます。「ちゃんと更新していれば大丈夫」と考えていると、対策の方向を間違えます。
狙われる「4つの入口」
建物にたとえるなら、WordPressには入口が4つあります。多くの人は玄関しか知らず、玄関にだけ鍵をかけています。
入口1：表玄関（ログイン画面）
いわゆる wp-login.php や /wp-admin/ です。ここは誰でも場所を知っています。WordPressで作られたサイトなら、初期状態では必ず同じ場所にあるからです。
ただし、玄関は一番よく守られている入口でもあります。ログイン試行回数を制限するプラグインを入れれば、「5回間違えたら1時間ロック」といった対策が効きます。攻撃する側も、ここを何万回も叩くのは効率が悪いと分かっています。だから攻撃者は、玄関以外を探します。
入口2：勝手口（XML-RPC）
これは、スマートフォンのアプリや外部サービスからWordPressを操作するために用意されている機能です。今はほとんどの人が使っていません。にもかかわらず、初期状態では有効になっています。
問題は、この入口が「ログイン画面ではない」ことです。玄関に付けた見張りは、勝手口には立っていません。ログイン試行回数を制限するプラグインの多くはログイン画面を監視しているので、こちらを通られると数えられないのです。
先ほどお話しした1日1万件超のアクセスは、まさにここに来ていたものです。使っていない扉が、24時間ノックされ続けている状態でした。
入口3：業者用の通用口（REST APIの一括処理）
これが、私が対応した事案で実際に突破された入口です。そして、いま最も説明が必要な場所だと思っています。
REST APIというのは、WordPressを外部のプログラムから操作するための、比較的新しい仕組みです。その中に「複数の処理をまとめて一度に実行する」機能があります。本来は、たくさんの更新をまとめて送って効率化するための、まっとうな機能です。
ここに隙があります。
玄関でパスワードを試すとき、1回試せば「1回失敗」と記録されます。5回で止められます。ところが、この一括処理の入口を使うと、1回のリクエストの中に何十回分ものログイン試行を詰め込んで送れてしまいます。 外から見れば「アクセス1回」です。見張りは1回しか数えません。
実際のログでは、攻撃者はこの入口に約1分間で25回リクエストを送り、その直後に玄関へ回って、正しいパスワードでログインに成功していました。束ねて送ることで、回数制限をすり抜けたわけです。
ログイン試行回数の制限を入れて「対策した」と思っていても、この通用口が開いていれば意味がありません。玄関に頑丈な鍵をかけて、通用口を開けたままにしていた、というのが実際に起きたことです。
入口4：表札（ユーザー名の露出）
厳密には入口ではありませんが、攻撃の成功率を大きく左右します。
WordPressは初期状態で、投稿者の一覧を外部から取得できるようになっています。URLの末尾に ?author=1 と付けるだけで、その投稿を書いた人のログイン用ユーザー名が表示されてしまうことがあります。
パスワードの総当たりは、ユーザー名とパスワードの両方を当てる必要があります。ところがユーザー名が分かっていれば、答えが半分埋まった状態から始められます。難易度がまるで違います。実際のログでも、攻撃前にこの方法でユーザー名を集めた形跡が残っていました。
攻撃には「下見」の段階がある
もう一つ、あまり知られていないことをお伝えします。
同じログには、攻撃者がインストールされているプラグインの説明ファイルを次々と読みに来て、バージョン番号を確認していた記録も残っていました。どのプラグインの、どのバージョンが入っているか。既知の弱点があるものはないか。それを調べてから、攻撃を始めているわけです。
泥棒が下見をするのと同じです。そしてこの下見の段階では何も壊れないので、サイト運営者は何も気づきません。
実際の被害の実態
侵入されてから被害が完成するまでの速さについても、具体的にお伝えします。
パスワードを突破した攻撃者がサーバー内に不正プログラムを設置し、その動作テストまで終えるのに要した時間はわずか2分半でした。アクセスログを秒単位で追って、初めて分かったことです。「気づいてから対応すればいい」が成り立たない理由がここにあります。気づいた時点では、すでに終わっています。
被害によって生じる問題
では、被害として何が起きるのでしょうか。技術的には、サイトの改ざん、個人情報の漏えい、他者への攻撃の踏み台にされることなどが考えられます。検索エンジンから危険なサイトと判定されて、SEO順位が急落することもあります。
ただ、実際に現場で対応してみると、最も重いのは別のところにあります。改ざんされたサイトは、訪問者にとって危険なサイトになるのです。知らないサイトに転送されたり、不正な広告が表示されたり、訪問者の情報まで狙われる可能性があります。つまり、あなたは被害者であると同時に、加害者になってしまいます。
その上、Googleに「危険なサイト」として登録されてしまうと、検索結果に警告が出る状態がしばらく続きます。技術的な復旧が終わっても、信用が戻るまでには時間がかかります。これが金銭的な損失以上に効いてくるのです。
セキュリティ対策の本質
あの対応の中で、依頼主が一番心配していたのは、サイトが直るかどうかではありませんでした。「自分たちのサイトのせいで、見に来てくれた方や関係者に迷惑がかかるのではないか」ということでした。
つまり、セキュリティ対策とはサイトを守る作業ではなく、そのサイトを信じて訪れてくれる人との関係を守る作業だと考えるべきです。
ここまで聞くと怖く感じるかもしれません。ですが、大事なポイントをお伝えします。やるべきことは決まっていますし、そのほとんどは無料でできます。順番さえ間違えなければ、初心者の方でも十分に守ることができます。
優先順位つき！今日からできる！WordPressセキュリティ対策の基本
対策を始める前に、優先順位を理解することが重要です。効果の大きさと、失敗のリスクの低さで順序立てています。この順番を守れば、初心者でも安全に進められます。
【1位】レンタルサーバーのWAFを有効にする
これを最優先にする理由は3つあります。
まず、サーバーの管理画面で切り替えるだけで数分で終わることです。ファイルを一切編集しないので、操作を間違えてサイトを壊す心配がありません。設定ファイルを触る知識も必要ありません。
次に、かなりの範囲をまとめてカバーできることです。WAF（Webアプリケーションファイアウォール）は、サイトの前に立って不審なアクセスを止めてくれる仕組みです。先ほど説明した勝手口や通用口からの総当たり攻撃も含めて、多くの不正アクセスをここで防ぎます。
そして、多くの国内レンタルサーバーに標準で付いていて、無料で使えることです。ところが初期状態でオフになっていたり、過去に誤作動を疑ってオフにしたまま忘れていたりすることが実際によくあります。
【2位】管理者アカウントの棚卸しと、パスワードの入れ替え
WordPressの管理画面のユーザー一覧を開いて、管理者権限を持っている人が誰なのかを実際に見てください。制作を依頼した会社のアカウントが残っていませんか。退職した担当者のアカウントは消えていますか。テスト用に作ったまま忘れているものはありませんか。
使っていないアカウントは、そのまま侵入口になります。誰も使っていないので、不審な動きにも気づきようがありません。
あわせて、そのアカウントに登録されているメールアドレスも確認してください。今も毎日見ているアドレスになっているでしょうか。
この確認が重要な理由があります。改ざん被害に気づけたきっかけは、「パスワードを変更しました」というWordPressからの通知メール一通でした。もしそれが誰も見ていない古いアドレスに送られていたら、発見は数日遅れ、その間サイトは改ざんされたまま公開され続けていたはずです。
技術的な対策と同じくらい、「おかしい」と気づける状態を作っておくことが重要です。
【3位】ログインURLの変更と、ユーザー名の露出を止める
この2つはセットで考えてください。
攻撃者は「どこを叩けばいいか」と「誰のパスワードを当てればいいか」の両方を知って初めて、効率的に攻撃できます。ログインURLを変えれば前者が、ユーザー名の露出を止めれば後者が分からなくなります。
どちらもセキュリティ系のプラグインで設定できるので、ファイルを直接編集する必要はありません。
初心者が陥りがちな失敗と、防ぐ方法
ここからが重要です。セキュリティ対策で起きる事故の多くは、攻撃されたからではなく、自分の設定ミスで自分を締め出すことです。 実例を挙げます。
最も多い失敗は、ログインURLを変えたが新しいURLを控えていないというものです。セキュリティプラグインは有効にした時点で新しいURLを管理者メールに送ってくれますが、そのメールを見落としたり消してしまったりすると、翌日から自分が入れなくなります。
対策はシンプルです。変更した瞬間にパスワード管理ツールへ、パスワードと一緒に保存してください。ブラウザのブックマークだけに頼るのは危険です。パソコンを買い替えた時点で失われます。
二段階認証を設定したが、リカバリーコードを控えていないという失敗もあります。スマートフォンを機種変更したり紛失したりした時点で、二度と入れなくなります。認証アプリを設定するとき、必ずリカバリーコード（バックアップコード）が表示されるので、それを必ず保管してください。
IP制限による「最強の対策」は、初心者にはおすすめしません。家庭のインターネット回線のIPアドレスは、多くの場合固定されていません。ある日変わります。そうなると自分が締め出され、しかも解除する手段も失います。
事故を防ぐ、たった2つのルール
とくに2つめが重要です。ログインしたまま作業を終えてしまうと、締め出されていることに翌日まで気づけません。
プラグインで強化！「裏口」も含めたログイン防御とスキャン機能
プラグインの役割を理解する
プラグインの役割を、正しく理解することから始めましょう。
プラグインはWordPressが起動したあとに動きます。つまり、攻撃者からのアクセスはすでにWordPressの中まで届いていて、その内側で「これは怪しい」と判定している状態です。家にたとえるなら、玄関を通ってリビングに入ってきた相手を、部屋の中の見張りが止めている状態です。
対してサーバーのWAFや設定ファイルによる遮断は、WordPressが動き出す前、建物の門の段階で止めます。中に入れないので、そもそもWordPressに負荷もかかりません。
もう一つ、重要な事実があります。プラグインは、それ自体が攻撃の対象になります。セキュリティプラグインに脆弱性が見つかった事例は実際にあります。守るために入れたものが、入口になることがあるのです。だから、増やせば増やすほど安全になるという単純な話にはなりません。
外側（サーバー）で使っていない入口を塞ぎ、内側（プラグイン）で玄関を守り異常を検知する。この役割分担が現実的です。
プラグインの選び方
「これ一つ入れれば完全に守れる」というプラグインは、実際には存在しません。 そして私が改ざん被害の再発防止をしたときも、プラグインを主役にはしませんでした。使ったのは、サーバー側のWAFと設定ファイルによる入口の遮断です。
国内のレンタルサーバーを使っているなら、SiteGuard WP Plugin が現実的な選択です。多くの国内サーバーで標準的に提供されていて、日本語で使え、動作が軽いです。初心者が設定できる範囲に機能が絞られているのも利点です。
海外製の多機能なものもありますが、機能が多いぶん設定項目も多く、通知も大量に届きます。初心者が使いこなすのは難しく、結局「よく分からないので全部オンにした」となって、自分が締め出されるケースが見られます。
セキュリティ系のプラグインは1つに絞ってください。複数入れると互いに干渉して、ログイン画面が二重に保護されて自分が通れなくなることがあります。
必ず設定すべき6つの急所
有効化しただけで満足しないでください。次の項目を確認してください。
1. ログインページの変更。 新しいURLを必ず控えて、パスワード管理ツールに保存することを忘れずに。
2. ログイン失敗時のエラーメッセージを詳細に出さない設定。 これは見落とされがちですが、初期状態のWordPressは「ユーザー名が違います」「パスワードが違います」と区別して表示します。攻撃者にとっては、ユーザー名が合っているかどうかの答え合わせができてしまいます。「ユーザー名またはパスワードが違います」とだけ返すように設定してください。
3. ログインロック（試行回数の制限）。 一定回数ログインに失敗したIPをロックすることで、玄関からの総当たり攻撃を防ぎます。
4. 画像認証（CAPTCHA）。 ログイン画面やコメント欄に追加して、ボットによる自動攻撃を遮断します。
5. 二段階認証。 パスワードが漏れても突破されないための最後の砦です。設定するときに表示されるリカバリーコードを必ず保管してください。ここまでやって設定完了です。
6. XMLRPC防御とユーザー名の列挙防止。 前章で説明した勝手口と表札を塞ぐ設定です。
REST APIの一括処理について
REST APIの一括処理を使った総当たりは、多くのセキュリティプラグインが対応していません。前章で説明した「通用口」です。ここはサーバー側の設定ファイルで塞ぐ必要があります。詳しくは次の章で説明しますが、プラグインだけでは守り切れない領域があることを頭に入れておいてください。
スキャン機能について、知っておくべきこと
ファイルの改ざんを検知するスキャン機能は有用です。ただし万能ではありません。
実際にバックドアを探したとき、不正なコードに含まれるはずの特徴的な文字列で検索をかけたのですが、まったく引っかかりませんでした。理由を調べたら、そのマルウェアは関数名と括弧の間にコメントを挟み込んで、文字列検索に引っかからないように作られていたのです。人間が読めば同じ処理でも、機械的な検索では別物に見えます。それだけの手間をかけて作られていました。
結局、犯人にたどり着いた決め手は、スキャンではなくファイルの更新日時でした。チームの誰も作業していない時刻に更新されたファイルがある。そこから追って、偽装されたプラグインを見つけました。
スキャン機能は「入れておけば安心」ではなく、「異常に気づくきっかけの一つ」と考えてください。そして、この話が示しているのは、検知よりも侵入させないことのほうがずっと確実だということです。
プラグインの導入が「必要最小限」であるべき理由
セキュリティを強化したい気持ちから、複数のプラグインを入れたくなるかもしれません。ですが、入れすぎると表示速度が低下し、不具合も増えます。何より、トラブルが起きたときに「どのプラグインが原因か」を特定するのが難しくなります。
シンプルに、信頼できるものを1つ選び、必要な設定を確実に行う。これが初心者にとって最も確実な方法です。
サーバー側でさらに強固に！盤石なセキュリティ設定
ここからの設定は、ファイルを編集する可能性が出てきます。だからこそ、境界線を明確にしておく必要があります。
失敗したときに自分で元に戻せるかどうか。これが判断基準です。
同じ設定ファイルの編集でも、FTPで原本を戻せる人にとっては安全な作業で、戻せない人にとっては、サイト全体を落として復旧できなくなる作業になります。手順の難易度ではなく、この一点で判断してください。
レベル1：誰がやっても失敗しない（今日やってください）
サーバーの管理画面で完結し、ファイルを一切編集しないものです。
- WAFが有効になっているか確認する
- PHPのバージョンが古くないか確認する。サポートが終了したPHPは、それ自体が脆弱性を放置している状態です
- 常時SSL化（https）されているか確認する
- サーバーが提供している自動バックアップが有効か、何日分残るかを確認する
- サーバーがWordPress向けのセキュリティ設定を提供していれば、有効にする
ここまでで、実は相当な範囲がカバーできます。設定を戻すのもワンクリックなので、リスクはほぼゼロです。
レベル2：慎重にやれば大丈夫（プラグイン経由）
XMLRPC の遮断と、ユーザー名の列挙防止。これらはセキュリティプラグインの設定画面から切り替えられるので、ファイルを触らずに済みます。
うまくいかなければ、プラグインの設定を戻すか、最悪でもFTPでプラグインのフォルダ名を変更すれば無効化できます。復旧の道が残っているという意味で、まだ安全圏です。
レベル3：ここが境界線（.htaccess の直接編集）
REST APIの一括処理を塞ぐには、サーバーの設定ファイル（.htaccess）を直接編集する必要があります。
具体的には、xmlrpc.php へのアクセス、?author= によるユーザー名の列挙、そしてREST APIの一括処理エンドポイントへのアクセスを、それぞれ拒否する記述を追加します。
効果は確実です。WordPressが動き出す前の、門の段階で止まります。
.htaccess を触ってよい人の条件
次の3つを全部満たすなら、やってもいいと思います。
- FTPまたはサーバーのファイルマネージャーで、ファイルをアップロードできる
- 編集前に原本をダウンロードして、パソコンに保管した
- 編集直後にサイトを確認できる時間帯に作業する
3つめは意外と重要です。深夜に設定して寝てしまい、朝までサイトが落ちていたということが起こります。
私自身の失敗から
正直にお話しすると、私もこの作業で失敗しています。
緊急対応の最中に .htaccess へ記述を追加したのですが、何をしている記述か分かるように日本語でコメント（説明書き）を入れたところ、文字化けで一部の文字が欠落し、記述そのものが壊れてサイトが500エラーになりました。
教訓は2つです。設定ファイルのコメントは半角英数字だけにすること。 そして、事前にバックアップを取っていたから、すぐ元に戻せたということです。
プロでもこうなります。だからこそ、原本の保管を条件に挙げています。
パーミッション設定について
wp-config.php の権限を400や440に変更する対策をよく見かけます。
これについては、初心者の方は触らなくていいというのが私の意見です。
理由は2つあります。まず、適切な値がサーバーの構成によって違います。サーバーがPHPをどう動かしているかで、400にすると動かなくなる環境も、600でなければいけない環境もあります。記事に書かれた数字をそのまま真似ると、サイトが止まることがあります。
もう一つは、多くの国内レンタルサーバーでは、初期状態ですでに適切な値になっているからです。変更しても、体感できる効果はほとんどありません。
リスクがあって効果が見えにくい作業は、優先度を下げるべきです。同じ時間を使うなら、WAFの有効化とバックアップ体制の確認に充ててください。
自分でやらない場合の代替案
「REST APIも塞ぎたいが、ファイルを触るのは怖い」という方に、2つ提案があります。
1つめ。WAFを有効にしてください。WAFは不審なアクセスのパターンを見て遮断するので、総当たり攻撃のかなりの部分をここで止められます。完全ではありませんが、何もしていない状態とは大きく違います。
2つめ。レンタルサーバーのサポート窓口に相談してください。「xmlrpc.php とREST APIの一括処理エンドポイントへの外部アクセスを遮断したい」と具体的に伝えれば、手順を案内してくれるサーバー会社もあります。自分で調べて手探りで触るより、ずっと安全です。
それでも不安が残るようでしたら、無理に進めないでください。セキュリティ対策をしようとしてサイトを落としてしまっては、本末転倒です。
万が一に備える！バックアップと被害時の対応
セキュリティ対策をどれだけ講じても、100%の安全は存在しません。だからこそ、被害に遭ったときの準備と、その対応方法を知ることが重要です。
絶対にやってはいけない5つのこと
【1】パスワードを変えて、それで終わりにする
いちばん多い間違いです。攻撃者は侵入した直後に、再侵入用の裏口をサーバー内に仕込みます。入口の鍵を替えても、裏口が開いたままなら意味がありません。パスワードを変えて安心した数日後にまた入れなくなるのは、この裏口が残っているからです。
【2】原因を特定しないまま、バックアップから復元する
これが最悪の一手です。理由は2つあります。
1つめ。侵入された原因はサイトの設定や環境にあるので、古い状態に戻しても原因はそのまま残ります。脆弱性ごと復活させることになり、また同じ手口で入られます。
2つめが深刻です。復元は上書きなので、攻撃の痕跡が全部消えます。 いつ、どこから、どうやって入られたのか。調べる材料そのものが失われるのです。そうなると、二度と原因は分からず、対策も打てません。
【3】不審なファイルを見つけて、いきなり削除する
気持ちは分かりますが、待ってください。削除すると、どんなファイルがどこに置かれていたかという情報が消えます。他にも仕込まれている場合、共通点をたどる手がかりを自分で捨てることになります。
【4】WordPressを再インストールする
「入れ直せばきれいになる」と考えがちですが、不正なファイルはWordPress本体とは別の場所にも置かれます。きれいにならないうえに、痕跡だけが消えます。
【5】改ざんされたまま、サイトを公開し続ける
調査に時間をかけている間も、訪問者は被害を受け続けます。Googleに「危険なサイト」として登録されると、復旧後も検索結果に警告が出る状態がしばらく続きます。
真っ先にやるべきこと
被害に気づいたら、この順番で行動してください。
【1】現状を保全する
まず、いまの状態をそのまま記録します。画面のスクリーンショット、届いた通知メール、そしてファイルとデータベースのコピーです。
ここで誤解しないでほしいのですが、このコピーは「復元するため」ではありません。汚染された状態の記録、つまり証拠です。
【2】サイトを一時的に止める
被害の拡大を止めます。メンテナンス表示に切り替えて、外部からのアクセスを遮断してください。作業する人だけが通れる仕組みを用意しておくと、調査を続けながら止められます。
【3】認証情報をすべて入れ替える
WordPressのユーザーだけでなく、FTP、サーバーの管理画面、データベース。攻撃者が握っている可能性のあるものを全部です。
ここで最も重要なのが、WordPressの設定ファイルにある「認証キー」の差し替えです。これを新しい値に書き換えると、現在有効なログイン状態がすべて無効になります。
なぜ重要かというと、パスワードを変更しても、すでにログインしているセッションは切れないからです。攻撃者がその瞬間ログイン中でも、認証キーを替えれば強制的に追い出せます。
【4】アクセスログを確保する
これは急いでください。理由があります。
私が侵入経路を秒単位で特定できたのは、発覚した当日にログを確保できたからです。あと数日遅ければ、「たぶん総当たりだろう」という推測で終わっていたはずです。
経験から言えること
対応した事案は、その日のうちに復旧まで完了しました。半日です。
なぜそれができたのか。依頼主が何も触らずに連絡してくれたことが大きかったです。攻撃を受けた直後の状態がそのまま残っていたので、調査ができました。
犯人にたどり着いた決め手は、ファイルの更新日時でした。チームの誰も作業していない時刻に更新されたファイルがある。そこを起点に追って、正規のプラグインを装った不正プログラムを見つけました。
もし先に、不審なファイルを削除していたら。あるいは、バックアップから復元していたら。ファイルの更新日時は全部書き換わって、この手がかりは完全に消えていました。原因が分からないまま、また同じことが起きていたはずです。
「何もしないでください」というのは、消極的なお願いに聞こえるかもしれません。でも実際には、これが復旧を早める最も効果的な行動です。
なお、「ログインできない」「サイトが真っ白になった」といった症状から実際に復旧する具体的な手順は、別の記事に詳しくまとめています。あわせてご覧ください。
バックアップの本当の価値
一つ反省があります。対応したサイトには、バックアップが残っていませんでした。 結果として復旧できましたが、「最悪これに戻せる」という土台が無い状態で調査と駆除を進めるのは、精神的にまったく違います。判断が慎重にならざるを得ないぶん、時間もかかりました。
バックアップは「取っているか」ではなく「戻せるか」です。そして保存先は必ずサーバーの外に置いてください。サーバーごとやられた場合、サーバー上のバックアップも一緒に汚染されます。
専門家に相談すべきタイミング
次のどれかに当てはまるなら、自力での対応は止めてください。
一度直したのに、また同じ状態に戻る場合、裏口が残っています。FTPやサーバーの管理画面にも入れない場合、サーバーごと取られている可能性があります。この場合はサーバー会社にも連絡してください。
問い合わせフォームや会員機能があり、個人情報を扱っている場合、情報が持ち出された可能性の評価と、関係者への報告が必要になります。バックアップが存在しない場合も同じです。
そして時間の話をもう一度。ログには寿命があります。「怖い」と感じた時点が、実は最も安く早く終わるタイミングです。
私は現役のweb制作エンジニアとして、WordPressの復旧や改ざん・乗っ取りへの対応、そして再発防止の設計を手がけています。サーバーのアクセスログ解析による侵入経路の特定、バックドアの発見と駆除、原因を突き止めたうえでの恒久対策まで。表面を直して終わりにせず、なぜ入られたのかを塞ぐところまでを一つの仕事だと考えています。
まだ被害に遭っていない段階でも構いません。「対策したいが何から手を付ければいいか分からない」「自分で設定を触るのが不安」という段階でのご相談も承っています。現状を確認して、優先順位をつけてご提案します。初回のご相談・お見積りは無料です。一緒に、原因から考えていきましょう。
Last modified: 30 Jul 2026