WordPressで個人サイトを公開していたところ、/xmlrpc.php へのアクセスがかなりの頻度で発生していた。
大規模サイトでも、有名サイトでもない。アクセス数の多いサイトでもない。
それでも、公開しているだけで継続的に狙われる。
狙われていたのは xmlrpc.php
今のところ、目立っているアクセス先はほぼこれだけだった。
/xmlrpc.php
xmlrpc.php は、WordPressを外部から操作するための機能を提供するファイルである。
外部アプリからの記事投稿やPingbackなどで使われる一方、認証試行や悪用の対象にもなりやすい。
攻撃側がサイトの内容を確認しているわけではない。
WordPressらしきサイトに対し、ボットが機械的に同じURLを叩いているだけだと思われる。
小規模サイトでも容赦なく来る
「こんな個人サイトを狙っても仕方がないだろう」と思うが、攻撃する側にサイトの規模は関係ない。
人間が一件ずつ標的を選んでいるわけではなく、自動化されたボットが大量のサイトへアクセスしている。
そのため、アクセス数が少なくても、収益がなくても、更新頻度が低くても、WordPressが公開されていれば試される。
人間の読者より、攻撃ボットの方が熱心に訪問してくる。
一般的な対策
通常であれば、以下のような対策を取ることになる。
-
xmlrpc.phpを無効化する - WAFで遮断する
- Webサーバーでアクセスを拒否する
- WordPress本体を更新する
- プラグインを更新する
- 不要なプラグインを削除する
- ログを監視する
- 多要素認証を導入する
Apacheで拒否するなら、例えば以下のように設定できる。
<Files "xmlrpc.php">
Require all denied
</Files>
Nginxなら以下。
location = /xmlrpc.php {
deny all;
}
ただし、Jetpackや外部投稿機能などで xmlrpc.php を使っている場合は、単純に無効化できない。
今回実施した対策
今回の対策は、もっと単純だった。
WordPressをやめた。
サイトをAstroで作り直し、静的サイトとして配信する構成へ移行した。
Astro
↓ ビルド
静的HTML・CSS・JavaScript
↓
Amazon S3
↓
Amazon CloudFront
↓
Amazon Route 53
PHPはない。
データベースもない。
WordPressの管理画面もない。
当然、xmlrpc.php もない。
攻撃ボットが今後も /xmlrpc.php へアクセスしてくる可能性はあるが、そこには何も存在しない。
Astroとは
Astroは、Webサイトを静的なHTMLとして出力できるサイト構築ツールである。
記事やページは、Markdown、HTML、Astroコンポーネントなどで記述できる。
今回のような個人サイトであれば、WordPressのようにアクセスのたびにPHPを動かし、データベースから記事を取得する必要はない。
あらかじめサイトをビルドし、生成されたファイルをS3へ配置すればよい。
npm run build
ビルド後は、通常 dist ディレクトリに静的ファイルが出力される。
dist/
├── index.html
├── sitemap.xml
├── assets/
└── 各ページのHTML
これをS3へアップロードし、CloudFront経由で配信する。
Astroを選んだ理由
公開環境にWordPressを置かなくてよい
最大の理由はこれである。
WordPress本体、PHP、データベース、管理画面、プラグインを公開環境から取り除ける。
攻撃対象を個別に守るのではなく、攻撃対象そのものを減らせる。
HTMLとして配信できる
Astroでビルドした後の公開物は、基本的に静的なファイルである。
S3はファイルを返すだけなので、記事表示のたびにサーバー側でPHPを実行する必要がない。
Markdownで記事を書ける
記事をMarkdownファイルとして管理できる。
---
title: "記事タイトル"
pubDate: 2026-07-30
---
本文を書く。
WordPressの管理画面へログインせず、エディタ上で記事を書いてGitで管理できる。
Gitで変更履歴を管理できる
記事、レイアウト、CSS、設定をすべてコードとして管理できる。
いつ、何を変更したか追跡しやすく、問題が起きた場合も以前の状態へ戻しやすい。
プラグイン更新に追われにくい
Astroにも依存パッケージの更新は必要だが、WordPressのように公開中のPHPプラグインが直接攻撃対象になる構造とは異なる。
ビルド環境と公開環境を分離できるため、公開サーバー上で多数のプラグインを動作させ続ける必要がない。
WordPressとAstroの違い
大まかに比較すると、以下のようになる。
| 項目 | WordPress | Astro |
|---|---|---|
| 記事の保存 | データベース | Markdownなどのファイル |
| ページ生成 | アクセス時にPHPで生成 | ビルド時に生成 |
| 公開環境 | PHP・DBが必要 | 静的ファイルだけでも可能 |
| 管理画面 | あり | 基本的になし |
| プラグイン | 豊富 | npmパッケージや連携機能 |
| 攻撃対象 | 管理画面、PHP、プラグイン、DBなど | 主に配信基盤とAWS設定 |
| 更新方法 | ブラウザ上で投稿 | エディタで編集して再ビルド |
WordPressの方が、ブラウザだけで記事を書きたい場合や、複数人で管理したい場合には便利である。
一方、個人でコードを管理でき、更新頻度もそれほど高くないサイトなら、Astroの方が構成を単純にできる。
Astroに移行すれば攻撃がなくなるわけではない
静的サイトへ移行しても、ボットからのアクセス自体はなくならない。
今後も /xmlrpc.php、/wp-login.php、/wp-admin/ などへのリクエストは飛んでくる可能性がある。
ただし、WordPressが存在しないため、そのリクエストから認証処理やPHP実行へ進むことはない。
S3やCloudFrontから404などを返して終了する。
また、以下の管理は引き続き必要になる。
- AWSアカウントの多要素認証
- IAM権限の管理
- S3バケットの非公開化
- CloudFrontのOrigin Access Control
- Route 53の管理
- TLS証明書の更新
- npmパッケージの更新
- Gitリポジトリの管理
攻撃対象がゼロになるのではなく、管理対象がWordPressからAWSとビルド環境へ移る。
WordPressを守るより、なくした方が早かった
WordPressには豊富な機能があり、ブラウザ上で記事を投稿できる利便性もある。
一方で、使っていない機能を含め、継続的な保守が必要になる。
今回のサイトでは、更新頻度も低く、コメント、会員管理、EC、複数人編集といった動的機能も必要なかった。
そのため、WordPressを守り続けるより、Astroで静的サイトに作り直し、WordPressそのものを公開環境からなくす方が合理的だった。
まとめ
WordPressを公開すると、小規模な個人サイトでも xmlrpc.php への自動アクセスが発生する。
一般的な対策としては、無効化、WAF、アクセス制限、更新管理などが考えられる。
今回採用した対策は以下である。
WordPressをやめる。
身も蓋もないが、WordPressを使う必要がないサイトなら、これが最も確実だった。