WordPress のログイン画面を隠蔽するとかえってサーバーに負荷が掛かってしまうことの検証
以前のブログ記事「WordPress のログイン URL を変更することにセキュリティ的な意味はない」では、このように述べた。
もしかしたら、ログイン URL を変えることによってウェブサイトの負荷軽減を考えている人がいるかもしれない。しかし、ログイン URL を変えるようなプラグインを入れた状態で標準のログイン画面にアクセスすると、基本的にトップページやテーマの 404 ページを出すような挙動になっているものが多く、大して負荷軽減になっていない。
今回のブログ記事では、本当にログイン画面を変えても負荷軽減になっていないことを検証してみる。
前提条件
検証に使用した環境は、こちら。
- Windows PC に Docker +
wp-envの組み合わせ- Ryzen 5 5500GT
- 32 GB RAM
- WordPress 6.9
- theme-test-data-ja をインポート
- Twenty Twenty-Five
- ApacheBench 2.3
プラグインの設定
ログイン画面を隠蔽するために、SiteGuard WP Plugin を使用する。
設定内の「ログインページ変更」だけを有効化して、以下のように設定した。
- 変更後のログインページ名 :
login_siteguard - 管理者ページからログインページへリダイレクトしない : チェック
この場合、以下のような挙動になる。
wp-login.phpにアクセス : 404 ページが表示されるwp-admin/にアクセス : 302 が返されてトップページへリダイレクト
ベンチマークを取る
プラグインあるなしによらず、wp-login.php に POST するという想定で、ApacheBench でベンチマークを取ってみる。このようなコマンドで、ログインを試行のシミュレーションをしてみる。
.\ab -c 50 -n 5000 -l -k -p request.txt -T "application/x-www-form-urlencoded" http://localhost:8888/wp-login.phprequest.txt は、実際に開発者ツールを開きながらログインを試行してできたリクエストを入れている。一旦ログインページを変更を無効にして、同プラグインのログイン履歴で試行が行われていることは確認済みだ。
そして、プラグインが有効であるときと、無効であるときの結果を比較する。
| 種類 | プラグイン有効 | プラグイン無効 |
|---|---|---|
| Time taken for tests | 215.049 sec | 59.529 sec |
| Total transferred | 404.345 MB | 52.340 MB |
| Requests per second | 23.25 req / sec | 83.99 req / sec |
| Time per request | 2150.493 ms | 595.293 ms |
ベンチマークの結果と考察
ベンチマーク結果によると、普通にログイン画面でエラーを出すよりも、404 ページを出す方が 3 倍以上テストに時間が掛かり、7 倍以上転送量が多く、捌けるレスポンス量は 3 分の 1 になり、ユーザーのリクエスト体感時間は 3 倍に伸びた。
つまり、ログイン画面よりも 404 ページを生成する方がかえってサーバーに負荷が掛かる。
注意点
これはあくまでベンチマークでの結果はこうだった、というだけで、例えばキャッシュが上手く効くようになっていると、どちらのパターンでも同等の速度が出たり、逆にログイン画面を出す方が遅くなったりする可能性がある。
また、そもそも「憂慮しなければならない程度の負荷なのか」という点についても、ここでは考えない。
じゃあ、どうすればいいのか？
ログインの試行回数が増えることで増加する負荷については、ログイン画面を隠蔽するなどの対策ではなく、レートリミットを設けるなどの対策が望まれる。
レートリミットによる 429 エラーは、まともにレスポンスを返すよりも低負荷になるはずだ。
また、会社で運用している環境や、固定 IP アドレスが用意できる場合などは、IP アドレス制限を掛けると良い。
