WordPressを狙う悪質ボットのIPを通報・撃退する方法
ブロックだけでは止まらない！WordPressを狙うボット攻撃の実態
WordPressサイトを公開し、Wordfence SecurityやCloudSecureといったWAF（Web Application Firewall）を稼働させていると、管理画面のリアルタイムログや通知メールには日々大量の「Blocked（遮断）」通知が蓄積されます。
これは主に悪意を持ったボットによる自動スキャンの痕跡です。ログを詳細に確認すると、主に以下のような手口が確認できます。
クロスサイトスクリプティング（XSS）の試行：検索フォームやURLパラメータに対し、<script> タグや悪意あるJavaScriptコードを注入して訪問者のブラウザ上で実行させようとする攻撃。
任意コード実行・バックドア探索：サーバーサイドの脆弱性を突くため、exec( や eval(、system( などのPHP関数を呼び出す文字列を含んだリクエストを送り込み、サーバーの制御権を奪おうとする試行。
ログイン試行（ブルートフォース攻撃）：wp-login.php や xmlrpc.php に対し、一般的なユーザー名と辞書攻撃ツールを組み合わせて数分間に何百回・何千回とパスワード入力を試みる総当たり攻撃。
WAFが適切に機能していれば、これらは「403 Forbidden」等で水際で弾かれ、直接的な改ざんや情報漏洩といった被害は防げています。
しかし、「遮断できているから安全」と放置しておくことはできません。
毎分数千回規模の不正リクエストが着信し続けると、Webサーバーはそれらの検証や遮断処理だけでCPUやメモリを激しく消費し、一般訪問者の表示遅延やサーバーダウンを招く重大なリスクを抱え続けることになります。
IPブロックだけでは不十分（踏み台サーバーの使い捨て構造）
攻撃ログを見つけるたびに、WAFのブラックリスト機能やサーバーの .htaccess を使って該当IPを手動でブロックしている運営者も少なくありません。
現代のサイバー攻撃は、個人のPC回線から直接行われるケースはほとんどありません。
攻撃者は世界中に存在するクラウドサービスや安価なVPS（仮想専用サーバー）を契約し、スクリプトによって自動化されたボットを配置して攻撃インフラを構築しています。
これらクラウドインフラの最大の特徴は「使い捨てが容易」である点です。
APIを使えば、数分で新しい仮想サーバーを立ち上げて新しいIPアドレスを取得できます。
そのため、サイト側がどれだけIPアドレスをブロックしても、攻撃側は即座に別のIPアドレスや別のプロバイダのサーバーへ乗り換えて攻撃を再開します。
IPアドレスの遮断登録を繰り返す作業は、次から次へと無限に現れる相手に対する「モグラ叩き」のようなものです。
ホスティング事業者へのAbuse通報が根本解決になる理由
この終わりのないいたちごっこを断ち切るために不可欠な防衛策が、攻撃元IPを保有・管理しているホスティング事業者に対する「Abuse（不正利用）通報」です。
AWS、Google Cloud、Microsoft Azureといった大手クラウドから、DigitalOcean、Vultr、Hetzner、Linodeなどの各種VPS事業者、さらには国内外のレンタルサーバーに至るまで、すべての正規プロバイダは利用規約（Acceptable Use Policy: AUP）を定めています。
その中では、自社のインフラを利用した不正スキャン、総当たり攻撃、脆弱性攻撃、スパム配信などの迷惑行為を例外なく厳格に禁じています。
被害を受けたサイト管理者から、攻撃の日時・タイムゾーン・アクセス元IP・具体的な検知ログといった客観的な証拠を添えて正式に通報が行われると、事業者のセキュリティ監視部門（Trust & Safetyチーム等）が調査に着手します。
規約違反が明白であると判断された場合、事業者側によって該当サーバーのネットワーク遮断、仮想インスタンスの強制破棄、悪質ユーザーのアカウント凍結といった強力なペナルティが執行されます。
攻撃者が利用している「踏み台サーバーそのもの」をインフラ事業者側の手で停止させることこそが、攻撃の発生源を潰し、自サイトへの攻撃トラフィックを根本から断つ最も効果的なアプローチです。
攻撃元IPから管理事業者（プロバイダ）を特定する
WHOIS情報で「どこの誰のサーバーか」を調べる仕組み
WAFのログに記録された「54.160.247.72」や「34.181.212.238」といった数字の羅列（IPアドレス）を見ただけでは、そのサーバーがどこの国のどんなサービスを利用しているのか、そしてどこへ通報すればいいのかは分かりません。
ここで活躍するのが「WHOIS（フーイズ）情報」です。 インターネット上のIPアドレスは、世界的な管理団体（ICANNや各地域のレジストリ）によって、プロバイダやクラウド事業者ごとにブロック単位で割り当てられています。
「このIPアドレスの範囲はどの組織が管理しているか」という所有者情報は、実はインターネット上の公開データベースで誰でも検索・閲覧できるようになっています。
そこでGoogle Geminiに相談して、IPを入力するだけでホスティングサービスを割り出すツールを作成しました。
WAFログ解析：IPアドレス判定ツール
攻撃元のIPアドレスを入力すると、AWSやGCPからのアクセスかどうかを判定します。
ハッカーが好むインフラの傾向（大手クラウド／海外格安VPS／Bulletproof Hosting）
ツールで判定してみると、全く聞いたことのない海外プロバイダから、誰もが知る有名IT企業まで、様々な組織名が表示されるはずです。
ボット攻撃や脆弱性スキャンを仕掛けるハッカーが好んで悪用するインフラには、以下のような明確な傾向があります。
大手パブリッククラウド（AWS、Google Cloud、Microsoft Azureなど）
アカウント作成が容易で、APIを使えばプログラムから自動的に数千台のサーバーを構築・破棄できるため、使い捨ての攻撃拠点として頻繁に悪用されます。また、一般企業の正規サービスも多数稼働しているため、サイト管理者側が「IP帯域を丸ごとブロックすると、正常なアクセスまで遮断してしまうかもしれない」と躊躇する心理を突く狙いもあります。海外の格安VPS（DigitalOcean、Vultr、Hetzner、Linodeなど）
月額数ドルという低コストで利用でき、利用開始時の審査も緩やかな傾向があるため、大規模なボットネットの構築拠点として世界中のハッカーから狙われやすい環境です。Bulletproof Hostingと呼ばれるサービス
ロシアや東欧などに拠点を置き、Abuse（不正利用）通報を意図的に無視する非合法寄りの事業者。ここに通報してもアカウントが凍結されることは稀ですが、裏を返せば、これ以外のまともなクラウド・VPS事業者（AWSやGCPなど）であれば、正確な証拠を添えて通報することで、高い確率で悪質サーバーを凍結・排除させることができます。
通報先は2パターン！Webフォーム型とメール連絡型
攻撃元のIPアドレスからプロバイダ（事業者）を特定したら、次はその事業者の不正利用対策窓口へ通報（Abuseレポートの送信）を行います。
世界中のホスティング事業者は数千社以上存在しますが、通報の受付窓口は大きく分けると「専用Webフォーム型」と「メール連絡型（abuse@宛）」の2パターンしかありません。
パターンA：専用Webフォームを持つ大手事業者（AWS、GCP、Azure等）
世界規模で巨大なインフラを展開するメガクラウドや、一部の大手VPS事業者（DigitalOceanなど）は、日々膨大な数の通報を機械的かつ迅速に処理するため、専用の通報フォーム（Webポータル）を用意しています。
AWS（Amazon Web Services）
特徴：攻撃の種類（Web App Attack、Port Scanning、Botnetなど）を選択し、送信元IPやログをフォームに直接入力して送信します。
Google Cloud（GCP）
特徴：「Compute Engine」などの利用サービスを選択し、攻撃元IPとWAFの検知ログ、または画面のスクリーンショットを添えて報告します。
Microsoft Azure
特徴：Microsoft Security Response Center（MSRC）が管理する窓口で、対象リソースのIPと不正アクセスの証拠ログを提出します。
DigitalOcean
特徴：海外の格安VPSとしてハッカーに悪用されやすいプラットフォームの1つ。専用フォームからインシデント種別を選んで即座にレポートが可能です。
パターンB：メールで通報する一般事業者（abuse@ドメイン宛）
中堅クラウド、海外の格安VPS、あるいは国内外の一般的なレンタルサーバー事業者の大半は、専用Webフォームを持たず、Eメールでの通報受付 を標準としています。
インターネットの国際標準規格（RFC 2142）では、ネットワークの不正利用を通報するための専用メールアドレスとして「abuse@<ドメイン名>
」を用意することが推奨・義務付けられています。
通報先メールアドレスの調べ方
WHOIS検索サービス（または前章の判定ツール）でIPアドレスを検索します。
検索結果のテキストから「OrgAbuseEmail 」「abuse-mailbox 」「e-mail 」などの項目を探します。
そこに記載されているアドレス（例:
abuse@vultr.comやabuse@hetzner.comなど）が正式な通報先です。
必須となる「4大証拠データ」
調査を迅速に進めさせるための必須チェックリスト
ホスティング事業者のセキュリティ担当部門（Trust & Safetyチーム）には、世界中から毎日数千〜数万件規模の通報が寄せられています。
「攻撃されて迷惑している」「サイトが重くなった」といった感情的な主張だけでは調査は一切進まず、客観的な技術的証拠が揃っていないレポートは即座に破棄されます。
事業者が自社の契約者に対してサーバー停止やアカウント凍結といった重い処分を下すためには、契約違反を裏付ける決定的な証拠が必要です。
１．攻撃元IPアドレス（Source IP Address）
記載内容：WAFログに記録されている、攻撃リクエストを送信してきたIPアドレス（例: 54.160.247.72）。
ポイント：複数のIPから分散攻撃を受けている場合は、当該プロバイダに帰属するIPアドレスのみを抽出し、箇条書きでリストアップします。無関係な他社のIPを混在させると照合エラーの原因になります。
２．攻撃発生日時と正確なタイムゾーン（Timestamp with Timezone）
記載内容：秒単位まで記録されたアクセス日時と、その基準となるタイムゾーン（例: 2026-10-31 15:30:22 JST または 2026-10-31 06:30:22 UTC）。
ポイント：タイムゾーンの明記は必須です。海外事業者のログは協定世界時（UTC）で管理されているため、「2026-10-31 15:30:22」とだけ書くと、相手は自国時間やUTCと誤認してログ照合に失敗します。日本標準時（JST）のログを提示する場合は、必ず「JST (UTC+9)」と併記するか、あらかじめUTCへ変換した時刻を併記してください。
３．標的となった自サイトのURL・ポート番号（Target URL & Port）
記載内容：攻撃リクエストが送り込まれた具体的なURLと通信ポート（例: [https://example.com/wp-login.php](https://example.com/wp-login.php)、Port 443）。
ポイント：トップページのドメインだけでなく、実際に狙われたエンドポイント（ログイン画面、REST API、検索パラメータ等）まで正確に伝えます。
４．WAFの検知ログ・悪意ある文字列（Raw Logs & Payload）
- 記載内容：WAFやWebサーバー（Nginx / Apache）が出力した生のアクセスログ（Raw Log）、および攻撃者が送り込んできた不正文字列。
ポイント：
XSS / SQLi / コード実行：不正文字列がURLやPOSTデータに含まれている部分。
- ブルートフォース攻撃：短時間に数十〜数百回連続で POST /wp-login.php に対して「403」や「200」が返されている連続ログ。
- User-Agent：攻撃ツール特有の識別子（例: sqlmap、python-requests、あるいは偽装されたブラウザヘッダー）。
WAFの部分、筆者もよくわかりません。
Geminiが教えてくれたことをそのまま掲載しています。
そのまま使える！汎用Abuse通報テンプレート（英語）
世界中のホスティング事業者やクラウドベンダーに通報する際、共通言語として機能するのは英語です。流暢な長文を書く必要はなく、事業者のセキュリティ監視チーム（Trust & Safety）や自動解析システムが「いつ・どのIPから・どんな攻撃が行われたか」を一目で把握できる定型フォーマットを使うことが、最も迅速なサーバー停止・アカウント凍結につながります。
通報先の窓口仕様（Webフォームかメールか）に合わせて使い分けられる2種類の英語テンプレートを用意しました。[ ] で囲まれた箇所をご自身のログ情報に書き換えてご利用ください。
パターン1：Webフォーム用テンプレート（コンパクト版）
AWS、Google Cloud、Microsoft Azure、DigitalOceanなどの入力フォーム（「Description」「Details」などの入力欄）に貼り付けるための簡潔なテンプレートです。
文字数制限があるかもしれませんが、多分以下の文章のアレンジで大丈夫です。
Dear Abuse Team,
I am writing to report malicious activities originating from an IP address hosted on your network.
Our Web Application Firewall (WAF) detected and blocked unauthorized attack requests targeting our WordPress website.
[Incident Summary]
– Source IP: [攻撃元IPアドレス（例: 54.160.247.72）]
– Timestamp: [攻撃発生日時とタイムゾーン（例: 2026-10-31 15:30:22 JST / 06:30:22 UTC）]
– Target URL: [狙われたURL（例: https://example.com/wp-login.php）]
– Target Port: 443 (HTTPS)
– Attack Type: [攻撃種別を選択: Web Application Attack (Vulnerability Scanning / Arbitrary Code Execution / XSS) または Brute Force Attack]
[Raw WAF Log / Sample Payload]
[ここにWAFの検知ログまたはHTTPリクエストを貼り付け]
This activity clearly violates your Acceptable Use Policy (AUP).
Please investigate the responsible customer account and take appropriate corrective actions, including null-routing or suspending the offending instance.
Thank you for your assistance.
Best regards,
[あなたの名前 または サイト管理者名]
[自サイトのURL]
パターン2：メール送信用テンプレート（abuse@宛て標準版）
中堅クラウドや海外格安VPS（Linode、Vultr、Hetznerなど）の abuse@<ドメイン名>
宛てに送信するメール用テンプレートです。件名（Subject）を見るだけで担当者がインシデントを即座に分類できるよう設計しています。
To: abuse@[プロバイダのドメイン名（例: abuse@vultr.com）]
Subject: Abuse Report: Unauthorized attack activities from [攻撃元IP]
Dear Abuse and Security Team,
I am writing to formally report malicious traffic targeting our web infrastructure, originating from an IP address allocated to your network.
Below are the details and raw logs of the incident captured by our security monitoring system:
=== Incident Details ===
– Offending IP Address: [攻撃元IPアドレス]
– Hostname (if known): [逆引きホスト名、分からなければ Unknown]
– Incident Date & Time: [日時（例: 2026-10-31 15:30:22 JST / 06:30:22 UTC）]
– Target Host / URL: [攻撃対象URL（例: https://example.com/…）]
– Target Port: 443 (HTTPS)
– Attack Classification: [攻撃内容（例: Automated Botnet Scanning, Remote Code Execution attempt, WordPress Credential Stuffing）]
=== Raw Evidence / Access Log ===
[ここにWAFログ・WebサーバーログをPlain Text形式で貼り付け]
（例）
2026-10-31 15:30:22 [BLOCK] 54.160.247.72 POST /wp-admin/admin-ajax.php?action=… – HTTP/1.1 403 Forbidden “User-Agent: python-requests/2.28.1”
================================
The observed activities indicate that this host is either compromised or actively used for hostile operations, which constitutes a violation of your Acceptable Use Policy.
We kindly request that you investigate this host, notify the tenant, and take necessary measures to terminate the malicious traffic at your earliest convenience.
Sincerely,
Site Administrator
[自サイトのドメイン名]
[連絡先メールアドレス]
テンプレート記入時のチェックポイント
タイムゾーンの併記（JST + UTC） 2026-10-31 15:30:22 JST (06:30:22 UTC) のようにUTCを併記すると、受領側でのログ突合が確実になります（日本時間はUTCより9時間進んでいます）。
Attack Type（攻撃種別）の選び方
不正なコードや脆弱性スキャンの場合：Web Application Attack (Vulnerability Exploitation / Remote Code Execution)
パスワード総当たりの場合：Brute Force / Credential Stuffing Attack
大量アクセスの乱れ打ちの場合：Automated Bot Scanning / Layer 7 DoS
管理者ユーザー名の伏字化 貼り付ける生ログの中に自身のWordPress管理画面ユーザー名が含まれている場合は、admin_****** などに置換して送信してください。
攻撃を耐えるだけの日々から「元を断つ」積極的な自衛へ
WordPressサイトを運営していると、WAFが弾き続ける大量の攻撃ログを見るたびに消耗し、「ブロックしているから大丈夫」と自分に言い聞かせてしまいがちです。しかし、悪質なボットや脆弱性スキャナーは、放置すればIPやサーバーを変えて何度でも執拗に攻撃を繰り返してきます。
攻撃のいたちごっこを断ち切るために必要なのは、ただ盾を構え続けることではなく、攻撃者の足元にあるサーバーそのものを奪う「Abuse通報」です。
ログからIPを割り出す：WHOIS情報や判定ツールを使い、相手が利用しているクラウドやVPSを特定する。
正確な証拠を揃える：秒単位の日時（JST/UTCの明記）、標的URL、WAFの生ログ（ペイロード）を過不足なくまとめる。
適切な窓口へ通報する：大手クラウドなら専用Webフォーム、一般VPSなら abuse@ 宛てに英語テンプレートで速やかにレポートを送信する。
正規のホスティング事業者であれば、明確な証拠を伴う利用規約（AUP）違反の通報を無視することはありません。調査を経て該当サーバーのネットワーク遮断やアカウント凍結が執行されれば、そのサーバーから発信されていた攻撃トラフィックは完全に停止します。
WAFログは、単に攻撃を防いだ記録ではなく、攻撃者を追い詰めるための強力な証拠データです。怪しいログを見つけたら「特定して通報する」というステップを運用ルーティンに加え、安全なサイト運営を維持していきましょう。
-
WordPressを狙う悪質ボットのIPを通報・撃退する方法の関連リンク
