How are the metrics and logs formatted for the count rule action in AWS WAF?

Last updated: 2022-07-27

I've set up AWS WAF and some of the rules in my web ACL are in the Count action. How do I analyze the Amazon CloudWatch metrics and logs for the rules in the count rule action?

Short description

You can use the count rule action to test rules before you implement them with their normal action settings. AWS WAF evaluates the requests against rules in the count rule action and reports matches in metrics, request samples, and logs.

You can also use the count rule action to troubleshoot rules that are generating false positives. False positives occur when a rule or a rule group blocks traffic that you aren't expecting it to block. If you identify a rule blocking requests that you want allowed, you can update the action for that rule to count. This excludes the rule from acting on your requests. For more information on detecting and mitigating false positives, see How can I detect false positives caused by AWS Managed Rules and add them to a safe list?

Resolution

To understand how the metrics and logs are formatted for the count rule action, consider the following three scenarios:

  1. Set the rule action for a custom rule to count mode.
  2. Set the rule action for individual rules to count mode in an AWS Managed Rules rule group.
  3. Override an entire rule group's action to count.

Set the rule action for a custom rule to count mode

Example

You have a web ACL (Test1-ACL) that has a single custom rule ( Geo-Count) with a count rule action. The Geo-Count rule counts the request if the request originates from the United States. If the client IP belongs to a different country, then the web ACL default action with an Allow action is matched.

The following is the JSON representation of this rule:

{
  "Name": "Geo-Count",
  "Priority": 0,
  "Statement": {
    "GeoMatchStatement": {
      "CountryCodes": [
        "US"
      ]
    }
  },
  "Action": {
    "Count": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "Geo-Count"
  }
}

If the request originates from a client IP located in the United States, the following occurs:

  • The request is counted.
  • The CloudWatch metric for the custom rule Geo-Count shows a data point in the CountedRequests metric.
    Note: CloudWatch reports the CountedRequests metric only when there is a nonzero value. To view the data, switch the statistic to Sum on the Graphed metrics tab in the CloudWatch console.
  • Because Geo-Count is a custom rule with the Count action, AWS WAF counts the request.
  • Then, AWS WAF evaluates the request against the web ACL default action. Since the web ACL default action is set to Allow, the request is allowed.
  • A data point for this action appears in the AllowedRequests metric for the web ACL.

For more information on metrics and dimensions included under the AWS WAF namespace, see AWS WAF metrics and dimensions.

When you update the action of a custom rule to Count, the rule is considered as a non-terminating rule from a logging perspective. So, if the request matches a custom rule in count mode, the following fields are logged:

  • nonTerminatingMatchingRules: The list of non-terminating rules that match the request.
  • ruleId: The ID of the rule that matched the request and was non-terminating.
  • action: This is always COUNT.
  • ruleMatchDetails: Detailed information about the rule that matched the request. This field is only populated for SQL injection (SQLi) and cross-site scripting (XSS) match rule statements.

If the Geo-Count rule matches the request, the logs show the nonTerminatingMatchingRules details as shown in the following example:

"nonTerminatingMatchingRules": [{
  "ruleId": "Geo-Count",
  "action": "COUNT",
  "ruleMatchDetails": [

  ]
}]

For more information on all possible log fields, see Log fields.

To turn on logging for a web ACL, see Managing logging for a web ACL.

Set the rule action for individual rules to count mode in an AWS Managed Rules rule group

You can override the actions of the rules inside a rule group, setting them to count for some or all of the rules. For rule actions configured inside the rule group to something other than count, the override changes that action so that only matching requests are counted.

If a web request matches the rule, AWS WAF processes the match as a count and then continues evaluating the subsequent rules in the rule group.

For more information on how to set the rule action to count in a rule group, see Setting rule actions to count in a rule group.

Example

You have a web ACL (Test2-ACL) that includes a AWS Managed Rules rule group (AWSManagedRulesKnownBadInputsRuleSet). There are no other rules in this web ACL and the web ACL default action is configured with an Allow action.

You update the Log4JRCE rule inside AWSManagedRulesKnownBadInputsRuleSet rule group to a Count action. Now, if a component (such as a URI, query string, and so on) in the client request has a Log4j vulnerability, then that request is counted by the Log4JRCE rule. If the request doesn't match any other rules in the rule group, then it's allowed by the web ACL default action.

The following is the JSON representation of this rule:

{
  "Name": "AWS-AWSManagedRulesKnownBadInputsRuleSet",
  "Priority": 0,
  "Statement": {
    "ManagedRuleGroupStatement": {
      "VendorName": "AWS",
      "Name": "AWSManagedRulesKnownBadInputsRuleSet",
      "ExcludedRules": [
        {
          "Name": "Log4JRCE"
        }
      ]
    }
  },
  "OverrideAction": {
    "None": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "AWS-AWSManagedRulesKnownBadInputsRuleSet"
  }
}

If you set the rule action to count for rules inside the rule group, these rules are considered excluded rules in the rule group. If you have metrics turned on, you receive COUNT metrics for each excluded rule.

If the request matches the Log4JRCE rule, the following occurs:

  • The request is counted.
  • The CloudWatch metric for the Log4JRCE rule shows a data point in the CountedRequests metric.

If no other rule inside the AWSManagedRulesKnownBadInputsRuleSet matches the request, the following occurs:

  • The request is allowed by the web ACL default action.
  • A data point appears in the AllowedRequests metric for the web ACL.

For excluded rules, the following fields are captured in AWS WAF logs:

  • excludedRules: The list of rules in the rule group that you have excluded. The action for these rules is set to Count.
  • exclusionType: A type that indicates that the excluded rule has the action Count.
  • ruleId: The ID of the rule within the rule group that is excluded.

If the Log4JRCE rule matches the request, the logs show the excludedRules details as shown in the following example:

"ruleGroupList":[
  {
    "ruleGroupId":"AWS#AWSManagedRulesKnownBadInputsRuleSet",
    "terminatingRule":null,
    "nonTerminatingMatchingRules":[
      
      ],
    "excludedRules":[
      {
        "exclusionType":"EXCLUDED_AS_COUNT",
        "ruleId":"Log4JRCE"
      }
    ]
  }
]

If an individual rule inside a rule group is updated to the count rule action, then the following occurs:

  • The logs for the request matching against this rule won't contain a Count action for the rule under the nonTerminatingMatchingRules field.
  • The AWS WAF logs show this rule under the excludedRules field.

Override an entire rule group's action to count

For information on how to override a rule group's action to count, see Overriding the resulting rule groups action to count.

For information on how to override a rule group's action to count, see Overriding a rule group's action to count.

Example

You have a web ACL (Test3-ACL) that includes an AWS Managed Rules rule group (AWSManagedRulesKnownBadInputsRuleSet). There are no other rules in this web ACL and the web ACL default action is Allow. All of the rules in the AWSManagedRulesKnownBadInputsRuleSet rule group are using the default action defined in the rule. This means that the rules inside this rule group aren't set to Count. However, the Override rule group action to count option is turned on.

The following is the JSON representation of this rule:

{
  "Name": "AWS-AWSManagedRulesKnownBadInputsRuleSet",
  "Priority": 0,
  "Statement": {
    "ManagedRuleGroupStatement": {
      "VendorName": "AWS",
      "Name": "AWSManagedRulesKnownBadInputsRuleSet"
    }
  },
  "OverrideAction": {
    "Count": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "AWS-AWSManagedRulesKnownBadInputsRuleSet"
  }
}

If a component (such as a URI, query string, and so on) in the client request has a Log4j vulnerability, the following occurs:

  • The request is blocked by the Log4JRCE rule.
  • Because Block is a terminating action, AWS WAF stops evaluating the rule group and returns the terminating action result to the web ACL.
  • At this point, the Override rule group action to count takes effect. The rule group's terminating action is overridden to a count.
  • AWS WAF then continues processing the rest of the rules in the web ACL.

If a request matches the Log4JRCE rule (or any other rule) inside the AWSManagedRulesKnownBadInputsRuleSet rule group, the following occurs:

  • CloudWatch shows a data point in the CountedRequests metric corresponding to the rule group name AWSManagedRulesKnownBadInputsRuleSet.
  • AWS WAF continues processing the rest of the rules in the web ACL after the override takes place. So, the request is ultimately matched against the web ACL default action. This shows as a data point in the AllowedRequests metric for the web ACL.
  • In the AWS WAF logs, the matching request contains a count action in the nonTerminatingMatchingRules field.
  • Additionally, the ruleGroupList shows the rule inside the rule group that originally blocked the request before the terminating action was overridden to count.
  • If the Log4JRCE rule matches the request, the logs show the ruleGroupList and nonTerminatingMatchingRules details as shown in the following example:
"ruleGroupList": [{
  "ruleGroupId": "AWS#AWSManagedRulesKnownBadInputsRuleSet",
  "terminatingRule": {
      "ruleId": "Log4JRCE",
      "action": "BLOCK",
      "ruleMatchDetails": null
    },
  "nonTerminatingMatchingRules": [

  ],
    "excludedRules": null
  }
],
"rateBasedRuleList": [

],
"nonTerminatingMatchingRules": [{
    "ruleId": "AWS-AWSManagedRulesKnownBadInputsRuleSet",
    "action": "COUNT",
    "ruleMatchDetails": [

  ]
}]

Did this article help?


Do you need billing or technical support?