サーバーへの不正アクセスを検知するには、「ログインの試行を見る」「ファイルの改ざんを見る」「WordPress のファイルが公式配布物と一致しているかを見る」という3つの層を組み合わせるのが現実的です。この記事では、Linux サーバー（Ubuntu/Debian 系と RHEL 系）で WordPress を動かしている前提で、ログ確認・fail2ban・AIDE・rkhunter・WP-CLI を使った検知の仕組みを、通知の受け取り方まで含めて組み立てます。
検知の考え方：防御とは別に「気づく仕組み」を持つ
ファイアウォールやログイン制限は侵入を防ぐための仕組みですが、どれも突破される可能性はゼロではありません。検知の役割は、突破された場合や設定ミスがあった場合に、被害が広がる前に気づくことです。
検知の対象は大きく次の3つに分かれます。
- 入口の異常：SSH や wp-login.php への大量のログイン失敗、普段と違う国や時間帯からのログイン成功
- ファイルの変化：wp-includes や wp-admin、wp-config.php の書き換え、アップロード用ディレクトリに置かれた PHP ファイル
- システムの変化：知らないユーザーの追加、cron の追加、見慣れないプロセスや待ち受けポート
1つのツールですべてを見るのではなく、軽いものを重ねて「どれか1つが鳴れば調べる」状態を目指します。作業は本番サーバーで行うことになるため、事前にサーバーのスナップショットかバックアップを取り、設定ファイルを変更する前には元のファイルをコピーしておいてください。
1. まずログで「今」を確認する
ツールを入れる前に、手作業でログを読めるようにしておくと、通知が来たときの調査が速くなります。
# 直近のログイン成功の履歴
last -n 20
# ログイン失敗の履歴（root 権限が必要）
sudo lastb -n 20
# SSH のログ（Ubuntu/Debian はユニット名が ssh、RHEL 系は sshd）
sudo journalctl -u ssh --since "24 hours ago"
# 認証ログから失敗をざっと数える（Ubuntu/Debian の場合）
sudo grep "Failed password" /var/log/auth.log | wc -lRHEL 系では認証ログが /var/log/secure にあります。ディストリビューションや設定によっては /var/log/auth.log が存在せず、journald だけに記録されていることもあります。
ログイン失敗が多いこと自体は、インターネットに公開されたサーバーではよくあることです。注目すべきなのは、失敗の直後に同じ送信元からの成功がある場合や、公開鍵認証のみにしているはずなのにパスワード認証の記録がある場合です。後者は SSH の設定が意図どおりに効いていない可能性を示しています。
WordPress 側のログイン試行は、Web サーバーのアクセスログで wp-login.php や xmlrpc.php への POST を数えると傾向がつかめます。
# Nginx の例（ログの場所は環境に合わせて変更）
sudo grep "POST /wp-login.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head2. fail2ban でログイン失敗を検知して止める
fail2ban はログを監視し、一定回数失敗した送信元 IP をファイアウォールで一時的に遮断するツールです。検知と防御の両方を兼ねます。
# Ubuntu/Debian
sudo apt install fail2ban
# RHEL 系（EPEL リポジトリが必要な場合があります）
sudo dnf install fail2ban設定は jail.conf を直接編集せず、jail.local に書きます。jail.conf はパッケージ更新で上書きされることがあるためです。
# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
# 自分の固定 IP は遮断対象から外す（例の値は置き換える）
ignoreip = 127.0.0.1/8 203.0.113.10
[sshd]
enabled = true
# journald にしかログが無い環境では次の行を有効にする
# backend = systemdsudo systemctl enable --now fail2ban
sudo fail2ban-client status sshdfail2ban-client status sshd で、現在遮断中の IP と累計の失敗数が見られます。つまずきやすいのは ignoreip の入れ忘れで、自分の作業中に入力ミスを繰り返すと自分が締め出されます。VPS の管理画面から使えるコンソール接続の手段を、作業前に確認しておくと安心です。
WordPress のログイン画面を守る jail はフィルタの自作が必要になるため、ここでは SSH に絞っています。WordPress 向けの設定は関連記事を参照してください。
3. AIDE でファイルの改ざんを検知する
AIDE（Advanced Intrusion Detection Environment）は、ファイルのハッシュや権限を記録したデータベースを作り、後から比較して変化を報告するツールです。
# Ubuntu/Debian
sudo apt install aide
sudo aideinit
# 生成された aide.db.new を aide.db として使う（aideinit が自動で行う場合もある）
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo aide --check --config /etc/aide/aide.conf
# RHEL 系
sudo dnf install aide
sudo aide --init
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
sudo aide --check初期状態では OS のシステムファイルが中心に監視されます。WordPress のディレクトリを追加する場合は、変化してよい場所を外すことが運用の要です。アップロード画像やキャッシュまで監視すると、毎日大量の差分が出て誰も読まなくなります。
# 監視ルールの追加例（パスは環境に合わせる）
# R は AIDE の定義済みグループ。使えるグループ名はバージョンや配布元の設定で異なるため aide.conf で確認する
/var/www/example/wp-admin R
/var/www/example/wp-includes R
/var/www/example/wp-config.php R
!/var/www/example/wp-content/uploads
!/var/www/example/wp-content/cache設定ファイルの場所は、Debian 系では /etc/aide/aide.conf と /etc/aide/aide.conf.d/、RHEL 系では /etc/aide.conf が一般的です。
運用で大事なのは、WordPress やプラグインを正規に更新したら、データベースを作り直すことです。これを忘れると、正規の更新と改ざんの区別がつかなくなります。チェックは cron やディストリビューション付属のタイマーで1日1回程度に設定し、結果をメールで受け取る形がよく使われます。
4. rkhunter で既知の不審な痕跡を探す
rkhunter は、既知のルートキットの痕跡、隠しファイル、システムコマンドの改ざんなどを調べるツールです。
sudo apt install rkhunter # RHEL 系は dnf（EPEL）
sudo rkhunter --update # 定義データの更新
sudo rkhunter --propupd # 現在のファイル属性を基準として記録
sudo rkhunter --check --sk # 検査（--sk はキー入力待ちを省略）rkhunter は誤検知が多いツールです。パッケージ更新でコマンドが入れ替わっただけでも警告が出るため、OS を更新したら --propupd で基準を記録し直します。警告が出たら、まずパッケージマネージャーでファイルの正当性を確認します（Debian 系なら debsums、RHEL 系なら rpm -V パッケージ名）。
5. WordPress のファイルを公式配布物と照合する
WordPress コアと WordPress.org 配布のプラグインは、WP-CLI で公式のチェックサムと照合できます。
cd /var/www/example
wp core verify-checksums
wp plugin verify-checksums --all一致しないファイルや、公式配布物に存在しないファイルが報告されます。有料プラグインや自作プラグインは照合対象外なので、それらは AIDE 側で監視します。
加えて、アップロード用ディレクトリに PHP ファイルがないかを定期的に確認すると、典型的なバックドアに気づきやすくなります。
find wp-content/uploads -type f -name "*.php"
# 直近2日に変更された PHP ファイル
find . -type f -name "*.php" -mtime -2プラグインで検知したい場合は、Wordfence Security などのスキャン機能を持つセキュリティプラグインも選択肢です。ただし、サイトそのものが乗っ取られるとプラグインの結果も信用できなくなるため、サーバー側の検知と併用するのが安全です。スキャン機能の範囲は無料版と有料版で異なり、内容も変わるため、公式の説明を確認してください（2026年10月現在）。
6. 通知を受け取り、誤検知を減らす
検知の仕組みは、結果を誰かが読まなければ意味がありません。次の点を決めておきます。
- 通知先：サーバーからメールを送る場合、送信ドメイン認証の設定がないと迷惑メールに振り分けられがちです。チャットツールの Webhook に送る方法もあります。
- 頻度：AIDE と rkhunter は1日1回、fail2ban は遮断時に通知、などツールごとに分けます。
- 基準の更新手順：「WordPress を更新したら AIDE のデータベースを作り直す」をアップデート手順書に組み込みます。
- 複数台の場合：台数が増えたら Wazuh のような HIDS（ホスト型侵入検知システム）で集中管理する方法があります。導入と保守の負担は大きくなるため、規模に応じて検討してください。
不審な変化を見つけたら、慌てて削除するのではなく、まずログとファイルの証拠を保存し、サーバーをネットワークから切り離すかどうかを判断します。消してしまうと侵入経路が分からなくなり、同じ穴から再侵入される原因になります。
まとめ
- 不正アクセスの検知は「ログイン試行」「ファイルの変化」「WordPress ファイルの整合性」の3層で考える
- fail2ban はログイン失敗の検知と遮断を兼ねる。ignoreip とコンソール接続手段を先に確認する
- AIDE は変化してよいディレクトリを外して監視し、正規の更新後はデータベースを作り直す
- rkhunter は誤検知が多いので、パッケージの正当性確認とセットで使う
wp core verify-checksumsとwp plugin verify-checksums --allで公式配布物と照合する- 通知先・頻度・基準の更新手順まで決めて、はじめて検知が機能する