Detection and blocking with the Next-Gen WAF

Web application firewalls (WAFs) are the major line of defense for organizations to protect their applications against malicious traffic. The first WAFs on the market protected simple websites using regular expression (regex) pattern-matching rules. However, this approach failed to scale as applications - and their attacks - became more sophisticated over the last few decades. 

The limitations of today’s legacy WAFs are rooted in the false belief that more rules make safer applications, and that complex rules tuning and maintenance is the price to pay for accurate, effective blocking. 

The Fastly Next-Gen WAF takes a fundamentally different approach to application security. Our solution provides accurate, effective protection out of the box, so you don’t have to constantly tune an extensive collection of regex rules. 

The limitations of legacy WAFs

How legacy WAF detection works

When a request is sent to a web server, WAFs inspect the request payload to determine whether the request is legitimate or benign. Many legacy WAFs rely on pattern-matching the contents of the payload to a set of indicators (or rules) associated with an attack.

 Figure 1: A regex-based WAF rules engine rejects a legitimate request that looks like a SQLi attack.

In the example above, an end-user submits a form with two different responses. Request 1 says “Let’s set the teams up!” while Request 2 says “Great! Just select users from Jess’ list where it makes sense”. Although Request 1 makes it through to the web app, Request 2 is rejected and determined as a Bad Request, even though the content is benign. 

This false positive is a common error for legacy WAFs. It pattern-matched words like SELECT, FROM, and WHERE as SQL commands and labeled the request as a potential SQL Injection attack, without understanding the context of the request.

Although this is a simple example, it highlights a number of detection and blocking failures that result in painful experiences for legacy WAF customers. 

First, the detection engine requires an extensive tuning period or learning mode to ensure that default rule sets do not generate false positives and block legitimate traffic. But the risk of false positives is so high for some organizations that they never leave “learning mode” to block live traffic. 

Second, blocking through pattern matching is insufficient scale. To prevent false positives, simple regex rules become increasingly complex and can grow into thousands over time. Customers using ModSecurity-based WAFs, for example, need more than 50 rules just to manage SQL injection attacks. 

Figure 2: Example of a Modsecurity rule against SQL injection as written in regular expression.

You can easily get stuck in the quagmire of rules tuning because its volume provides a believable veneer of security - until an inevitable code change that breaks the WAF and the re-tuning starts again. 

The legacy approach of using default rules leaves you with subpar options: enable fewer rules you've validated as “safe” yet leave your applications exposed, or enforce more rules for catching more potential attacks that risk blocking legitimate traffic in exchange. Both choices force you to rely on manual rules management, leaving applications - and end-users - vulnerable to attacks. 

How legacy WAFs fail modern organizations

When evaluating security solutions, teams focus on “security efficacy”: the ability to successfully keep applications safe with a high level of accuracy and usability. Legacy WAFs’ reliance on regex and complex rulesets fail to meet this standard and provide teams a false sense of security. In other words, solutions that rely on maintaining fragile systems are inherently less effective. 

A WAF for today’s multi-cloud, complex environments needs to deliver beyond the security promises of legacy WAFs, and provide a next-generation security experience that doesn’t compromise on usability. To provide better WAF efficacy, a new solution must:

1. Detect attacks accurately without relying on regex pattern matching

2. Block attacks at scale without constant rules tuning

3. Learn from its environment for preventive protection

Improved security efficacy with the Fastly Next-Gen WAF

Next-Gen WAF Overview

The Fastly Next-Gen WAF was designed by security practitioners who have lived the pain of constant rules tuning and have seen where pattern matching and signature-based rule sets fall short. The outcome is a solution that delivers better security efficacy because it’s more accurate and easier to use. 

Compared to legacy WAFs that rely on regex matching and are rarely used in blocking mode, nearly 90% of Fastly's customers enable full blocking mode across all default attack types with virtually no tuning.

The key to our reliable, accurate decisions lies in our patented architecture and proprietary detection technology SmartParse, which makes contextual, instantaneous decisions inline to determine if malicious or anomalous payloads are present. Using our intuitive rule builder, you can programmatically block attacks at scale without constant rules tuning that can break your apps. Furthermore, our Network Learning Exchange (NLX) can block potential attacks based on a continuous feed of customer data. 

Accurate detection with SmartParse

SmartParse Overview 

The Fastly Next-Gen WAF detects potential attacks without relying on the regex pattern matching of legacy WAFs. Instead, our detection engine SmartParse analyzes request parameters to determine whether the code is actually executable and tokenizes the results. This intelligent approach has a much lower false-positive rate and is much faster at detecting OWASP Top 10, API, and other advanced application attacks. 

Detecting injection attacks with SmartParse

Injection attacks are one of the most common attack paths to insert malicious code or read sensitive data without permission. With injection attacks via SQL injection (SQLi) or cross-site scripting (XSS), untrusted data is sent to an interpreter as part of a command or query in an attempt to extract sensitive data.

Figure 3: Web request tokenized and analyzed using SmartParse

Continuing our form submission sample from above, we now see the Fastly Next-Gen WAF tokenizing the same form submission response. Instead of flagging the payload as a SQLi attack, it understands the intent of the message, that words like select and where are normal and expected for this application. 

Attack Spotlight: Log4Shell

To address modern attacks like Log4Shell, our Product and Engineering teams developed a method for SmartParse to deobfuscate and distill complex Log4Shell attack payloads into their most basic form.

Figure 4: How SmartParse translates Log4shell attack payload

In this example, we processed the payload information into a single line of code, allowing SmartParse to easily detect Log4Shell attacks without requiring a rule for every variant. This reduces the amount of overhead and complexity to gain complete coverage at scale, which is critical for high-impact vulnerabilities.

“Because I'm an engineer, if I have questions they are usually pretty technical. It's a joy to work with support people that get the technical questions I have. And anytime I open a support ticket with Fastly, I get a response that same day from the right person with the technical proficiency to help me figure out my problem.”

Brian Benns

Senior Site Reliability Engineer, GIPHY

Block application attacks at scale 

Fastly Next-Gen WAF’s signals and rules enable you to go beyond injection attacks to automatically block OWASP Top 10 and other advanced Layer 7 threats at scale. Use a combination of out-of-the-box system signals (like SQLi, XSS, and CMD.EXE) and custom signals with our intuitive rule builder to create custom responses to malicious traffic for your unique environment.

A modern approach to rule building 

In our console, you can create custom thresholds, rate limiting, automatic blocking, and alert triggers specific to your web applications and business logic. You can apply them on individual sites (site rules) as well as globally (corp rules) to be easily used across multiple sites.

Figure 5: The Fastly Next-Gen WAF rule builder provides an intuitive interface for quickly setting up or modifying rules.

Unlike legacy WAFs, you can configure rules to create conditional responses based on our highly-accurate system signals and your own custom signals. Our modern approach goes beyond blocking to include signal tagging, rate limiting, and thresholding traffic requests, allowing you to take deeper control over your apps and APIs with a higher level of accuracy. 

In addition, our developer-first approach means our features are accessible via APIs, allowing DevOps teams to leverage Fastly's capabilities programmatically, ensuring seamless integration with CI/CD pipelines and other automated workflows.

Control application traffic with thresholding and rate limiting

While some companies are comfortable with going into immediate blocking mode with us, others might be more wary on high-impact applications or APIs. The Fastly Next-Gen WAF provides you greater blocking control and vastly improves detection accuracy by allowing customers to separate blocking decisions from initial detections using a threshold-based approach.

Instead of the legacy approach of blocking any incoming request that matches a regex immediately, our Next-Gen WAF uses SmartParse detections coupled with time-based thresholds and anomaly data around the request and response to make informed blocking decisions. By giving you an additional step between and immediate blocking, the Next-Gen WAF allows you to get out of logging-only mode faster while building confidence to get to an immediate blocking state. 

Figure 6: How to implement rate limiting and threshold blocking in the Next-Gen WAF console

Additionally, you can also use rate limiting to control the impact of client requests on your applications and APIs. Our rule builder allows you to customize your rate limiting based on a wide range of conditions, including custom signals. 

Easy virtual patching with Templated Rules

A virtual patch prevents the exploitation of a known vulnerability in either a module or framework. A virtual patch analyzes transactions and intercepts attacks in transit, so malicious traffic never reaches the web application. The resulting outcome from applying a virtual patch is that, while the actual source code of the application itself has not been modified, the exploitation attempt does not succeed. This buys time in the development process to fix the underlying vulnerability while the patch is protecting the application at runtime.

Fastly provides and enables you to apply virtual patches that address various Common Vulnerability and Exposures (CVEs) and immediately block requests containing the CVE exploit. Within the console, you can use templated rules that cover various CVEs in a default list.

Figure 7: In this templated rule example, the Fastly Next-Gen WAF can block requests that attempt to exploit the Apache Log4j JNDI vulnerability that leads to remote code execution.

Preemptive security with NLX

When incoming requests contain attacks, a snippet of that request is sent to our Cloud Engine (see the Data Redactions FAQ to learn how this is done in a safe and private manner). The Cloud Engine aggregates attacks from across all deployed agents, including other customers’ agents. When enough malicious activity is seen from a potential attacker, we process that information through our Network Learning Exchange (NLX).

Figure 8: How our Network Learning Exchange interacts with the Fastly Next-Gen WAF Cloud Engine

Fastly’s NLX is an IP reputation feed engine that flags malicious IP addresses as a signal, allowing you to take action on potential threats even before they reach your network. The breadth of our protection allows you to take a proactive approach to application security, and our research shows attacks are not as targeted as we think - 69% of IPs tagged by NLX targeted multiple customers, and 64% targeted multiple industries. 

Because NLX uses verified attack sources to analyze future potential threats, the Next-Gen WAF becomes a self-learning detection engine. By refreshing every 24 hours, the signal remains highly relevant and improves blocking accuracy while providing broader context around various attacks. During the period covered by our research, 54% of attacks were preemptively flagged by NLX, allowing teams to potentially stop over half of the attacks before they reach their systems.

Experience advanced detecting and blocking today

The Fastly Next-Gen WAF provides advanced protection for your applications, APIs, and microservices, wherever they live, from a single unified solution. We improve the standards of security efficacy by providing highly accurate protection in an easy-to-use, developer-friendly solution that scales with your business. To experience it for yourself, request a demo today.