Protecting AEM websites using standard traffic filter rules

Learn how to protect AEM websites from Denial of Service (DoS), Distributed Denial of Service (DDoS), and bot abuse using Adobe-recommended standard traffic filter rules in AEM as a Cloud Service.

Learning objectives

Implementation overview

The implementation steps include:

Prerequisites

Before proceeding, ensure you’ve completed the required groundwork as described in the How to set up traffic filter and WAF rules tutorial. Also, you have cloned and deployed the AEM WKND Sites Project to your AEM environment.

Key actions of the rules

Before we dive into the details of the standard traffic filter rules, let’s understand the key actions that these rules perform. The action attribute in each rule defines how the traffic filter should respond when the conditions are met. The actions include:

Review and define rules

Adobe-recommended standard traffic filter rules serve as a foundational layer for identifying potentially malicious traffic patterns by logging events like IP-based rate limits being exceeded, and block traffic from specific countries. These logs help teams validate thresholds and make informed decisions for ultimately transitioning to block-mode rules without disrupting legitimate traffic.

Let’s review the three standard traffic filter rules that you should add to the AEM WKND project’s /config/cdn.yaml file:

1. Prevent DoS at the Edge

This rule sends an alert when it detects a potential Denial of Service (DoS) attack at the CDN. The criteria for triggering this rule is when a client exceeds 500 requests per second (averaged over 10 seconds) per CDN POP (Point of Presence) at the edge.

It counts all requests and groups them by client IP.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev", "stage", "prod"]
data:
  trafficFilters:
    rules:
    - name: prevent-dos-attacks-edge
      when:
        reqProperty: tier
        equals: 'publish'
      rateLimit:
        limit: 500
        window: 10
        penalty: 300
        count: all
        groupBy:
          - reqProperty: clientIp
      action:
        type: log
        alert: true

The action attribute specifies that the rule should log the events and trigger an alert when the conditions are met. Thus, it helps you monitor potential DoS attacks without blocking legitimate traffic. However, your goal is to eventually transition this rule to block-mode once you have validated the traffic patterns and adjusted the thresholds.

2. Prevent DoS at the Origin

This rule sends an alert when it detects a potential Denial of Service (DoS) attack at the origin. The criteria for triggering this rule is when a client exceeds 100 requests per second (averaged over 10 seconds) per client IP at the origin.

It counts fetches (cache-bypassing requests) and groups them by client IP.

...
    - name: prevent-dos-attacks-origin
      when:
        reqProperty: tier
        equals: 'publish'
      rateLimit:
        limit: 100
        window: 10
        penalty: 300
        count: fetches
        groupBy:
          - reqProperty: clientIp
      action:
        type: log
        alert: true

The action attribute specifies that the rule should log the events and trigger an alert when the conditions are met. Thus, it helps you monitor potential DoS attacks without blocking legitimate traffic. However, your goal is to eventually transition this rule to block-mode once you have validated the traffic patterns and adjusted the thresholds.

3. Block OFAC Countries

This rule blocks access from specific countries that fall under OFAC restrictions.
You can review and modify the country list as needed.

...
    - name: block-ofac-countries
      when:
        allOf:
          - { reqProperty: tier, in: ["author", "publish"] }
          - reqProperty: clientCountry
            in:
              - SY
              - BY
              - MM
              - KP
              - IQ
              - CD
              - SD
              - IR
              - LR
              - ZW
              - CU
              - CI
      action: block

The action attribute specifies that the rule should block access from the specified countries. This helps you prevent access to your AEM site from regions that may pose security risks.

The complete cdn.yaml file with the above rules looks like this:

Deploy rules

To deploy the above rules, follow these steps:

Test rules

To verify the effectiveness of the standard traffic filter rules, at both the CDN Edge and the Origin, simulate high request traffic using Vegeta, a versatile HTTP load testing tool.

Review alerts

Alerts are generated when the traffic filter rules are triggered. You can review these alerts in the AEM Actions Center.

Analyze results

To analyze the results of the traffic filter rules, you can use the AEMCS CDN logs and the ELK dashboard tool. Follow the instructions from the CDN logs ingestion set-up section to ingest the CDN logs into the ELK stack.

In the following screenshot, you can see the AEM Dev environment’s CDN logs ingested into the ELK stack.

Inside the ELK application, the CDN Traffic Dashboard should show the spike at the Edge and Origin during the simulated DoS attacks.

The two panels, Edge RPS per Client IP and POP and Origin RPS per Client IP and POP, display the requests per second (RPS) at the edge and origin respectively, grouped by client IP and Point of Presence (POP).

You can also use other panels in the CDN Traffic Dashboard to analyze the traffic patterns, such as Top Client IPs, Top Countries, and Top User Agents. These panels help you identify potential threats and adjust your traffic filter rules accordingly.

Splunk integration

Customers who have Splunk Log forwarding enabled can create new dashboards to analyze the traffic patterns.

To create dashboards in Splunk, follow Splunk dashboards for AEMCS CDN Log Analysis steps.

The following screenshot shows an example of a Splunk dashboard that displays the maximum origin and edge requests per IP, which can help you identify potential DoS attacks.

When and how to refine rules

Your goal is to avoid blocking legitimate traffic while still protecting your AEM site from potential threats. The standard traffic filter rules are designed to alert and log (and eventually block when the mode is switched) threats without blocking legitimate traffic.

To refine the rules, consider the following steps:

Summary

In this tutorial, you learned how to protect AEM websites from Denial of Service (DoS), Distributed Denial of Service (DDoS), and bot abuse using Adobe-recommended standard traffic filter rules in AEM as a Cloud Service.

Recommended WAF rules

Learn how to implement Adobe recommended WAF rules to protect your AEM websites from sophisticated threats that use advanced techniques to bypass traditional security measures.

Protecting AEM websites using WAF traffic filter rules

Learn how to protect AEM websites from sophisticated threats including DoS, DDoS, and bot abuse using Adobe-recommended Web Application Firewall (WAF) traffic filter rules in AEM as a Cloud Service.

Activate WAF

Use cases - beyond standard rules

For more advanced scenarios, you can explore the following use cases that demonstrate how to implement custom traffic filter rules based on specific business requirements:

Monitoring sensitive requests

Learn how to monitoring sensitive requests by logging them using traffic filter rules in AEM as a Cloud Service.

Learn more

Restricting access

Learn how to restrict access by blocking specific requests using traffic filter rules in AEM as a Cloud Service.

Learn more

Normalizing requests

Learn how to normalize requests by transforming them using traffic filter rules in AEM as a Cloud Service.

Learn more

Additional resources