はじめに
【記事作成について】 本記事は、実際発生した攻撃とその対処の記録を、AI（Claude）との対話を通じて整理・文章化したものです。技術的な内容については、専門家の確認を経ていない点にご留意ください。
【対象環境】
- サーバー：ConoHa WING
- CMS：WordPress
- 本記事の対策手順は上記環境を前提としています
ウェブサイトの急激なアクセス増加を検知し、調査したところxmlrpc.phpへの攻撃であることが判明しました。本記事では、その検知から対処、そして今後に備えたバックアップ体制の構築までを記載しています。
同じような状況に遭遇された方の参考になれば幸いです。
事象：急激なアクセス増加
通常のアクセス数よりも明らかに多いアクセスがあることに気づきました。特にアメリカからのアクセスが目立っていました。
最初の兆候
- 普段見ない海外からの大量アクセス
- アクセス数が通常の数倍に増加
- サイトの表示速度に影響はなし
原因調査：アクセスログの確認
ConoHa WINGのコントロールパネル【サイト管理 – アクセス解析 – ログ – アクセスログ】からアクセスログをダウンロードし、詳細を確認しました。
ログから判明したこと
アクセス先の分析：
- xmlrpc.phpへの POST/GET リクエストが圧倒的に多い
- トップページ（/）へのアクセスは正常な範囲
- 他のページは通常通り
アクセス元の特徴：
- 世界中の様々なIPアドレスから攻撃
- クラウドサービス（Azure、OVHなど）のIPが多数
- 規則的なアクセスパターン（ボットによる自動攻撃）
ステータスコード：
- すべて 403 Forbidden または 301 Redirect
- 幸いなことに既存のセキュリティ設定でブロックされていた
xmlrpc.php攻撃とは
xmlrpc.phpはWordPressの標準機能の一つで、外部アプリからの投稿などに使用されます。しかし、この機能を悪用した攻撃が頻繁に行われています。
主な攻撃目的
- ブルートフォース攻撃：管理者パスワードの総当たり攻撃
- DDoS攻撃：大量リクエストでサーバーに負荷をかける
- スパム投稿：自動的にコメントやトラックバックスパムを送信
- 脆弱性の探索：セキュリティホールを探す
攻撃が成功すると…
- サイトの乗っ取り
- マルウェアの配布拠点にされる
- 他サイトへの攻撃の踏み台
- 情報漏洩
- サーバーの強制停止
実施した対策
1. サーバー負荷の確認
まず、攻撃によってサーバーに実害が出ていないか確認しました。【WiNG – サーバー管理 – 契約情報 – リソース】
確認項目：
- CPU使用率：最大15%（正常範囲）
- メモリ使用率：最大3%（正常範囲）
- 結論：すべてブロックされており、サーバーへの影響なし
2. WAF（Web Application Firewall）の有効化
ConoHa WINGのWAF機能を確認し、OFFになっていたためONに設定しました。【WiNG – サイト管理 – サイトセキュリティ – WAF】
WAFの効果：
- SQLインジェクション対策
- クロスサイトスクリプティング（XSS）対策
- 不審なアクセスパターンの自動検知・遮断
3. xmlrpc.phpの完全無効化
すでに海外アクセス制限はON【WiNG – サイト管理 – サイトセキュリティ – WordPressセキュリティ】にしていましたが、これは主に管理画面が対象です。xmlrpc.phpへのアクセスも完全にブロックするため、無効化しました。
方法：
- プラグイン「Disable XML-RPC」をインストール
- または、.htaccessに以下を追加【WiNG – サイト管理 – サイト設定 – 応用設定 – .htaccess設定】：
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
4. Basic認証の設定
以前から管理画面にBasic認証を設定していました。ワードプレスログイン画面は通常一つですが、これにより多層防御が実現されます。
多層防御の構成：
- Basic認証（第1の壁）
- WordPressログイン（第2の壁）
- WAF（常時監視）
- 海外アクセス制限
方法：
下記の方法でログイン画面URL（ディレクトリ、wp-adminなど）にディレクトリアクセス制限をかけます。
対策後の状況
攻撃ログは継続中だが…
xmlrpc.phpを無効化した後も、アクセスログには攻撃の記録が残り続けていますが、下記の状態であり、特に問題はなさそうです。
理由：
- 攻撃ボットは無効化されたことを知らない
- 機械的に攻撃を続けるだけ
- すべて403エラーで弾かれている
- サーバー負荷は依然として正常範囲
アクセスログをスッキリさせるには
攻撃ログ自体をなくしたい場合は、Cloudflareの導入が効果的です。サーバーに到達する前にブロックするため、ログも残りません。
ただし、現状で実害はゼロなので、今のところ追加対応は見送っています。
バックアップ体制の構築
攻撃対策と合わせて、万が一に備えたバックアップ体制も整備しました。
3段構えのバックアップ
1. ConoHa WINGの自動バックアップ（標準機能）
- 過去14日分を自動保存
- Webサイト、データベース、メールデータが対象
- 復元も簡単
設定場所：
- ConoHaコントロールパネルの【WING – サーバー管理 – 自動バックアップ】
2. UpdraftPlusによる自動バックアップ
WordPressプラグイン「UpdraftPlus」を導入し、Googleドライブに自動バックアップを設定しました。
設定内容：
- ファイルのバックアップ：毎週（4週分保持）
- データベースのバックアップ：毎日（14日分保持）
- 保存先：Googleドライブ（15GBまで無料）
- メール通知：ON
設定手順：
- プラグイン「UpdraftPlus」をインストール・有効化
- 設定 → UpdraftPlus Backups → 設定タブ
- バックアップスケジュールを設定
- リモートストレージで「Google Drive」を選択
- 「変更を保存」をクリック（重要！）
- Googleアカウントで認証
- 初回手動バックアップを実行
3. 手動バックアップ（月1回）
重要な変更前には手動でバックアップを取得し、外部HDDやクラウドストレージに保存します。
バックアップのテスト
バックアップを設定したら、必ず復元テストを行うことをお勧めします。いざという時に「バックアップが壊れていた」では意味がありません。
まとめ：WordPress運営者が今すぐやるべきこと
最低限のセキュリティ対策チェックリスト
- [ ] WAFをONにする
- [ ] WordPress本体とプラグインを最新版に更新（自動更新設定）
- [ ] xmlrpc.phpを無効化（使用していない場合）
- [ ] 管理画面にBasic認証を追加
- [ ] 推測されやすいユーザー名（admin等）を使わない
- [ ] 強固なパスワードを設定
- [ ] 定期的にアクセスログをチェック
バックアップ体制チェックリスト
- [ ] サーバー側の自動バックアップを確認
- [ ] WordPressプラグインで外部バックアップを設定
- [ ] 復元テストを実施
- [ ] 月1回の手動バックアップ
定期メンテナンスの実施
- 毎週：WordPress/プラグインの更新チェック
- 毎月：アクセスログの確認
- 3ヶ月に1回：バックアップの動作確認
- 重要な変更前：必ず手動バックアップ
おわりに
今回の攻撃は幸いにも既存のセキュリティ設定でブロックされており、実害はありませんでした。しかし、この機会にセキュリティとバックアップ体制を見直し、強化することができました。
WordPressは世界中のウェブサイトの40%以上で使用されているため、常に攻撃者のターゲットになります。「自分のサイトは大丈夫」と思わず、定期的なセキュリティチェックとバックアップの確認を行うことが重要です。
この記事が、同じような状況に遭遇された方や、WordPressのセキュリティ対策を検討されている方の参考になれば幸いです。
参考リンク：
注意事項： 本記事は当事務所での対応事例を記録したものです。環境やWordPressのバージョンによって適切な対処法は異なる場合があります。重要な変更を行う前には必ずバックアップを取得し、必要に応じて専門家にご相談ください。
