Web server protection: Web application firewalls for web server protection

Introduction

Firewalls are an integral part of the tools necessary in securing web servers. In this article, we will discuss all relevant aspects of web application firewalls. We’ll explore a few concepts that touch on these firewalls, both from a compliance and technical point of view, as well as examine a few examples of how we can use ModSecurity to enforce some rules.

Overview

Web application firewalls (WAFs) are security solutions that can be installed on web servers with the aim of protecting web applications from abuse by hackers. Put another way, a WAF is an application firewall for HTTP applications.

Learn Web Server Protection

Get hands-on web server security skills with nine courses covering infrastructure, hardening, command-line utilities, web application firewalls, active defense and more.

Start Learning

A WAF can either be a server plugin, appliance or filter and can be used to protect various web applications from attacks such as cross-site scripting (XSS) or SQL injection (SQLi). Some WAFs are open-source while others are proprietary.

Let’s consider some advantages and disadvantages of open-source WAFs.

Pros of open-source WAFs

The biggest advantage of open-source WAFs is that they are so much more affordable when compared to proprietary WAFs. If you do not want to spend huge amounts of cash on high-end WAFs, your best bet would be to acquire one of the most common and trusted WAFs such as ModSecurity.

Open-source WAFs offer great flexibility. This means that they are highly customizable and will allow you to perform configurations as per your project needs, and they will work absolutely fine. You are able to add various modules as you wish.

Cons of open-source WAFs

Since open-source WAFs are “freely” accessible, you are not going to get very lucky with configuration and troubleshooting. You will mostly and always have to do all the configurations by yourself, and things sometimes get very tangled.

Another disadvantage comes in the user-friendliness. The interfaces you get as you run these WAFs do not get very user-friendly and you have to figure out a lot on your own. This is especially true when it comes down to analyzing traffic.

Most open-source WAFs do not support caching. This is a bad thing because it affects the page loading speeds.

Some common open-source WAFs include ModSecurity, Ironbee, NAXSI, WebKnight, ShadowDaemon and lua-resty-waf, which is still currently in development.

WAF for compliance

WAFs can have compliance configurations wherein their operation can provide compliance reports based on required standards. An organization, for instance, may prefer a WAF with the capability to perform PCI DSS reporting.

Finding a WAF that checks all the boxes when it comes to compliance might be a bit difficult, and in such cases, organizations must ensure that they have controls in place that satisfy the needs that are not met by the WAF. This is important because during security audits and penetration tests, you will need to account for the missing gaps. These extra controls account for missing WAF configurations.

WAF for security

WAFs can provide very good security when it comes to protecting web applications. They effectively block against multiple attacks, preventing hackers from conducting information gathering and exploiting web applications. The techniques applied involve issuing rulesets that check against certain characters that can be fed into input fields.

Hackers can bypass WAFs by checking for blind attacks that still affect these WAFs in the event that security patches have been pushed by the vendor but the owners of the WAF have not updated. Such bypasses effectively allow hackers to circumvent security measures put in place to secure the web application against certain attacks.

Several WAF evasion techniques exist, which include the following.

1. Using wildcard characters

These characters (mostly the question mark character) are effective when bypassing rulesets.

The screenshot below shows an example of a bypass that can be applied to list the contents of the /etc/passwd file. This technique can be used to discover command injections.

2. Using comment syntaxes

This is effective when bypassing SQL injection. The idea here is to use a comment instead of using raw characters that will pop up an SQL error message.

Instead of using queries such as union+select, hackers can use comments as shown below:

/?id=1+un/**/ion+sel/**/ect+1,2,3--

3. Using concatenation

This is effective for bypassing rulesets that block command injections. WAFs that check against key words such as “etc” and “passwd” can be bypassed by using the command below at the URL section.

These are just a few examples of bypasses that can easily be avoided by installing the latest WAF updates and patches and running most recent WAF solutions.

WAF false positives

One of the best ways to judge between firewalls is on accuracy. WAFs have to determine whether the traffic coming into a web server or web application is legitimate or not. Attackers will attempt to mimic the activities of normal users, and this will eventually trick the WAF into producing false alerts. Ideally, these false alerts should not be reported; however, when they are, we refer to them as false positives. False negatives, on the other hand, are the malicious traffic which gets allowed through the WAF without getting flagged.

Avoiding false positive alerts is not as easy as it may sound. In fact, we highly encourage striking a balance between false positives and false negatives for a good firewall configuration. This balance is struck by considering two very important points:

1. Extremely tolerant firewall rules may result in malicious traffic being allowed in through the web application
2. Extremely harsh firewall rules may result in a lower risk of compromise while accidentally blocking legitimate user traffic

A good firewall configuration balance ensures that either of the two sides discussed above is not excessively leaned to.

ModSecurity and OWASP CRS

One of the most common open source WAFs is mod_security by OWASP. This is a cross-platform WAF, and for web servers such as Apache, it can be added on as a module in order to examine inbound and outbound traffic. ModSecurity is very powerful and offers a variety of functions:

1. Full HTTP traffic logging
2. Real-time application security monitoring and access control
3. Continuous passive assessment monitoring
4. Web application hardening
5. XML web service router

The OWASP Core Rule Set (CRS) is a set of generic attack detection rules that can be configured to check against the OWASP Top 10 security risks. When you install ModSecurity, it does not come with any rulesets, and so you can include the ModSecurity CRS for generic protection.

The OWASP CRS is not only supported by ModSecurity, but also various compatible WAFs. OWASP CRS is open-source and can be contributed to here. The OWASP CRS by default will produce false positives. We need to perform certain configurations to minimize these, in order to gain an accurate picture of attacks.

Creating mod_security rules

After the installation of ModSecurity, you will need to configure rulesets, since the default installation is without any rules. You can either decide to use the ModSecurity Core Rule Set or you can manually configure the rulesets. We discussed the CRS above, so we shall go ahead and discuss manual configuration below.

ModSecurity rules are made up of four parts:

1. Variables: This instructs ModSecurity where to look
2. Operators: This instructs ModSecurity when to trigger a match
3. Transformations: This instructs ModSecurity how it should normalize variable data
4. Actions: This instructs ModSecurity what to do if a rule matches

The structure of how a rule looks like is shown below:

SecRule VARIABLES "OPERATOR" "TRANSFORMATIONS,ACTIONS"

The following are some examples of rulesets that you can apply on your web server to check that certain rules are met.

Index file denial

The following rule accepts HTTP requests and obtains the URI portion, converts it to lowercase and searches for “/index.php”. If this is in the request, the rule drops the request.

SecRule REQUEST_URI "@streq /index.php" "id:1,phase:1,t:lowercase,deny"

Request method validation

Web servers tend to accept various request methods during client requests. The rule below ensures that client request methods are checked and satisfy the basic rules.

SecRule REQUEST_METHOD "!@rx ^[A-Z]{3,16}$" 

"phase:1,t:none,block,msg:'Invalid request method',logdata:%{REQUEST_METHOD}"

Detecting proxy requests

This rule below is used to detect CONNECT requests that are used for SSL tunneling.

SecRule REQUEST_METHOD "@streq CONNECT"

"phase:1,t:none,block,msg:'Proxy access attempt (CONNECT)'"

Restricting request methods

The rule below accepts only the commonly used request methods.

SecRule REQUEST_METHOD "!@rx ^(?:GET|HEAD|POST|OPTIONS)$" 

"phase:1,t:none,block,msg:'Only standard request methods allowed',logdata:%{REQUEST_METHOD}"

Request protocol validation

The following rule only accepts HTTP 1.0 and HTTP 1.1 protocol versions. Any other protocol versions, in most cases, are from scanners attempting to fingerprint the web server.

SecRule REQUEST_PROTOCOL "!@rx (?i)^HTTP/1.[01]$" 

"phase:1,t:none,block,msg:'Invalid request protocol',logdata:%{REQUEST_PROTOCOL}"

You can have a variety of configured rules, such as restricting content types (where you can allow only certain content types) and disabling file uploads (where you can effectively block any kind of file uploads).

Conclusion

WAFs are a very reliable method of securing your web server and web applications from cyberattacks. You do not even have to spend too much yet can enjoy a very detailed level of configuration should you decide to employ open-source solutions. You should also compare the performance of several different WAF solutions in order to decide which one works best for you.

Learn Web Server Protection

Get hands-on web server security skills with nine courses covering infrastructure, hardening, command-line utilities, web application firewalls, active defense and more.

Start Learning

Sources

1. Web Application Firewall, OWASP
2. Best Open Source Web Application Firewall to Secure your Web Apps, ServerGuy
3. PCI 6.6: Why You Need A Web Application Firewall And Network Firewall, Security Metrics
4. Web Application Firewall (WAF) Evasion Techniques, Medium (theMiddle)
5. How to tune your WAF installation to reduce false positives, O'Reilly