【更新中】AWS WAFのマネージドルールについてメモ
y_romuAWS WAFの仕組みがよく分からなかったため、調べた内容をメモとしてまとめていきます。
WAFのコストや、AWSが提供する無料のマネージドルールなどを中心に調べました。
WAFの仕組みについて
WAFを利用するためには、まずWeb ACLを作成する必要があります。
このWeb ACLはルールグループを格納するための上位のコンテナであり、複数のルールグループを格納することができます。
Web ACLには、複雑さの度合いを示すキャパシティユニットと呼ばれる上限が設けられています。
現在は5000が上限ですが、1500を超えると追加料金が発生するため注意が必要です。（以前はキャパシティユニットの上限は、Web ACL一つにつき1500でした。）
ルールグループにはキャパシティ（コスト）が設定されているため、Web ACLの上限に収まるように設定する必要があります。
5000という上限があるため、Web ACLに対して無限にルールグループを割り当てる事はできません。
ルールグループとは、複数のルールをまとめた中間のコンテナです。
ルールグループにはAWSや第三者が提供する作成済みのマネージドグループがあります。
ユーザーが自分でルールグループや、ルールを作成することもできます。
ルールグループには、1つ以上のルールが含まれています。
(https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html)画像出典: [AWS]
例えばこちらの「AWSManagedRulesAmazonIpReputationList」というAWSが提供する無料のマネージドルールグループには、3つのルールが含まれています。
WAFのコストについて
※内容に間違いがあるかもしれません。
(https://aws.amazon.com/jp/waf/pricing/)画像出典: AWS
よく分からなかったのがコチラです。
Web ACLに応じた課金
Web ACLは1つにつき5ドルの課金です。時間で按分されるため、途中で削除すればその分安く済みます。Web ACLは実際に使っていなくても、作成した時点から課金されます。
ルール
ルールグループには、AWSが提供する無料のマネージドルールグループがあります。
しかしそれ以外の有料のマネージドルールグループや、自作したルールグループをWeb ACLに割り当てると課金されます。
（AWSが提供する無料のマネージドルールグループを除いて）ルールグループをWeb ACLにアタッチすると、Web ACLにアタッチしたルールグループの数と、そのルールに含まれるルールの数分課金されます。
つまり...
ルールグループ単位の課金（1ドル/1個）
ルール単位の課金（1ドル/1個)
例えば自分でルールグループを作成し、そこにルールが3つ含まれているとします。
このルールグループをWeb ACLにアタッチすると、(Web ACLにアタッチしたルールグループが1個) + (ルールグループに含まれるルールが3個)で、合計4ドル/月発生します。
ここに、さらにWeb ACLの課金とリクエスト数に応じた課金が発生します。
ルールグループは作成しただけでは課金されません。
Web ACLにアタッチすると課金が発生します。
ただし、そのWeb ACLを実際にCloudFrontやALBにアタッチしていない状態でも課金が発生するため注意が必要です。
リクエスト数
100万リクエストあたり0.6ドルの課金が発生します。
例
・Web ACLを一つ作成し、AWSが提供する無料マネージドルールをアタッチした場合（キャパシティユニットは1500以下、リクエスト数は100万とします。）
→Web ACLの料金とリクエストに応じた料金のみのため、月額5.6ドルです。
AWSが提供する無料マネージドルールグループについて
AWSが提供している各無料マネージドルールグループについて、その特徴や使いどころなど個人的な内容をメモしていきます。
Core rule set（コアルールセット (CRS) マネージドルールグループ）
クロスサイトスクリプティング（XSS）や不正なボット、EC2メタデータサービスへの不正アクセスなど、Webアプリに対する代表的な脅威を幅広くカバーしているルールセットです。
広範な攻撃に対してカバーしているため、ぜひ導入しておきたいルールグループです。
例えばCloudFront-ALB-EC2といった構成ならば、最前面のCloudFrontにアタッチして不正なリクエストをブロックする事で、CloudFrontでキャッシュすらさせないようにする事ができます。
ブロックによって無駄なキャッシュやオリジンへの転送を防げるため、セキュリティ面だけでなくコスト面でも優位になります。
ただし、ルールの内容については他のルールグループと重複する場合もあります。
その場合は必要に応じて、より特定のケースに対応した他のルールグループを追加で導入してください。
Admin protection（管理者保護マネージドルールグループ）
これは、WebアプリケーションやCMSの管理画面への外部からのアクセスを検知・ブロックするためのルールセットです。
例えばWordPressを使っている場合、/wp-login.phpへのアクセスを防ぐ事ができます。
CMSを使っていたり、管理者インターフェースをパブリックに公開しているなど、公開Webアプリの場合は管理画面を保護するために導入するのがオススメです。
ただし開発段階などで正規のユーザーのアクセスも遮断する可能性があるため、BlockではなくCountモードに移行する、自分のIPだけ許可をするなどの対応が必要になる場合があります。
このルールグループも、CloudFrontなど最前面にアタッチするのがおすすめです。
Amazon IP reputation list（Amazon IP 評価リストマネージドルールグループ）
AWSが収集・分析した脅威インテリジェンスをもとに、悪性と判断されたIPアドレスからのリクエストを自動的にブロックするルールグループです。
優先度は高めです。
AWSリソースに対して偵察を行っているIPアドレスをブロックしたり、DDoS攻撃に関係するIPアドレスを検査することができます。
そのため、こちらも最前面となるCloudFrontにアタッチする事が望ましいです。
不正なリクエストがオリジンに届く前に、CloudFrontで遮断する事ができます。
Anonymous IP list（匿名 IP リストマネージドルールグループ）
このルールグループでは、匿名性が高い通信元からのアクセスをブロックします。
具体的には、VPNやTorなどを使ってアプリケーションからIDを隠そうとするユーザーを除外できます。
匿名IPからの不正なアクセスを防ぎたい場合には有効ですが、出張中の社員がVPN経由で接続してくる場合など、正規ユーザーを誤検知でブロックするケースも考えられます。
そのため最初はCountモードでログを確認したり、特定のIPはブロックしないなど運用を工夫する必要がありそうです。
そのため優先度は中～やや低いと思います。
Known bad inputs（既知の不正な入力マネージドルールグループ）
このルールグループでは、不審な入力パターンを検出して予防的にブロックします。
例えば攻撃ツールが使う特定のリクエスト形式や、脆弱性を突くために試される不審なヘッダーや入力値などです。
こういった不振な入力パターンを「攻撃目的の入力だ」と判断して検出します。