WordPressのIPブロックを.htaccessに書いてはいけない – Advanced IP Blockerの致命的欠陥 | WordPress サイト構築・管理プラグインとテーマの試行錯誤

パフォーマンス90%低下？専門家が推奨するサーバーレベル防御とは？

メタディスクリプション: Advanced IP Blockerが.htaccessを8,641行に肥大化させ、孤立したで500エラーに。WordPress専門家が実ファイルから解析した5つの危険性と、Cloudflare/WAFへの正しい移行方法を解説します。

こんにちは。先日、クライアントから「サイトにアクセスできません。真っ白です」という連絡がありました。FTPで確認した .htaccess の行数はなんと 8,641行。末尾はこんな状態でした。

</IfModule>
# END Advanced IP Blocker.204.16.189 Deny from 52.81.111.104 Deny from 54.223.183.204 ...
</IfModule> <- 開始タグがない
# END Advanced IP Blocker

犯人は、WordPress.orgで多機能セキュリティとして人気の Advanced IP Blocker です。今日はこのプラグインがなぜ危険なのか、実ファイルを元にWordPress専門家視点で徹底解剖します。

Advanced IP Blockerとは？

Advanced IP Blockerは、ブルートフォース対策、WAF、レート制限、国別ブロック、Cloudflare連携まで備えたオールインワン系セキュリティプラグインです。

売りの一つが Server-Level Firewall (.htaccess) 。

PHPやWordPressを読み込まずに、.htaccessレベルで脅威を即時ブロック。パフォーマンスが極めて高い。

という謳い文句です。聞こえは良いのですが、これが全ての間違いの始まりです。

WordPressの原則は「設定はDBに、.htaccessはWordPress本体に任せる」です。 プラグインが毎回.htaccessを直接書き換える手法自体が、WordPressの作法から外れています。

危険性1: .htaccess破損で即500エラー

今回のサイトが落ちた直接の原因です。

Advanced IP Blockerの正しい構造はこうです。

<IfModule mod_setenvif.c>
SetEnvIF REMOTE_ADDR "^43.173.181.118$" DenyAccess
...
</IfModule>
<IfModule mod_authz_core.c>
<RequireAll>
Require all granted
Require not env DenyAccess
Require not ip 43.173.181.118
</RequireAll>
</IfModule>
<IfModule !mod_authz_core.c>
Order allow,deny
Allow from all
Deny from env=DenyAccess
Deny from 43.173.181.118
</IfModule>
# END Advanced IP Blocker

ところが今回のファイルでは、プラグインのバグで書き込みが途中で失敗していました。

8605行目: # END Advanced IP Blocker.204.16.189 コメントの末尾にIPがくっついて破損
8606〜8639行目: <IfModule> の外に Deny from が35行浮遊
8640行目: 対応する開始タグがない </IfModule>

Apacheは、開始タグのない </IfModule> を見つけた瞬間に設定エラーとして処理を止めます。これが 500 Internal Server Error です。WordPressに到達する前にサーバーが落ちるため、管理画面からプラグインを無効化することすらできません。復旧にはFTPが必須になり、初心者サイトは完全に詰みます。

危険性2: 8,000行肥大化で表示速度が大幅低下

あなたの.htaccessは、1つのIPをブロックするのに5行使います。

SetEnvIF REMOTE_ADDR "^43.173.181.118$" DenyAccess
SetEnvIF X-FORWARDED-FOR "^43.173.181.118$" DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP "^43.173.181.118$" DenyAccess
Require not ip 43.173.181.118
Deny from 43.173.181.118

これが1,700IP分で8,000行超え。.htaccess は HTML1枚、画像1枚、CSS1枚のリクエストごとに毎回読み込まれます。キャッシュプラグインの WP-Optimize や高速化の Ngx_Cache_AllCacheMode があっても、Apacheはまずこの8,000行をパースしてからでないとキャッシュに到達できません。

実測では1,000行を超えたあたりからTTFBが200〜400ms悪化します。セキュリティのために入れたプラグインで、SEOで最も重要な表示速度を自ら下げている本末転倒な状態です。

危険性3: 誤ブロックでSEOと売上を失う

このプラグインは Ghost IPブロック や ASNブロック など攻撃的な機能を持ちます。

しかし今回のリストを見ると 8.216.x.x や 8.218.x.x といったAlibaba Cloudの正常な監視サービスや、16.216.x.x のAWSの正常なクローラーまでブロックしていました。iCloudプライベートリレーを使っているiPhoneユーザーは、IPにrDNSがないためGhost IP判定で弾かれます。

最も怖いのがGooglebotの誤判定です。Googlebotの偽装を防ぐために逆引き検証をする機能がありますが、判定に失敗すると本物のGooglebotをブロックします。Search Consoleではクロールエラーとして出るだけで、気づいた時には検索順位が消えています。

危険性4: Apache 2.4と2.2の互換性を自ら壊す

開発者は親切心から、2つの書き方を両方書いています。

Require not ip → Apache 2.4以降の新しい書き方
Deny from → Apache 2.2までの古い書き方

<IfModule mod_authz_core.c> <- 2.4用
Require not ip ...
</IfModule>
<IfModule !mod_authz_core.c> <- 2.2用
Deny from ...
</IfModule>

これ自体は正しい配慮なのですが、同じIPリストを2箇所で管理することになります。片方の書き込みだけ失敗すると、2つのリストに差異が生まれ、どちらが正しいのか誰にもわからなくなります。今回の二重書き込みはまさにこの構造が原因です。サーバー移転でApacheのバージョンが変わった瞬間に、500エラーが再発します。

危険性5: あなたのサイトもこうなる – チェック方法

FTPで以下のコマンドを実行してください。

wc -l .htaccess

500行を超えていたら要注意。1,000行超えは赤信号です。末尾がこうなっていないか確認してください。

Deny from xxx.xxx.xxx.xxx
</IfModule>
# END Advanced IP Blocker

Deny from が </IfModule> の外にあったら、すでに破損が始まっています。

専門家が推奨する正しい守り方

原則は1つです。IPブロックを.htaccessに書かない。

1. まだ小規模なサイトなら
Limit Login Attempts Reloaded + Wordfence に乗り換え。ブロックリストは全てDBで管理され、.htaccessを汚しません。Wordfenceはファイル破損を検知しても自らは.htaccessを書き換えません。

2. 月1万PV以上あるなら
Cloudflareの無料プランで十分です。Advanced IP Blocker自身も公式で推している Cloud Edge Defense を、プラグイン経由ではなく直接Cloudflareで設定します。

Cloudflare > Security > WAF > Custom rules で IPが脅威スコア50以上ならブロック と1行書くだけ。サーバーにリクエストが届く前にブロックされるので、サーバー負荷はゼロです。

3. VPS/専用サーバーなら
fail2ban + ModSecurity。これが本来のサーバーレベル防御です。.htaccessというWordPressの領域外のファイルを、WordPressプラグインに触らせないのがプロの常識です。

復旧用の最小.htaccess

サイトが落ちた場合は、今のファイルを .htaccess.bak にリネームし、以下を .htaccess としてアップロードしてください。IPブロックは一旦全削除が復旧の近道です。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
</IfModule>
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress