Search Topic

CDN + WAF: Enhancing and Protecting Your Website

CDN + WAF: Enhancing and Protecting Your Website

Implementing a robust content delivery network (CDN) and an advanced web application firewall (WAF) can be more than a technical upgrade—it can be a critical architectural and strategic technical consideration. This is because digital threats constantly evolve, and site performance expectations are at an all-time high.


In the following, we’ll examine how amazee.io’s managed CDN and advanced WAF offerings can make your site faster, more reliable, and more secure. To do this, we will explain CDNs and WAFs in more detail. Next, we’ll deep-dive into amazee.io’s managed CDN offering and explain how our advanced WAF works. We’ll then explain why CDN and WAF are so important and lay out what a fully managed service like ours will mean for your business.


The Evolution of Web CDNs


Originally, websites were hosted on servers co-located in fixed locations. This legacy setup often struggled under high traffic, leading to slow load times and potential outages. The introduction of CDNs changed the website hosting game. 


What are CDNs? CDNs cache content across a globally distributed network of nodes to ensure users receive cacheable data from the closest server, reducing latency and improving access globally.


amazee.io’s Advanced CDN Capabilities

Modern CDNs like the one provided by amazee.io transcend this legacy role, offering content caching and optimized delivery routing using advanced techniques to ensure content is available via global points of presence (POPs). They also provide the quickest load times by dynamically adjusting to changing internet conditions and working around outages and congestion. 


In addition, modern CDNs incorporate filtering-based security features directly at the edge of the network, enhancing your overall web security.

Deep Dive into WAFs

What is a WAF? A WAF secures a website by monitoring and filtering incoming traffic to block hacking attempts and other unwanted traffic. It's a shield against application-layer attacks, such as the OWASP Top-10, including attack vectors like SQL injections, cross-site scripting (XSS), code injection, and more. 


Our amazee.io advanced WAF leverages several techniques to adapt dynamically to new threats in real time, providing a defensive layer that grows smarter over time.


Exploring amazee.io’s Managed CDN Filtering and Advanced WAF

Managed CDN Filtering


When choosing a CDN and WAF solution for your organization, comparing apples to apples is essential. Many traditional WAFs operate based on pattern-matching rules, creating black-and-white criteria for blocking or allowing requests. Most modern CDNs today also support some basic filtering based on pattern matching (or regular expressions, as we call them in development). 


It is not uncommon for vendors to market a CDN with this basic filtering as a CDN + WAF. However, while the basic filtering offers similar functionality to a traditional WAF, it does not compare to the dynamic capabilities of a next-generation WAF like the one used by amazee.io. 


But before we delve further into our Advanced WAF, let’s look at some examples of the types of protections and rules you can implement with a modern CDN that offers helpful protection for your web presence. These filters take the form of rules written in Varnish Configuration Language (VCL), which the CDN loads and enforces. These .vcl files can be customized, and we at amazee.io keep an ever-expanding set of global .vcl files. These global .vcl files are updated anytime we gain valuable knowledge or insight from specific customer situations so that all our customers may benefit from said experiences.


Below are examples of how we use .vcl rules to enhance our CDN’s protective capabilities:

1. Custom Filtering to Block Unwanted Traffic

One significant feature of our WAF is its ability to filter out unwanted traffic before it impacts the server load. For example, requests to non-existent resources like `/autodiscover.xml,` commonly targeted by bots, are automatically blocked using the following VCL snippet:

# Autodiscover.
if ( req.url.path ~ "(?i)/autodiscover\.xml$" ) {
  set req.http.X-Waf-Block = "1";
  set req.http.X-Waf-Block-Id = "autodiscover";
  error 600 "Blocked";
}

This effectively reduces unnecessary load on your infrastructure by preventing these requests from consuming resources.

2. Advanced SQL Injection Prevention

SQL injection is a prevalent threat that can expose sensitive data and compromise your database. Our WAF uses sophisticated pattern matching to detect and block these attempts:

# Obvious SQLi in URL.
if ( req.url.path ~ "select unhex" ||
  req.url.path ~ "select name_const" ||
  req.url.path ~ "unhex\(hex\(version\(\)\)\)" ||
  req.url.path ~ "union select" ||
  req.url.path ~ "select concat" ||
  req.url.qs ~ "union select" ||
  req.url.qs ~ "select concat") {
    set req.http.X-Waf-Block = "1";
    set req.http.X-Waf-Block-Id = "sqli";
    error 600 "Blocked";

These rules ensure that common SQL injection patterns are recognized and mitigated instantly.

3. Cookie Stripping for Static Assets

To enhance caching efficiency, our CDN strips unnecessary cookies from requests for static assets, which allows these resources to be cached more effectively:

# Always cache the following file types for all users.
if ( req.http.X-Pass == "0" && req.url.ext ~ "(?i)^(7z|avi|avif|bmp|bz2|css|csv|doc|docx|eot|flac|flv|gif|gz|ico|jpeg|jpg|js|less|mka|mkv|mov|mp3|mp4|mpeg|mpg|odt|otf|ogg|ogm|opus|pdf|png|ppt|pptx|rar|rtf|svg|svgz|swf|tar|tbz|tgz|ttf|txt|txz|wav|webm|webp|webmanifest|woff|woff2|xls|xlsx|xml|xz|zip)$" ) {
  set req.http.X-Static-Asset = "1";
  unset req.http.Cookie;
}

This example demonstrates how cookies are processed and stripped unless they are essential for the application, thus optimizing both security and performance.

4. Stale-while-error and stale-while-revalidate

# Set stale_if_error and stale_while_revalidate.
# @see https://docs.fastly.com/en/guides/serving-stale-content
set beresp.stale_if_error = 86400s;
set beresp.stale_while_revalidate = 60s;

Sometimes, your site may experience an error and go down, or the CDN may need to refresh its version of your cached assets. In these cases, there are ways to avoid impacting user experience or performance using features like stale-while-error, which will serve a cached version of your site in case of errors or downtime and prevents users from experiencing downtime, and serve-while-revalidate, which will serve a cached version of your site. At the same time, the cache is refreshed in the background, which prevents users from experiencing longer load times if the cache happens to be revalidating during their visit.

Advanced WAF


Our advanced WAF not only defends against traditional threats but is also equipped to tackle modern, sophisticated attacks through a combination of manual tuning, algorithmic analysis, and intelligent decision-making.


OWASP Top 10 + Beyond


We can’t discuss WAFs without mentioning the OWASP Top 10. OWASP is the Open Web Application Security Project, an international non-profit focused on web application and API security. They make all their materials available for free so that anyone can educate themselves and work to improve the security situation of their web applications. They are most known for their OWASP Top 10, a report of the current top 10 most critical security risks facing applications. A team of security experts puts together the report and updates it regularly. You can learn more about these risks and how to combat them on the OWASP Project Top 10 page.


Below, you can see a report from the dashboard of an instance of our Advanced WAF dedicated specifically to tracking OWASP Top 10 attack attempts. We are looking at part of the WAF dashboard for a single high-traffic client site, and we can see that in the past 24 hours, the WAF has caught various OWASP attack attempts, including SQL injection (SQLi), Cross Side Scripting (XSS), Command Execution (CMDEXE), and Traversal. On the last day, 44,000 SQLi attacks were stopped alone. We can see from this that our Advanced WAF is highly aware of these types of attacks and monitors for and blocks them effectively.

OWASP injection Attacks

We can dig deeper into this report and look at specific requests flagged as OWASP attacks. In the screenshot below, we are looking at a single request flagged as an OWASP Traversal attack attempt. But we can also see that other characteristics of the request also resulted in security flags by the WAF: 


Site Flagged IP: The system had already flagged the IP of this request as having attempted malicious or suspicious behavior previously.

Code Injection: This request included a suspicious file code, which is a sign of an attempt at code injection.

SigSci IP: We will touch on this more later, but this flag tells us that we have learned from the more extensive network that this IP has been identified as a malicious actor due to behavior in other corners of the web.

Request; Signals/Payloads; Source; Response

Our dashboard reports allow us to view more than just OWASP attacks – they also allow us to view and compare overall requests. Zooming out beyond OWASP and looking at the rest of the traffic attempting to access our origin, we can see that about 60,000 of our total requests are OWASP attacks out of 8 million requests– just a tiny fraction of our total traffic to origin. And out of those 8 million total requests, we have 2 million total blocked requests – so beyond our 60,000 OWASP attack attempts, our WAF is additionally blocking 1,940,000 suspicious requests.

Dashboard

Machine Learning


One of our Advanced WAF's superpowers is its machine-learning capabilities. Across the web, there are bad actors, and when one WAF on the more extensive network of our globally distributed WAF system encounters and identifies one of these bad actors, it flags that IP for the whole network. Each local WAF instance learns from all of its siblings across the distributed system and is often prepared in advance when it encounters one of these bad actors.

Of course, there is a dashboard within the WAF where we can view a report of these occurrences. Referencing the screenshot below, we can see that in the past 24 hours, the more comprehensive network identified 186,000 requests from IPs as bad actors. We can investigate further by viewing the individual requests, and when we do, we will often see – as here – that the requests from these IPs are indeed attempting attacks. In the example below, we see three requests from advanced-flagged IPs from the network, and they attempt SQLi, Traversal, and Login / Authentication weakness, respectively.

Traffic Source Anomalies, and Requests

Advanced WAF: Dynamic Events


Our Advanced WAF also dynamically identifies and tracks Events. This ability exemplifies how state and history, with our WAF tracking behavior over multiple points in time, come into play. Traditional WAFs lack state and history, evaluating each request as “fresh” without the ability to put it in the context of other requests from the same source. amazee.io’s Advanced WAF can track separate requests happening across time, use context to identify that they are all part of one more significant event, and then make an intelligent decision about when and how to react to the event. 


Looking at our screenshot below, we can see an event and walk through the timeline of analysis and reaction. First, we know that we’ve blocked IP 51.15.238.160. This results from multiple steps, the first of which is that the more extensive machine-learning network already flagged this IP as a bad actor. So we had a heads up before this IP even visited us that they had committed malicious behavior elsewhere. Starting right out of the gate with that context, we see that the IP attempts some XSS on our site and is marked locally as a bad actor. Not only does it attempt XSS once, but it attempts XSS 10 times before it hits what we call a “threshold,” which we have set in the system. Hitting that threshold further flags the IP as malicious. 


A side note on thresholds: Why would we ever allow an IP to attempt XSS ten times before decidedly flagging it as malicious? We may have legitimate business tasks on the website that present as attack attempts. For example, our website might have a form that requires the submitter to “sign it,” necessitating the inclusion of a signature file at the end of it. This means a file will be included in the POST request, which our WAF will likely flag as a code injection attack. 


However, we know from our experience with this particular website that the alerts coming from this form are often false alarms caused by normal users submitting a signature file. To prevent false positives, we can set a thoughtful threshold allowing this action by a single IP a certain number of times before the WAF decides this is a series of malicious attempts. 


Additionally, this flag is taken in context with other flags. If this is the only activity, and it only happens a time or two, this might be a legitimate user submitting our web form, and blocking them would actually be detrimental to the website's business use. However, if the same IP repeatedly performs XSS and/or makes other malicious attempts alongside this request, we clearly need to block this traffic swiftly and decisively.


Back to our Event Timeline, the IP hits our threshold of 10 XSS attempts, and then the WAF blocks not just this one request but all requests coming from this IP, as it interprets this as a more significant event to be intercepted and blocked.

Events; Blocking requests from 51.51.238.160

Site Rules 


In a nod to traditional WAFs, amazee.io’s Advanced WAF also supports creating and enforcing rules. However, these rules transcend the traditionally boolean nature of WAF rules and allow for the creation of nuance within analysis and enforcement.


Take, for example, the first rule in the screenshot below. It is obvious and straightforward, without any nuance. If we have a request from an IP already identified locally as a bad actor →  block this immediately.


In our second rule, we can see more nuance in action. This rule says that the listed patterns often signal spam when present in the query parameters of the URL. It then applies a flag that communicates to the WAF, “This is likely spam,” but it does not immediately block the request based on this single flag. It creates this flag to be taken in context with other characteristics of the request – the presence or absence of other suspicious behavior or system flags – which then inform a more intelligent and nuanced decision by the WAF on blocking or allowing this traffic. 


The third rule we see here gets even more nuanced. Sometimes, legitimate business tasks on a website – as in our earlier web form example – can exhibit similarities to attack attempts. For example, Bob from marketing adds content to the website and enters a javascript snippet in the WYSIWYG. This is technically XSS because JavaScript is embedded in a form submission. However, in this case, Bob is not trying to hack the site. He’s just trying to do his job. We can put some nuanced rules in place to handle this exception and ensure that Bob is not blocked by the WAF every time he tries to get fancier than is wise with his WYSIWYG adventures. If we know, for example, that the company HQ is in Australia and that the path to the content edit form is node/\d+/edit, we can create a rule that says, “If the method is POST on this node/\d+/edit path coming from Australia, don’t flag this request as XSS.” 


This does not result in black-and-white block/allow behavior by the WAF. Instead, it provides context so that the WAF can make a nuanced decision about how to react. Perhaps there are other flags present on this request: maybe it’s from Australia, but the larger network flagged the IP. The WAF will evaluate these factors and determine whether to block the traffic.


To create an exception like this in a traditional WAF – something like ModSec - you’d have to write many specific and targeted exclusion rules manually. This sort of system is very high touch and requires constant tuning because false positives can result in traffic seemingly blocked for no reason. Additionally, systems like ModSec have “Top to Bottom” rule enforcement. They run through their list of rules looking for boolean block/allow criteria and react when they hit the first rule instructing them to block or allow. For this reason, rules towards the bottom of the ruleset may never be run, and the traffic may never be evaluated against them, even if they are rules targeted explicitly toward the very requests being assessed. This is an example of how the ability to evaluate requests against a much larger context of behavior over time is essential for thoughtfully shaping traffic at the WAF layer.

Site Rules

The Strategic Importance of Modern CDNs and Advanced WAFs

Implementing a sophisticated CDN and/or WAF is becoming essential for businesses aiming at high availability, competitive performance, and robust security. By leveraging amazee.io’s managed CDN and advanced WAF services, your website gains the edge in handling large traffic volumes and defending against increasingly complex cyber threats.


What a fully managed service means for your business

At amazee.io, our CDN and WAF services are fully managed by our dedicated Platform Team, ensuring that your edge infrastructure is continuously monitored, updated, and optimized without requiring direct intervention. 


This white-glove approach allows you to focus on your core business while we handle web performance and security complexities. 


We generally pair our services with a Technical Account Manager (TAM), who provides an additional layer of personalized support. Your TAM serves as your strategic partner, offering tailored advice and insights that align with your specific operational needs. They facilitate seamless communication between you and our Platform Team, ensuring that any specific requirements or issues are addressed promptly and effectively. 


With a TAM, you gain expert management of your CDN and WAF and a proactive ally in optimizing your infrastructure. 


Taken together, this makes our managed services a comprehensive asset for your organization’s digital presence.


Conclusion


As digital needs evolve, so does the necessity for more comprehensive and adaptive web delivery and security solutions. amazee.io’s advanced CDN and WAF technologies operate at the forefront (or should we say Edge?) of this evolving landscape. Our goal is to provide another CDN service and enhance your web strategy, ensuring your sites remain resilient, responsive, and secure against tomorrow's threats.


To learn more about how amazee.io’s CDN and WAF can add value to your business, contact us today or book a meeting with our technical team for an in-depth conversation!


Writer