目次：

  1. 1. はじめに
  2. 2. これまでのAWS WAFマネージドルールの誤検知対応
  3. 3. ルールグループの例外機能リリース後の誤検知対応
  4. 4. ルールグループの例外機能を設定してみる
  5. 5. ルールグループの例外機能の動作とフルログの確認（マネージドルールをBLOCKモードにして、個々のルールを例外にするパターン）
  6. 6. ルールグループの例外機能の動作とフルログの確認（マネージドルールをCOUNTモードにして、個々のルールを例外にするパターン）
  7. 7. WafCharmではAWS WAFマネージドルールのルールグループの例外機能を活用した新機能を準備中です！！

【1. はじめに】

2018年12月21日に、AWSがAWS WAFのマネージドルールにて非常に有効な「ルールグループの例外機能」の新機能リリースをしました。
Announcing Rule Group Exceptions for Managed Rules for AWS WAF:
https://aws.amazon.com/jp/about-aws/whats-new/2018/12/announcing-rule-group-exception-for-managed-rules-for-aws-waf/

本リリースにて、AWS WAFマネージドルールの制約であった誤検知対応が一新されます。

これを受けて、WafCharmでも「ルールグループの例外機能」を最大限に活かした新機能のリリースに着手開始しましたので、近々のWafCharmリリースをお楽しみに！！

まずはリリース前後の変化からご紹介します！

 

【2. これまでのAWS WAFマネージドルールの誤検知対応】

下記のブログでも紹介したマネージドルールの制約として、「ブラックボックス」、「まるごと操作しかできない」という制約がありました。

この「まるごと操作しかできない」ということは、誤検知対応する際に必要以上に防御力が低下してしまうということを意味します。

以前に公開したブログにも、この点を記載していますので、ご参考までに。
AWS WAF マネージドルール 入門編（https://www.wafcharm.com/jp/blog/aws-waf-managed-rule-introduction-jp/）

・ルールがブラックボックス。AWS WAFのルールを自分たちで作成した場合にはルールの中身がホワイトボックスになり、どうして検知したのかが分かります。一方のマネージドルールは、どのようなルールが入っているのか分かりません。

・誤検知が発生した際に、マネージドルールというルールの集合体をまるごとCOUNTモードに変更する必要がある。本来やりたいことは、誤検知してしまったルールだけをCOUNTモードに変更することですが、マネージドルールの場合にはそれができません。

【3. ルールグループの例外機能リリース後の誤検知対応】

今回のAWS WAFのアップデートにより、AWS WAFマネージドルールの制約の１つである「まるごと操作しかできない」が解消しました！！

※マネージドルールに含まれているルールが「ブラックボックス」という制約の解消はしていません。

誤検知が発生した際に、これまでのマネージドルールではマネージドルールをまるごとCOUNTモード（遮断せず、検知だけする）に変更する必要がありましたが、今後はマネージドルールの中でも誤検知の発生したルールだけをCOUNTモードに変更する細かな操作が可能となりました。

該当のルールだけCOUNTモードに変更できるので、誤検知対応するのに必要以上に防御力を下げる必要はなくなりました！

 

【4. ルールグループの例外機能を設定してみる】

マネージドルールのルールグループの例外機能を利用するためには3ステップがあります。

Step1. フルログ機能を出力する
Step2. フルログから除外したいルールのruleIdを特定する
Step3. 特定したruleIdの除外設定をする

Step1. フルログ機能を出力します。下記のブログを参考に出力設定をしましょう。

AWS WAF Full Log を S3 に出力する（https://www.wafcharm.com/jp/blog/aws-waf-full-log-s3-output-jp/）

Step2. フルログから除外したいルールのruleIdを特定する

マネージドルールにはBLOCKモード(No override)とCOUNTモード(Override to count)の2つのモードがあります。

この2つのモードによってフルログの出力内容は少し違ってきますが、着目すべきruleIdは同じところに記載されています。

また、ruleIdはリージョン毎に異なりますので十分に注意してください。
例えば、東京リージョンのマネージドルールとバージニア北部リージョンのマネージドルールとではruleIdが異なります。

フルログにおけるruleId記載箇所の一覧表

　

マネージドルールが
BLOCKモード
（No override）		 マネージドルールが
COUNTモード
（Override to count）
ルールグループの例外に必要な
ruleIdの記載箇所		 該当するruleIdは
ruleGroupListの中の
terminatingRuleに含まれるruleIdとなります。		 該当するruleIdは
ruleGroupListの中の
terminatingRuleに含まれるruleIdとなります。

 
マネージドルールがBLOCK(No override)モードのフルログ内容
（今回利用させて頂いたマネージドルールはFortinet Managed Rules for AWS WAF – Complete OWASP Top 10です）

{
  "timestamp": xxxxxxxxxxx,
  "formatVersion":1,
  "webaclId":"5ad3da2f-e79d-xxxx-xxxx-xxxxxxxxxxxx",
  "terminatingRuleId":"3747215b-91ff-xxxx-xxxx-xxxxxxxxxxxx",
  "terminatingRuleType":"GROUP",
  "action":"BLOCK",
  "httpSourceName":"ALB",
  "httpSourceId":"app/f6ba4d85d77dd153",
  "ruleGroupList":[
    {
      "ruleGroupId":"3747215b-91ff-xxxx-xxxx-xxxxxxxxxxxx",
      "terminatingRule":{
        "ruleId":"c8dd8378-6959-xxxx-xxxx- xxxxxxxxxxxx",
        "action":"BLOCK"
      },
      "nonTerminatingMatchingRules":[],
      "excludedRules":null
    }
  ],
  "rateBasedRuleList":[],
  "nonTerminatingMatchingRules":[],
〜以下省略〜

マネージドルールがCOUNT(Override to count)モードのフルログ内容
※注意点として、COUNT(Override to count)モードの場合のフルログでは、ruleIdが２箇所出てきます。「nonTerminatingMatchingRulesのruleId」ではなく、「ruleGroupListのterminatingRuleのruleId」が正しいものとなります。

{
  "timestamp": xxxxxxxxxxx,
  "formatVersion":1,
  "webaclId":"5ad3da2f-e79d-xxxx-xxxx-xxxxxxxxxxxx",
  "terminatingRuleId":"Default_Action",
  "terminatingRuleType":"REGULAR",
  "action":"ALLOW",
  "httpSourceName":"ALB",
  "httpSourceId":"app/f6ba4d85d77dd153",
  "ruleGroupList":[
    {
      "ruleGroupId":"3747215b-91ff-xxxx-xxxx-xxxxxxxxxxxx",
      "terminatingRule":{
        "ruleId":"c8dd8378-6959-xxxx-xxxx-xxxxxxxxxxxx",
        "action":"BLOCK"
        },
        "nonTerminatingMatchingRules":[],
        "excludedRules":null
    }
  ],
  "rateBasedRuleList":[],
  "nonTerminatingMatchingRules":[
    {
      "ruleId":"3747215b-91ff-xxxx-xxxx-xxxxxxxxxxxx",
      "action":"COUNT"
    }
  ]
〜以下省略〜

Step3. 特定したruleIdの除外設定をする
Step2にて、除外したいルールのruleIdが「c8dd8378-6959-xxxx-xxxx- xxxxxxxxxxxx」であることを特定することができました。

次に、このruleIdの除外設定をしていきます。
ここでは、誤検知が発生したことを想定して、マネージドルールはBLOCK（No override）モードで、ruleIdが「c8dd8378-6959-xxxx-xxxx- xxxxxxxxxxxx」のルールのみをCOUNTモードにする流れをご紹介します。

Step3-1. AWS WAFナビゲーション（https://console.aws.amazon.com/waf/）にアクセスします。

Step3-2. AWS WAFナビゲーション > Web ACLs > “該当のWebACL”を選択 > 「Rules」タブ > 「Edit web ACL」をクリックします。

Step3-3. 赤枠の矢印ボタンをクリックします。

Step3-4. 左の赤枠にruleIdを入力し、右の赤枠の＋ボタンをクリックします。

Step3-5. Statusが、「0 rule(s) excluded」から、「1 rule(s) excluded」に変更されます。それが確認できたら、「Update」をクリックします。

Step3-6. 赤枠のように、該当のマネージドルールに対して「1 rule(s) excluded」となっていれば設定完了です。

 

【5. ルールグループの例外機能の動作とフルログの確認（マネージドルールをBLOCKモードにして、個々のルールを例外にするパターン）】

4章のルールグループの例外機能の設定前には403(forbidden)を返す擬似攻撃リクエストが、4章の設定後には200OKが返ってきていることが確認できました。

投げたリクエスト：curl http://xxxxxxxx.ap-northeast-1.elb.amazonaws.com/?pw=%27%20or%201%20=%201

ルールグループの例外設定前：403 fobbiden
ルールグループの例外設定後：200 OK

これにより、マネージドルールとしては、BLOCKモードにして、ルールグループの例外機能を設定することで、設定したルールのみBLOCKしないようになりました。

そして、フルログ上では除外設定したルールで検知した場合には
ruleGroupListのexcludedRulesのruleIdに出力されることがわかりました。

マネージドルールがBLOCK(No override)モードで、ruleIdが「c8dd8378-6959-xxxx-xxxx- xxxxxxxxxxxx」のルールのみ除外した場合のフルログ内容

{
  "timestamp": xxxxxxxxxxx,
  "formatVersion":1,
  "webaclId":"5ad3da2f-e79d-xxxx-xxxx-xxxxxxxxxxxx",
  "terminatingRuleId":"Default_Action",
  "terminatingRuleType":
  "REGULAR","action":"ALLOW",
  "httpSourceName":"ALB",
  "httpSourceId":"app/f6ba4d85d77dd153",
  "ruleGroupList":[
    {
      "ruleGroupId":"3747215b-91ff-xxxx-xxxx-xxxxxxxxxxxx",
      "terminatingRule":null,
      "nonTerminatingMatchingRules":[],
      "excludedRules":[
        {
          "ExclusionType":"EXCLUDED_AS_COUNT",
          "ruleId":"c8dd8378-6959-xxxx-xxxx- xxxxxxxxxxxx"
        }
〜以下省略〜

ちなみに、サンプルログにはACTIONがCOUNTとして出力されることを期待していましたが、出力されることはありませんでした。
 

【6. ルールグループの例外機能の動作とフルログの確認（マネージドルールをCOUNTモードにして、個々のルールを例外にするパターン）】

ほとんど使用するケースはないと思いますが、マネージドルールをCOUNT(Override to count)モードにして、ruleIdが「c8dd8378-6959-xxxx-xxxx- xxxxxxxxxxxx」のルールのみ除外設定してみました。

期待としては、マネージドルール全体としてはCOUNTモードとなり、例外設定したルールだけBLOCKモードになるという動作です。

設定は以下の通りです。

投げたリクエスト：curl http://xxxxxxxx.ap-northeast-1.elb.amazonaws.com/?pw=%27%20or%201%20=%201

ルールグループの例外設定前：200 OK
ルールグループの例外設定後：200 OK

結果としては、マネージドルール全体をCOUNTモードにした状態で、個々のルールがBLOCKモードになるという訳ではありませんでした。

AWSとしても、ニーズとしてマネージドルールの誤検知対応の改善というのが今回の新機能リリースの意図だったんでしょう。

マネージドルールがCOUNT(Override to count)モードで、ruleIdが「c8dd8378-6959-xxxx-xxxx- xxxxxxxxxxxx」のルールのみ除外した場合のフルログ内容

{
  "timestamp":xxxxxxxxxxx,
  "formatVersion":1,
  "webaclId":"5ad3da2f-e79d-xxxx-xxxx-xxxxxxxxxxxx",
  "terminatingRuleId":"Default_Action",
  "terminatingRuleType":"REGULAR",
  "action":"ALLOW",
  "httpSourceName":"ALB",
  "httpSourceId":"app/f6ba4d85d77dd153",
  "ruleGroupList":[
    {
      "ruleGroupId":"3747215b-91ff-xxxx-xxxx-xxxxxxxxxxxx",
      "terminatingRule":null,
      "nonTerminatingMatchingRules":[],
      "excludedRules":[
        {
          "ExclusionType":"EXCLUDED_AS_COUNT",
          "ruleId":"c8dd8378-6959-xxxx-xxxx- xxxxxxxxxxxx"
          }
〜以下省略〜

ちなみに、サンプルログには何も出力されることはありませんでした。
 

【7. WafCharmではAWS WAFマネージドルールのルールグループの例外機能を活用した新機能を準備中です！！】

今回のAWS WAFのルールグループの例外機能リリースを受けて、WafCharmでもこの機能をうまく活用した新機能のリリースを準備開始しました！！

準備開始した背景として、実は今回のリリースではまだマネージドルールの制約を解消しきれていないからです。

・フルログにて、ruleIdを特定できないとCOUNT（override to count）モードに変更できないという煩雑さ
・マネージドルールが「ブラックボックス」である
などなど。

マネージドルールが「ブラックボックス」であることによる危険性として、１つ例を出しておきます。
例えば、ユーザが誤検知を回避するために、SQLインジェクションを防御するルールを認識なく、COUNTモードに切り替えてしまう恐れがあります。その結果、知らぬ間にSQLインジェクション攻撃の対策ができていないという最悪のシナリオになる可能性があります。

WafCharmでは、これらの制約を解消できて、さらにAWS WAFやAWS WAFマネージドルールをより使いやすく、より楽に運用できるような機能を近々リリースいたしますので、WafCharmが気になっているお客様はぜひ弊社までお問い合わせください！

以上、AWS WAFマネージドルールのルールグループの例外機能のご紹介でした！