よこやま良平
WordPressで身に覚えのない管理者追加や投稿改ざんが見つかると、
「不正アクセス元IPを特定して止めたい」と考えるのは自然です。
結論からいえば、サーバーログから接続元IPの候補は調べられます。
ただし、IPアドレスだけで攻撃者本人や侵入経路を断定することはできません。
20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。実際の復旧現場でも、IPは重要な手掛かりですが、必ず時刻や操作内容とセットで判断しています。
- サーバーログのどこにIPアドレスが記録されるか分かる
- 不正アクセスが疑われる通信を時刻とURLから絞り込める
- CDN・WAF・プロキシ経由で誤認しやすい点を避けられる
- IPから分かることと、分からないことを区別できる
- 調査後に遮断・復旧・再発防止へ進む順番が分かる
調査で大切なのは、怪しく見えるIPを一つ探すことではありません。
「いつ・どのURLへ・何を送信し・何が変わったか」を時系列でつなぐことです。
この記事では、ログ調査が初めてでも進められる確認順と、
IP情報を過信して正常利用者まで遮断しないための限界を解説します。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
不正アクセス元IPはサーバーログの時刻と操作を組み合わせて調べる
不正アクセス元IPを調べる時は、発生時刻と対象操作を先に絞り、
該当時間帯のサーバーログを前後の通信ごと確認するのが正解です。
アクセスログには通常、接続元IP、日時、リクエスト先、HTTPメソッド、
応答コード、転送量、参照元、User-Agentなどが一行単位で残ります。
先に「何が起きた時刻か」を決める
たとえば、身に覚えのない管理者の登録メールが10時15分に届いたなら、
10時15分だけでなく、その前後30〜60分程度を確認します。
侵入者はログイン後すぐに管理者を作るとは限りません。
ログイン試行、認証成功、設定確認、ユーザー追加が数分から数十分に分かれる場合があります。
改ざんファイルの更新時刻、WordPressの通知メール、注文や問い合わせの異常、
監査ログのイベント時刻も集めると、見るべき範囲を狭くできます。
一行のログだけで正常・不正を決めない
wp-login.phpへのPOSTがあるだけでは、侵入成功とは断定できません。
管理者本人のログイン、ログイン失敗、セキュリティ診断でも似た記録が残るためです。
同じIPが直前にログイン画面を取得し、その後管理画面へ移動しているか、
ユーザー追加やプラグイン編集に関係するURLへ進んだかを連続して見ます。
ログへ色付け、削除、並べ替え、上書き保存をすると、原本の同一性を説明しにくくなります。調査は複製したファイルで行い、取得日時と対象期間を別の作業記録へ残してください。
サーバーログでIPを読む前に確認する4つの前提
ログの先頭にある数字をそのまま攻撃元と判断する前に、
ログ形式、時刻、経由サービス、IPの共有性という4点を確認すべきです。
ログ形式とIP列の意味を確認する
ApacheのCombined Log Formatでは先頭に接続元IPが置かれることが多く、
Nginxでも設定により$remote_addrが先頭へ記録されます。
しかし、ログ形式はサーバー会社や管理者が変更できます。
先頭列が実IPとは限らず、仮想ホスト名やプロキシのアドレスが追加される場合もあります。
203.0.113.42 - - [24/Oct/2026:00:12:08 +0900] "POST /wp-login.php HTTP/1.1" 302 0 "-" "ExampleBrowser/1.0"
203.0.113.42 - - [24/Oct/2026:00:12:10 +0900] "GET /wp-admin/ HTTP/1.1" 200 18240 "-" "ExampleBrowser/1.0"上記は文書用に予約された架空IPを使った例です。
302の直後に管理画面が200で返っていても、ログイン成功の裏付けには追加確認が必要です。
サーバーとWordPressのタイムゾーンをそろえる
アクセスログがUTC、WordPressがJSTなら、同じ出来事でも9時間ずれます。
さらにCDNやWAFの管理画面が別タイムゾーンを使うこともあります。
ログの日時末尾にある+0900や+0000を確認し、
比較表には元の時刻とJSTへ換算した時刻の両方を残すと混乱しません。
調査時間は一点ではなく幅を持たせる
通知時刻は、実際の操作時刻と一致しない場合があります。
メール配送の遅延、予約処理、キャッシュ、サーバー間の時計ずれがあるためです。
最初は前後30〜60分を対象にし、関連通信が途中から始まっていれば、
さらに手前へ範囲を広げます。最初から一日分を眺めるより見落としを減らせます。
複数ログを比較する時は、各システムの時刻精度も記録します。
秒単位で一致しなくても、操作の順序と間隔が整合するかを確認してください。
CDN・WAF・リバースプロキシの経由を確認する
Cloudflareなどを経由するサイトでは、Webサーバーから見える接続元が、
利用者ではなくCDNのIPになる場合があります。
実IPを別ヘッダーから記録する構成でも、信頼するプロキシ範囲の設定が不適切なら、
外部から偽のX-Forwarded-Forを送られて誤認する危険があります。
CDN公式のIP範囲、サーバー側の実IP復元設定、WAFログの記録項目を確認してください。経路が分からない時は、ホスティング会社へ「どの列が元の接続元か」を問い合わせるのが安全です。
IPv4・IPv6・共有IPを区別する
ログにはIPv4だけでなく、コロンで区切られたIPv6も記録されます。
表記が違っても、どちらも接続元を示す候補として同じ時系列へ並べます。
ただし企業、携帯回線、家庭用ルーターでは、複数端末が一つの公開IPを共有します。
IPが一致しても、同じ人や同じ端末とは限りません。
不正アクセス元IPをサーバーログから探す手順
不正アクセス元IPの候補は、症状から対象時間とURLを決め、
通信を絞り込んでから同一IPの前後を追う順番で探します。
手順1：症状と対象時刻を一行で書く
まず「10月24日0時15分ごろ、不審な管理者追加メールを受信」のように、
確認できた事実だけを一行で書きます。
「海外から侵入された」など、まだ根拠のない推測は混ぜません。
調査開始時点の事実と仮説を分けることで、後から結論を修正しやすくなります。
手順2：関係するURLとHTTPメソッドを絞る
WordPressの認証なら/wp-login.php、管理画面なら/wp-admin/、
REST APIなら/wp-json/への通信を確認します。
画面表示に多いGETだけでなく、データ送信に使われるPOST、PUT、DELETEも見ます。
ただしREST APIや管理画面の正常操作でも同じメソッドが使われます。
grep 'wp-login.php' access-copy.log
grep 'POST /wp-' access-copy.log
grep '203.0.113.42' access-copy.logコマンドは調査用コピーに対して実行し、出力も別ファイルへ保存してください。
共有サーバーで操作権限がない場合は、管理画面の検索機能を使えば十分です。
手順3：応答コードと通信の連続性を見る
200は処理成功を示す場合がありますが、ログイン失敗画面も200になることがあります。
301・302は転送、401・403は認証やアクセス拒否、404は対象なしが基本です。
重要なのは一つの数字ではなく、同じIPがどの順番でURLへ接続したかです。
ログイン後に管理画面、ユーザー編集、プラグイン編集へ続くなら調査優先度が上がります。
手順4：User-Agentと転送量を補助材料にする
User-Agentはブラウザやツールの種類を示しますが、送信側が自由に変更できます。
珍しい文字列だから攻撃、一般的なブラウザ名だから安全とは判断できません。
それでも、同一IPの一連の通信で文字列が一貫しているか、
正規担当者の端末と明らかに異なるかを見る補助材料にはなります。
応答サイズや処理時間も参考になります。大量のデータ取得、短時間の連続POST、
通常利用では見ないURL巡回が重なれば、調査対象として優先できます。
手順4：同一IPの前後30〜60分を追う
候補IPが見つかったら、その一行だけを抜き出して終わらせず、
前後のURL、時刻、User-Agent、応答コード、転送量を並べます。
短時間に多数のユーザー名を試す通信と、成功後に少数の管理画面へ進む通信では、
意味が異なります。失敗した攻撃と、侵害につながった操作を分けてください。
- 元ログ名、対象期間、タイムゾーン
- 接続元IP、最初と最後の確認時刻
- URL、HTTPメソッド、応答コード
- User-Agent、参照元、転送量
- 同時刻に起きたWordPress側の変更
IPアドレスをWordPressの操作と突き合わせる方法
IP候補の信頼度を上げるには、WebサーバーログとWordPress側の変更、
メール、WAF、FTP・SSHなど別の記録を同じ時系列へ並べます。
管理者追加・メール変更・投稿改ざんの時刻を集める
不審な管理者が増えた場合は、ユーザーID、ログイン名、表示名、メール、権限、
登録日時を記録します。削除は調査とバックアップの後です。
投稿改ざんなら更新日時だけでなく、リビジョン、変更者、埋め込まれたURL、
公開状態の変化も確認します。自動更新や正規担当者の作業と区別するためです。
監査ログ・通知メール・WAFログを照合する
監査ログプラグインを導入済みなら、ログイン成功、ユーザー作成、権限変更、
プラグイン操作などのイベントを確認します。
導入していなかったサイトへ、事件後に慌てて追加しても過去記録は戻りません。
その場合はメール、サーバーログ、バックアップ差分など既存資料を優先します。
WAFに同じIPと時刻の検知があれば参考になりますが、
検知名だけで侵入成功とは判断せず、遮断済みか通過済みかも確認してください。
Web経由とFTP・SSH経由を分ける
ファイルが改ざんされていても、侵入経路がWordPressとは限りません。
FTP、SFTP、SSH、ホスティング管理画面の認証情報が悪用される場合もあります。
Webアクセスログに対応する操作がないなら、FTP・SSHログ、ファイル管理画面、
自動デプロイ、バックアップ復元、正規担当者の作業履歴を調べます。
時系列表は「事実・根拠・判断」を分ける
調査表には、時刻、記録元、IP、操作、結果、根拠ファイル、判断を分けて書きます。
「怪しい」だけでは、後から別担当者が再確認できません。
たとえば「0時12分10秒、アクセスログ、候補IP、管理画面GET、200」は事実です。
「ログイン成功の可能性が高い」は判断なので、別列へ記録します。
同じ時刻帯にWebアクセス、監査イベント、通知メール、ファイル更新が重なると、候補IPと実際の変更の関係を説明しやすくなります。それでも人物特定とは別問題です。
不正アクセス元IPだけでは攻撃者を特定できない理由
サーバーログのIPは通信経路の手掛かりですが、
その回線を使った人物、端末、所在地を直接証明する情報ではありません。
動的IP・NAT・共有回線で利用者が入れ替わる
家庭や携帯回線では、再接続や時間経過で公開IPが変わることがあります。
逆に、一つのIPを家庭内の複数端末や企業全体で共有する構成も一般的です。
同じIPが別の日にも現れたからといって、同じ人とは限りません。
IPの割り当て時刻まで含めた契約者情報は、通常サイト運営者には分かりません。
VPN・プロキシ・ボットネットは中継地点を表示する
VPNや公開プロキシを経由した通信では、サーバーに残るのは出口IPです。
そのIPを利用した多数のユーザーのうち、誰が操作したかはログだけで判断できません。
マルウェア感染した第三者端末や侵害済みサーバーが中継に使われることもあります。
その場合、IPの所有者自身も被害者である可能性があります。
位置情報と所有者情報は概算にすぎない
IP検索サービスで分かる国、地域、通信事業者は参考情報です。
データベースの更新遅れ、VPN出口、クラウド事業者の拠点により実際と異なります。
海外IPだから不正、国内IPだから安全という判断もできません。
正常な検索エンジン、CDN、外部サービスが海外IPを使う一方、攻撃が国内中継を使うこともあります。
IP評価サービスは「既知の傾向」を見る道具
IP評価サービスやWHOISで、クラウド事業者、通信事業者、既知の迷惑通信報告を
確認できます。ただし、評価がないことは安全の証明になりません。
逆に悪評があっても、今回の侵害を起こした証拠とは限りません。
所有者情報とログの事実を分け、調査メモには参照日時と情報源を残します。
候補IPをSNSやブログで「犯人」として公開すると、無関係な利用者や侵害された中継先へ被害を広げるおそれがあります。必要な共有先をホスティング会社、専門家、法執行機関などへ限定してください。
不正アクセス元IPを見つけた後の安全な対応
候補IPが見つかった後は、証拠を保存し、必要なら影響を限定して遮断し、
認証情報と脆弱性の両方を直してから復旧確認へ進みます。
証拠保存を終えてから限定的に遮断する
進行中の攻撃なら遮断は有効ですが、先に元ログ、WAFイベント、対象時刻、
設定変更前の状態を保存します。遮断操作そのものも日時と担当者を記録してください。
IP単位の拒否は回避されやすく、共有IPなら正常利用者も巻き込みます。
ログイン試行制限、二要素認証、WAFルール、管理画面制限などを組み合わせます。
誤遮断に備えて戻し方を決める
業務担当者、決済サービス、監視サービス、検索エンジンなどを誤って止めると、
被害調査とは別の障害を生みます。遮断前にIPの用途と影響範囲を確認してください。
ルール名、追加日時、対象IP、理由、解除条件を記録し、
問題が出た時にすぐ戻せる状態で実施します。期限付き遮断も有効です。
パスワード変更だけで終わらせない
WordPress管理者、ホスティング、FTP・SFTP・SSH、データベース、
メール、CDNなど、侵害範囲に応じて認証情報を変更します。
ただしバックドアや不正な管理者が残っていれば、変更後の情報も再取得されます。
不審ユーザー、改ざんファイル、予約タスク、プラグイン、テーマ、外部連携も確認が必要です。
侵入経路を閉じてから安全な復旧を確認する
古いプラグイン、漏えいした認証情報、脆弱な外部連携、管理画面の保護不足など、
根本原因を修正しなければIPを遮断しても再侵入されます。
復旧後は管理者一覧、表示、投稿、フォーム、決済、検索結果、送信メール、
サーバー負荷を確認し、一定期間ログを監視してください。
専門家やサーバー会社へ渡す情報を整理する
相談時は「怪しいIPがあります」だけでなく、最初に気づいた症状、対象時刻、
ログのタイムゾーン、該当行の前後、変更した設定をまとめます。
個人情報、Cookie、認証トークン、注文情報が含まれるログは、
公開チャットへ貼らず、相手と安全な受け渡し方法を決めてください。
- 元ログと関連記録を保全する
- 候補IPとWordPress操作を時系列で照合する
- 進行中の攻撃だけを影響確認後に止める
- 認証情報、脆弱性、不正ファイルをまとめて直す
- 復旧後もログとサイト動作を監視する
プラグイン設定だけでなく、更新・バックアップ・緊急復旧まで継続して任せたい場合は、
保守サービス「クイックレスキュー365」の内容も確認してください。
不正アクセス元IPとサーバーログのよくある質問
サイト運営者が持つログだけで人物を特定することは通常できません。動的IP、共有回線、VPN、中継サーバーがあるため、IPは通信経路を追う手掛かりとして扱います。
安全とは限りません。正常な利用者や外部サービスを止める一方、攻撃者は国内IPや別の中継先へ切り替えられます。サイトの利用地域と業務影響を確認し、ログイン保護やWAFと組み合わせてください。
CDN、WAF、ロードバランサー、リバースプロキシを経由している可能性があります。実IPを記録する設定と、信頼すべき中継元の範囲をサーバー会社やサービス公式資料で確認してください。
ホスティング会社へ、対象日時、ドメイン、必要なログ種別、保存期間を伝えて取得可否を確認します。自分で設定変更や復元を進める前に、WAF・CDN・FTP・SSHなど残っている別の記録も保全してください。
不正アクセス元IPは複数ログの時系列で判断する
不正アクセス元IPをサーバーログから調べる時は、
発生時刻、対象URL、HTTPメソッド、応答コードを使って候補を絞ります。
そのうえで、同一IPの前後の通信、WordPressの変更、監査ログ、WAF、
メール、FTP・SSH記録を時系列で突き合わせることが重要です。
- 原本ではなく複製ログを調査する
- タイムゾーンとログ形式を先に確認する
- CDN・WAF・プロキシ経由のIPを誤認しない
- IP一つで人物や所在地を断定しない
- 遮断だけで終わらず、侵入経路と残存物を直す
IPは調査を前へ進める有力な手掛かりですが、結論そのものではありません。
事実と推測を分け、第三者が再確認できる記録を残して安全に復旧してください。
WordPressの不正アクセス・乗っ取りが自分で直せない時は
ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。
・WordPressが真っ白画面
・WordPressがログインできない
・ホームページのマルウェアや乗っ取り
・サイトの表示くずれ
・エラーが表示されている
これらでお悩みなら最短30分ですぐに解決します！
いまなら期間限定で
・万一改善されない場合は全額返金保証で安心!
・30日間動作保証で安心!
・初期費・調査料 0円で安心!