Scribble at 2023-01-12 09:37:10 Last modified: unmodified
これは今月に再公開した「WordPress のセキュリティ対策」に関係がある話なので追記するかもしれない。或るサイトが WordPress で運用されていて、サーバの PHP が 7.x 系統と古いため、このほど PHP 8.x 系統のサーバと入れ替えるので、サイトを移設してもらいたいという。最初にディレクターから聞いたときは、現行のサーバで PHP をバージョン・アップするかのような話だったため、7.x 系統で動いていた２年くらい前の WordPress（上場企業の案件ではよくあることだが、情シスとか出入り業者に脅されたり莫大な予算を要求されてか、WordPress の更新すらやってないサイトが意外と多い）だが、そのまま管理画面でアップデートすればいいだろうと思っていた。しかし、いざ作業する日が近づいてくると、新規サーバのアクセス情報という書類がきて、なんだサーバを移設するんじゃないかという話に変わったのである。
こういう大企業のサイトでは、サーバの運用会社も子会社とかでガチガチに固められていることが幾つかあり、レンタル・サーバのコンパネ・サイトに IP アドレスの制限がかかっていたりして、それなりに作業が複雑になる。現行サーバは当社の執務室の固定 IP アドレスや広告代理店の IP アドレスでしかアクセスできないらしいので、ひとまずディレクターに現行サーバの DocumentRoot 以下を全てダウンロードしてもらい、上の階層に wp-config.php がないことを確認してもらった。それから、サーバのコンパネには IP 制限がかかっているのに WordPress の管理画面には制限がないため、サイトの投稿データは WordPress のエクスポートで取り出した。幸か不幸か、WordPress は使っているものの、実際には「お知らせ」の更新にしか使われていないので、殆ど投稿データはない。本文すら別の静的ページに飛ばす URL が書いてあるだけである。
こうして、新サーバの情報をもらっているので、そちらにコンテンツを移設した。こちらの新サーバはコンパネに僕の自宅からでもアクセスできたのは幸いである。しかも、実際にコンパネにアクセスすると、驚いたことに Apache の httpd.conf までコンパネで編集してウェブ・サーバを再起動できるという強力な内容だった。そら IP 制限くらいかけるはずだ。ともあれ、MySQL が起動していないので起動し、どうやらこのサイトでは WordPress を自動インストールして使っていたようなので、そのままインストールしてプラットフォームは完了である。あとは、静的なコンテンツをアップロードして、httpd.conf を編集して仮のホスト名でアクセスする DocumentRoot を本来のドメインでアクセスする DocumentRoot に一致させて、phpMyAdmin で wp-options を編集して WordPress の暫定的なドメインを仮のホスト名に変更し、これで WordPress にログインできた。
しかし、テーマを現行サイトで使っているテーマに変更してからログアウトすると、ログインするときに 403 エラーが出てログインできなくなってしまった。これは焦ったが、よくあるディレクトリやファイルのパーミッションも問題ないし、キャッシュも消したし、プラグインも無効にしてみたのだが、どうもアクセスできない。そこで、ログインするための URL を変更しているのに、どうもプラグインを使っていないということを思い出してテーマの functions.php を見ると、ここでログインのファイル名をフックして変更し、直に wp-login.php へアクセスしたときは 403 エラーを返すようになっていた。なので、変更後のファイル名で作られた特殊な wp-hogehoge-login.php をアップロードしなおして 403 は出なくなった。
ということで、管理画面へのログイン URL を変更するという措置が有効な「対策」であるとすれば（僕は必ずしもそうは思っていないのだが）、それには幾つかのやり方があるので、ご紹介する文章を僕の記事に加えてもいいだろうと思ったわけである。大別すると、(1) プラグインでリダイレクトする、(2) ハード・コーディングでファイル名を変更する、(3) functions.php でアクセスをフックして変更するという三つくらいのやり方があるようだ。ただ、セキュリティ対策をプラグインに依存するのは概してよくないから (1) は選びたくないし、(2) のハード・コーディングは WordPress のアップデートを常に手動で行う必要があってよくないし（自動にすると wp-login.php を上書きされてしまう）、(3) も結局はハード・コーディングと変わらないリスクがあって、WordPress のコア・システムの変更に追随しなくてはならない。よって、マルチ・レイヤー防御という原則から言えば、
<FilesMatch "wp-login.php">
RewriteCond %{QUERY_STRING} !(^|&)magic=word($|&)
RewriteRule . /index.php$1 [L]
</FilesMatch>
のようにして、ファイル名を変更するよりも magic=word というクエリがなければトップ・ページにリダイレクトしてしまうように rewrite した方がいいような気がする。WordPress の対策を WordPress で実行するのは、できるだけ止めた方がいい。