2021.10.14 AWS WAFの運用方法~マネージドルールの落とし穴とは?~

この記事では、AWS WAFの運用方法として外すことのできない「マネージドルール」をご紹介します。マネージドルールを作成する手順、マネージドルールでの運用の注意点を解説します。

AWS WAFの構築・運用方法については下記の記事で紹介していますのでこちらも参考にしてください。

参考記事

会社の顔「Webサイト」を守れ!AWS WAFとは?~構築・運用編~ 新規ウィンドウで開く

マネージドルールとは?

マネージドルールとは、一般的にアプリケーションの脆弱性に対応した「ルール集」という意味です。

  • この記事でのマネージドルールの意味は「AWS WAFのルール集」という意味です。

AWS WAFは、「ユーザー自身でルールを更新し、管理すること」が基本の運用方法です。この基本運用方法では、ユーザー自身の運用負荷が大きいことがデメリットでした。しかしマネージドルールを利用した場合、ユーザー自身で独自のルールを記述せずに、一般的なアプリケーションの脆弱性・不要なトラフィックからAWS環境を保護することができます。
またマネージドルールを管理する会社(WAFベンダー)が、ルールのアップデートを行います。ルールの運用はWAFベンダーに任せることができるため、ユーザーは運用の手間・工数を削減することができます。

利用料金の例

マネージドルールの適用は、AWS利用料金に加え、WAFベンダーが提供するマネージドルールなどに追加料金が発生します。WAFベンダーごとにマネージドルールの利用料金、料金体系も異なります。ご自身の目的にあったマネージドルールを提供しているWAFベンダーを選定してください。

AWS WAFでマネージドルールを適用する場合、以下の項目で料金が決定します。今回は、CSC社が提供するマネージドルールの料金体系 新規ウィンドウで開くをご紹介します。

料金決定項目 基本料金
1リージョンごとのマネージドルール利用料金 $25.00/月
AWS WAFへのリクエスト料金 100万リクエストごとに$1.2
  • AWS利用料金+マネージドルール利用料金のため、基本料金が少し高くなっている。

具体的な利用料金例

CSC社のManaged Rules for AWS WAF -HighSecurity OWASP Set-を追加した場合

前回算出した利用料金にマネージドルールを1つ追加した場合
  • AWS利用料 $18.60
  • マネージドルールを1ルール追加 $1.00
    (A)マネージドルールを1ルール追加したAWS利用料金 合計$19.60(¥2,156)
マネージドルール利用の料金
  • 利用料 1リージョン × $25.00 = $25.00
  • リクエスト料金(100万未満は繰り上げ)1 × $1.20 = $1.20
    (B)マネージドルールの料金 合計 $26.20/月(¥2,822)
マネージドルールを適用後のAWS WAF利用料金

(A)$19.60 + (B)$26.20 = $45.80/月(¥5,038)

  • $1=¥110としています。

AWS WAF マネージドルールを作成する

今回は、AWS管理のWAFマネージドルールを作成します。

  1. (1)

    作成したWeb ACLのリージョンを選択します。

    AWS WAF 新規ウィンドウで開くを開き、左ペインより「Web ACLs」を選択してください。事前に作成していたWeb ACLを選択し、タブより「Web ACLのリージョン(今回はAsia Pacific)」を選んでください。選択後「Web ACL名(今回はTOKAI-WEBACL)」をクリックします。

  2. (2)

    選択したWeb ACLのルールを変更します。

    「Rules」タブを選択し、「Add rules」タブを開いてください。その後「Add managed rule groups」をクリックしてください。

  3. (3)

    複数のマネージドルールグループから、AWSが管理している「AWS Managed rule groups」を選択します。

    今回は「AWS Managed rule groups」を選択しましたが、ご自身が追加したいWAFベンダーのマネージドルールグループを選択することができます。AWSが管理しているマネージドルールグループの詳細は、AWS管理ルールルールグループリスト - AWS WAF、AWS Firewall Manager、および AWS Shield Advanced 新規ウィンドウで開くを確認してください。

  4. (4)

    ルールを選択します。

    今回は「Core rule set」を使用するので、アクションより「Add to web ACL」を選択してください。

    • どのルールを選択するかは、ご自身の目的に合わせて適切に選択してください。

    ルール選択後「Add rules」をクリックしてください。

  5. (5)

    選択したルールを保存します。

    「Set rule priority」では何も変更をせずに、「Save」をクリックしてください。

AWS WAFマネージドルールの運用方法

1. 基本的な運用方法

マネージドルールに一致した通信をグラフで確認できる「Cloud Watchメトリクス」を利用し、運用状況の確認を行います。

  1. (1)

    ルールを設定したWeb ACLを開きます。

    AWS WAF 新規ウィンドウで開くを開き、左ペインより「Web ACLs」を選択してください。先ほどルールを設定したWeb ACLを開いてください。

  2. (2)

    Cloud Watchメトリクスより、運用状況を確認します。

    ルールを作成すると、ルールマッチブロックリクエストとブロックリクエストの運用状況を確認できます。ルールを複数作成すると、折れ線グラフの本数・グラフの項目は増えます。運用状況を見える化でき、非常に便利です。

2. 運用時の注意点

ここまでマネージドルールを作成してきましたが、デメリットが存在することにお気づきでしょうか?以下でデメリットをご紹介します。

マネージドルールのデメリット
項目 理由
ルールの仕様がブラックボックス マネージドルール内で定義されているパラメータは、ユーザーへ公開されていない。強固なセキュリティを提供できなくなる可能性があるため、非公開とされている。
ルールのチューニングができない ユーザーの環境に細かく合わせたルールをチューニング(セキュリティポリシーを設定する)ことができない。

さらに具体的なデメリットをご紹介します。

項目 具体的なデメリット
仕様がブラックボックスで発生するデメリット
  • 意図しない通信をブロックしてしまうこと
チューニングができないことで発生するデメリット
  • 自身の環境に不要なルールがあっても、余分な課金が発生すること
  • 意図しない通信をブロックしてしまうこと

WAFのマネージドルール利用にあたり大きなデメリットなのが「意図しない通信をブロックしてしまう」ことです。以下で、意図しない通信をブロックしてしまう事象に対応するための手順をご紹介します。

3. 意図しない通信のブロックが発生した際に対応すべきこと

ブロックが発生したルールの特定を行う

許可されるべき通信がブロックされた場合は、まずブロックしたルールを特定します。

  1. (1)

    手順「(1)ルールを設定したWeb ACLを開きます。」を参照しながら、ルール設定済みのWeb ACLを開きます。

  2. (2)

    タブより「Over view」を選択し、同ページをスクロールし、サンプルリクエストを表示してください。

  3. (3)

    サンプルリクエストより「Action」が「BLOCK」になっている、許可されるべき通信ログを確認します。

    Rule inside rule groupからブロックされたルールを特定します。今回は、Metric name「AWSManagedRulesCommonRuleSet」のRule inside rule group「~CrossSiteScripting_URIPATH」でブロックされています。これでブロックが発生したルールの特定が完了しました。

ブロックされたルールの無効化設定を行う

ブロックが発生したルールを特定した後、ブロックされたルールの無効化設定を行います。
こちらの設定は、あくまでも一時的な処置としてください。無効化したルールに対応する攻撃に完全に無防備になってしまうためです。

  1. (1)

    手順「(1)ルールを設定したWeb ACLを開きます。」を参照しながら、ルール設定済みのWeb ACLを開きます。

  2. (2)

    タブより「Rules」 を選択し、対象のマネージドルールを選択します。

    • 今回は「AWS-AWSManagedRulesCommonRuleSet」をクリックします。
  3. (3)

    「Edit」をクリックしてください。

  4. (4)

    ルール一覧より、ブロックされたルールの「Rule Action」を変更します。

    「Count」にチェックをいれ、「Save rule」をクリックしてください。これでブロックされたルールの無効化設定が完了しました。

    • 今回はブロックされたルール「CrossSiteScripting_URIPATH」をカウントモードに設定します。

新たに優先度の高いルールを設定する

今回は、CrossSiteScripting_URIPATHでブロックされているのでURIがスクリプトとして判断されています。例えば管理やテストのためにURIでスクリプトを使用している場合、以下の対応が検討されます。

  • 拠点IPアドレスから許可するルールを追加する。
  • 偶然にも意図せずURIがスクリプトと判断されている場合は、特定のURIだった場合は許可するルールを追加する。

このように原因によって作成ルールは様々ですが通信を許可するルールを作成し、ブロックされるルールより優先度を高く設定することで意図しない通信のブロックに対応できます。
今回は例として「index.htmlから始まるURI通信を許可するルール」を作成します。

  1. (1)

    手順「(1)ルールを設定したWeb ACLを開きます。」を参照しながら、ルール設定済みのWeb ACLを開きます。

  2. (2)

    タブより「Rules」を選択し、「Add rules」から「Add my own rules and rule groups」を選択します。

  3. (3)

    各種パラメータを入力して、ルールを追加します。

    パラメータ項目 入力事項
    Rule type 追加したいルールタイプを選択する。
    • 今回は「Rule builder」を選択
    Rule Name ルール名を入力する。
    • 今回は「uri_match」と入力
    Type Regular ruleを選択する。
    • Rate-based ruleは、発信元IPからリクエスト数に応じてルールを作成するという意味です。
    パラメータ項目 入力事項
    If a request Matches the statementを選択する。
    Statement inspect 調査する対象を選択する。
    (例)リクエスト送信元の国であれば、URI path、Headerなどを選択する。
    • 今回は「URI path」を選択
    Match type 「String to match」で記載した文字列をどのようにマッチさせるかを選択する。文字列と完全一致、文字列で始まる、文字列を含む などの条件を指定できる。
    • 今回は「Starts with string(文字列で始まる)」を選択
    String to match マッチさせる文字列を入力する。
    • 今回は「index.html」を入力
    Text transformation テキスト変換ができる。文字コードを変換、小文字に変換などが行える。
    • 今回は「None(変換なし)」を選択
    パラメータ項目 入力事項
    Action ルールとマッチした場合の動作を選択する。
    • 今回は「Allow」を選択し通信を許可する
  4. (4)

    優先度を上げたいルールを選択します。

    優先度を高くしたいルールを一覧より選択し「Move up」をクリックしてください。クリック後、ルールの優先度が変更されます。ルールの優先度が変更になったことを確認し「Save」をクリックしてください。これで、意図しない通信のブロック対応が完了しました。

まとめ

今回はAWS WAF マネージドルールについて、構築・運用方法をご紹介しました。マネージドルールは、あくまで「汎用ルール」です。そのため個別のアプリケーションに合わせ、快適に利用をするためには、マネージドルールへチューニングが必要になります。
弊社では、お客様の環境に合わせたマネージドルールのチューニング対応も行っております。構築や運用にお悩みの方、当記事を読んでAWS WAFに興味がある方など、是非弊社までお問い合わせ 新規ウィンドウで開くください。

関連サービス

おすすめ記事

導入のお問い合わせはこちら

AWSやAmazon WorkSpacesの導入から接続回線、運用・保守まで何でもお任せください。

お問い合わせ・資料請求