AWS入門ブログリレー2024〜AWS WAF編〜

こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。

当エントリは弊社AWS事業本部による『AWS 入門ブログリレー 2024』の1日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。今回のテーマは『AWS WAF』です。

AWS WAFとは

AWS WAFは、下記AWSサービスのリソースを保護し、保護されたWebアプリケーションリソースに転送されるHTTP/HTTPSリクエストを監視出来るWeb Application Firewall(WAF)です。

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

サービスページ↓

開発者ガイド↓

そもそもWAF（Web Application Firewall）とは

WAFは、その名の通りWebアプリケーションのためのファイアウォールです。

保護対象のWebアプリケーションとインターネット間のHTTP/HTTPSリクエストを監視することで、一般的なWebアプリケーションへの攻撃（XSS、SQLi等）やDDoS攻撃などの攻撃を緩和することが出来ます。

WAFは全ての攻撃を防御するようなものではなく決して万能ではないですが、Webアプリケーションサーバーに届いていたはずの多くの悪意あるリクエストからサーバーを保護することが出来ます。

AWS WAFで何が出来るのか？〜機能紹介〜

先述の通り、AWS WAFは基本的にHTTP/HTTPSリクエストを監視し、そのリクエスト内容に応じてフィルタリング、ラベリングを行うことが出来ます。

例えば、下記のようなユースケースの場合にAWS WAFは有用です。

• ある特定のIPアドレスからのリクエストを全て許可/拒否したい
• ある特定の国や地域からのリクエストのみを許可/拒否したい
• ある特定の条件で送られてくる高頻度のHTTP/HTTPSリクエストを抑えたい

上記はあくまで一例ですが、後述するルールを駆使することでWebアプリケーションの運用における様々な課題に対応出来るでしょう。

現在、AWS WAFでは下記のような機能が存在します。

• ウェブトラフィックフィルタリング
• Bot Control
• アカウント乗っ取り詐欺の防止
• アカウント作成詐欺防止

上記はAWS WAFのサービスページに特徴として列挙されていたものです。簡単に各内容を紹介します。

ウェブトラフィックフィルタリング

AWS WAFのメイン機能です。

HTTP/HTTPSリクエストを監視し、指定したルールに応じてリクエストをフィルタリングすることが出来ます。

後述しますが、"ルール"は既に作成されているものだけでなく、オリジナルでユーザーが作成することも出来ます。

先述の通り、IPアドレスやリクエストのヘッダー、ボディ、リクエスト先のURIなどの条件に基づいたルールを作成することが可能です。

ユーザーは基本的に、Webアプリケーションに届くリクエストを確認し、そのリクエストに応じて必要なルールを作成、適用することでWAFを運用します。

Bot Control

Bot Controlとは、その名の通りデータスクレイパーやクローラーなど一般的なBotによるアクセスを可視化、抑制出来る機能で、基本的には用意されているルールを有効化するだけで利用することが出来ます。

現時点でBot Controlのルールには Common と Targeted の2種類が存在します。

Commonは俗に言うシグネチャベースのルールです。User-Agentなどのリクエストに含まれる静的なデータをもとに、リクエストがBotによるものかどうかを判別します。

Targetedは特定のURIなどターゲットを絞った攻撃を行うBotに対して有効なルールです。Commonに含まれるようなシグネチャベースのルールに加え、機械学習分析を使用したアノマリベースのルールも含まれています。

また、Bot ControlにはBotのトラフィックをモニタリング可能な専用のダッシュボードも用意されています。

より詳しい情報は以下の開発者ガイドをご参照ください。

アカウント作成詐欺防止

正式名称は、AWS WAF Fraud Control Account Creation Fraud Prevention (ACFP)で、去年発表された比較的新しい機能です。

近年、アカウント登録機能を持ったWebアプリケーションにおいて1人の攻撃者がアカウントを不正に大量作成するといった行動が見られています。そして攻撃者はそれらをアカウントを利用し、なりすましやフィッシングなどのサイバー攻撃を行います。

このACFPは機械学習を利用し、不正なアカウント作成を行なっている疑いのあるリクエストを検出、ブロックしてくれます。こちらもBot Control同様、用意されているルールを有効化するだけで利用可能です。

より詳しい情報は以下の開発者ガイドをご参照ください。

アカウントの乗っ取り詐欺の防止

こちらも同じく去年発表された機能で、正式名称はAWS WAF Fraud Control account takeover prevention (ATP)です。

上記は作成詐欺防止でしたが、こちらは既に作成されているアカウントに対する乗っ取りを防止するための機能です。

攻撃者が個人のアカウントへ不正アクセスし、認証情報を盗もうとしている場合、そのような乗っ取り行為とみられる不審なリクエストを本ルールで検知することが出来ます。こちらも基本的には用意されているルールを有効化するだけで利用可能です。

より詳しい情報は以下の開発者ガイドをご参照ください。

AWS WAFにおけるリソース

AWS WAFには主に下記3つのリソースが存在します。

• Web ACL
• ルールグループ
• ルール

それぞれのイメージが分かるように、私の中のイメージを図にしてみました。あくまで簡単にリソースの関連についてのイメージを掴むための図なので、グローバルやリージョナルなど表現しきれていない箇所があることはご了承ください。

それでは、各リソースの紹介をします。

Web ACL

実はこのWeb ACLというリソースがAWS WAFにおけるWAFそのものです。

ユーザーはこのWeb ACLというリソースを作成し、そこに任意のルールやルールグループを追加していきます。

Web ACLにルールを追加する際、気を付けなければならないのがWCU（Web ACL Capacity Unit）と呼ばれるルール容量です。Web ACLにはWCUと呼ばれるルールの容量が存在し、1,500 WCU以内であれば追加料金不要で利用することが出来ますが、そこを越えてしまうと追加料金が発生します。WCUの上限は5,000です。WCUはルール、ルールグループごとに決まっているため、総WCU量を意識しながらルールを組み合わせましょう。

また、Web ACLは複数作成することが可能です。1つのWeb ACLを保護したい複数のAWSリソースに関連付けることが出来ます。

より詳しくWeb ACLのことを知りたい方は以下の開発者ガイドをご参照ください。

ルールグループ

ルールグループとは、簡単に言うとルールの集合体です。

作成後はWeb ACLに追加する形で利用可能で、Web ACLとは独立した存在なのでWeb ACLを削除してもルールグループは再利用可能です。複数のWeb ACLに追加することも可能です。

ルールグループは以下の2つに大別されます。

• マネージドルールグループ
• 独自のルールグループ

それぞれのルールグループについてご紹介します。

マネージドルールグループ

マネージドルールグループとは、その名の通りAWSもしくはサードパーティー企業によって管理されているルールのセットです。マネージドなルールセットなので、ルールの更新は自動で行われます。つまり、ユーザーは特に意識することなく常に最新の脅威に対応したルールを利用することが可能です。

そんなマネージドルールグループは大きく以下の2つに分けられます。

• AWSマネージドルールグループ
  • AWSが管理するルールグループ
  • Bot Controlやアカウント不正利用などの一部ルールグループを除き、基本的に無料で利用可能
• AWS Marketplace マネージドルールグループ
  • AWS以外のサードパーティ企業が管理するルールグループ
  • OWASP Top10に対応するものなど、様々なユースケースに想定したものが用意されており、有料（従量課金）で利用可能

さらに、AWSマネージドなルールグループは以下の通りです。

• ベースラインのルールグループ
  • AWSManagedRulesCommonRuleSet (WCU: 700)
    • SSRFやXSS、ファイルインクルージョンなど一般的なWebアプリケーションに対する攻撃を緩和するルールセット
    • 必要なWCUは大きいが、その分含まれているルールは多い
  • AWSManagedRulesAdminProtectionRuleSet (WCU: 100)
    • 公開されているWebアプリケーションの管理者専用ページへの外部アクセスをブロックするルールセット
    • WordPressなど管理者ページが存在するWebアプリケーションを運用する場合には導入を検討すると良い
  • AWSManagedRulesKnownBadInputsRuleSet (WCU: 200)
    • 悪用されたことのある脆弱性を突いた攻撃など、既知の不正な入力に対するルールセット
    • 2021年に世間を騒がせたLog4jのRCE脆弱性(CVE-2021-44228、CVE-2021-45046、CVE-2021-45105)のルールもここに含まれている
• ユースケース固有のルールグループ
  • AWSManagedRulesSQLiRuleSet (WCU: 200)
    • SQLインジェクション攻撃を緩和するルールセット
    • 過信は禁物だが、WCUも少なく非常に有用なルールグループ
  • AWSManagedRulesLinuxRuleSet (WCU: 200)
    • Linux OSに対する攻撃を緩和するルールセット
    • このルールグループは後述の AWSManagedRulesUnixRuleSet と組み合わせて利用する必要がある
  • AWSManagedRulesUnixRuleSet (WCU: 100)
    • POSIX OSに対する攻撃を緩和するルールセット
  • AWSManagedRulesWindowsRuleSet (WCU: 200)
    • PowerShellコマンドのリモート実行など、Windows OS固有の脆弱性を悪用する攻撃を緩和するルールセット
  • AWSManagedRulesPHPRuleSet (WCU: 100)
    • PHP固有の脆弱性を悪用する攻撃を緩和するルールセット
  • AWSManagedRulesWordPressRuleSet (WCU: 100)
    • WordPress固有の脆弱性を悪用する攻撃を緩和するルールセット
    • 先述の AWSManagedRulesSQLiRuleSet と AWSManagedRulesPHPRuleSet と組み合わせて利用する必要がある
• IP評価のルールグループ
  • AWSManagedRulesAmazonIpReputationList (WCU: 25)
    • Amazonの内部脅威インテリジェンスで悪意のあるアクターだと評価されているIPアドレスからのリクエストを緩和するルールセット
    • WCUも少なく、基本的には有効化しておくと良い
  • AWSManagedRulesAnonymousIpList (WCU: 25)
    • Torノードや一時的なプロキシなど、クライアント情報を匿名化したリクエストを送ってくる既知のIPアドレスなどからのリクエストをブロックするルールセット
    • こちらも基本的には有効化しておくと良い
• アカウント作成詐欺防止のルールグループ
  • AWSManagedRulesACFPRuleSet (WCU: 50)
    • 不正なアカウント作成の試みを行うリクエストを緩和するルールセット
    • 利用には別途料金が必要
• アカウント乗っ取り防止のルールグループ
  • AWSManagedRulesATPRuleSet (WCU: 50)
    • 悪意のあるアカウント乗っ取りを試みるリクエストを緩和するルールセット
    • 利用には別途料金が必要
• Bot Controlのルールグループ
  • AWSManagedRulesBotControlRuleSet (WCU: 50)
    • 悪意あるBotからのリクエストを緩和するルールセット
    • 保護レベルを Common と Targeted から選択可能
      • Common : 基本的なシグネチャベースのルールのみ
      • Targeted : Commonのルールに加え、機械学習を用いたアノマリベースのルールによってより高度なBotからのリクエストを緩和可能

各ルールグループの開発者ドキュメントには含まれるルールが記載されています。より詳細にルールグループを知りたい方は各ルールグループのリンク先をご参照ください。

独自のルールグループ

一方、ユーザーが任意のルールを作成することも出来ます。

ユーザーが作成するルールグループは独自のルールグループと呼ばれ、任意のルールを作成/追加することが出来ます。

独自のルールグループにはWCUを固定値として指定することが出来、ユーザーはそのWCUを越えないようにルールを作成して追加する必要があります。

どのようなルールを作成することが出来るのかについては後述します。

独自のルールグループについて作成方法や編集方法など、より詳しく知りたい方は以下の開発者ガイドをご参照ください。

以上、ルールグループの紹介でした。

ルールグループについてより詳しく知りたい方は以下の開発者ガイドをご参照ください。

また、ここでは紹介しませんでしたが、AWS Firewall ManagerやAWS Shield Advancedなど他のAWSサービスによって提供されるルールグループも存在します。詳しくは以下の開発者ガイドをご参照ください。

ルール

ここまでWeb ACLとルールグループについて話してきました。ルールとは、それらの中に含まれるリソースで、リクエストを評価するリソースそのものです。

ユーザーがルールを作成する上で、どういう評価条件を作れるのか、評価後にどのようなアクションを選択出来るのか、以下のコンポーネントについてご紹介します。

• ルールタイプ
• ルールステートメント
• ルールアクション

ルールタイプ

ルールのタイプとしては、主に以下の2つが選択出来ます。

• IP Set
• Rule Builder
  • Regular rule
  • Rate-based rule

IP Setでは、事前に作成したIPリストを利用し、そのIPアドレスから送られてきたリクエストやそのIPアドレスをヘッダーに含むリクエストを判定することが出来ます。判定後のアクションは任意で選択可能です。

Rule Builderはその他のルール作成のタイプです。IPアドレスで制御するルール以外を作成したい場合はこちらを選択し、任意のルールを作成することになります。

Rule Builderの中にRate-based ruleと呼ばれるルールタイプがあります。このタイプを利用することでレートベースのルールを作成することが出来ます。

レートベースルールは2024年のアップデートで評価期間が最短1分になりました。これにより、ある条件を満たすリクエストが1分間に指定した閾値以上来たときに任意のアクションを取ることが出来ます。また、任意のルールと組み合わせることも可能です。

レートベースの評価期間は現在下記の4段階から選択可能です。

• 1分
• 2分
• 5分
• 10分

ルールステートメント

ルール内で条件を作成するために利用するコンポーネントのことをルールステートメントと呼びます。

作成する各判定条件を繋ぐために利用する論理演算子 AND, NOT, OR は論理ステートメントと呼ばれ、条件作成に利用するものは一致ルールステートメントと呼ばれます。

以下は一致ステートメントをまとめたものです。

• 地理的一致
  • 検査対象のリクエストがどこの国から来たか判定
• IPセット一致
  • 検査対象のリクエストがどのIPアドレスから来たか判定
• ラベル一致
  • マネージドルールによって付与されたラベルをもとに判定
• 正規表現一致
  • リクエストコンポーネントを指定した正規表現文字列で判定
• 正規表現パターンセット
  • リクエストコンポーネントを事前に作成した正規表現のセットで判定
• サイズ制約
  • リクエストコンポーネントと指定したバイト数を比較して判定
• SQLi攻撃
  • ボディーやヘッダーなど特定のリクエストコンポーネントにSQLiの可能性がある文字列が含まれているかどうかを判定
• 文字列一致
  • リクエストコンポーネントに指定した文字列が含まれているか判定
• XSS攻撃
  • ボディーやヘッダーなど特定のリクエストコンポーネントにXSSの可能性がある文字列が含まれているかどうかを判定

地理的一致では既に用意されている国コードからリクエストを送った国を判定することが可能です。IPセット一致は先述のIP Setルールタイプと同じものです。

これらのルールステートメントにはそれぞれWCUが定められていて、それらの合計値がそのルールのWCUとなります。

ルールアクション

作成した評価条件の後、以下のアクションを行うようにルールを設定することが出来ます。

• Allow
  • リクエストをそのまま保護対象のAWSリソースに通します
• Block
  • リクエストをブロックします
  • デフォルトではHTTPステータスコード 403 を返しますが、任意のカスタムレスポンスを設定することも可能です
• Count
  • リクエストをカウントし、そのまま処理を継続します
• CAPTCHA および Challenge
  • CAPTCHAパズルやサイレントチャレンジなど、リクエストがBotから送信されていないことを確認するために利用します
  • CAPTCHAとChallengeの詳細については 開発者ガイド をご参照ください。

AWS WAFのダッシュボード

AWS WAFのダッシュボードは2023年〜2024年にかけて大幅にアップデートされました。

新しいダッシュボードの詳細については下記ブログをご参照ください。

また、2024年の3月にAWS公式による新しくなったAWS WAFダッシュボードの紹介ブログも投稿されました。こちらも併せてご参照ください。

AWS WAFの料金

AWS WAFの基本的な料金（東京リージョン）は以下の通りです。

上記の月額料金は、実際には利用した時間ごとに比例配分される従量課金制です。

リクエストの料金はWCUが1500を超えている場合500WCUごとに、100万リクエストあたり $0.20 の追加料金が発生します。さらに本文検査制限を超えるリクエストについても16KBごとに、100万リクエストあたり $0.30 の追加料金が発生します。

そして上記に追加で、サードパーティ製のマネージドルールやAWSマネージドなBot Control、アカウント不正利用対策ルールに応じた料金が発生します。

また、CAPTCHAとChallengeのルールアクションの利用にも以下の料金が発生します。

料金の詳細は以下のサービスドキュメントをご参照ください。

AWS WAFリソースのクォータ

AWS WAFのクォータは引き上げ可能なデフォルトクォータと引き上げ不可能な固定のクォータが存在します。

それぞれ1アカウント、1リージョンごとに定められたもので、リージョンを跨いで各クォータは累積されません。

引き上げ可能なデフォルトクォータ

引き上げ不可能な固定のクォータ

上記の各図は以下の開発者ドキュメントから引用しています。APIのクォータなど、より詳細な情報は下記ドキュメントをご参照ください。

終わりに

以上、『AWS 入門ブログリレー 2024』の1日目のエントリ『AWS WAF』編でした。 次回、3/26は弊社木村優太 による「CloudWatch Synthetics編」の予定です！