WordPressのクラック被害からAstro+Cloudflare Pagesでブログを復旧・移行しました


MitsNote本館へアクセスいただきありがとうございます。しばらくの間、当ブログが正常に表示されない状態が続いていましたが、システムをWordPressから「Astro+Cloudflare Pages」へ移行して復旧しました。今後の備忘録も兼ねて、サイト停止の原因となった不正アクセスの手口と、新しい環境への移行手順をまとめます。

WordPressのクラック被害と不正メール配信の手口

当ブログが表示されなくなった直接の原因は、長年運用していたWordPressサイトが不正アクセス(クラック)を受け、スパムメール配信の踏み台にされたことです。レンタルサーバー業者から「[SUPPORT][重要] 改竄について」という警告メールが届き、ドメイン直下の .bwlthk1f_mlr.php などのファイルから送信者を詐称したスパムメールが大量に発信されているため、緊急処置としてサーバーアカウントを凍結したと通知されました。

レンタルサーバー業者から届いた「[SUPPORT][重要] 改竄について」という件名の通知メールのスクリーンショット。ドメイン直下の .bwlthk1f_mlr.php などから送信者を詐称したスパムメールが大量に発信されているため緊急処置としてサーバーアカウントを凍結したこと、複数の侵入口が作成されている恐れがあるため /public_html/.fast-cgi-bin と /public_html/log を除くすべてのWebサイトデータを削除して脆弱性のない最新版に置き換えること、あわせてFTPパスワードの変更とFTP接続情報を共有する全パソコンのセキュリティーチェックを実施して返信するよう求める内容が記載されている。 レンタルサーバー業者から届いたアカウント凍結と改ざん対応の通知メール

メールで指摘された .bwlthk1f_mlr.php は、末尾の _mlr という文字列から、攻撃者が外部からメールを不正送信するために設置したPHPスクリプト(Webメーラー)と考えられます。ファイル名の先頭にドット(.)を付けてLinux環境の隠しファイルにし、発見を遅らせる細工がされていました。攻撃者はWordPress本体やプラグインの脆弱性などを突いてサーバー内に侵入し、設置したスクリプトを外部から実行してサーバーのメール送信機能を悪用していたとみられます。

さらにサーバー内を確認すると、画像フォルダーの深い階層などにも多数のマルウェアが埋め込まれていました。見つかった不正スクリプトを1つ削除しても別の経路から再侵入・再生成できるよう、複数のバックドアが作られていたと考えられます。また、Wayback Machineのアーカイブの一部にも改ざんの痕跡があり、いつから侵入されていたか特定できませんでした。

メールの指示どおりに復旧するには、バックアップを取得したうえで /public_html/.fast-cgi-bin と /public_html/log を除くすべてのWebサイトデータを削除し、脆弱性のない最新版で再構築する必要がありました。あわせて、FTPパスワードの変更と、FTP接続情報を共有する全パソコンのセキュリティーチェックも求められていました。しかし、改ざんされたファイルが紛れ込んでいるバックアップから、手作業でマルウェアを完全に取り除くのは不可能と判断しました。そのため、レンタルサーバーはそのまま解約し、セキュリティー管理の負担が大きい動的CMS(WordPress)から移行することにしました。

静的サイトジェネレーター「Astro」の採用と導入

移行先には、Webフレームワークの「Astro」を選びました。Astroは静的サイトジェネレーター(SSG)であり、WordPressのようにアクセスのたびにデータベースを読み込んでPHPでページを生成するのではなく、記事データから事前に生成したHTMLや画像などの静的ファイルだけをサーバーから配信します。サーバー上でPHPを実行しないため、今回のように不正なPHPスクリプトを設置・実行されて踏み台にされる心配がなく、ページの読み込みも速くなります。

Node.js環境で npm create astro@latest コマンドを実行してプロジェクトを初期化し、ブログ用のテンプレートをベースにサイトを構築しました。ローカルでの開発やプレビューも npm run dev コマンドで手軽に行えます。

記事データの救出と復元

クラックされたサーバーのバックアップデータは、マルウェアの混入や改ざんが広範囲に及んでおり、そのまま再利用するのは危険でした。そのため、サーバーのバックアップは使わず、テキストと画像をそれぞれ別の経路から復旧しました。

記事のテキストデータは、wayback_machine_downloader を用いてWayback Machineのアーカイブから一括取得しました。一方、画像データは、ローカル環境に残っていた元画像と、アーカイブから安全を確認できたものだけを選んで再配置しました。

取得したテキストデータをMarkdown形式に変換し、画像とあわせてAstroで読み込めるように調整することで、当時のURL構造を維持したまま記事を復元できました。

GitHub+Cloudflare Pagesによる配信構成

新しいブログの配信基盤には、GitHubとCloudflare Pagesを採用しました。手元で構築したAstroのディレクトリー一式を、GitHub Desktopを使ってそのままGitHubのリポジトリーへプッシュしています。このリポジトリーをCloudflare Pagesと連携させると、更新を自動で検知してAstroがビルドされ、生成したファイルがエッジサーバーから配信されます。これにより、サーバーの管理をCloudflareに任せつつ、ページを高速に配信できる環境へ移行できました。

現在の運用方法と今後の展望

現在は、VS CodeでMarkdownファイルを執筆し、GitHub Desktopでプッシュして記事を更新しています。パソコンでの作業は軽快ですが、この方法ではローカル環境が必要なため、出先で手軽に記事を執筆・公開しにくいのが課題です。

今後は、ヘッドレスCMSの導入を検討しています。ヘッドレスCMSを連携させれば、配信基盤は安全な静的サイトのまま、WebブラウザーからWordPressのように管理画面を使って記事を執筆・管理できるようになります。

まずは記事を表示できる状態まで復旧できました。新しくなった「MitsNote本館」を、今後ともよろしくお願いいたします。