Zenn
📝

AWS WAF最新コンソール （v2）からClassicまでのざっくりまとめ

に公開
AWS
WAF
shield
tech

AWS WAF Classic から最新に移行する機会があったので個人的に触ったところだけですがまとめてみます。CloudFront を使用しているウェブアプリケーションでの設定になります。関連するサービスとして Shield にも少し触れます。

AWS WAF とは

AWS WAF は AWS が提供する WAF です。2025 年 7 月現在複数のコンソールがあるのでそちらから整理してみます。

AWS WAF の現状

2025 年 7 月現在 3 つのコンソールがあります。これから使用する方は最新で良いと思います。最新は 2025 年 6 月にアップデートされたコンソールですが実際の中身は v2 のようです。つまり新しいワードが使われていますが、ベースとなる機能、仕様は v2 になっているようでした。

https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/working-with-console.html

具体的には以下の 3 つがあります。

  • v2 ｜ AWS コンソールで WAF を開くと最初に表示されるコンソールです。
  • 最新｜ WAF コンソール画面左メニューの「Switch to the new WAF console New」というリンクから開けます。
  • Classic ｜ WAF コンソール画面左メニューの「Switch to AWS WAF Classic」というリンクから開くことができます。※非推奨

最新コンソール

最新のコンソールは左メニューの最下部から入ることができます。少々新しい単語が出てきていますが、おそらく概念的には v2 をわかりやすくしたというもので基本は v2 だと思います。個人的にはよりビジネス寄りの方も設定できるように項目や単語が調整された印象でした。

v2

AWS コンソールの上部検索窓から WAF を検索して最初に開かれる画面が 2019 年にローンチされた v2 の画面です。基本概念が Classic から少し変更になり、色々と応用が効く範囲が広がりました。

Classic

AWS コンソールの左メニューにひっそりとリンクがあります。こちらはあと 2 ヶ月ほどで終了しますので新規では設定しないようにしましょう。

WAF(Web Application Firewall)とは

そもそもの WAF を簡単にまとめてみます。WAF は、通常のファイアウォールでは防御できない、文字通りウェブアプリケーションの脆弱性を悪用した外部からの攻撃に対する防火壁として対応するものです。具体的には SQL インジェクションやクロスサイトスクリプティング（XSS）、OS コマンドインジェクションなどの攻撃、ネットワークの L7 レイヤー（アプリケーション層）に関連する攻撃を防ぐことができます。

また IP での制限も WAF が使われるメリットです。筆者もある地域から DDoS を受けた際にこの機能を使って防げた経験があります。

AWS WAF で保護できるリソース

AWS WAF は AWS のサービスの保護として使うことができます。以下は設定できるサービスの一覧です。

  • Amazon CloudFront ディストリビューション
  • Amazon API Gateway REST API
  • Application Load Balancer
  • AWS AppSync GraphQL API
  • Amazon Cognito ユーザープール
  • AWS App Runner サービス
  • AWS Verified Access インスタンス
  • AWS Amplify

今回はよく使われる CloudFront での利用を取り上げます。

AWS WAF で使われる設定項目

WAF では主に以下の項目を設定することで条件にあった通信を拒否・許可・カウントします。

  • IP セット
  • ルール
  • ルールグループ
  • アクション
  • ウェブ ACL

IP セット

IP セットは接続元の IP アドレスの範囲を指定します。そしてこの IP の範囲に基づいて処理をします。特定の IP 範囲から来た通信を許可する or 拒否するという使われ方をします。

ルール

これはHTTP通信で使われるヘッダやリクエストに含まれる文字列などを指定して通信を許可 or 拒否という処理をします。

ルールグループ

ルールをまとめてルールグループにすることができます。これで管理が楽になります。

アクション

アクションには大きく分けて終了アクションと非終了アクションがあります。具体的には以下のものがあります。

  • 許可ー終了
  • 拒否ー終了
  • カウントー非終了
  • CAPTCHA および Challenge ー終了 or 非終了

あと一つ特殊なものとしてデフォルトアクションがあります。順番に整理してみます。

許可

ルールに当てはまった場合に通信を許可します。アクション実行後は終了します。

拒否

ルールに当てはまった場合に通信を拒否します。アクション実行後は終了します。

カウント

ルールに当てはまった場合に通信を許可しつつその回数をカウントします。アクション実行後は終了しません。

CAPTCHA および Challenge

こちらはボット対策やキャプチャを利用する際に使用します。アクションの後は設定次第で終了か非終了になります。こちらは私自身使っていないので詳細は公式ドキュメントをご参照ください。

https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/waf-captcha-and-challenge.html

デフォルトアクション

デフォルトアクションは Web ACL 内のどのルールにも一致しなかったリクエストに対して、最終的に AWS WAF がどのようなアクション（許可またはブロック）を実行するかを定義するものです。
許可は基本的には通信を許可し、リストに上げたものをブロックするというブラックリスト形式です。
ブロックは基本的に通信をブロックし、リストに上げたものを許可するというホワイトリスト形式です。

ウェブ ACL（保護パック）

ウェブ ACL を CloudFront や ALB に設定するイメージです。AWS のサービスにアタッチする単位をウェブ ACL と言います。ウェブ ACL には IP セット、ルール、ルールグループが含まれます。
新コンソールに新しく保護パックというものが出ていますが実態はウェブ ACL です。

コンディション（Classic での概念）

コンディションは Classic のみで使われていた概念で v2 ではルールに統合されています。具体的に設定する項目です。IP アドレスや SQL インジェクションで使われる文字列などを設定します。

WCU とは

WCU（キャパシティユニット）はルールごとに掛かる容量を AWS 側で設定したものです。WAF においては処理が複雑になればコンピュータリソースも比例して消費されます。これを数値化したものが WCU となります。例えば AWS-AWSManagedRulesAntiDDoSRuleSet というルールセットには 50WCU、AWS-AWSManagedRulesLinuxRuleSet には 200WCU という数値が設定されています。こういったルールセットを組み合わせてウェブ ACL（保護パック）を作成し、AWS サービスにアタッチしていきます。この WCU が 1500 を超えると追加料金が発生するので注意しましょう。WCU は最大で 5000 まで設定することができます。

https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-waf-capacity-units.html

AWS Shield Standard とは

Shield はWAFとは別のサービスでWAFで防げない領域を担当するセキュリティサービスです。主に DDoS 攻撃（SYN フラッド攻撃、UDP リフレクション/アンプ攻撃）を防ぎます。攻撃名からもわかるように L3、L4 レイヤーのプロトコルが関連する領域で効果を発揮します。AWS Shield Standard は無料で何も設定しなくてもインターネットに面したすべての AWS サービスに適用されている状態です。代表的なサービスは Elastic Load Balancing (ELB)、Application Load Balancer、Amazon CloudFront、Amazon Route 53 などです。

Shield は DDoS 攻撃に有効ですが、HTTP リクエストフラッド攻撃などの L7 レイヤー（アプリケーション層）の攻撃に対しては無力です。L7 レイヤーは WAF が担当します。

今回想定している攻撃

主な DDoS 攻撃とアプリケーションに対する攻撃を想定して設定します。

想定 DDoS 攻撃

  • SYN フラッド攻撃 ｜ Shield 担当
  • UDP リフレクション／アンプ攻撃 ｜ Shield 担当
  • HTTP リクエストフラッド／F5 アタック ｜ WAF 担当

アプリケーションに対する攻撃

  • SQL インジェクション ｜ WAF 担当
  • クロスサイトスクリプティング（XSS）｜ WAF 担当
  • OS コマンドインジェクション ｜ WAF 担当

移行ハンズオン

ここからは私が実際に行った手順を元にハンズオン形式でまとめてみます。CloudFront で公開しているウェブアプリケーションに設定する形です。Classic で使用していた設定を含みつつ、最新のコンソールからルールを追加しながら設定しました。

AWSWAF Classic のルールを確認

当方の環境で設定していたものがあったのでまずは現状を確認しました。

  1. AWS マネジメントコンソールにログイン
  2. CloudFront のコンソールを開きます。
  3. CloudFront のディストリビューションを選択します。
  4. 「セキュリティ」タブを選択します。
  5. 「セキュリティ - ウェブアプリケーションファイアウォール」の横の三角をクリックすると詳細が確認できます。ここに「enabled」という青いボタンと乱数字（WAF Classic）のリンクがあればクリックします。これがないのであれば WAF Classic は設定されていない可能性があります。
  6. この画面で設定されている WEBACL を確認できます。Name をクリックすると詳細が確認できます。
  7. 「Rules」タブを選択します。この画面では以下の項目が確認できます。
    　　 ∟If a request matches all of the conditions in a rule, take the corresponding action
    　　ルールが適用された場合に以下のアクションを実施します。
    ・If a request doesn't match any rules, take the default action
    　　 ∟ デフォルトのアクションがこの項目に書かれています。つまりルールに該当しなかった通信に関してどのように対応するのかをここで指定しています。
    ・AWS resources using this web ACL
    　　 ∟ ここにアタッチされているリソースが表示されます。Classic の場合は CloudFront のリソースがアタッチされています。
  8. 「Rule」の名前をクリックすると詳細が確認できます。
  9. ここで設定されているルールを確認します。

AWS WAFv2 の設定（新コンソール）

今年新しくなったコンソールも基本的には v2 の仕組みをラップして設定しやすくしたものです。
以下の公式マニュアルに沿って設定をしていきます。

https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/setup-iap-console.html

  1. AWS コンソールでまずリージョンを選択します。CloudFront は「us-east-1」を選択する必要があります。
  2. v2コンソールにアクセスします。https://console.aws.amazon.com/wafv2/homev2
  3. 開いたページの左メニューから「Switch to the new WAF console New」というリンクをクリックします。これで最新のコンソールになると思います。
  4. オレンジの「保護パックを追加」ボタンをクリックします。
  5. アプリカテゴリから次の項目を選択します。
  • コンテンツおよび公開システム
  • API および統合サービス
  • メディアおよびファイル処理
    今回はウェブアプリケーションを想定していますが適宜ご自身の環境に合わせて設定してください。
  1. トラフィックリソースは「APIとウェブの両方」を選択します。
  2. 「リソースを追加」というボタンをクリックするとプルダウンが表示されるので「CloudFront リソースまたは Amplify リソースを追加」を選択します。すると CloudFront のディストリビューションが表示されると思いますので選択します。
  3. リソースを選択したら保護パックの候補を提案してくれるので適宜選択します。ルールの項目をクリックすると具体的な内容が表示されます。またルールの右側にはアクションが表示されているので前述のアクションを考慮して動作をイメージしましょう。
    私の環境では重要というセットで表示された以下のルールを設定しました。予算も 19 ＄/月と表示してくれるのがありがたいですね。
  • レイヤー 7 DDoS 攻撃対策｜ Count
  • IP 許可リスト｜ Allow
  • IP ブロックリスト｜ Block
  • 地理的制限｜ Block
  • グローバルレート制限｜ Default
  • 本文サイズ制限ルール｜ Default
  • AWS コアルールセット｜ Default
  • 既知の不良入力保護｜ Default
  • SQL インジェクション保護｜ Default
  • Linux および Unix 保護｜ Default
  • 管理者保護ルール｜ Default
  1. 名前と説明はこの保護パックに対して設定します。後から見て何に使っているかがわかるように書いておきましょう。
  2. 「保護パックのカスタマイズ <i>- オプション</i> - オプション」も設定していきましょう。「デフォルトのルールアクション」は最初「すべてを Count アクションに設定」しログを確認しながら絞っていく方法が推奨されていました。前述のルールセットだと「Count アクションと Block アクションに推奨のデフォルトを使用する」を選択すると Block アクションが含まれているのでサイトにアクセスできなくなる場合もあります。設定がはっきりわかっている場合以外は Count から始めるのが良いかもしれません。
  3. 「グローバルレート制限ルールのレート制限」はある IP からのアクセス数が 5 分間のうち一定数を超えたら発動するイベントを設定するというものです。
  4. 「ブロックする IP アドレス」「許可する IP アドレス」は具体的に IP がある場合は設定しましょう。
  5. 「国固有のオリジン」は推奨してくれる設定が入っていますので調整が必要な場合は適宜設定してください。
  6. ログ保存先を設定します。

ここまでで WAF のウェブ ACL（保護パック）が設定できました。
この設定を今回は CloudFront に適用していきます。

CloudFront でウェブ ACL を設定する

以下の手順でウェブ ACL を設定していきます。私の場合は Classic の設定が残っているのでこの手順で入れ替えます。

  1. AWS マネジメントコンソールにログイン
  2. CloudFront のコンソールを開きます。
  3. CloudFront のディストリビューションを選択します。
  4. 「セキュリティ」タブを選択します。
  5. 「セキュリティ - ウェブアプリケーションファイアウォール」の横の三角をクリックすると詳細が確認できます。
  6. 「Manage protections」をクリックします。
  7. 「セキュリティ保護を有効にする」にチェックを入れ「既存の WAF 設定を使用」にもチェックを入れるとウェブ ACL が表示されます。※ここでウェブ ACL が表示されない場合は一度 WAF のコンソールに戻り、Global リージョンでウェブ ACL を作成しているか確認しましょう。CloudFront は Global リージョンで稼働するので Global リージョンでウェブ ACL を作成する必要があります。
  8. 「ウェブ ACl」を選択して「save changes」をクリックすると CloudFront のデプロイが開始されます。CloudFront のディストリビューション一覧画面で最終変更日が表示されたら設定が反映されます。

設定後テスト

ここからは稼働しているアプリケーションごとにテストを実施します。私の場合は基本的な CRUD 操作と画像アップロード操作を実施したところ画像アップロードで 403 が返ってきました。調査したところ AWSManagedRulesAdminProtectionRuleSet が原因そうだったのでこのルールセットの中身を一つずつ Count に設定し、最小限の Count でアップロードできるように設定しました。さらに特定のURIのみをCount、他はBlockという設定も加えてスコープを絞っています。前述のルールではさまざまなルールが適用されているので、もしあまりにも色々動かないようでしたら全て count ベースで調整するというのもお勧めされているようです。いずれにしてもこの WAF の設定は運用しながら適宜メンテナンスする必要があるものという認識をしておくことが大切です。

ルールの変更

ルールを変更したい場合もあると思います。その手順を以下に示します。

  1. AWS コンソールでまずリージョンを選択します。CloudFront は「us-east-1」を選択する必要があります。

  2. v2コンソールにアクセスします。https://console.aws.amazon.com/wafv2/homev2

  3. 開いたページの左メニューから「Switch to the new WAF console New」というリンクをクリックします。これで最新のコンソールになると思います。

  4. 左メニューから「リソースと保護」というリンクをクリックすると作成したルールセットが表示されるので選択します。ここでもリージョンを間違えるとリソースが表示されないのでご注意ください。

  5. 表示された画面で「ルール View and edit」をクリックすると設定したルール一覧が表示されます。ここで個別のルールを設定することもできますし、「ルールを追加」からさらにルールを追加することも可能です。windowsOS 用のルールセットなどカスタマイズされたルールもあるので一度どんなものがあるかみてみると良いと思います。※WCU が 1500 を超えると追加料金が発生するのでその点だけご注意ください。

ログの設定

AWS WAF では処理した通信をログとして吐き出すことができます。このログを確認するとアプリケーションからテストをして画像アップロード時に 403 が出た場合にどのルールが通信を弾いたのかなどが確認できます。例えば以下の記述がログに記録されていたとしましょう。


"ruleId":"SizeRestrictions_BODY","action":"BLOCK"

これは SizeRestrictions_BODY というルールが通信を BLOCK したという記録です。SizeRestrictions_BODY は AWS-AWSManagedRulesCommonRuleSet というルールセットに含まれています。

設定手順は以下のドキュメント通りに進めていただければと思います。

https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/logging-management-configure.html

IP セットの設定

IP セットは初期設定のルールで以下の項目で設定されています。

  • IP 許可リスト｜ Allow
  • IP ブロックリスト｜ Block

これらは文字通りリストとして指定した IP を許可、拒否するというものになります。なので具体的な IP を指定していきます。

では以下で具体的に IPv4 でのブロックリストを設定してみます。

IPv ４ブロックリスト設定

  1. AWS コンソールでまずリージョンを選択します。CloudFront は「us-east-1」を選択する必要があります。

  2. v2コンソールにアクセスします。https://console.aws.amazon.com/wafv2/homev2

  3. 開いたページの左メニューから「Switch to the new WAF console New」というリンクをクリックします。これで最新のコンソールになると思います。

  4. 設定した保護パックを選択すると背景が青くなりますのでその状態で「セットとグループを管理」→「IP セットを管理」をクリックします。

  5. 今回設定した「xxxx_IP4_Block」をクリックします。

  6. 開いた画面で「新しい IP アドレスを編集および追加」をクリックします。

  7. 次の画面で「IP アドレス」の欄に「10.0.0.0/32」のようにブロックしたい IP アドレスを指定し「IP アドレスを保存」をクリックします。

これで指定した IP アドレスからのアクセスをブロックすることができるようになりました。

実際にブロックできるか確認してみる

CloudShell というサービスがあるのでそちらから確認してみます。

  1. CloudShell は AWS コンソールの左下に常に表示されていると思います。

  2. クリックするとブラウザ上でシェルが立ち上がります。

  3. アプリケーションにテスト用の HTML を用意してアクセスできることを確認します。以下はただテストという文字を表示するだけのページを用意しています。


$ curl https://example.com/test.html
テスト

これで CloudShell からの（AWS 管理の IP からの）通信が通ることが確認できました。

  1. 次にこの CloudShell が動いている AWS 管理の IP を確認します。

curl http://checkip.amazonaws.com/
13.230.30.124

コマンドを叩いたタイミングや環境などでこの値は変わると思いますので自分でコマンドを叩いて確認してください。この表示された IP 上で CloudShell が動作しているということがわかりました。ではここからの通信をブロックできるか確認してみます。

  1. この IP を 13.230.30.124/32 として後ろに「/32」をつけて前項の(IPv４ブロックリスト設定)の通りに設定します。
  2. 再度 CloudShell からテストページが叩けるか確認してみます。

$ curl https://example.com/test.html
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>

上記のように 403 エラーが返ってきたら設定が効いています。私がテストした際は設定が反映されるまでに数分かかったのでもしかすると CloudFront のエッジに反映されるような動きがあるのかもしれません。

  1. さらに自分の PC 内のブラウザと shell からhttps://example.com/test.htmlにアクセスして表示されればCloudShellのIPからだけ通信が拒否されていることが確認できると思います。

IPセットと地理的制限との違い

IP セットではより細かく IP ごとに設定ができます。地理的制限も国や都市などの場所で制限をかけており、その元になっているのは IP ですが、絞り込める単位が最低でも都市となり、IP セットよりもざっくりとした絞り込みになります。地理的制限は AWS が地理情報 DB を管理するためそういった意味でも管理コストは IP セットに比べると低いという側面もありますね。

参考資料

公式ドキュメント

今回の内容が掲載されているAWS公式のドキュメントです。

https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/working-with-console.html

https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/waf-captcha-and-challenge.html

https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-waf-capacity-units.html

https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/logging-management-configure.html

Udemy

新コンソールと実際にIPセットのブロックが働いているかの確認で参考にさせていただきました。初学者・経験者ともにおすすめの講座です！

https://www.ketancho.net/entry/aws14days

あとがき

今 AWS WAF のコンソールは過渡期だと個人的には思いますが、新コンソールでは初心者にも設定はやりやすくなったと感じます。（もともと WAF を触っていた人は v2 のコンソールの方がわかりやすいかもしれません）私自身も今回の移行で新たな設定を追加でき、サービスのセキュリティレベルも上げられたと思います。この機会に一度設定を見直してみるのも良いと思いました。

Discussion