AWS WAF セキュリティーオートメーションがWAFv2で利用できるようになりました

2020年7月9日のアップデートで、AWS WAF セキュリティーオートメーションがWAFv2 APIをサポートするようになりました。

aws.amazon.com

1. AWS WAF Security Automationsとは

AWSには、AWS WAFというWebアプリケーションファイアウォールのサービスがあります。 AWS WAF セキュリティーオートメーションは、そのAWS WAFの設定を自動化、運用の自動化を手助けしてくれるソリューションです。実体としては、CloudFormationテンプレートとしてAWSから提供されています。

2.AWS WAFの構築方法の推移

AWS WAFは2015年から提供されたサービスですが、なんのテンプレートもなく作成する場合、例えばHTTPヘッダのXXをチェックして〜といったようなルールを多数書く必要があります。この作業は技術的にも心理的にもハードルが高い印象がありました。

2017年〜2019年の状況

2017年になり、AWSから2つのCloudFormationテンプレートが提供されました。それらを利用すると簡単にAWS WAFのレッスンを設定できるようになりました。また、マネージドルールがF5やFortinetなどのセキュリティベンダーから提供され、マーケットプレイスから購入し機能をオンにするだけですぐに使えるようになりました。

一部カスタマイズが必要な場合もありますが、基本的には以下のいずれかをベースにして利用したパターンが多かったのではと思います。

方法1. 3rdパーティー提供のAWS WAFマネージドルールを利用
方法2. セキュリティーオートメーションのテンプレートを利用
方法3. OWASP TOP 10のテンプレートを利用

その後、OWASP TOP 10のテンプレートでは更新ありませんが、セキュリティーオートメーションのテンプレートは時々更新されています。本ブログでも何度か記事を書いています。

なお、2017年当初のセキュリティオートメーションは以下のような構成でした。

AWS Black Belt Online Seminar 2017 AWS WAF from Amazon Web Services Japan

2020年〜

現在はAWS純正のマネージドルールができました。また、WafCharmというサービスがCSC社から提供されていて、マネージドルールと同等レベルのルールを設定し、運用サポートもついてきます。

したがって、下記いずれか、または組み合わせて使うという選択になると思います。

方法1. AWS提供のAWS WAFマネージドルールを利用
方法2. 3rdパーティー提供のAWS WAFマネージドルールを利用
方法3. セキュリティーオートメーションのテンプレートを利用
方法4. WafCharmを利用

3. AWS WAF Security Automations 3.0

さて、セキュリティーオートメーションの話に戻ります。

今回はバージョンが3.0に上がりました。 AWS WAFv2へ対応した、メジャーバージョンアップです。

3-1. アップデート箇所

AWS WAFv2に対応
AWSマネージドルールを自動的にデプロイするオプションの追加
NodeJSへの依存を排除。コードをPython 3.8に更新
トラフィック（RPS）が高すぎる場合のAPIコールスロットリングの問題を解決
CFNスタックによって行われるレート制限チェックを2000から100に下げました
WAF、CloudFront、およびApplication Load Balancerアクセスログ用のAthenaデータベースパーティションを追加
ワークロードをAthenaワークグループに分割

3-2. 3.0の構成

AWS Documentation > AWS Solutions > AWS WAF Security Automations

2017年のものと大体同じですが、AWS Managed RulesやAthenaやKinesis Data Firehoseが加わっています。また、S3バケットやLambdaの数も増えてます。

4. 設定してみる

基本的にAWS WAF セキュリティオートメーションのページから辿っていけば、設定方法はわかるようになっています。（ただ、2020年7月11日現在では、日本語ページでは3.0は記載がないので、英語ページを確認します。）

4-1. Launch in the AWS Console

AWS WAF Security AutomationsとAWS WAF Security Automations for AWS Classicの２種類があります。 WAFv2でセキュリティオートメーションを使いたい場合は前者を選択します。

4-2. CloudFormationスタックの作成

4-3. CloudFormationスタックのパラメータを入力

スタックの名前

設定項目	設定値	説明
スタックの名前	AWSWAFSecurityAutomations	任意の名前。WebACL名、ルール名のプリフィックスにも使われる

Protection List

設定項目	選択できる設定値	説明
Activate AWS Managed Rules Protection	no
Activate AWS Managed Rules Protection	yes	AWSManagedRulesCommonRuleSetを有効
Activate SQL Injection Protection	yes	一般的なSQLインジェクション攻撃をブロックするコンポーネントが有効
Activate SQL Injection Protection	no
Activate Cross-site Scripting Protection	yes	一般的なXSS攻撃をブロックするコンポーネントが有効
Activate Cross-site Scripting Protection	no
Activate HTTP Flood Protection	yes - AWS WAF rate based rule	HTTPフラッド攻撃をブロックするコンポーネントとしてAWS WAFレートベースルールを有効
	yes - AWS Lambda log parser	HTTPフラッド攻撃をブロックするコンポーネントとしてLambda log parserを有効
	yes - Amazon Athena log parser	HTTPフラッド攻撃をブロックするコンポーネントとしてAthena log parserを有効
	no
Activate Scanner & Probe Protection	yes - AWS Lambda log parser	スキャナーとプローブをブロックするコンポーネントとしてLambda log parserを有効
	yes - Amazon Athena log parser	スキャナーとプローブをブロックするコンポーネントとしてAthena log parserを有効
	no
Activate Reputation List Protection	yes	サードパーティのレピュテーションリスト（spamhaus、torproject、emingingthreats）にあるIPアドレスからのリクエストをブロック
Activate Reputation List Protection	no
Activate Bad Bot Protection	yes	不正なボットとコンテンツスクレイパーをブロックするコンポーネントを有効
Activate Bad Bot Protection	no

Settings

設定項目	選択できる設定値	説明
Endpoint Type	CloudFront	使用するリソースのタイプを選択
Endpoint Type	ALB	使用するリソースのタイプを選択
Application Access Log Bucket Name		Activate Scanner & Probe Protectionを有効にした場合は、CloudFrontまたはALBのアクセスログを保存するS3バケットの名前を入力

Advanced Settings

設定項目	選択できる設定値	説明
Error Threshold	50	Activate Scanner & Probe Protectionを有効にした場合は、IPごとの1分あたりの許容可能な不正リクエストの最大数を入力
Request Threshold	100	Activate HTTP Flood Protectionを有効にした場合は、IPアドレスごとに5分間あたりの最大許容要求を入力。AWS WAFレートベースのルールには100より大きい値が必要。（Lambda / Athenaログパーサーオプションを選択した場合、ゼロより大きい任意の値を使用可能）
WAF Block Period	240	Activate Scanner & Probe Protection、またはHTTP Flood Lambda / Athenaログパーサーが有効な場合は、ここで指定した期間（分）は、該当するIPアドレスをブロック
Keep Data in Original s3 location	No
Keep Data in Original s3 location	Yes	Activate Scanners＆Probes ProtectionでAmazon Athenaログパーサーを選択した場合、パーティショニングがログファイルとAthenaクエリに適用される。デフォルトでは、ログファイルは元の場所からs3のパーティション化されたフォルダー構造に移動する。このパラメータを有効にすると、ログのコピーを元の場所に保持。

4-4.WebACLの確認

パラメータ次第で多少変わりますが、以下のようなルールを持つWebACLが作成されます。

5. マネージドルールと重複する問題について

下記のようにAWSマネージドルールとセキュリティオートメーションの機能が重複しています。

機能	AWSマネージドルール	セキュリティオートメーション
クロスサイトスクリプティングからの保護	AWSManagedRulesCommonRuleSet	Activate Cross-site Scripting Protection
SQLインジェクションからの保護	AWSManagedRulesSQLiRuleSet	Activate SQL Injection Protection
不正IPリストをブロック	AWSManagedRulesAmazonIpReputationList AWSManagedRulesAnonymousIpList	Activate Reputation List Protection

どちらを利用したらいいのだろうかという疑問が湧きました。

基本的にはマネージドルールをメインで使い、マネージドルールに無い機能をセキュリティオートメーションからピックアップして使えばいいような気がしています。具体的には、以下の機能はマネージドルールにはありません。

HTTP Flood ProtectionのRequest Threshold
Scanner & Probe Protection

実はHTTP Flood ProtectionのRequest Thresholdに関しては、AWS WAFの標準機能としてレートベースでルールを記載すれば簡単に可能です。ただし、「レートベースのルールに対して定義できる最小リクエスト率」が100という制限があります。つまり、5分で100回同じIPアドレスからアクセスを受けたという条件は書けますが、5分で50回同じIPアドレスからアクセスを受けたという条件は書けません。もし細かい制御が必要であれば、セキュリティーオートメーションのログ解析機能を検討できそうです。