今からすぐ使えるファイアウォール自動化ソリューション
「AWS WAF セキュリティオートメーション」を試してみる
岡本 真樹
みなさん、こんにちは。ソリューションアーキテクトの岡本真樹です。
皆さんは「AWS ソリューションライブラリ」いうページがあるのをご存知でしょうか ?
このAWSソリューションライブラリの中には、すぐにお客様の課題に対応できるよう導入までの手順や AWS CloudFormation のテンプレート等を含めた AWS ソリューション実装 というリファレンスとなる実装パターンが多数掲載されています。
今回はこの中から、セキュリティにフォーカスを当てて、AWS WAF (ウェブアプリケーションファイアウォール) に関するソリューションのご紹介をします。
セキュリティの運用では、設定を行ってあとは稼働中にトラブルがない限り放っておくということは望ましくないことです。特にウェブアプリケーションの防御では、設定は行ったものの運用ができずに放置されてしまうケースが多いので「最初に WAF のルールセットをどう選択したらいいの ?」という質問をよく伺います。さらに運用の視点で「不正なアクセスをするサイトに対する IP ブロックリストを継続的に管理する負担が・・・」というコメントもご担当者の方からよく伺います。
今回、ご紹介する「AWS WAF セキュリティオートメーション」は、セキュリティ担当者の負担を減らしながら脅威に対応できる自動化 (オートメーション) の仕組みを AWS WAF とともに実装できるソリューションです。
それでは、「AWS WAF セキュリティオートメーション」がどんなソリューションなのか見ていきましょう。
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
この記事のデモを無料でお試しいただけます »
毎月提供されるデベロッパー向けアップデート情報とともに、クレジットコードを受け取ることができます。
「AWS WAF セキュリティオートメーション」ソリューションとは ?
今回紹介するソリューションは「AWS WAF セキュリティオートメーション」という一般的なウェブベースの攻撃をフィルタリングするための AWS WAF のルールを自動的に適用するものです。
このソリューションでは、通常の基本的なマネージドのルールセットに加えて、ウェブサイトを保護するルールを動的に追加していく仕組みを導入できます。
具体的には、AWS WAF に対して、次の 2 つのカテゴリのルールセットを設定していくことが可能です。
クロスサイトスクリプト (XSS) 攻撃のようなウェブアプリケーション特有の攻撃手法に対するルールセット
Amazon Athena や AWS Lambda と連携させたアクセスログに基づく動的に作成される IP ブロックリスト
このソリューションで全てのルールセットを使用した場合、こちらのようなルールセットがデプロイされます。
そして、このルールセット (WebACLs) を Amazon CloudFront や Elastic Load Balancing の ALB (Application Load Balancer) にアタッチすることで、ウェブアプリケーションに対する攻撃に対する防御を行い、アプリケーションの可用性とリソースの安全性を確保し、過剰なリソースの消費を防ぐことができます。
使用している AWS サービスは ?
本ソリューションの中核となるのは、AWS WAF です。
Amazon CloudFront または Application Load Balancer (ALB) に対してこのソリューションを実装した AWS WAF を適用することにより、背後にあるウェブアプリケーションを保護します。
この環境を実装するための AWS CloudFormation を実行する際に、適用するルールセットをパラメータとして選択します。
選択されたルールセットに応じて、ルールセットの内容を動的に変更していくための AWS サービスが展開されます。
アーキテクチャ図で左側に書かれている AWS WAF のルールセットとして、「A」から「E」は AWS WAF のルールとなります。
| AWS マネージドルール (A) | ウェブアプリケーションに対する一般的な脅威に対するブロックを行います。 *参考 : 「AWS WAF 用 AWS Managed Rules の発表」(ブログ) |
| 手動 IP リスト (B および C) |
アクセスをブロックまたは、許可するリストを設定します。このIPの追加は AWS WAF のコンソールより手動で実施します。 *参考 : 「IP セットルール」 (開発者ガイド) |
| SQL インジェクション (D) および XSS (クロスサイトスクリプト) (E) |
URI、クエリ文字列、リクエストボディ内の一般的な SQL インジェクションや XSS 攻撃のパターンから保護するためのルールを適用します。 *参考 : |
それ以降の「F」から「I」として生成されるルールは、このソリューションで動的に構成される IP のブロックリストです。
| HTTP フラッド (F) | ウェブアプリケーションに対する DDoS 攻撃や総当たりのログインの試行など、特定の IP アドレスからの大量のリクエストで構成される攻撃から保護するのに役立ちます。 Amazon S3 に保存されたアクセスログを Athena または、AWS Lambda によって処理を行いブロックするIPアドレスをリストに追記します。これ以外にも、AWS WAF のもつ「レートベースのルール」を選択することも可能です。ログの処理のためのサービスまたはレートベースのルール機能の選択についてはデプロイ方法のなかで記載します。 |
| スキャナーとプローブ (G) | アプリケーションアクセスログを解析して、異常な量のエラーなどの疑わしい動作を検出します。 Amazon S3 に保存されたアクセスログを Amazon Athena または、Lambda によって処理を行いブロックする IP アドレスをリストに追記します。ログの処理のためのサービスの選択についてはデプロイ方法のなかで記載します。 |
| IP 評価リスト (H) | デプロイされた Lambda が、Amazon CloudWatch Event により 1 時間毎に起動されてサードパーティ (spamhaus、torproject および、emergeingthreats) の IP 評価リストを入手し、IPv4 と IPv6 のアドレスのブロックリストを作成します。 このソリューションではこのような実装になっていますが、加えて現在の AWS WAF のマネージドルール機能があるので「Amazon IP 評価リスト」を使用することも可能です。 |
| 悪意のあるボット (I) | 攻撃をおびき寄せることを目的としたセキュリティメカニズムであるハニーポットにアクセスした IP アドレスのブロックを行います。ウェブアプリケーションに対して URL を埋め込み、ボットがこの URL へのアクセスを試みたときに、Amazon API Gateway から Lambda を起動し、不正なボットとみなした送信元 IP アドレスをこのルールセットに追記します。 このソリューションではこのような実装になっていますが、加えての AWS WAF の「AWS WAF Bot Control (ブログ)」の機能があるのでこちらを使用することも可能です。 |
コスト試算の例
このソリューションを実行することにより発生する AWS サービスのコストは、適用するルールセットおよびトラフィックのパターンにより異なります。詳細については、このソリューションで使用する AWS の各サービスの料金表ウェブページを参照してください。
デプロイ時に「HTTP フラッド (F)」と「スキャナーとプローブ (G)」については、いくつかの実装パターンを選択することが可能です。
参考として、Amazon Athena Log Parser とともに使用すると、Athena の使用料金が課金されます。デフォルトでは、各 Athena クエリは 5 分ごとに実行され、過去 4 時間のデータをスキャンします。スキャンするデータの量は、アクセス数にもとづくログの量に依存します。120 万回 / 日のアクセスがウェブサーバーにあると想定した場合、5 分ごとの Athena クエリが 1 ヶ月実施されると 288 回 x 30 日のスキャンとなるため、月額コストの見積もりは、およそ
0.0005 USD x 288 回 x 30 日 = 4.32 USD となります。
デプロイ方法 / 設定方法
このソリューションの設定はオプションを含めて、全部で 5 つのステップがあります。
この作業を行う前には、CloudFront または ALB でデプロイされたウェブアプリケーションの環境があることが前提となります。この環境に対して、以下の一連のステップで AWS WAF およびルールに対応するサービスの連携のソリューションをデプロイしていきます。
以下は、すでに実装されている ALB に対して、ソリューションを適用していきます。
ステップ 1 : CloudFormation スタックの作成
本ソリューションで使用する CloudFormation テンプレートを実行するために、こちらのランディングページ にアクセスします。
AWS コンソールで起動する を選択します。
CloudFormation が起動されて、スタックの作成の画面になります。
このソリューションの実装では、リージョンとして 東京 を選択することが可能です。
「前提条件 - テンプレートの準備」、「テンプレートの指定」は変更せずにそのまま 次へ を選択します。
クリックすると拡大します
「スタックの名前」に任意の名前を入力し、「パラメータ」を指定します。
クリックすると拡大します
.Protection List セクションで適用するルールを選択します。
これらのすべてのルールを「Yes」で選択した場合、AWS WAF ウェブ ACL キャパシティーユニット の値は、 1072/1500 となります。
Protection List セクションで適用するルールは以下の通りです。
Activate Protection Managed Rules Protection : |
「AWS マネージドルール (A)」がデプロイされます。 |
Activate SQL Injection Protection |
「SQL インジェクション (D) 」がデプロイされます。 |
Activate Cross-site Scripting Protection |
「XSS（クロスサイトスクリプト） (E)」がデプロイされます。 |
Activate HTTP Flood Protection |
「HTTP フラッド (F)」がデプロイされます。 このパラメータは 3 つの実装のオプションから選択することが可能です。 |
Activate Scanner & Prove Protection |
「スキャナーとプローブ (G)」がデプロイされます。 パラメータは 2 つの実装のオプションから選択することが可能です。 |
Activate Reputation List Protection |
「IP 評価リスト (H)」がデプロイされます |
Activate Bad Bot Protection |
「悪意のあるボット (I)」がデプロイされます。 |
クリックすると拡大します
Activate HTTP Flood Protection の機能については、以下の表をご参照ください。
「Amazon Athena Log Parser」および「AWS Lamdba Log Parser」は、このソリューションで実装されるログを処理するためのコンポーネントとなります。
| パラメータ （実装パターン） |
AWS WAF レートベースルール |
Amazon Athena Log Parser | AWS Log Lambda Parser |
| 機能 | AWS WAF のレートベースのルールが設定されます。 クライアント IP からの 5 分間に許可する連続的なリクエストの数を指定できます。リクエストレートが閾値を下回るまで、新しいリクエストをブロックします。 米国東部 (バージニア北部) リージョン以外を選択し、CloudFront に対してこのソリューションをデプロイする場合は、このパラメータ選択する必要があります。 |
AWS WAF のログを取り込み処理を行う、Amazon Athena クエリと Lambda 関数が設定されます。 Lambda 関数は CloudWatch Event により 5 分ごとに実行されます。実行のスケジュールはパラメータで調整を行うことが可能です。 また、Athena のデフォルトのクエリを変更することも可能です。実装ガイドの付録 D: Amazon Athena クエリのセクション で変更方法を確認してください。 |
Lambda が設定されます。 Amazon S3 に保存されたファイルを解析します。処理を実施している時点のファイルのコンテキスト内の情報のみで判定します。 |
Activate Scanner & Prove Protection の機能については、以下の表をご参照ください。
| パラメータ （実装パターン） |
Amazon Athena Log Parser | AWS Log Lambda Parser |
| 機能 | ウェブアプリケーションリソース (CloudFront または ALB) のログを取り込み処理を行う Amazon Athena クエリと Lambda 関数が設定されます。 Lambda 関数は CloudWatch Event により 5 分ごとに実行されます。実行のスケジュールはパラメータで調整を行うことが可能です。 また、Athena のデフォルトのクエリを変更することも可能です。 実装ガイドの付録 D: Amazon Athena クエリのセクション で変更方法を確認してください。 |
Lambda が設定されます。 Amazon S3 に保存されたファイルを解析します。処理を実施している時点のファイルのコンテキスト内の情報のみで判定します。 |
Log Monitoring Settings の設定をします。
こちらの例は、「スキャナーとプローブ (G)」および「HTTP フラッド (F)」を設定した場合の、各種しきい値 (最大許容リクエスト数やブロックする期間等) となります。
Endpoint Type |
使用するリソースのタイプ (CloudFront もしくは ALB) を設定します。 必ず設定先のリソースに合わせて変更してください。今回の記事の例では「ALB」を選択しています。 |
| Application Access Log Bucket Name | 「スキャナーとプローブ (G)」(Activate Scanners and Probe Protection) を利用する場合には、CloudFront または ALB のアクセスログを保存するための Amazon S3 のバケットの名前を設定します。 CloudFormation テンプレートをデプロイしているのと同じ AWS リージョンにある必要があります。 |
クリックすると拡大します
IP Retention Settings についても必要に応じて設定を行います。
「スタックオプションの設定」、「詳細オプション」は変更せずに 次へ を選択します。
レビューを下へスクロールし、IAM リソースのカスタム名での作成の項目と、CAPABILITY_AUTO_EXPAND の機能要求に関する項目にチェックを入れ、スタックの作成 を選択します。
クリックすると拡大します
ステップ 2 : 許可セットと拒否セットを変更する (オプション)
CloudFormation のスタックとしてデプロイされた AWS WAF のコンソールで、必要に応じて IP アドレスを手動で設定することができます。
こちらの 4 つの許可または拒否の IP セットに対して、設定が可能です。
クリックすると拡大します
それぞれの IP セットの中で、Add IP Address のボタンより、IP アドレスとサブネットを指定して追加します。
クリックすると拡大します
ステップ 3 : ウェブアプリケーションにハニーポットリンクを埋め込む (オプション)
ステップ 1 で「悪意のあるボット (I)」を有効にした場合、自らのウェブサイトのコンテンツにハニーポットの URL を埋め込むことにより不正なボットからのリクエストを検出することが可能です。
ステップ 1 の CloudFormation スタックで実装された CloudFront 上のエンドポイントを活用し、この仕組みを動作させます。作業は、AWS WAF の連携を CloudFront にした場合と、ALB にした場合で異なります。くわしくは 実装ガイド のセクション (20ページ) を参考に、本番稼働サイトのウェブコンテンツ側への URL の埋め込み作業を行なってください。
以下は、ALB に実装する場合です。
ステップ 1 で構築した CloudFormation スタックを開き、出力タブを選択します。
出力 の中から、BadBotHoneypotEndopint キーの URL をコピーします。
クリックすると拡大します
このエンドポイントリンクをウェブコンテンツに埋め込みます。このリンクは、style 属性を非表示に設定して人が直接アクセスしないようにします。”nofollow” の設定については、実装ガイド の 22 ページに注意事項が記載されていますので、実装時に確認してください。
<HTML>
<a href="https://XXXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/ProdStage" rel="nofollow" style="display: none" aria-hidden="true">ハニーポットリンク</a>
</HTML>ステップ 4 : ウェブ ACL をウェブアプリケーションに関連づける
AWS WAF コンソールから使用する Web ACL をリージョンを選択して、Rules タブで「Add Association」からエンドポイントを指定します。
今回は、ALB に対して関連づけを行います。
クリックすると拡大します
ステップ 5 : ウェブのアクセスログ記録を設定する
ウェブのアクセスログを保存する Amazon S3 の指定を行います。
作業は、AWS WAF の連携を CloudFront に行った場合と、ALB に行った場合で異なります。
ALB の場合は、コンソールで EC2 を開きナビゲーションペインで「ロードバランサー」を選択します。
AWS WAF が関連づけられている Application Load Balancer を選択し、「アクション」から「属性の編集」を選択します。
このなかで、アクセスログを有効化し、ステップ 1 でパラメータとして指定した S3 バケット名を入力します。
クリックすると拡大します
動作の確認
このソリューションのデプロイをステップ 5 まで実施したら、AWS WAF によりアクセスの制御が実行されています。運用の際は AWS WAF のメトリクスをダッシュボード等で日々チェックをしていきます。
実装ガイド には動作の確認方法は記載されていませんが、次のような方法で特定の IP アドレスに対するブロックが開始されることを確認ができます。
今回、AWS WAF の通常のルールセット以外に、このソリューションでデプロイされたルールセットに対する確認のポイントを記載します。
悪意のあるボット (I) (Bad Bot Protection) の確認
ボットの動作を人的に試すために、ステップ 3 の作業でウェブアプリケーションに直接埋め込んだ URL をブラウザで直接アクセスします。これにより、AWS WAF の BadBot の IPv4 ブロックリストに反映される状況を確認することが可能です。
ブラウザで Step3 でウェブアプリケーションに埋め込んだ URL に直接アクセスします。
クリックすると拡大します
サイトへのアクセス後、AWS WAF の Web ACLs のルールセットにアクセスした IP アドレスが反映されていることが確認されます。
クリックすると拡大します
元のサイトへのアクセスはすべて AWS WAF により Error Code 403 で拒否されます。
AWS WAF の BadBot に関する Blocked のメトリクスについてもカウントされます。
クリックすると拡大します
HTTP フラッド (F) (HTTP Flood Protection) の確認
このルールでは、同一の IP アドレスから一定時間閾値を超えたアクセスが実施されるとブロックリストに追加されます。そのため、ウェブアプリケーションへアクセスを行う各種テスターを活用することにより確認が可能です。
例えば、builders.flash で以前紹介した「大規模な負荷テストを実行可能。「Distributed Load Testing on AWS」 を試してみる」を参考に、Load Tester を実装すると、ウェブアプリケーションに対して特定の IP アドレスからのアクセスを一時的に集中させることで、アクセスの状況が「Allowed」から「Blocked」に変わる状況を確認できます。
IP 評価リスト (H) (IP Reputation List Protection) の確認
ここではブロックの状況を確認することはできませんが、AWS WAF の IP Sets の中の IPReputationslists のルールセットをみると Blocked のアドレスが反映されていることを確認できます。
こちらの例では、2699 の IPv4 アドレスがブロック対象のアドレスとして登録されています。
クリックすると拡大します
リソースの削除方法
CloudFormation から、このソリューションの親スタックを選択して削除します。ネストされたスタックも自動的に削除されます。これにより、 このソリューションで使用されている AWS リソースが、S3 バケットを除きすべて削除されます。
手動で削除すべき S3 バケットは 2 つあります。
ステップ 1 で Application Access Log 用に設定した S3 バケットは、不要な場合は削除してください。
あわせて、CloudFormation のスタックが自動的に作成した AccessLoggingBacket も手動で削除が必要となります。
以下に自動的に作成された S3 バケットとスタックの削除の方法を記載します。
まず、コンソールの CloudFormation の中で、スタックの削除の前に AccessLoggingBacket として作成されている S3 バケットの名前を CloudFormation スタックのリソースの部分で確認しておきます。
クリックすると拡大します
S3 バケットの名前を確認した後、スタックの削除 をクリックします。
クリックすると拡大します
AWS WAF API の制限が原因で、レート超過のスロットリングの問題により一部の IP セットが削除されない場合は、それらの IP セットを手動で削除してから、あらためてスタックを削除します。
その後、コンソールの Amazon S3 の中で、事前に確認した S3 バケットの名前を検索して、その S3 バケットを削除します。
クリックすると拡大します
まとめ
いかがでしたでしょうか。「AWS WAF セキュリティオートメーション」ソリューションにより、ウェブアプリケーションおよびセキュリティの管理者の方はアクセスの状況に基づき不審なアクセスを排除する環境を AWS WAF を用いて簡単に構築することができます。
実環境の運用に関しては CloudWatch のメトリクスやログの情報によりブロックの状況のモニタリングを行っていきます。ウェブ ACL のテスト として、ウェブのルールのアクションを一旦「カウント」に設定しウェブリクエストの正しい傍受ができたことを確認した後に、改めて「ブロック」にしてルールの適用を行うことができます。このような形でテストを行いながら誤検知を避けて運用していくことをおすすめいたします。
ぜひ、AWS WAF の活用のひとつのパターンとしてご検討ください。
筆者プロフィール
岡本 真樹
アマゾン ウェブ サービス ジャパン合同会社
シニアソリューションアーキテクト
ソリューションアーキテクトして、中央官庁のお客様を中心に様々なお客様を支援させて頂いております。ネットワークとセキュリティの経験を踏まえて、今後はクラウドの大きな可能性を感じています。そのクラウド活用し世の中がより便利になるようにと思い日々働いています。好きなサービスは AWS Direct Connect と AWS Security Hub です。
プライベートでは、週末に市民オーケストラでティンパニ奏者としてコンサートにむけて練習を楽しんでいます。
AWS を無料でお試しいただけます