When and how should you use a Web Application Firewall?

Some network engineers think that Web Application Firewalls (WAFs) are so complicated, they've been known to run away and hide for days when they've encountered one. Others believe that WAFs can only be worked on by a secret society of magicians with telepathic powers who ride on unicorns. I can confirm that both of these are myths.

On a serious note, WAFs are talked about a lot within the networking industry, but it's often not clear what they're for, how they work, or why anyone needs them. There is a great deal of marketing hype and vague claims towards 'improved security' surrounding WAFs, and I often find very little of substance on the topic on vendor websites. I hope to change that for you.

This is not a blog for those who spend their days knee-deep in WAF deployment and customization. Instead, this blog is for those of you that know what a Web Application Firewall (WAF) is, but haven't got down into the finer details yet, and want an easy-to-understand, 10-minute summary of what it's all about. Let's go!

How to train your Web Application Firewall

Training a WAF can be difficult - but not impossible. Find out how we recommend doing it, and how our tools make the whole process easier.

Insights from the load balancer expertsAaron West

The first line of defence is your network firewall

The first line of defence is a network firewall, and not a Web Application Firewall (yes, really!) and there must be a separate network firewall in front of any other parts of your network, including appliances such as a load balancing solution. This is a principle referred to as "defence in depth" where having multiple levels of security improves the overall resilience of a network topology.

Network firewalls look at the protocols, connections, and interfaces at the Network Layer, whereas WAFs look at requests operating at the Application Layer. The Network Layer (Layer 3) looks at how it's being passed from one place to another. The Application Layer (Layer 7) serves as the business part, if you like, of what is actually going on within a connection – that is, the transaction itself. Firewalls are typically Layer 3 or Layer 4 but also, there are application aware firewalls that act at Layer 7.  A Layer 7 firewall and WAF are very similar but not exactly the same.

Network firewalls consist of, at minimum, what we call a packet filter. Packet filtering happens at the Network Layer (Layer 3). Packet filters are exactly what they sound like: they look at each packet and say, "No, no, I don't want you," or alternatively, "OK, fine, you can go through," based on filtering rules that specify which ports, IP addresses and protocols are allowed.

Some of the more advanced network firewalls also do what is called stateful inspection, where they examine packets over a period of time and look at the incoming and outgoing packets across an entire connection history. With stateful inspection, the total exchange of conversations taking place is observed as each packet moves back and forth.

WAF: the second line of defence

A WAF looks at traffic from a different perspective to a network firewall. Whilst a firewall at the network layer filters out bad requests (e.g. from a blocked IP address, from a port we’ve decided we want to block, a specific request from a bad protocol), a WAF looks at the actual body of the request to see if it’s got anything naughty in it that might cause our server to do anything we don’t want it to do.

The WAF rules determine the decisions that are then made as each request is received. The decisions are made based on the rule set, which formally defines what is a "good" and "bad" request in terms of a cascading set of rules, before then passing on the requests that aren't blocked (or are specifically allowed).

WAF rules can allow all requests that are not blocked, block all requests that are not allowed, or "shades of grey" in between. Which of these is used for a given rule depends on the type of attack that it is intended to prevent and the requirements of the application that it is protecting. In some cases, you might choose to always allow a particular type of Web request if it is a specific application requirement, although you need to accept the security risk that comes with that approach.

In terms of the "thought process" that the entire stack goes through when receiving requests on a load balancer with a WAF, it goes something like this:

1. Any request that passes through the network firewall, and then through the ADC's baseline firewall, hits the WAF.
2. If the request is a secure Web request (HTTPS), it first needs to be unsecured to plaintext HTTP so the WAF can find out what's in it. This is done using a process called SSL termination. All ordinary plaintext HTTP traffic that isn't secure goes straight to the WAF.
3. All requests then come into the WAF "front end" via HTTP, which is where they enter the WAF rule engine (ModSec running on Apache, in our case) so that they can be inspected. These rules then determine what happens to the request based on pattern matching, rate limiting, geographic location, or other criteria.
4. All requests that are not blocked are then passed on to the Virtual IP (VIP) service, which contains the pool of Real Servers across which connections are being load balanced. The traffic to the Real Servers can be either via HTTP directly, or if required, the traffic can be re-encrypted back to HTTPS for a secure onward connection.

Tailoring our WAF and network firewall

Loadbalancer.org provides the ability to tailor what is blocked by the combination of the network firewall and WAF using our custom WebUI configuration tools, giving our customers a number of different options:

1. Our Firewall Lockdown Wizard, when enabled, locks the appliance interface and sensitive services on the ADC as its default behaviour, so that the appliance can only be accessed from a specific network (or group of networks). A new WAF service is pre-configured with standard blocking functionality for the industry-standard classes of attack defined in the OWASP Core Rule Set.
2. Our customers can then use the default ADC firewall and WAF functionality as a starting point, specifying their own rules to block specific types of traffic to satisfy any custom requirements that are not covered by default. It is also possible to improve the network firewall rules to maximise the benefit of the WAF. For example, if we filter out a particular type of protocol that we don’t want to even get to the WAF, it’s not something the WAF even has to filter.
3. Loadbalancer.org can create custom WAF and network firewall rules for you that will protect your specific application, using a custom script for our built-in Firewall Lockdown Wizard and a customised WAF rule set. Sometimes, it can be quite a challenge working out how to structure network firewall and WAF rules so that they do exactly the right thing for a given application and potential attack surface. We've been doing this for ages, though, so we know exactly how to get it right for you.
4. Our WAF can also be "trained" by disabling rules that block good traffic, tweaking anomaly scores, and paranoia levels as required, so only the traffic that actually should be filtered is actually filtered – at least, as much as is feasible without compromising the protection offered too severely.

How to use WAFs responsibly

Many of our customers choose not to use our WAF, for a range of good reasons. Here's a couple of scenarios where you too might choose NOT to use the WAF in our product:

1. You might already have a WAF on your network firewall running in front of the load balancer, and therefore the Loadbalancer.org WAF is not required. You can have a WAF that's not on a load balancer. Some appliances are standalone WAF products that also include a network firewall or CDN e.g. Cloudflare or Imperva. A WAF can be separate from a load balancer, and it is unlikely that there will be any security benefit at all to having multiple chained WAFs in the topology – especially if they all implement broadly the same set of rules.
2. A WAF may not be required for your application. Whilst it is rare in the current industry, you may have static content only, which means you don't need your web apps going through a WAF. However, there is still the possibility of malformed requests exploiting vulnerabilities in the Web server used to host the static content.
3. A WAF is not protocol-compatible with your application. For example, you might have an app that's not suitable for WAF protection (e.g. TCP mode traffic), or you don’t want to do SSL termination on the load balancer.
4. The traffic characteristics might mean the rate or size of the HTTP requests is too high for a WAF to be practical due to the resulting resource requirements and performance impact.
5. There could be an unacceptable operational risk to legitimate traffic being blocked due to unforeseen triggering of one or more WAF rules, and hence denying access to critical applications.

The take-home message

An ADC can be used to support overarching security objectives, but it is not a security device in its own right, and should not be used as a first line of defence. Instead, its primary function is to optimise and manage application traffic and improve performance by balancing loads, offloading SSL processing, and caching content.

ADCs can provide features that can help support the overall security ecosystem and make your applications more secure, and Loadbalancer.org takes measures to ensure our products are as secure as possible. However, security can only be improved in a meaningful way by embedding good network security principles across your entire infrastructure and organisation. Security is not something that can be provided by a product, but is a general ethos and approach to network administration.

To make this point a little more bluntly, I consider that the term "security appliance" is something of a misnomer: that means we are definitely not one! This is because no single component of your network can achieve better security in isolation. The best firewall technology in the world can only deliver a limited overall security benefit within a fundamentally insecure network. Therefore, purchasing an ADC with security as your primary objective would be misguided.

Before embarking on using a WAF by default, first understand what you’re actually trying to achieve. In many cases, it may be that a WAF is more trouble than it is worth, especially if the application's scope will be limited by what it has access to.

If you'd like some general advice on WAFs, please feel free to get in touch with our team: we'd be glad to tell you the honest truth, as we have always promised to do for over 20 years.