Examples and result analysis of traffic filter rules including WAF rules

Learn how to declare various types of traffic filter rules and analyze the results using Adobe Experience Manager as a Cloud Service (AEMCS) CDN logs and dashboard tooling.

In this section, you will explore practical examples of traffic filter rules, including WAF rules. You will learn how to log, allow, and block requests based on URI (or path), IP address, the number of requests, and different attack types using the AEM WKND Sites Project.

Furthermore, you will discover how to use dashboard tooling that ingests AEMCS CDN logs to visualize essential metrics through Adobe provided sample dashboards.

To align with your specific requirements, you can enhance and create custom dashboards, thus gaining deeper insights and optimizing the rule configurations for your AEM sites.

Examples

Let’s explore various examples of traffic filter rules, including WAF rules. Make sure you have completed the required setup process as described in the earlier how to set up chapter and that you have cloned the AEM WKND Sites Project.

Logging requests

Begin by logging requests of WKND login and logout paths against the AEM Publish service.

kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    # On AEM Publish service log WKND Login and Logout requests
      - name: publish-auth-requests
        when:
          allOf:
            - reqProperty: tier
              matches: publish
            - reqProperty: path
              in:
                - /system/sling/login/j_security_check
                - /system/sling/logout
        action: log

Analyzing analyzing

Let’s analyze the results of the publish-auth-requests rule by downloading the AEMCS CDN logs from Cloud Manager and using the dashboard tooling, which you set up in the earlier chapter.

Blocking requests

In this example, let’s add a page in an internal folder at the path /content/wknd/internal in the deployed WKND project. Then declare a traffic filter rule that blocks traffic to subpages from anywhere other than a specified IP address that matches your organization (for example, a corporate VPN).

You can either create your own internal page (for example, demo-page.html) or use the attached package.

kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    ...

    # Block requests to (demo) internal only page/s from public IP address but allow from internal IP address.
    # Make sure to replace the IP address with your own IP address.
      - name: block-internal-paths
        when:
          allOf:
            - reqProperty: path
              matches: /content/wknd/internal
            - reqProperty: clientIp
              notIn: [192.150.10.0/24]
        action: block

Analyzing

To analyze the results of the block-internal-paths rule, follow the same steps as described in the earlier example.

However, this time you should see the Blocked requests and corresponding values in the client IP (cli_ip), host, URL, action (waf_action), and rule-name (waf_match) columns.

Prevent DoS attacks

Let’s prevent DoS attacks by blocking requests from an IP address making 100 requests per second, causing it to be blocked for 5 minutes.

kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    ...
    #  Prevent DoS attacks by blocking client for 5 minutes if they make more than 100 requests in 1 second.
      - name: prevent-dos-attacks
        when:
          reqProperty: path
          like: '*'
        rateLimit:
          limit: 100
          window: 1
          penalty: 300
          groupBy:
            - reqProperty: clientIp
        action: block

Analyzing

To analyze the results of the prevent-dos-attacks rule, follow the same steps as described in the earlier example.

This time you should see many Blocked requests and corresponding values in the client IP (cli_ip), host, url, action (waf_action), and rule-name (waf_match) columns.

Also, the Top 100 attacks by client IP, country, and user-agent panels show additional details, which can be used to further optimize the rules configuration.

For more information on how to prevent DoS and DDoS attacks, review the Blocking DoS and DDoS attacks using traffic filter rules tutorial.

WAF rules

The traffic filter rule examples so far can be configured by all Sites and Forms customers.

Next, let’s explore the experience for a customer who has procured an Enhanced Security or WAF-DDoS Protection license, which lets them configure advanced rules to protect websites from more sophisticated attacks.

Before continuing on, enable the WAF-DDoS Protection for your program, as described in the traffic filter rules documentation setup steps.

Without WAFFlags

Let’s first see the experience even before WAF Rules are declared. When the WAF-DDoS is enabled on your program, your CDN logs by default log any matches of malicious traffic, so you have the right information to come up with appropriate rules.

Let’s begin by attacking the WKND site without adding a WAF rule (or using the wafFlags property) and analyze the results.

Analyzing

To analyze the results of attack simulation, follow the same steps as described in the earlier example.

However, this time you should see the Flagged requests and corresponding values in client IP (cli_ip), host, url, action (waf_action), and rule-name (waf_match) columns. This information allows you to analyze the results and optimize the rule configuration.

Note how the WAF Flags distribution and Top attacks panels show additional details, which can be used to further optimize the rule configuration.

With WAFFlags

Let’s now add a WAF rule that contains wafFlags property as part of the action property and block the simulated attack requests.

From a syntax perspective, the WAF rules are similar to those seen earlier, however, the action property references one or more wafFlags values. To learn more about the wafFlags, review the WAF Flags List section.

kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    ...
    # Enable WAF protections (only works if WAF is enabled for your environment)
      - name: block-waf-flags
        when:
          reqProperty: tier
          matches: "author|publish"
        action:
          type: block
          wafFlags:
            - SANS
            - TORNODE
            - NOUA
            - SCANNER
            - USERAGENT
            - PRIVATEFILE
            - ABNORMALPATH
            - TRAVERSAL
            - NULLBYTE
            - BACKDOOR
            - LOG4J-JNDI
            - SQLI
            - XSS
            - CODEINJECTION
            - CMDEXE
            - NO-CONTENT-TYPE
            - UTF8

Analyzing

Repeat the same steps as described in the earlier example.

This time you should see entries under Blocked requests and the corresponding values in client IP (cli_ip), host, url, action (waf_action), and rule-name (waf_match) columns.

Also, the WAF Flags distribution and Top attacks panels show additional details.

Comprehensive analysis

In the above analysis sections, you learned how to analyze the results of specific rules using the dashboard tool. You can further explore analyzing results using other dashboard panels, including:

Next step

Get familiar with recommended best practices to reduce the risk of security breaches.

Additional resources

Traffic Filter Rules Syntax

CDN Log Format