XserverのWordPressに、毎朝の改ざんチェックを追加する | PC-FAN

このスクリプトを作ったきっかけは、2026年9月に自分が管理しているWordPressで、気になるアクセスを見つけたことでした。

9月下旬、不審なアクセスの中にステータスコード200 を返しているものがありました。200 は「リクエストされたページやファイルを返した」という意味で、ログでその数字を見ると、「きたな！？」という少し嫌な予感がします。

アクセスの内容を見ると、.env や .git/config、wp-config のバックアップらしきファイルを探す形跡がありました。さらに、WordPress配下の怪しいPHPファイルを探索するようなリクエストも混ざっています。

ちょうどそのころ、XserverからもWordPressの脆弱性に関する注意喚起の通知が届いていました。WordPress本体やプラグインなどの更新状況を見直し、アクセスログを確認しているうちに、「サーバー上のWordPressファイルも、一度きちんと見ておいたほうがよさそうだ」と考えるようになりました。

そこで、Xserverにログインして、WordPress本体やプラグインのファイルを確認したのですが、2日続けてチェックしたことで、流石にこれを毎回やるのは面倒だなと感じました。

SSHでサーバーにログインし、対象のディレクトリへ移動して、WP-CLIを実行し、その結果を確認する。複数サイトがあると、この繰り返しだけでもなかなか時間を取られます。

そこで、WordPressの公式チェックサムを使って、Xserver上のWordPressを毎朝まとめて確認する小さなスクリプトを作りました。この記事では、そのときに作った Xserver WordPress 朝パトロール と、WordPress本体・公式プラグインのファイル不一致を確認する方法を紹介します。

きっかけになった不審アクセスのログ

実際にアクセスログを見ていると、次のような種類のリクエストが定期的に流れてきます。

[WordPress Recon] probing for wp-config backup and exposed configuration paths
[Fingerprinting] probing for .git/config exposure
[Fingerprinting] probing for .env and related exposed files
[Web Shell Probe] probing for suspicious PHP files and backdoor paths
[Auth Attack] probing login and admin entry points

.env や .git/config は、設定情報や開発時の情報が露出していないかを探る典型的な探索先です。wp-config のバックアップらしきファイルや、不審なPHPファイル名へのアクセスも、WordPressサイトではよく観測されます。

このようなアクセス自体は、必ずしも「侵入された」という意味ではありません。ですが、気になるパスへのアクセスが 200 を返していたり、複数日にわたって同じ種類の探索が続いたりすると、こちら側の確認作業も必要になります。

不審アクセスの観測ログは、別ページの Abusive Bot / Malicious IP Address List でも日次で整理しています。アクセス元IP、攻撃種別、遮断状況、継続監視の判断を一覧化しておくと、「今日だけの単発なのか」「継続して見ておくべき相手なのか」が分かりやすくなります。

たとえば、2026年9月の月次ログでは、次のように「危険パスで 200 応答があったIP」を追跡対象として扱っています。

[2026-09-21 SOC運用向け]

- 34.187.177.97
  AbuseIPDB 個別照会: https://www.abuseipdb.com/check/34.187.177.97
  WHOIS Info: Google LLC (GOOGL-2), US, Abuse Contact, Legacy
  Comment: [Web Shell Probe] probing for suspicious PHP files and dangerous backup paths
  Status: common_security.txt Applied

static deny 済み（危険パス200）
  - 34.187.177.97 success200=4
    paths=/index.php?s=index/\x5Cthink\x5Capp/invokefunction&function=call_user_func_array&vars[0]=file_get_contents&vars[1][]=.env,
          /xargs-basic/?path=..%2F..%2F.env
    last_seen=2026-09-21T00:26:01+09:00

このIPは、翌日以降の日報でも「危険パスで 200 応答が確認されているため優先確認が必要」として扱っています。こうしたログを見ていると、入口側の遮断や監視だけでなく、WordPress側のファイルが意図せず変わっていないかもあわせて確認したくなります。そこで使ったのが、WordPress公式チェックサムです。

この記事で扱うこと・扱わないこと

この記事で扱うのは、「エックスサーバー上のWordPressで、公式チェックサムを使ってファイルの不一致を確認する方法」です。

手動で確認するだけなら、WP-CLIのチェックサム確認コマンドで十分です。ただ、複数サイトを毎日見ていくとなると、同じ確認作業を忘れずに続けるほうが大変です。

そこで今回は、毎朝自動で確認を実行し、問題が検出されたときだけ気付けるようにする Xserver WordPress 朝パトロール を紹介します。

知っておいてほしい注意点（万能ではありません）

先にとても大切なポイントをお伝えしておくと、このチェックさえしていればセキュリティ対策は完璧、というわけではありません。

今回のスクリプトが監視するのは、あくまで「WordPress本体」と「WordPress.orgの公式ディレクトリに登録されているプラグイン」のファイル不一致のみです。

そのため、以下のような部分は今回のチェックの対象外となります。

• オリジナルテーマや有料テーマの改ざん
• 公式ディレクトリ外の有料プラグインの改ざん
• アップロードディレクトリ（画像などが保存される場所）への不審なファイル設置
• データベース（DB）の書き換えや、身に覚えのない管理者ユーザーの追加

これらを確認するためには、別のセキュリティ対策を組み合わせる必要があります。

WordPress公式チェックサムで確認できること

cd /home/example/example.com/public_html/wp
wp core verify-checksums
wp plugin verify-checksums --all

WordPressには、公式に配布されているファイルと、現在サーバー上にあるファイルが一致しているかを確認する「チェックサム」という仕組みがあります。WP-CLIを使うと、WordPress本体とWordPress.org公式ディレクトリに登録されているプラグインを、公式データと照合できます。

もし公式ファイルと異なる内容になっているものがあれば、結果に「不一致（Mismatch）」として表示されます。有料プラグインや独自プラグインなど、WordPress.org公式ディレクトリ以外から入れたものは照合できない場合があり、環境によっては警告や失敗として表示されることがあります。

単一のサイトであれば、必要なときにこのコマンドを実行すれば十分です。ただ、複数サイトを運用している場合は、サイトごとにディレクトリを移動して同じ確認を繰り返すことになります。問題がなければ画面の出力にも大きな変化がないため、忙しいとどうしても後回しになりがちです。

そこで、毎朝自動で確認を実行し、問題が検出されたときだけ通知を受け取れる仕組みを作ることにしました。

自動確認スクリプト「Xserver WordPress 朝パトロール」

その手間を解消するために作ったのが、Xserver WordPress 朝パトロール です。

このスクリプトは、エックスサーバー上で稼働しているWordPressを対象に、本体とWordPress.org公式プラグインのチェックサム検証を毎日自動で実行します。

主な機能と特徴は以下の通りです。

• 問題がない場合: 検証結果をログファイルに記録して終了します。
• 不一致が見つかった場合: 対象のサイトとWP-CLIの出力をメールで通知します。

正常時は通知しない設定も選べます。普段は静かに動かしておき、気になる結果が出たときだけメールで気づくという使い方です。

また、外部の監視サービスにサーバーの接続情報などを預けずに済む点も安心材料です。すべて自身のXserver環境内だけで動かす小さなスクリプトです。

「朝パトロール」の処理の流れ

このスクリプトが実行する処理は、非常にシンプルです。毎朝、次のステップを自動で順番に実行します。

毎朝7時にチェックする
  ↓
WordPress本体を公式チェックサムで確認する
  ↓
WordPress.org公式プラグインを公式チェックサムで確認する
  ↓
問題がなければログへ記録する
  ↓
不一致があればメールで通知する

スクリプトの役割について（書き換えや削除は行いません）

このスクリプトは、WordPressを書き換えたり、不正ファイルを削除したりはしません。

このスクリプトの役割は、あくまでも「公式ファイルと違う状態になっていないか」を監視し、異変にいち早く気付くことです。

ファイルを操作しないため、「スクリプトの誤作動でサイトが崩れてしまう」といった心配がなく、安全に利用することができます。

対象とする動作環境

このスクリプトが対象にしているのは、次のような環境です。

• Xserverのレンタルサーバー
• SSHが利用できること
• サーバー上でWP-CLIの wp コマンドが利用できること
• WordPressが $HOME 配下に設置されていること

Xserver以外でも動く可能性はありますが、この記事ではXserver向けのツールとして紹介します。

インストール前に確認する「環境診断モード」

いきなりインストールするのが不安な場合は、まず環境診断だけ実行できる機能を用意しています。

次のコマンドを実行すると、システムに変更を加えない「診断モード」でチェックが走ります。

sh install.sh --check

このモードでは、ファイルの新規作成やcronの登録は行いません。サーバー側の設定を変更せずに、WP-CLI、crontab、sendmailコマンドが見つかるか、また対象のWordPressを自動検出できるかだけを安全にテストできます。

実行すると、画面には次のような診断結果が出力されます。

$ sh install.sh --check
WordPress チェックサム監視 環境診断

診断対象: /home/example
設置予定: /home/example/checksums

OK: wp-checksums-monitor.sh が見つかりました
OK: WP-CLI が利用できます (/usr/bin/wp)
OK: crontab が利用できます
OK: sendmail が利用できます
OK: ホームディレクトリを確認しました

検出したWordPress:
  - example.com: /home/example/example.com/public_html/wp
  - example.jp: /home/example/example.jp/public_html/wp

診断結果: インストール可能です

本格的に導入する前に、まずはこの診断モードを実行しておくことで、「サーバー側に必要なコマンドが揃っているか」「スクリプトが対象のWordPressを見つけられるか」を事前に確認できます。

変更前にシミュレーションする「ドライランモード」

環境診断で問題がなければ、次は実際のインストール手順へ進む前に、設定予定の内容をシミュレーションしておきます。

以下のコマンドを実行します。

sh install.sh --dry-run

このドライランモードでは、検出されたWordPressサイトの一覧、作成予定のファイル、そして登録予定のcronが画面に表示されます。この段階でも、まだファイル作成やcrontabの書き換えといった実際の変更は行われません。

監視対象サイトの個別選択

サーバー内に複数のWordPressが見つかった場合は、すべてを一括で監視対象に指定することも、番号で必要なサイトだけを個別に選ぶことも可能です。

実行すると、以下のような選択画面が表示されます。

検出したWordPress:
  1) example.com: /home/example/example.com/public_html/wp
  2) example.jp: /home/example/example.jp/public_html/wp

監視対象を選択してください。all または番号をカンマ区切りで指定 [all]: all

サーバーの運用状況によっては、サブディレクトリにある別サイト、テスト用のサイト、あるいは過去の古いバックアップ用サイトなどが一覧に検出されることがあります。

ここは大事なところです。一覧をしっかりと確認し、必要なサイトだけを選択するようにしてください。

すべて対象にする場合は、そのまま all で進めて問題ありません。

実行結果の確認例

1. 問題が検出されなかった場合（正常時）

問題がない場合は、次のようにログへ結果が残ります。

$ MAIL_MODE=none ./wp-checksums-monitor.sh
[2026-09-30 07:00:03 +0900] Starting checksum verification for example.com at /home/example/example.com/public_html/wp
[2026-09-30 07:00:12 +0900] Completed checksum verification for example.com: no problems detected.
[2026-09-30 07:00:12 +0900] Starting checksum verification for example.jp at /home/example/example.jp/public_html/wp
[2026-09-30 07:00:20 +0900] Completed checksum verification for example.jp: no problems detected.
[2026-09-30 07:00:20 +0900] Completed multi-site checksum verification: total=2 failed=0

2. ファイルの不一致が見つかった場合（異常検知時）

公式ファイルとの不一致が検出された場合は、ログへの記録と同時に、「どのサイトで」「どのファイルに問題が発生したのか」をメールで確認できるようにしています。

WordPress checksum alert
Site: example.com
Path: /home/example/example.com/public_html/wp
Time: 2026-09-30 07:00:12 +0900

Core status: 1
Warning: File doesn't verify against checksum: wp-includes/example.php
Error: WordPress installation doesn't verify against checksums.

Plugin status: 0
Success: Verified 12 of 12 plugins.

この通知が届いた場合は、まず対象サイトとファイル名を確認します。WordPress本体や公式プラグインの更新直後に一時的な差分が出ることもありますが、身に覚えのないPHPファイルや、更新していないはずのファイルが出ている場合は、バックアップやアクセスログとあわせて確認する必要があります。

チェックサム確認の「できること」と「できないこと」

チェックサム確認は便利ですが、これだけですべてのセキュリティリスクを防げるわけではありません。ツールの役割を正しく把握したうえで運用するために、確認できる範囲と対象外となる範囲を整理しておきます。

主に確認できること（監視範囲）

• WordPress本体ファイルの不一致
• WordPress.org公式プラグインのファイル不一致

確認対象ではないこと（監視対象外）

• テーマの改ざん
• 有料プラグインや独自プラグイン
• uploads 配下に置かれた不正ファイル
• データベース内の改ざん
• 管理者ユーザーの不正追加
• wp-config.php や .htaccess の変更
• サーバー全体が侵害されているケース

まずは「早期発見の足がかり」として

このように、このスクリプトだけでWordPressのセキュリティ対策がすべて完了するわけではありません。役割はあくまで、「公式ファイルと現在の状態にズレが生じていないか」を監視することに特化しています。

しかし、セキュリティ被害の一部では、本体の脆弱性や公式プラグインの隙を突いたファイル書き換えが行われることがあります。コアな部分の不一致に毎朝自動で気付ける可能性があるだけでも、日々のサイト運用における安心感は高まります。

この記事のまとめ

今回は、エックスサーバー上のWordPressに、毎朝の自動チェックサム確認を導入する方法についてご紹介しました。

記事の要点を振り返ると、次の通りです。

• WordPress公式チェックサムで、WordPress本体ファイルの不一致を確認できる
• WordPress.org公式プラグインも、WP-CLIでチェックサム確認できる
• 複数サイトを毎日手動で確認するのは手間がかかる
• Xserver WordPress 朝パトロール では、この確認をcronで毎日実行する
• 正常時は静かにログへ記録し、不一致があればメールで通知できる
• ただし、テーマ、有料プラグイン、uploads、データベースなどは主な検知対象外

このツールは、WordPressの改ざん兆候を確認するための補助ツールです。完全なマルウェア検知、侵入防止、復旧を保証するものではありません。

位置づけとしては、「日々の運用確認を少しだけ強化し、安心感を増やすための道具」です。WordPress本体やプラグインの基本的なアップデート、定期的なバックアップ、不要なプラグインの整理といった、土台となるセキュリティ対策と適切に組み合わせて活用してください。