ELB配下のWebサイト(WordPress)でIP制限を掛ける
前提
AITPのIMIです。
Webサイトやシステムの管理領域にIPでの制限を掛けるといったセキュリティ施策は広く一般的に用いられる手段ですが、当然ながらアクセス元のグローバルIPが解っている必要があります。
インターネットと直接通信しているサーバーであれば基本問題はありませんが、ロードバランサーなどを経由した場合には状況が異なります。
例えば、 Route53 → AWS ELB（ロードバランサー） → EC2 という良くある構成の場合、EC2に到達した際にWebサーバー（Apacheなど）から見えるIPはELBのIP（ローカルIPアドレス）となります。
その場合、多数の外部アクセスがあっても何パターンかのELBローカルIPアドレスとしか見えませんので、冒頭のような制限を実施することが出来なくなってしまいます。
ならどうすればいいのさ？その1
最初に結論を記載してしまいますと、以下で一応の実現は可能です。
一応のと書いた通り、落とし穴がありますので後述します。
- 本来の送信元IPアドレスは
X-Forwarded-Forヘッダの末尾へと格納されている。 - Confに以下の設定を書き込む事で、一応は送信元IPが参照できる。
- Confファイルを追加・編集後は、httpd Reload等をして設定を反映すること。
設定の出来る場所はいくつかありますが、例として、/conf.d/ 配下に ProxyAddHeaders.conf として保存しました。
ProxyAddHeaders On # デフォルトでONになっている場合は不要
RemoteIPHeader X-Forwarded-ForWordPressでの利用例
タイトルに記載の通り、Wordpressのログインページに制限をかけたい場合はドキュメントルート等で .htaccess を設置します。/wp-admin/ 配下全てに掛ける方が確実ではありますが、プラグイン等の動作に影響する可能性もあるので、それぞれの環境で判断が必要となります。
# Allow IPs
<FilesMatch "wp-login\.php">
<RequireAny>
# Office-IP
Require ip xxx.xxx.x.x
# My-IP
Require ip xxx.xxx.x.x
</RequireAny>
</FilesMatch>繰り返しになりますが、ここまでの設定で一見期待した動作が得られるように見えます。
しかし、既に述べた通り落とし穴が存在します。
ならどうすればいいのさ！？その2
引っ張りましたが、こちらでも結論から記載しますと以下が問題点です。
- X-Forwarded-Forヘッダは偽装が出来る。
- IPv4でも膨大なパターン数があるとは言え、情報はどこから漏れるか解らない。
- 仮に悪意をもった第三者が、開放されているIPを知った場合のリスクは大きい。
～そして対策へ～
今回は、ELB配下のWebサイトという点がポイントです。
ヘッダを偽装したとして、それはあくまでELBを経由することで初めて効果が出るものです。
まさに、X-Forwarded-Forの言葉通りですね。
そして最終的には、CTOにも指摘をもらい以下の結論に辿り着きました。
WebサーバーでX-Forwarded-ForヘッダのIPを見るのがダメなら、その手前のELB・ALB時点で送信元IPを見れば良いじゃない。
以下に実際のALBリスナーの設定例キャプチャを掲載します。
言葉で補足をしますと、最初のIP判定で許可IPを持つユーザーは/wp-login.phpへと誘導が完了するので、/wp-login.phpへの一般アクセスはとにかく拒否。という意図となっています。
まとめ
WordPressを利用する以上、各種のセキュリティ対策は必須になります。
この記事以外のやり方も多数あるとは思いますが、ELB・ALBを利用している環境下では、
このような手法で管理画面ログインを塞いでしまうことは、一つの対策として低コストで実施できる有効な手段と言えそうです。