AWS WAFの匿名IPリストのマネージドルールHostingProviderIPListでAWSのIPがブロックされることの確認と回避方法

AWS WAFのHostingProviderIPListルールでは、AWSのIPアドレスからのアクセスがブロック対象となります。スコープダウンステートメントによる指定したIPアドレスのブロック回避方法とともに動作を確認してみました。

#AWS WAF

#AWS

清水俊也

2021.12.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

清水です。AWS WAFで利用できる匿名IPリスト（Anonymous IP List）マネージドルールグループのHostingProviderIPListルールでは、ホスティングプロバイダーやクラウドプロバイダーのIPアドレスをブロックします。このブロック対象にはAWSのIPアドレスも含まれ、EC2やNATゲートウェイにアタッチしたElastic IPなどからアクセスした場合に、リクエストがブロックされてしまいます。本エントリではこの事象、AWSのIPアドレスがHostingProviderIPListルールでブロックされることを実際に確認しつつ、AWSのIPアドレスでも指定したものはブロックを回避するようスコープダウンステートメントを設定する方法についてまとめてみます。

HostingProviderIPListでAWSのIPアドレスがブロックされることを確認してみる

まずはAWS WAFの匿名IPリスト（Anonymous IP List）マネージドルールグループを使用した際に、AWSのIPアドレスがHostingProviderIPListルールでブロックされることを実際に確認してみます。

AWS managed rule groupの「Anonymous IP list」を設定したWAFを作成し、ALBに関連付けます。

このALBではアクセスすると以下のように「200 OK」の文字列を返すようにしています。

実際に私の自宅のインターネット回線を使用したアクセスや、スマートフォンからのモバイル回線を使ったアクセスでは上記の「200 OK」を確認することができました。AWS WAFのマネジメントコンソール、Sampled requestsからもアクセスを許可していること（Anonymous IP listのルールグループに引っかかっていないこと）が確認できます。

続いて、このURLに対してAWS東京リージョンに起動したEC2からアクセスできるか確認してみます。curlコマンドを実行してみたところ、以下のように「403 Forbidden」が返ってきました。AWS WAFでブロックされている状態ですね。

$ curl https://www.example.net/
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
</body>
</html>

Sample requestsから該当するリクエストについても確認してみます。アクセスに使用したEC2のIPアドレス（54.XXX.XXX.245）で、かつcurlコマンドからのリクエストがブロックされていることが確認できました。

ブラウザからAWSのIPアドレスを用いたプロキシ経由でアクセスした場合についても確認してみます。弊社のElasticGateという仕組みを使用しました。ElasticGateはVPN+プロキシ環境であり、どこからでも固定されたグローバルIPでの通信を可能にしています。この固定されたグローバルIPはAWS（東京リージョン）のものとなっています。詳細については以下エントリをご参照ください。

Developers.IO 2018 で「クラスメソッドの成長を支えるクラウド時代の情報システム」を話しました #cmdevio2018 | DevelopersIO

このElasticGate経由で先程のページをChromeブラウザで確認してみます。やはり「403 Forbidden」が返り、WAFでブロックされている状態です。

Sample requestsからもブロックされていることが確認できました。

AWSのIPアドレスからのアクセスが匿名IPリスト（Anonymous IP List）マネージドルールグループを使用したWAFでブロックされることが確認できました。実際にブロックされているルールについて詳細を確認してみましょう。Sample requestsで確認した情報から、ルールグループ内の「AWS#AWSManagedRulesAnonymousIpList#HostingProviderIPList」ルールでブロックしているとのことです。

この「HostingProviderIPList」の詳細をドキュメントで確認してみます。AWS WAFデベロッパーガイドの「AWS管理ルールルールグループリスト」の項目、「IP 評価ルールグループ」の「匿名 IP リスト」、「HostingProviderIPList」の項目に以下の記載があります。

エンドユーザートラフィックのソースになる可能性が低いホスティングプロバイダーとクラウドプロバイダーの IP アドレスのリストを検査します。例には、AWS などのクラウドプロバイダーがあります。

AWS管理ルールルールグループリスト - AWS WAF、AWS Firewall Manager、および AWS Shield Advanced

ドキュメントにズバリ記載があるとおり、AWSのIPアドレス含めクラウドプロバイダーのIPアドレスは一般的なエンドユーザのトラフィックになる可能性は低く、この「HostingProviderIPList」ルールでのブロック対象としているわけですね。

AWS WAFのスコープダウンステートメントを使って指定したIPをブロックしないようにする

「HostingProviderIPList」ルールでAWSのIPアドレスがブロックされることが確認できました。ドキュメントの記載の通り、一般的なエンドユーザのIPアドレスがAWSのものになる可能性は低いかと思います。一般的なエンドユーザ向けのWebサイトなどではこの「HostingProviderIPList」ルールを有効にしておいたほうがよさそうです。

しかし、例えばAWSの環境をプロキシにしている（弊社のElasticGateの）ような場合だったり、Amazon WorkSpacesを使っていたりする場合、この「HostingProviderIPList」ルールが意図しない（参照させたいユーザのリクエストを対象とした）ブロックとなってしまいます。また一般的なエンドユーザではなく外部システム連携などで、AWSのIPアドレスからのリクエストが発生する場合もブロック対象となります。

この回避を考えた場合、「HostingProviderIPList」ルール自体をブロックではなくカウントモードにする（WAFでブロックするのはルールセット内の「AnonymousIPList」ルールのみ）ことが一つ考えらます。ただしこの場合、AWS含めたクラウドプロバイダーやホスティングプロバイダーのIPアドレスをWAFによるブロック対象から一括で外すことになってしまいます。

もし接続元となるAWSのIPアドレスがわかっているのであれば、もう一つの回避策としてWAFのスコープダウンステートメントを設定する方法を採ることができます。WAFのルールグループで、指定したIPアドレス以外のリクエストのみを評価するようスコープダウンステートメントを設定します。指定したIPアドレスはこのルールグループでの評価対象外になりブロックされることはありませんが、指定したIPアドレス以外のクラウドプロバイダーやホスティングプロバイダーのIPアドレスは引き続きブロック対象となります。

実際にこのスコープダウンステートメントを設定してみましょう。まずはIP setを作成します。IP addresses欄にWAFでブロックさせないAWSのIPアドレスを入力します。（以下では/32で入力していますが、/24などでIPアドレスレンジを指定することも可能です。）

WebACLのRulesの項目、「AWS-AWSManagedRulesAnonymousIpList」を選択して[Edit]ボタンで進みます。

「Enable Scope-down statement」のチェックボックスをonにします。「Scope-down statement - optional」の項目が展開されていない場合はクリックして展開しましょう。

スコープダウンステートメントに設定した条件の場合のみ、ルールグループで評価されることになります。今回はIP setで指定したIPアドレス以外を評価対象にしたいわけなので、以下のように設定し[Save rule]でルールを保存します。

If a request
- doesn't match the statement (NOT)
Statement
- Inspect
  - Originates from an IP address in
- IP set
  - NotAnonymousIPs （先ほど作成したIP set）
IP address to use as the originating address
- Source IP address

なお、このスコープダウンステートメントを使用することによりWCU（Web ACL Capacity Unit）を消費する点に注意しましょう。今回はIP setを使用しているのでWCUを1使用しています。スコープダウンステートメント追加前は50/1500 WCUsだったのが、51/1500 WCUsになっていますね。（IP セット一致ルールステートメント - AWS WAF、AWS Firewall Manager、および AWS Shield Advanced）

実際に先ほどと同じEC2インスタンスから、再度アクセスしてみます。今度はWAFにブロックされず、コンテンツである「200 OK」が表示されました。

$ curl https://www.example.net/
<html><head><title>200 OK</title></head><body><h1>200 OK</h1></body></html>

Sample requestsからもリクエストがブロックされず許可されていることが確認できます。

AWSのIPアドレスを用いたプロキシ環境yElasticGate経由でのアクセスも同様に「200 OK」が表示されました。

まとめ

AWS WAFのマネージドルールグループの「Anonymous IP List」を適用した環境に対して、AWSのIPアドレスからアクセスした場合、「HostingProviderIPList」ルールでブロックされることを確認してみました。「HostingProviderIPList」ルールの内容を確認するとAWSのIPアドレスをブロックすることは意図した挙動になります。（当初、このルールの内容を把握しておらず、AWSのIPアドレスがブロックされたことで少しビックリしました。）特定のAWSのIPアドレスや他クラウドプロバイダー、ホスティングプロバイダーのIPアドレスからのアクセスをブロックさせたくない場合は、スコープダウンステートメントを活用してルールグループの評価対象外に設定しましょう。