Last updated on

案件を機に見直した、Webサイトの不正アクセスと復旧の見方

  • wordpress
  • security
  • hosting

はじめに

Webサイトの制作に関わる立場（静的サイトや CMS／WordPress 等）で、不正アクセスや改ざんの事態に遭遇した経験をきっかけに、対策と復旧の見方を改めて整理し直しました。

前提として、公開しているブラウザから見える Webサイトと、その下のホスティング・転送・運用に焦点を当てます。大規模業務システムのような「内部 API と複雑な権限設計が主戦場」の話は扱いません。

不正アクセスを受けたら、まず何をするか

侵害や障害の具体像は案件ごとに異なるので、網羅的な手順書ではなく、サーバー専任に限らず、制作・フロント／テーマ実装に関わる人も含めて、最初に揃えておきたい一次対応の順番だけ列挙します。

  1. 窓口を決める — 契約上のホスティング／保守の連絡先、クライアント側の決裁者。誰がホストと話すか、制作が直接パスワードを変えていいか、を事前にそろえる。
  2. 指示のない上書きをしない — 「とりあえず手元の一式を FTP で流し込む」は、証拠の消失や二次被害の原因になり得ます。リストアや調査の方針が出たあとに動く。
  3. いま起きている症状をメモする — サイトが白画面か、DB エラーか、管理画面だけか、FTP が通らないのか。画面の言葉だけで一つの原因に決めつけない（後述のレイヤーで分ける）。
  4. 「どのアカウントの話か」を混同しない — WordPress 管理画面のログイン、MySQL 接続（wp-config.php）、FTP／SFTP／パネルは別物。復旧作業の会話でそれぞれ取り違えやすい。
  5. 不審ファイルの扱いは運用側の指示に従う — ローカルに落として開いたり実行したりせず、必要なら窓口に任せる。

復旧の方法 — レイヤーで切り分ける

復旧は「型の決まったマニュアル一つ」ではなく、どのレイヤーが壊れているか／戻っているかで手順が変わります。頭の中では次のブロックに分けて読むと、症状とログの対応が取りやすいです。

  • 閲覧者のブラウザ — ページ閲覧やフォーム送信が、サーバー上の Web アプリ（CMS・プラグイン・テーマ）へ届く。
  • サーバー上の Web アプリ — CMS がデータベースを読み書きする（閲覧・管理画面の主経路）。
  • 運用・アクセス（ブラウザ経路とは別にファイルや成果物で触れる層）
    • FTP／SFTP／パネルからは、ファイル一式の置換で Web アプリ側を直接書き換え得る。
    • ビルド・デプロイ・秘密の取り扱いでは、意図しない公開が Web アプリ側に波及し得る。

典型としては次のような読み分けが効きます。

  • Webサイト全体が「データベース接続エラー」のまま — アプリの改ざん以前に、復旧直後の DB 側設定と wp-config.php の不整合、または DB サービス未復旧、が原因になり得ます。運用が DB パスワードをローテした直後は特に、サーバー側だけ更新されているケースがありえます。
  • FTP クライアントは「接続できない」、サーバーログでは TLS のあと 530 Login incorrect — 回線不全だけでなく、ユーザー名・パス・アカウント状態（ロック等） を先に疑う順序になりやすい。ここでいうユーザー名は管理画面の WordPress ユーザーとは別です。
  • ファイルのクリーンリストアと DB のリストアの組み合わせ — どの世代まで戻すか、プラグインの版はどこまで一致させるかはホスト・保守の運用に依存します。制作側は、許可のある範囲で「良いと分かっているコミットやビルドと本番の差」を機械可読に確認するなど、手伝えることがあります。

WordPress／プラグインと「環境の版ズレ」

FTP を知られていなくても、プラグインやテーマの脆弱性に対する自動スキャナの話は珍しくありません。復旧後の再調査では、プラグイン・テーマのバージョンと更新日時を箇条書きで残すと、関係者との会話が早くなることが多いです。「検証環境では問題なかった」のに本番だけ、と言い切る前に、自動更新で本番だけ版が進んでいた可能性も念頭に置きます。自動更新の ON／OFF は契約・窓口の方針とそろえるのが無難です。

同一サーバーに複数サイトがある場合

侵入が一つのサイトに閉じるかは、OS ユーザー分離・コンテナ・別アカウントなどの設計に依存し、サイトの数を足し算するほど単純ではありません。逆に、似た CMS 構成が並んでいれば共通プラグインの欠陥が横断する側面もあります。自分の担当サイトのソースが健全でも、同居サイトや共用 FTP の変更が連鎖していると、復旧の遅れやログの見え方が「自分のコードだけ」では説明できなくなることがあります。

どんな経路で不正アクセスを受ける可能性があるか

「管理ユーザーのパスワードが強ければ済む」と一種類にまとまらないのが、この手の Webサイトで起きやすいパターンです。Webサイトのコードがきれいでも、別レイヤーで突破される典型を表にまとめます。

区分論点の例
ホスティング・転送・パネルFTP／SFTP／サーバーパネル／デプロイ用鍵の漏えい。ブラウザのフォームとは別経路。
CMS（WordPress 等）プラグイン・テーマの未修正脆弱性。管理画面へのボット総当たり。
運用・公開パス・ビルドバックアップや環境ファイルの誤公開、リポジトリへの秘密の混入。

大規模な業務システムに比べ、/wp-admin のような管理画面や、固定のホスティングパネルへの攻撃比率が論点になりやすい、という意味でも、ブラウザから公開されている一般的な Webサイトでは視点が異なります。

予防のためにできること

制作・フロントに関わる範囲で、短く列挙します。

  • できること — リポジトリに秘密を載せない。復旧の許可が出たあと、既知の良好なタグ／ビルドと本番の差を機械可読に確認する。運営のリストアや調査方針より先に、根拠のないフルアップロードで上書きしない（事後対応の項目と同じだが、平常時からチームで共有しておくとよい）。
  • 任せる・窓口で確認すること — アップロード領域で PHP が実行されるか、uploads の監査、WAF、アカウント粒度、バックアップ世代とリストア手順。不審ファイルを勝手に開かないことは運用側から制限されることがあり、その指示に合わせる。

同一サーバーに他サイトがある契約では、隔離やアカウントの粒度がリスク見積もりに効く、という認識だけでも、見積もりや保守範囲の会話に役立ちます。

用語ミニ辞典（この記事だけで意味をそろえる）

語メモ
wp-config.php の DB ユーザー・パスワード管理画面のログインとは別。MySQL への接続用。復旧後にサーバー側だけ変わっていると Webサイト全体が「データベース接続エラー」のままになり得る。
FTP の 331 と 530331 は「ユーザー名は受理、パス待ち」に近いことが多く、530 は多くはログイン不正（パス違いやアカウント状態）。TLS が通っているのに 530 なら、「回線」の前に資格情報を疑う順序になりやすい。

おわりに

この記事は、後から「レイヤーを混ぜずに読み返す」ための骨格としても使っています。タイムラインや検証用の細部は、公開の場ではなく自分用の短文メモにだけ残す運用にしています。