10G光クロス×MAP-Eサバイバル。fail2banの次はこれ！WordPressのユーザー名露出とXML-RPCをNginxレイヤーで先行遮断するセキュリティ強化編

前回の「fail2banによる動的迎撃」に続く、セキュリティ強化の次なるステップは「情報の隠蔽」と「Nginxレイヤーでの超先行遮断」です。
WordPressは標準状態のままだと、攻撃者に対してログインID（ユーザー名）などの重要な手がかりを自らペラペラと喋ってしまう仕様になっています。どれだけパスワードを複雑にしても、IDという「鍵穴」の形がバレてしまっては防御力は半減します。

今回の環境は、自宅サーバーの手前に「フロントドアとしてVPS（リバースプロキシ：以下「串」）」を1枚挟んだ強固な構成です。この構成を最大限に活かし、悪意あるアクセスが自宅サーバーに到達する遥か手前の「VPS側（プロキシレイヤー）」で、怪しいリクエストを1つずつ安全に叩き落とす鉄壁の防壁を1ステップずつ構築していきましょう。

🔒 Step 1：VPS側で「xmlrpc.php」を封鎖する

まず最初に着手するのが、アタックの最大の温床である xmlrpc.php の完全封鎖です。

📁 VPSの設定ファイルへの追記

VPS側のNginx設定ファイル（test-site.online の設定）を開きます。 server { ブロックのすぐ下（既存の設定よりも必ず上）に、以下のコードを記述します。

server {
    listen 443 ssl;
    server_name test-site.online;

    # =========================================================
    # 🛡️ 【最優先】フロントエンド独立防御ルール
    # =========================================================

    # 【防壁1】XML-RPCへのアクセスを単体で強制拒否
    location ~ ^/xmlrpc\.php {
        deny all;
        access_log off;     # 攻撃ログでディスクが埋まるのを防ぐ
        log_not_found off;
    }

server {
    listen 443 ssl;
    server_name test-site.online;

    # =========================================================
    # 🛡️ 【最優先】フロントエンド独立防御ルール
    # =========================================================

    # 【防壁1】XML-RPCへのアクセスを単体で強制拒否
    location ~ ^/xmlrpc\.php {
        deny all;
        access_log off;     # 攻撃ログでディスクが埋まるのを防ぐ
        log_not_found off;
    }

🔄 反映と動作確認テスト
VPS側で設定ファイルの構文チェックとリロードを行います。

sudo nginx -t
sudo systemctl reload nginx

sudo nginx -t
sudo systemctl reload nginx

Wi-Fiを切ったスマホのブラウザで https://test-site.online/xmlrpc.php にアクセスし、画面に 403 Forbidden と表示されれば第1ステップは成功です！

🔒 Step 2：VPS側で「REST API」経由のユーザー名露出を拒否する

XML-RPCの裏口を塞いだら、次は今回の本丸である「REST API経由のユーザー名ダダ漏れ問題」を狙い撃ちで封鎖します。

📁 VPSの設定ファイルへ「追記」

先ほど開いたVPS側の設定ファイルを再度開きます。先ほど書いた【防壁1】のすぐ下に、以下のブロックをそのまま書き足します。前のコードを消す必要はありません。

# 【防壁2】REST APIのユーザー一覧露出を単体で強制拒否
    location ~ ^/wp-json/wp/v2/users {
        deny all;
        access_log off;     # 攻撃ログを無効化してディスク消費を防ぐ
        log_not_found off;
    }

# 【防壁2】REST APIのユーザー一覧露出を単体で強制拒否
    location ~ ^/wp-json/wp/v2/users {
        deny all;
        access_log off;     # 攻撃ログを無効化してディスク消費を防ぐ
        log_not_found off;
    }

🔄 反映と動作確認テスト

追記したら、同じようにVPS側でテストとリロードを行います。

sudo nginx -t
sudo systemctl reload nginx

sudo nginx -t
sudo systemctl reload nginx

既存のプロキシ設定に邪魔されることなく、しっかりと 403 Forbidden となり、ユーザー名などのJSON情報が外部から完全に覗けなくなっていれば成功です！ (※自宅Wi-Fiに繋がったPCや、管理画面にログインしている状態なら、今まで通り正常にアクセスできるので管理作業の邪魔になりません)

🔒 Step 3：VPS側で「著者アーカイブスキャン」を強制転送する

URLの末尾を狙った狡猾なユーザー名スキャンをシャットアウトし、botを煙に巻きます。

📁 VPSの設定ファイルへ「追記」

VPS側の設定ファイルをもう一度開き、先ほど成功した【防壁2】のすぐ下に、以下の防壁コードをさらに追記します。

# 【防壁3】ユーザースキャン（?author=数値）を検知してトップへ強制転送
    if ($query_string ~* "author=([0-9]+)") {
        return 301 $scheme://$host/;
    }

# 【防壁3】ユーザースキャン（?author=数値）を検知してトップへ強制転送
    if ($query_string ~* "author=([0-9]+)") {
        return 301 $scheme://$host/;
    }

🔄 反映と動作確認テスト

追記したら、同じようにVPS側で構文チェックとリロードを行います。

sudo nginx -t
sudo systemctl reload nginx

sudo nginx -t
sudo systemctl reload nginx

URLが実際のユーザー名（https://test-site.online/author/ユーザー名/）に書き換わる隙を一切与えず、アクセスした瞬間に一瞬でトップページ（https://test-site.online/）へ強制的に引き戻されれば成功です！

🏠 まとめ：VPS側を『面』で鍛えるのが、最もシンプルで確実な正解

「ネットの記事通りに設定しても、なぜかセキュリティをすり抜けて自宅の管理画面まで届いてしまう」というインフラ特有の罠。その根本的な原因は、VPS側のアクセス制限における「URLの書き方の穴（前方一致のガバさ）」にありました。
今回のように、VPS側の制限を ~ ^/（正規表現による完全一致） に統一するだけで、自宅サーバー側のややこしい設定を弄る必要は一切なく、不正なリクエストをVPSの水際で100%シャットアウトできるようになります。

同じリバースプロキシ構成で「制限をかけたはずなのになぜかすり抜ける……」と頭を抱えている方は、ぜひVPS側の記述をこの『新陣形』に見直してみてください！

次の記事は2026年7月31日公開です。

10G光クロス×MAP-Eサバイバル。VPS防壁をすり抜ける「生IP直打ちボット」をNginxレイヤーで無言でゴミ箱に捨てるセキュリティ設定

Ubuntu+WordOpsで動かす自宅WordPressのセキュリティ設定周りの総仕上げ。ルーターの仕様制限を逆手にとった物理ポート制約から、生IP直打ちへのNginxでの即時拒否設定まで、個人運用の実戦的な防御陣形を解説します。

tech.ice-military.com

2026.07.31