This blog post is a recap of our recent webinar that addresses the questions:
The webinar discusses basic WAF concepts and provides a deeper understanding of how to deploy, configure, optimize and operationalize a WAF effectively.
Watch a recording of WAF Essentials Unlocked: Everything You Need from Beginner to Advanced webinar.
In the modern application security landscape, a WAF is a crucial layer of security for web applications. For the uninitiated, a WAF is a security device able to filter, monitor and block web traffic (HTTP). It’s worth noting that a good WAF is also bidirectional: it should be able to inspect the request traffic on its way to an application server in addition to (optionally) inspecting the response traffic being returned to a client.
A WAF sits between the users of a given web app and the application servers themselves. Precisely where the WAF lives is flexible: in a public cloud, in a DMZ near the web servers or even directly on the web servers themselves. Graphically, the situation looks like so:
It’s common to see a WAF bundled with a load balancer (reverse proxy). The point at which full, layer 7 (application layer) load balancing is taking place, it's relatively simple to feed the HTTP traffic through a WAF engine and gain its defensive and security benefits.
The load balancing layer can take care of things like:
In the realm of information security, the concept of defense in depth applies. The core principle is that the strongest way to secure a system, like a web application, is to use multiple, independent layers of security, like a multi-layered onion:
No single security measure is perfect in the real world: that includes WAFs. If one or more security measures are bypassed, then multiple additional defensive layers are still in place and able to stop attacks. A WAF is an important defensive layer for modern web applications, especially apps that are exposed to the wider public internet.
Imagine the following scenario: a department head or team lead turns around and says, “We need to put a WAF in front of our web apps. Our new security policy says so. Please make it happen.” A ‘mandated WAF’ deployment: it must be deployed and, quite likely, the task won’t be given additional time or resources to make it a reality.
When corporate IT policies are updated, they may gain a new requirement like “All external-facing web applications must sit behind a WAF for security.” Similarly, the need to meet external security standards, like PCI DSS, can have the same effect as they define similar WAF requirements for web applications.
These kinds of security requirements that demand a WAF be deployed typically require three things:
Interestingly, the specifics of deploying and configuring a WAF are almost always left unspecified. That’s left to the person deploying the WAF to figure out. It’s very rare for a security standard to define what sensitivity level a WAF should use of how aggressive a WAF rule set should be. Provided that a WAF meets the above three points it should fulfil the majority of “mandated WAF” scenarios.
Deploying this kind of WAF is fast and easy with the LoadMaster solution. The deployment looks as follows: point the LoadMaster solution at the application server and then enable the WAF engine:
Setting up the virtual service (a simple application layer reverse proxy) takes about 60 seconds: define the IP address that clients will connect to, define the IP address of the application server and that’s it.
Enabling the WAF engine is as simple as expanding the “WAF” tab in the web UI and checking the Enabled box, like so:
It’s that simple! Reviewing the requirements list:
Moving beyond a basic “mandated” WAF deployment, it can be given ‘teeth’ to create a more tangible, robust layer of security. This comes with a few prerequisites but is still well within reach of most people deploying a WAF.
Prerequisites for stepping up the level of security provided by a WAF:
Most WAFs use, or at least offer, the OWASP CRS rule set: this includes the LoadMaster WAF. OWASP CRS is the de facto set of free and open-source WAF rules and is published under the umbrella of the OWASP Foundation.
The CRS WAF rules are spread across four “paranoia level” categories of increasing security:
The lowest level, “paranoia level 1” (PL 1), is a subset of simple, uncontroversial WAF rules that are not prone to causing false positives (i.e. this subset of rules is rarely triggered in error by legitimate web traffic).
Moving up to PL 2 adds in an additional layer of rules. These extra rules provide a broader range of detection at the expense of added complexity with a higher likelihood of encountering false positives.
PL 3 adds in rules that are even more aggressive and error-prone. Finally, all the way up at PL 4, all rules are in play, including the most aggressive ones. PL 4 offers a very high level of security but also a very high number of false positives to be handled.
It’s important to strike the right balance between security and usability. While a “mandated WAF” might be sufficiently well served at PL 1, real-world web applications that are exposed to the public internet should be afforded the protection of PL 2 by default. This level gives good protection without overwhelming the WAF team with false positives to resolve.
High-risk and sensitive environments (e.g. banking, power plants, e-voting) may make use of PL 3 and PL 4, but specialist, high-paranoia level deployments like these typically come attached with ample time and consultancy needed to make them work correctly. The cost of high security is the time it takes to tame the very aggressive rules in the high paranoia levels.
What technologies are in use by the web application being protected? Does it use PHP? Does it use any Java? Are there databases involved? The WAF detection rules are grouped into different categories. If some of these categories are irrelevant then they can be disabled: this removes the rules from play and means they cannot cause false positives later.
Is it relevant to inspect the body of HTTP requests? While the HTTP request line and request headers are inspected by default, parsing and inspecting request bodies is optional.
For a typical WAF deployment, this option should be enabled under WAF > Advanced Settings on a LoadMaster solution:
This is particularly important when defending APIs as it allows for JSON and XML payloads to be parsed and inspected.
Also on the “Advanced Settings” page: how much body data should be inspected? This should be kept as low as possible to avoid opening the WAF up to denial-of-service attacks by maxing out its CPU.
A body size limit of 16 KkB may be sensible for production environments, although sometimes much larger limits may be required for compatibility reasons.
Which HTTP methods should be allowed? The default allowed methods are GET, HEAD, POST and OPTIONS. Some web apps may need additional methods like PUT, DELETE or more exotic ones.
Which file extensions should be forbidden? By default, malicious and anomalous-looking file extensions are flagged, e.g. “.bat”, “.config”, and “.ini”. While it’s unlikely, if any of these are legitimately needed then the default list should be amended.
Finally, which request header fields should be forbidden? Some legacy request headers are known to be open to abuse, e.g. “accept-charset” which can be used to smuggle payloads through a WAF undetected (request an exotic character encoding and the WAF may become blind if it's unable to read it!). If any of the default forbidden headers are legitimately required, then the list should be amended.
To make this process as simple as possible, a new template is being provided which features all the above steps presented in the style of an easy-to-follow questionnaire, along with documentation, added context, lists of default settings and recommendations.
When a legitimate HTTP request causes WAF rules to trigger in error this is referred to as a false positive.
False positives cause a variety of problems: they create a poor user experience, they make it difficult to detect and stop real attacks, and they potentially cause compliance issues. For a deep dive into false positives and resolving them, see our recent blog post: What Are WAF False Positives, Why Should I Care and How Can I Fix Them?
In short, false positives must be tuned away by changing if and when problematic rules are executed. The LoadMaster 360 platform features a suite of automated tools to assist with this process. Firstly, the WAF logs are inspected and the most likely candidates for being false positives are automatically flagged for attention:
This can take potentially hundreds of thousands of lines of log data and pick out a dozen or so false positive candidates for a human operator to look at. This is achieved by using smart filters and can save operators a significant amount of time.
Once a false positive has been confirmed, LoadMaster 360 will also automatically write the configuration needed to tune away the false positive:
This removes the need to learn any WAF configuration language which can be a major barrier to entry for non-WAF trained operators.
It’s crucial to test an application through a WAF. Setting up regular testing can help alleviate problems later down the line. For example, running an automated test suite after updating a web application may flag new false positives caused by new or changed features in the application itself. Better to flag new problems during testing rather than a customer running into them in production.
Even running a very simple test can answer the common question of “Is my WAF working?” Sending a simple request through the WAF stack like:
my-app.local/foo?bar=/bin/bash
is sufficient to trigger the Unix command injection rules and generate a log entry. If a log entry appears flagging “/bin/bash” against the test machine’s IP address then the WAF is confirmed to be working (‘detecting threats’ and ‘logging detection events’, as mentioned earlier).
Consider a situation where a backend web application has a known vulnerability but cannot be patched. There are many reasons why this might be the case, for example:
This is where virtual patches can help.
If the nature of the vulnerability is well understood, which is often the case, it may be possible to write a custom WAF rule(s) to detect and block attack attempts. For example, if an exploit requires sending a specially crafted HTTP POST request to the vulnerable location /api/foo there would be several possible approaches:
These kinds of approaches are all possible using the LoadMaster WAF engine. The custom rules constitute a “virtual patch” to secure access to the web application until the application itself can be fully, properly patched.
Starting with a “mandated WAF”, it’s quick and easy to get set up. Take a LoadMaster appliance, point it at the web server(s) to be protected, click “Enable” in the WAF tab, and that’s it: most security requirements that demand the presence of a WAF are immediately satisfied.
Giving the WAF more teeth involves choosing the right paranoia level (security level) to operate at. It also involves having a bit of an understanding about the application and its traffic and configuring the WAF to suit.
False positives, when they occur, need to be tuned away. There are a variety of ways to do this and it’s an expansive topic (and the recent subject of its own blog post). LoadMaster 360 does a lot of the heavy lifting automatically with its smart log filters and automatic rule tuning tools.
Finally, several advanced ideas can extend a WAF’s capabilities and usability. Testing is key as an application must work correctly when run through a WAF. Not just today’s build of the app, but the next patch version and every subsequent version afterward. Automated test suites can help. For situations where patching vulnerabilities in software isn’t an option, virtual patches can bridge the gap between “vulnerable right now” and “fully patched tomorrow.”
All of this, and more, is possible using a LoadMaster load balancer.
Take our 30-day free trial for a test and see if it meets your needs as a user-friendly load balancer with a built-in WAF.
Reach out with any questions you might have and we’ll be happy to support you on your load balancing and WAF journey.