In-network WAF vs. SaaS WAF

Traditionally, web application firewalls (WAFs) were appliances deployed in the same network as the web servers. Let’s call them “in-network WAFs.” These in-network WAFs were physically close to the web servers they protected. Even in the cloud, WAFs usually were deployed in the same private network as the web servers. The cloud providers (such as AWS, Azure, and Google Coud) all offer versions of in-network WAFs for customers to deploy alongside their web services. These WAFs acted as gatekeepers for all HTTP traffic, checking every request and filtering out malicious content before it reached the web servers.

Fortra Managed WAF is an in-network WAF with managed service. Once a website is setup, nothing reaches the web servers without first passing through the WAF.

Things changed with the rise of SaaS services. Along with SaaS applications, WAFs became available as SaaS services from CDN companies like Akamai, Cloudflare, and Fastly. Similar to other SaaS services, SaaS WAFs share a pool of computing resources at the content delivery networks (CDN) companies’ data centers. These CDN data centers are physically separate from your web servers, often by hundreds of miles.

The big benefit of SaaS WAFs is they require no deployment. If you want to check the “WAF compliance” box, all you need is a credit card and about 30 minutes.

The majority of WAFs today are deployed as SaaS WAFs. I get it: Ease of deployment is important. But “easy” often means cutting corners. Cutting corners is a bad idea for cybersecurity.

How SaaS WAFs Took Over the WAF Market

The internet grew up delivering web pages to browsers. Content delivery networks became a crucial backbone of the Internet. Caching web content in geographically dispersed endpoints around the world was a brilliant idea that accelerated web page load times. Over time, CDNs expanded into an enormous $25 billion market.

With data centers around the world, CDN companies began asking themselves: What else can we sell? They needed a way to grow.

Consequently, CDN companies began offering content hosting services. They began offering network services. They began offering security services. This led to the birth of the SaaS WAF. The SaaS WAF is a sideline business for the security division of the CDN company. It’s an upsell for existing CDN customers. It provides just enough WAF to satisfy the “WAF compliance” checkbox.

But what if you want real WAF protection? What if your goal is actual security?

It’s like the pharmacy department in a supermarket. There are just enough meds and vitamins there for your grocery run. But if you’re seriously ill, you need a real pharmacy.

Why In-network WAFs Are Better

Imagine a house with your family inside. There’s a big yard around the house. There’s a fence around the entire yard.

You happen to know that some bad guys are trying to break into your house, so you want to put up some security. Would you put the security on the fence gate, or would you put the security on your house doors?

If you have something important to protect, you need security close to what you are trying to protect. It doesn’t make sense to put your best security far away from your assets. There are just too many ways for bad guys to get past a fence.

Does it make sense to put your WAF hundreds of miles away from your web servers, across the public internet?

If you search for WAF architecture on the internet, you won’t find discussions about WAF placement. CDN companies don’t want to talk about this. This is the SaaS WAF’s biggest flaw. CDN companies know this, and they can’t fix it.

Problems with SaaS WAFs

What’s so bad about having the public internet between the SaaS WAF and your web servers?

1. Bypass prevention

For any WAF deploy to be effective, this is absolutely critical. You must ensure that traffic to your web servers pass through the WAF first. If any traffic can bypass the WAF and go straight to the web servers, your attackers will find it: There’s no point in having a WAF.

In-network WAFs: Bypass prevention is easy. If your WAF and web servers are in the same cloud network (AWS, Azure, Google Cloud), simply configure security groups on the WAF and web servers to limit access to each other. In your own data center, use a firewall or router with access control between the WAF and web servers. You also can choose not to assign public IPs to the web servers for extra security. For the truly worried, physically cable the WAF to the web servers. Point is: The WAF is in the same network as the web servers. You have lots of options.
SaaS WAFs: Bypass prevention becomes far more difficult. The SaaS WAF must send traffic across the Internet to your web servers, so you must allow Internet access to your web servers. How do you ensure that all traffic to your web servers first passes through the SaaS WAF?
- One approach for SaaS WAFs is to add firewall rules limiting inbound traffic to the SaaS WAF provider’s networks. Sounds good … except CDNs (and SaaS WAFs by extension) have multiple data centers worldwide, and an ever-changing list of source IPs. Keeping up with a CDN’s IP blocks is a never-ending effort. Missing IP block updates could lead to WAF bypass or blocking legitimate traffic. In practice, few SaaS WAF customers take this approach.
- The main bypass prevention technique CDN/SaaS WAF companies recommend is HTTP headers. The SaaS WAF adds HTTP headers to signal that traffic came through it. Problem is: Attackers also can add the same HTTP headers. To make matters worse, these SaaS WAF header names are published online. Even if you use custom header names, they are still fixed values. Once determined attackers learn the header names, they have an open path to your web servers.
- Another technique for SaaS WAFs is to hide your web server IP. That’s security through obscurity, which doesn’t work. An attacker just needs to lookup your public IP blocks and run a scan. Or a random attacker’s scans can land on your 80/http and 443/https ports. Hiding your web server IPs is not security.

Without robust bypass prevention, SaaS WAFs may provide a false sense of security. Legitimate users might be the only ones going through the SaaS WAF. Attackers are bypassing the fence and coming in through the front door.

2. Internal websites & Non-production environments

Most organizations have internal applications on their private networks. These applications reside behind the corporate firewall and are not exposed to the Internet. Some of these appls may be connected to data and resources that require serious access control, even from internal users (think HR information, source code, patient records, secret world domination plans) Approximately 43% of cybersecurity breaches result from insider threats. How do you secure these websites against every contractor or intern who comes through the door? What about those Wi-Fi and VPN-connected laptops in the field?

Also consider your non-production environments (stage, QA, test, development): While your production environments are likely protected by a WAF, shouldn’t your development and testing teams use the same architecture as production? This way, they can adhere to the same security standards and troubleshoot issues before promoting code.

In-network WAFs: You are in complete control here. The decision to protect internal websites and non-production environments is yours. In-network WAFs sit on the same network, alongside your web servers. If you want protection for internal websites, simply add the website to your WAF. You can always change your mind later.
SaaS WAF: How would you protect internal websites and non-production environments using a SaaS WAF?

Would you route internal traffic across the Internet to the SaaS WAF and back again? If you haven’t locked down your CDN’s source IPs on the firewall (see #1 issue above), you would be opening your internal applications to the Internet. Does it make sense to expose internal websites to the Internet?

While theoretically possible, it makes no sense to use a SaaS WAF to protect internal websites and non-production environments. If you opt for a SaaS WAF, you’ve essentially decided not to protect these internal resources.

3. Flexibility

By their nature, SaaS WAFs are monolithic beasts. To maximize profits, they run a single application code base that serves thousands of different customers simultaneously. These systems combine applications and infrastructure to handle a large number of concurrent connections. However, to run efficiently, SaaS WAFs offer limited customization.

Let’s say you needed a Federal Information Processing Standards (FIPS) compliant WAF. The SaaS WAF provider can’t mandate FIPS compliance for all their customers.

Now, imagine you needed a slipstream patch for your WAF to address a specific attack or application vulnerability. Applying this patch across the entire SaaS WAF infrastructure would be a time-consuming process. While your website is under attack, how long do you think it would take to get your custom patch with a SaaS WAF?

For some of our customers, their urgent needs are relatively straightforward – such as special forms of access controls or handling specific header types. However, making these changes for a monolithic SaaS WAF is significant, because they could impact thousands of customers.

In contrast, an in-network WAF allows for easy customization and quick turnarounds for issues and vulnerabilities. Since each a customer’s WAF is a separate deployment, an in-network WAF developer can make changes to a specific WAF without impacting other customers. For instance, one customer’s WAF can be FIPS-compliant without imposing the same requirement on others.