Using AWS WAF Efficiently to Secure Your CDN, Load Balancers, and API Servers

The introduction of software has made remarkable changes to how business is conducted. "Back then," people would meet in person, and most companies used manual methods, which were not scalable. Software has changed the game, and web applications are essential for a business's success. Software is how customers interact with businesses, share their data, and receive goods and services.

Software-as-a-service (SaaS) has become a giant industry, taking care of hosting services used by customers by upgrading, scaling, and securing customer data. With the massive proliferation of SaaS services, many are using AWS, and security is a big concern. Malicious actors seek to steal customer data or DDoS-ing the service to prevent legitimate customers from accessing the website.

It’s 2024, and we are still struggling with the security of hosted web services. The Mirai botnet has been one of the most successful botnets, taking down big companies and creating variants of botnet code. Protecting web applications is a non-trivial problem, and the urgency of securing them at various stages of the architecture cannot be overstated.

Problem

Web applications face many problems, each varying and sophisticated in its own right. This means our firewall rules must be created separately to handle these problems.

DDoS Attacks

These assaults aim to inundate web applications by sending them excessive traffic from numerous compromised machines, rendering services inaccessible to authorized users.

Credits: Rustam, F., Mushtaq, M., Hamza, A., Farooq, M., Jurcut, A., & Ashraf, I. (2022). Denial of Service Attack Classification Using Machine Learning with Multi-Features. Electronics, 11(22), 3817. 

SQL Injection

Attackers use application code weaknesses to inject harmful SQL statements, which could lead to unauthorized access to important data.

Credits: Alghawazi, M., Alghazzawi, D., & Alarifi, S. (2023). Deep learning architecture for detecting SQL injection attacks based on RNN autoencoder model. Mathematics, 11(15), 3286.

Cross-Site Scripting

Malicious code is inserted into reliable websites, running in users' browsers and possibly stealing valuable information or taking control of user sessions.

Credits: Mwila, K. A. (2020). An assessment of cyber attacks preparedness strategy for public and private sectors in Zambia (Doctoral dissertation, The University of Zambia).

Cross-Site Request Forgery

Attackers deceive users into carrying out unintended actions on a web application while they are logged in.

Credit: Cross-Site Request Forgery (CSRF) Christopher Makarem by Christopher Makarem in IOCSCAN

Script Kiddies

Bots are used to automatically scrape content, carry out credential-stuffing attacks, or engage in other malicious activities.

Credits: What Is Credential Stuffing and How Can It Impact You? By Dashlane

The consequences of such assaults could be significant and could result in compromised data, financial loss, service disruption, and long-term damage to a company's image. The challenge lies in developing a security infrastructure that can adequately mitigate these risks while also being flexible and capable of expanding to counter new attack methods.

Traditional web application firewalls usually do not effectively handle these complicated challenges, particularly in cloud-native settings where applications are spread out in different native services and regions. This is where AWS WAF (Web Application Firewall) is important, providing a deeply integrated solution for AWS customers.

Technologies

AWS WAF

AWS WAF is a flexible and robust service Amazon provides as part of its AWS Suite.  From their website, they make it very clear.

With AWS WAF, you can create security rules that control bot traffic and block common attack patterns such as SQL injection or cross-site scripting (XSS).

Broadly, AWS WAF provides some fundamental building blocks using which one can build a robust protection system.

1. Managed rules: Managed rules block common, well-known attack patterns. AWS creates and updates these rules, saving customers from reinventing the wheel.
2. Custom rules: Not all attacks can be blocked using managed rules. Some attacks are more unique to a customer’s service implementation and need specialized handling. The customer is responsible for creating and updating these rules.
3. IPSet is a set of IP addresses that one can use to allowlist or block. AWS provides a managed list and customers can create their own.
4. Regex: Some attack patterns can be reused with minor variations. Could you create a regex pattern and reuse it within your custom rules?

AWS WAF has a WebACL concept, where one can bundle everything together as a single cohesive unit and attach it to supported AWS Service resources that need to be protected.

AWS CloudFront CDN

AWS CloudFront is the flagship CDN product offered by Amazon and securely delivers data, photos, videos, and any content that the customer wishes thereby reducing latency if caching policies are enabled. Along with the typical benefits of a CDN like lower latency, it offers

1. DDoS protection at the edge: The attacks don’t make it over to your servers.
2. Caching region-specific static pages to significantly reduce browsing times
3. Encrypt the end-to-end experience using secure digital certificates.

AWS Application Load Balancer

AWS provides two kinds of load balancers: Network Load Balancer (NLB), which works on the L3/L4 layer of the networking stack, and Application Load Balancer (ALB), which works on the L7 application layer. AWS WAF works primarily on the L7 layer.  This is made abundantly clear by AWS WAF or AWS Shield.

For WAF to work, we have to choose ALB rather than NLB. Load balancers are supposed to be highly available by expectation, and if the attacker manages to compromise the load balancer, it defeats the primary purpose. Using AWS Shield and AWS WAF with ALB is the recommended solution.

AWS API Gateway

API Gateway is a fully managed cloud service that lets developers build and deploy APIs, the most common being REST APIs. It allows an authentication mechanism and is highly scalable. Since most requests are served at the L7 or HTTP layer, attackers can send specially crafted requests to exploit any possible security loopholes.

To mitigate this potential security risk, we should associate AWS WAF with API Gateway to address issues specific to this use case and this layer of the architecture stack.

Methodologies

Block Different Kinds of Attacks at Different Stages

Not all attacks can be blocked at all places of the cloud stack. Even if it can be, it might not be as efficient as one might think. Primarily, we can block at three places.

1. CDN - Block regional attacks: It works well when the attackers are not highly distributed, but it works quite well even if they are distributed everywhere. CloudFront has multiple Point-of-Presence (PoP) worldwide with storage and computing that will block malicious attacks at the first point of traffic ingress and spare the webservers from taking the brunt of such expensive attacks. 
2. Application Load Balancer: These are regional load balancers sitting inside the AWS network, probably inside your subnet, and have the responsibility of spreading the traffic load across multiple instances of your web server. Most of the common attacks should be blocked by the time traffic reaches ALB. At this layer, more complex and rarer attacks can be handled. 
3. API Gateway: The API Gateway is the place where we would address the specific attacks related to API Design. The attacker may try to send a malformed POST request that has the capability to cause serious issues. Such validations might be too expensive to implement in code. 

Different AWS Rules for Different AWS Resources

Rate Based Rules

The best place to put rate-based rules is on the edge, closer to the users. A lot of times, we use IP-based rate-limiting. Depending on the implementation of the rate-limiting logic for that specific CDN, it might be possible to be quite efficient since the number of IPs that can use a particular PoP is a much smaller subset of all the customers accessing that service. In the case of CloudFront, there is a PoP in San Francisco and Santa Clara, both within the greater San Francisco Bay Area. Traffic from San Jose will be routed to Santa Clara PoP, and San Mateo or Oakland will be routed to San Franciso PoP. Each PoP has a smaller address space to compute the rate limits.

An example of rate based rule is:

{
  "Name": "RateLimitRule",
  "Priority": 1,
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "RateLimitRule"
  },
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  }
}

Maliciously Crafted Requests

Non-rate-limiting but low-effort high-volume attacks like Log4J or SQL injection attacks based on most common patterns can be best blocked at the Edge itself. This ensures that the traffic that makes it to regional data centers is much smaller than the total traffic sent to the edge. 

Specific Headers Allowlist

If your application requires specific headers to be present, you can allow them to be listed as the first rule of your WebACL and set the default action of WebACL to block. This ensures that all malformed HTTP requests will be blocked at the edge and significantly filters out unwanted traffic at the edge.

Validation Token

If you want your application to contain specific validation tokens in headers, you can specify such rules in the WebACL associated with the Application Load Balancer. This ensures that other services in your organization that want to access your service can directly reach ALB within the AWS network itself. Putting these kinds of rules on ALB WAF ensures that they are enforced for both internal and external users. 

File Types

If your API endpoint only allows specific file type uploads, that can be included in the WAF associated with the API Gateway. Such restrictions can be implemented in application logic, too, but if you want to block an explicit list, then the WAF on the API Gateway can be a good choice.

JWT or API Key

If your application uses JWT for token-based authentication, the WAF rules can focus on such logic when associated with API Gateway. We can use the same place for API Key Validation. An example of such a rule is:

{
  "Name": "ValidateJWTToken",
  "Priority": 5,
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "ValidateJWTToken"
  },
  "Statement": {
    "NotStatement": {
      "Statement": {
        "ByteMatchStatement": {
          "SearchString": "Bearer ",
          "FieldToMatch": {
            "SingleHeader": {
              "Name": "Authorization"
            }
          },
          "TextTransformations": [
            {
              "Priority": 0,
              "Type": "NONE"
            }
          ],
          "PositionalConstraint": "STARTS_WITH"
        }
      }
    }
  }
}

Payload Limits

If we want to implement Payload size limits, we can put them on either the edge, API, or ALB. There is no correct answer, and it depends on your business logic. Ideally, it’s best to put such rules on the edge to avoid massive data transfer costs, but it can also mean internal services can bypass such limits.

Blocking Some Attacks in Application Logic

Not everything can be blocked at the WAF rules level since it can be too complex to implement using the standardized WAF syntax. Take, for example, a Downgrade attack, where the attack would like to exploit the backward compatibility nature of the design. Authentication validation systems can be susceptible to Pass-The-Hash attacks, where the attacker does not need to de-hash the hashed password but tries to restart the session using stolen hashed passwords. Code Injection attacks should be addressed in the code itself as we use code to validate the input data.

Overall Design

Conclusion

Using AWS WAF with CloudFront, API Gateway, and Load Balancer created a robust and reliable architecture. As cloud-native solutions, one can use AWS CDK to define the code configuration, thereby explicitly following Infrastructure as Code patterns. We can tailor specific rules to specific stages and resources to create a seamless and efficient security posture.

I would strongly suggest the engineers working on the cloud architecture not consider any design to be set in stone. Regular iterations and reviews are needed to avoid accumulating unnecessary technical debt. Using AWS WAF needs to include a proper operational plan and incident response plan. Keeping an eye on WAF Logs and extracting relevant metrics is crucial in keeping an eye on the efficiency of the rules. I suggest carefully considering alarms based on the business needs and typical traffic patterns. The operational plan should outline how such alarms behave, and the incident response plan should outline what the on-call should do when specific incidents are in progress.