php2shell対応のメモ

世間を賑わせている、PHPの2件の脆弱性（php2shell）。実はブログサイトも影響があるのではと思い立ったのが、23日の金曜日でした。
かなり騒がれていたのに、随分とのんびりしてました。

さて、どんな状況なのかをまずは、確認しました。
ブログサイトは、WordPressを使っていますので、今回のPHPの脆弱性を受ける可能性が高いです。現状、AWSのLightsailを使って構築していましたので、その辺りを確認することから初めて行きます。

1. 状況確認

(1) WordPressの状況

管理者画面にログインし、「ツール」-「サイトヘルス」を確認したところ、PHPのバージョンは、8.2.28でした。

PHP公式ページの案内では、Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35と記載がありますので、残念ながら対応しないといけないことが確認できました。

(2) AWS Lightsailの状況

AWSのLightsailのページにアクセスすると、PHP update recommended と This blueprint is being deprecated と表示されていて、やはり何かしらの対応が必要だと促していました。

2. 対応方針

AWS Lightsailは、ブループリントで簡単にアプリケーションがセットアップしてくれるものの、アップデートなどのメンテナンスまで実施してくれるわけではないため、注意が必要でした。
合わせて、Bitnamiのブループリントが、非推奨（deprecated）とのことなので、PHPだけではなく、ブループリントを乗り換えることも必要だと思いました。

そこで今回は、一旦 PHP update recommended のガイドに沿って、対応を進めようと思います。
大まかな流れとしては、以下となりそうです。

1. WordPressのバックアップを取る。
2. Lightsailのインスタンスを新規作成する（推奨のブループリントでWordpressを構築）
3. バックアップファイルからリストアする。
4. static IPアドレスの付け替え
5. サーバ証明書の再作成
6. サイトの動作確認
7. 古いインスタンスの削除

3. WordPressのバックアップを取る

「All-in-One WP Migration」プラグインを使い、バックアップを取得します。

「All-in-One WP Migration」-「バックアップ」と進み、「バックアップを作成」をクリックします。

この「All-in-One WP Migration」は、ブログ記事の他、アップロードしている画像などのメディアファイル、プラグインなども合わせて一つの .wpress ファイルにまとめてくれて、ダウンロードできるようになります。

4. Lightsailインスタンスの新規作成

Create an instance をクリックして、新しいインスタンスを作成していきます。

Instance locationは、現状と同様に、Tokyo, Zone A (ap-northeast-1a) としました。

次にイメージのプラットフォームとブループリントの選択となります。
プラットフォームは、Linux appsとして、ブループリントは、WordPress 7.1 Lightsail としました。
WordPress detailsを開き、ブループリント提供者が、Lightsail であることを確認します。

次に、プランですが、ここでは、General purpose、Dual-stack、$7 としました。
インスタンスの設定として、インスタンスの名前を設定（WordPress-2）して、
Automatic snapshotsを有効にしました。（JST 02:00開始）
SSH Keyについては、ここで新規作成しました。（WP-lightsail）
Download private keyをクリックして、秘密鍵をダウンロードします。.pemの拡張子のファイルです。

準備が整ったら、Create instance をクリックして作成します。

画面が変わり、しばらくすると、Instance state が、Running となり、起動したことが確認できます。
また、Public IPv4 address、Private IPv4 address、Public IPv6 address 部分にも、IPアドレスがアサインされていることが確認できます。
このタイミングでは、System status check、Instance status check は、Initializing となっていました。

5. 新しいWordPressインスタンスの設定とリストア

(1) デフォルトパスワードの確認

LightsailでセットアップしたWordPressの管理画面にアクセスするためのユーザーIDとパスワードを確認します。

Lightsailの管理画面で新規作成したインスタンスを選択し、Connect usign SSH をクリックすると、ブラウザ画面でSSHコンソールアクセスが可能となります。
Linuxへのログインパスワードなど入力はなく、最初からシェル操作が出来る状態です。
この画面で、ガイドにある、「cat ~/application_credentials」を確認します。
このコンソールは、コピー＆ペーストが可能なので、便利です。

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Oct 25 03:12:06 2026 from xxx.xxx.xxx.xxx
admin@ip-xxx-xxx-xxx-xx:~$ cat ~/application_credentials
user
xxxxxxxxxxxxxxxx
admin@ip-xxx-xxx-xxx-xx:~$ 

WordPressの管理画面にアクセスする際の、ユーザーIDとパスワードが表示されますので、メモしておきます。

(2) WordPress 管理画面へのアクセス

Lightsailの管理画面で新規作成したインスタンスを選択し、Access WordPress Admin をクリックすると、WordPressのログイン画面が表示されますので、先ほど確認した、ユーザー名とパスワードを入力してログインします。

※ブラウザによっては、httpsでアクセスを試みて注意喚起の画面が表示されますが、内容を確認の上アクセスします。

(3) バックアップデータのリストア

バックアップデータをリストアするので、「All-in-One WP Migration」プラグインを有効化します。

「All-in-One WP Migration」-「Import」を選択します。

先ほどダウンロードした、.wpress ファイルを、IMPORT FROMで、「FILE」をクリックして、アップロードします。

アップロードするファイル容量が大きいと、以下のようにエラーとなってしまいます。

いくつか解決方法はあるのですが、今回はサーバ上の設定ファイルを編集して対応することにします。

(4) php.iniファイルの編集とApache2の再起動

php.iniファイルを編集して、Apache2を再起動して有効化します。

php.iniの場所 ： /etc/php/8.2/apache2/php.ini
php.iniファイルを、sudo vimで開き、以下のように設定し、保存しました。

upload_max_filesize = 1024M 
post_max_size = 1024M 
memory_limit = 512M 
max_execution_time = 300 
max_input_time = 300

バックアップファイルが、800MBを超えていたので、1024Mとしました。
※プラグインなど多数有効にしていたため、バックアップファイルのサイズが大きくなってました。

php.iniファイルの編集ができたら、その設定を反映させるべく、Apache2を再起動します。

sudo systemctl restart apache2

(5) バックアップデータのリストア（再び）とWordPressの動作確認

アップロード可能なファイル容量を大きくしたので、今度はエラーとならないはずです。
「All-in-One WP Migration」-「Import」を選択し、.wpressファイルをアップロードします。

ファイルアップロードが完了して、少ししたら、以下の注意が表示されます。内容を確認の上、「PROCEED」をクリックしてリストアを開始します。

順調にリストア作業が進むと、「サイトをインポートしました。」と表示され、リストアが完了したことがわかります。

その後、WordPressのブログ記事などが正しく表示されるかなど確認していきます。

このタイミングでは、記事の詳細を表示しようとするとエラーになったりするかもしれませんが、まぁ、それなりに表示されることが確認できたので、ヨシとします。
リンク先となるドメイン名の表記などが合ってないことが原因と考えられます。

また、AWSのLightsailでWordPressを構築すると、HTTPS通信のためサーバ証明書として自己署名のサーバ証明書が最初に設定されてきます。
いわゆるオレオレ証明書なので、当然、「この接続ではプライバシーが保護されません」（Chrome）、「この接続は安全ではありません」（Safari）が表示してきます。

こちらは後程対応していきます。

6. DNSサーバのAレコード、AAAAレコードの変更

Lightsailのインスタンスを作成した後に、自動的に割り当てられるIPアドレスをDNSサーバに登録します。
現在は、cloudflareのDNSサービスを利用しているので、cloudflareの管理画面にログインして、DNSレコードのIPアドレスを、新しいLightsailインスタンスのグローバルIPアドレスに変更しました。

7. Lightsail Setupの実行

Lightsailのインスタンス画面で、Getting started タブの中にある、「Start Lightsail Setup」をクリックしてセットアップを進めます。

このセットアップウィザードでは、ドメイン名を新規で設定することなどもできるようですが、今回は既存サイトの設定となり、ドメインの設定については、「Third party domain」を選択しました。

途中でスタティックIPアドレスの設定がありますので、Create static IP を実行しました。
※これまで設定してなかったのですが、グローバルのIPアドレスが変更になることはありませんでした。サーバを再起動などさせなければそのままだったのだと思います。
※今後も同じとは限らないのでこのタイミングで、スタティックIPアドレスを設定しました。

グローバルIPアドレスのアサインが完了すると、DNSへの登録をするように説明がありました。
このタイミングで、CloudflareのDNSサーバの設定を変更しました。

次に、SSL/TLS証明書の作成画面となります。
ドメイン名、連絡先のメールアドレスを入力します。

「I authorize Lightsail to configure a Let’s Encrypt certificate on my instance.」にチェックを入れ、Lightsailへアクセスを許可する設定を入れます。

必要事項を入力して、Create certificate をクリックして進みます。

※Cloudflareでドメインを管理している場合

アサインしたスタティックIPと、DNSサーバから応答があるIPアドレスが違うため、エラーとなるケースがあるようです。このエラーを回避するため、一時的にCloudflareの設定を変更します。

CloudflareのDNSレコード設定画面

プロキシ ステータスの項目を、一時的に「DNSのみ」に変更する。
DNSレコード1行ごとに設定・保存が必要となる。

CloudflareのDNSレコードの設定を変更した後、変更が反映されているか、DNS伝搬チェッカーなどで確認します。

先ほど、AWS Lightsail上でスタティックIPをアサインしましたが、このIPになっているかどうか確認します。

Let’s Encrypt SSL/TLS証明書でサーバ証明書を発行する際、DNSサーバからの応答と設定が合っているかを確認しているのだと思います。

セットアップの完了を待ちます。

Let’s Encrypt SSL/TLS証明書でサーバ証明書の設定が始まり、15分かかるとメッセージが表示されます。
ウィザード画面では、以下のように進捗状況が確認できました。

サーバ証明書の設定も完了すると以下のような画面になります。

TLS通信の確認

ブラウザを開き、WordPressサイトにアクセスをして確認します。

一旦、LightsailのWordPressサーバ単体でも、Let’s Encrypt発行のサーバ証明書でTLS通信していることが確認できました。

その後、CloudflareのDNSサーバ上で、プロキシを有効にしました。

伝搬が完了後、再びサイトにアクセスして、問題なく通信出来ることを確認しました。
サーバ証明書は、Cloudflare側で用意されているものに変わっていて、LightsailのWordPressに直接通信があるのではなく、一旦Cloudflareのプロキシを経由していることが確認できます。

CloudflareはGoogleとも提携していて、プロキシのサーバ証明書の発行の際、認証局(CA)として提携しているGoogle Trust Servicesの認証局を使っているようです。

8. 古いインスタンスの停止

新しいサイトの動作確認を終えた後、
PHPのバージョンが古く、Bitnamiのブループリントも非推奨となった古いインスタンスを選択し、Stopをクリックして停止しました。

まとめ

php2shell対応としては、別の環境に作り直して引っ越しする、という対応となりましたが、今後も同様の対応を行う機会が増えてくるようにも思えますので、手順を確認しておけたので良かったと思います。

何かの参考になれば。