Blocking DoS and DDoS attacks using traffic filter rules

Learn how to block Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks using rate limit traffic filter rules and other strategies at the AEM as a Cloud Service (AEMCS) managed CDN. These attacks cause traffic spikes at the CDN and potentially at the AEM Publish service (aka origin) and can impact site responsiveness and availability.

This tutorial serves as a guide on how to analyze your traffic patterns and configure rate limit traffic filter rules to mitigate those attacks. The tutorial also describes how to configure alerts so that you are notified when there is a suspected attack.

Understanding protection

Let’s understand the default DDoS protections for your AEM website:

These built-in protections should be considered a baseline for an organization’s ability to minimize the performance impact of a DDoS attack. Since each website has different performance characteristics and may see that performance degradation before the Adobe-defined rate limit is met, it is recommended to extend the default protections through customer configuration.

Let’s look at some additional, recommended measures that customers can take to protect their websites from DDoS attacks:

Rate Limit Traffic Rules Variations rate-limit-variations

There are two variations of rate limit traffic rules:

Customer journey

The steps below reflect the likely process through which customers should go about protecting their websites.

The rest of this tutorial guides you through this process.

Recognizing the need to configure rules recognize-the-need

As mentioned previously, Adobe by default blocks traffic at the CDN that exceeds a certain rate, however, some websites may experience degraded performance below that threshold. Thus, rate limit traffic filter rules should be configured.

Ideally, you would configure the rules before going live to production. In practice, many organizations reactively declare rules only once alerted to a traffic spike indicating a likely attack.

Adobe sends a traffic spike at origin alert as an Actions Center Notification when a default threshold of traffic from a single IP address is exceeded, for a given PoP. If you received such an alert, it is recommended to configure a rate limit traffic filter rule. This default alert is different from the alerts that must be explicitly enabled by customers when defining traffic filter rules, which you will learn about in a future section.

Analyzing traffic patterns analyze-traffic

If your site is already live, you can analyze the traffic patterns using CDN logs and Adobe provided dashboards.

Configure the dashboard tooling using one of the following options:

ELK - configuring dashboard tooling

The Elasticsearch, Logstash, and Kibana (ELK) dashboard tooling provided by Adobe can be used to analyze the CDN logs. This tooling includes a dashboard that visualizes the traffic patterns, making it easier to determine the optimal thresholds for your rate limit traffic filter rules.

Splunk - configuring dashboard tooling

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.

Looking at data

The following visualizations are available in the ELK and Splunk dashboards:

Choosing threshold values

The threshold values for rate limit traffic filter rules should be based on the above analysis and making sure that legitimate traffic is not blocked. See the following table for guidance on how to choose the threshold values:

The multiple to use depends on your expectations of normal spikes in traffic due to organic traffic, campaigns, and other events. A multiple between 5-10 may be reasonable.

If your site is not yet live, there is no data to analyze, and you should make an educated guess on the appropriate values to set for your rate limit traffic filter rules. For example:

Configuring rules configure-rules

Configure the rate limit traffic filter rules in your AEM project’s /config/cdn.yaml file, with values based on the discussion above. If needed, consult with your Web Security team to make sure the rate limit values are appropriate and do not block legitimate traffic.

Refer to Create rules in your AEM project for more details.

kind: CDN
version: '1'
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  trafficFilters:
    rules:
    ...
    #  Prevent attack at edge by blocking client for 5 minutes if they make more than 500 requests per second on average
      - name: prevent-dos-attacks-edge
        when:
          reqProperty: tier
          in: ["author","publish"]
        rateLimit:
          limit: 500 # replace with the appropriate value
          window: 10 # compute the average over 10s
          penalty: 300 # block IP for 5 minutes
          count: all # count all requests
          groupBy:
            - reqProperty: clientIp
        action:
          type: log
          experimental_alert: true
    #  Prevent attack at origin by blocking client for 5 minutes if they make more than 100 requests per second on average
      - name: prevent-dos-attacks-origin
        when:
          reqProperty: tier
          in: ["author","publish"]
        rateLimit:
          limit: 100 # replace with the appropriate value
          window: 10 # compute the average over 10s
          penalty: 300 # block IP for 5 minutes
          count: fetches # count only fetches
          groupBy:
            - reqProperty: clientIp
        action:
          type: log
          experimental_alert: true

Note that both origin and edge rules are declared, and that the alert property is set to true so you can receive alerts whenever the threshold is met, likely indicating an attack.

It is recommended that the action type is set to log initially so you can monitor traffic for a few hours or days, ensuring that legitimate traffic does not exceed these rates. After a few days, change to block mode.

Follow the below steps to deploy the changes to your AEMCS environment:

Configuring request transformation rules configure-request-transform-rules

In addition to rate limit traffic filter rules, it is recommended to use request transformations to unset query parameters not needed by the application to minimize ways to bypass the cache through cache busting techniques. For example, if you only want to allow search and campaignId query parameters, the following rule can be declared:

kind: "CDN"
version: "1"
metadata:
  envTypes:
    - dev
    - stage
    - prod
data:
  experimental_requestTransformations:
    rules:
      - name: unset-all-query-params-except-those-needed
        when:
          reqProperty: tier
          in: ["publish"]
        actions:
          - type: unset
            queryParamMatch: ^(?!search$|campaignId$).*$

Receiving traffic filter rules alerts receiving-alerts

As mentioned above, if the traffic filter rule includes experimental_alert: true, an alert is received when the rule is matched.

Acting on alerts acting-on-alerts

Sometimes, the alert is informational, giving you a sense of the frequency of attacks. It is worthwhile to analyze your CDN data using the dashboard described above, to validate that the traffic spike is due to an attack, and not just an increase in legitimate traffic volume. If the latter, consider increasing your threshold.

Attack simulation attack-simulation

This section describes methods to simulate a DoS attack, which can be used to generate data for the dashboards used in this tutorial and to validate that any configured rules successfully block attacks.

To simulate an attack, tools like Apache Benchmark, Apache JMeter, Vegeta, and others can be used.

Edge requests

Using the following Vegeta command you can make many requests to your website:

$ echo "GET https://<YOUR-WEBSITE-DOMAIN>" | vegeta attack -rate=120 -duration=5s | vegeta report

The above command makes 120 requests for 5 seconds and outputs a report. Assuming the website is not rate limited, this can cause a spike in traffic.

Origin requests

To bypass the CDN cache and make requests to the origin (AEM Publish service), you can add a unique query parameter to the URL. Refer to the sample Apache JMeter script from the Simulate DoS attack using JMeter script