保守先のサイトでWordPressを更新しているとき、サイトの中に「移行プラグインが残したバックアップ」が4本あるのを見つけました。合計893MB。URLを直接たたくと、ログインなしで丸ごとダウンロードできました。
結論から書きます。バックアップにはデータベースが入っています。管理者のパスワード（ハッシュ化されたもの）やメール送信の設定が含まれます。プラグインは既に消されていて、バックアップだけが残っていました。その日のうちに4本とも削除し、外から404になることを確認しました。以後、月次の点検項目に「バックアップ置き場に外からアクセスできないか」を加え、保守先7サイトで露出がないことを確認しています。
きっかけ
10月23日、SEOプラグインとWordPress本体の更新のために、サーバーにSSHで入って作業前のバックアップを取っていました。容量を見ると wp-content/ai1wm-backups/ というフォルダが異様に大きい。中に .wpress という拡張子のファイルが4本、5月30日・6月3日・6月4日・6月12日の日付で、1本あたり214〜243MBありました。
.wpress は「All-in-One WP Migration」というサイト移行プラグインが作るファイルで、サイトのファイルとデータベースを1本にまとめたものです。春にサイトを移したときの残骸でした。プラグイン自体はもう入っていません。
最初に：作業する場所を整理
- サーバー（SSHかFTP）。フォルダの中身と、同梱の設定ファイル（.htaccess）を見る場所
- ブラウザ、または curl。外からそのURLに本当にアクセスできるかを試す場所
- サーバーの管理パネル。アクセスログがあればここ
用語は3つだけ
- 公開フォルダ：サーバー上で、URLでアクセスできる範囲。WordPressの
wp-contentはこの中にあります - .htaccess：フォルダごとにアクセスの可否を決める設定ファイル
- ディレクトリ一覧：フォルダのURLを開いたときにファイル名が並ぶ表示。これを隠すのと、ファイル自体を塞ぐのは別物です
手順0：本当に外から取れるのかを確かめる【ブラウザ・curl】
フォルダには、プラグインが置いた .htaccess が同梱されていました。中身は、拡張子の扱い・既定の表示ファイル・「ディレクトリ一覧を出さない」の3行だけ。ファイル自体へのアクセスは塞いでいません。
実際に、ファイル名を指定して外から取ってみました。
HTTP 200
Content-Length: 253,980,571242MBのファイルが、ログインなしで返ってきます。部分取得（Range）も通るので、分割して落とすこともできます。
「ファイル名が分からなければ落とせない」も成り立ちませんでした。4本のうち2本は、ファイル名の末尾が3桁の数字でした。日付が分かれば1,000通りを試すだけです。残る2本は長いランダム文字列でしたが、ディレクトリ一覧を出さない設定だけでは、推測しやすい名前のものは守れません。
手順1：中身に何が入っているかを把握する【サーバー】
.wpress の中には、サイトのファイル一式と、データベースの全テーブルが入ります。つまり次が含まれます。
- ユーザー一覧と、パスワードのハッシュ
- サイトの設定（メール送信のサーバー・パスワードなど、プラグインが保存した値）
- 問い合わせフォームの送信履歴を保存するプラグインがあれば、その中身
「古いバックアップだから中身も古い」は慰めになりません。5月時点の管理者パスワードが、いまも同じなら生きています。
手順2：削除する【サーバー】
4本とも削除しました。削除は、1本ずつ絶対パスを指定して実行しています。フォルダごと消すコマンドは、指定を間違えたときの被害が大きいので使いません。
削除後、フォルダは893MBから20KBになり、サイトは200のまま、4本のURLはすべて404になりました。
削除で足りるのは、プラグインが入っていないからです。もし移行プラグインを使い続けるなら、バックアップの置き場を公開フォルダの外にするか、.htaccess で「このフォルダのファイルは返さない」を自分で書く必要があります。プラグインの同梱設定だけでは塞がりません。
手順3：ほかのサイトを同じ目で見る【ブラウザ・curl】
移行プラグイン以外にも、バックアップを公開フォルダの中に置く仕組みはあります。保守先と自社の7サイトで、次のフォルダに外からアクセスできるかを確かめました。
/wp-content/ai1wm-backups/（All-in-One WP Migration）/wp-content/updraft/（UpdraftPlus）/wp-content/uploads/backwpup/ほか（BackWPup はフォルダ名に乱数が付くので、設定画面で確認）
結果は、ファイルが返ってくるものはゼロでした。1サイトだけフォルダが残っていて（今回削除したサイト）、中身は空です。別のサイトでBackWPupを使っていますが、保存先フォルダは外から403で、ファイルは取れません。
手順4：月次の点検項目に入れる
先日の記事で書いた「保守先を外から点検する」仕組みに、この項目を足しました。見るのは「バックアップ置き場のURLにGETして、ファイル名が分かる・ファイルが返る、のどちらかが起きないか」です。プラグインを消してもバックアップは残る、という前提で毎月見ます。
つまずき早見表
| 起きたこと | 原因 | 対処 |
|---|---|---|
| バックアップが外から落とせる | 置き場が公開フォルダの中で、ファイルへのアクセスが塞がれていない | 削除するか、公開フォルダの外に移す |
| 「一覧を出さない」設定があるから大丈夫だと思った | 一覧を隠すのとファイルを塞ぐのは別 | ファイル名を指定して外から取ってみる |
| ファイル名が推測できる | 末尾が3桁の連番 | 推測不能な名前でも、塞ぐのが先 |
| プラグインを消したのに残っている | プラグインの削除はバックアップを消さない | フォルダを自分で見る |
| 誰かに落とされたか分からない | アクセスログを見ないと分からない | ログの保存期間を確認。分からないなら「漏れた前提」で管理者パスワードを変える |
確認方法：自分のサイトで今日できること
- ブラウザで
https://自分のドメイン/wp-content/ai1wm-backups/と/wp-content/updraft/を開く。ファイル名が並んだら、その場で問題です - 並ばなくても安心しない。FTPかサーバーのファイルマネージャーで同じフォルダを開き、ファイルがあれば、そのファイル名をURLに付けて開いてみる。ダウンロードが始まれば、外から取れています
- 取れていたら、削除するか公開フォルダの外へ移し、管理者パスワードとメール送信のパスワードを変える
正直に書いておくこと
- 5月から10月までの間に、誰かがダウンロードしたかどうかは確認していません
- 今回の7サイトは当社の保守先に限った確認です。移行プラグインを使ったことがあるサイトは、同じ構造を持っている可能性があります
- 「公開フォルダの外に置く」はサーバーの契約によってはできません。その場合は
.htaccessで塞ぐか、取り終えたら消す運用になります
要点3行
- 移行プラグインのバックアップは、プラグインを消しても公開フォルダに残る
- 「一覧を出さない」設定は、ファイル自体を守らない。外からファイル名を指定して取ってみる
- 見つけたら削除し、漏れた前提で管理者とメール送信のパスワードを変える
