Insight into Web Application Firewalls - Part 2

balaji
By balaji

April 17, 2010

In the previous article, we discussed about the basics of WAF, procedure to connect Apache with Tomcat and the installation part of ModSecurity. We took ModSecurity (an open source WAF) to understand the detailed aspects of the WAF. In this article, we look at the configuration part of a WAF. We will create some simple as well as complex rules to filter HTTP traffic. We would also discuss the use of Regular Expressions to create complex rules.

insight-into-waf-p2.jpg

In the previous article, we discussed about the basics of WAF, procedure to connect Apache with Tomcat and the installation part of ModSecurity. We took ModSecurity (an open source WAF) to understand the detailed aspects of the WAF. In this article, we look at the configuration part of a WAF. We will create some simple as well as complex rules to filter HTTP traffic. We would also discuss the use of Regular Expressions to create complex rules.

Configuring WAF

After having restarted Apache, mod_security will be installed but not activated and enabled. In order to activate mod_security, we need to add some directives to httpd.conf file. Here are few examples to get started:

#Enable mod_security module
#Possible values ON/OFF/DynamicOnly
SecFilterEngine ON
#Retrieve request payload
#Possible values ON/OFF
SecFilterScanPost ON
#Verify the encoding of URL request
#Possible values ON/OFF
SecFilterCheckURLEncoding ON
#Enables logging Functions
#Possible values ON/OFF/RelevantOnly
#ON - All HTTP requests will be logged
#OFF - Nothing will be logged at all
#RelevantOnly - Requests matches any filter will be logged only
SecAuditEngine ON
#Used in conjunction with SecAuditEngine and
#specifies the location of the log file.
#Possible values – File path
SecAuditLog /log/log_file.log
#Allows scanning of POST request.By default only GET requests are scanned
#Possible values ON/OFF
SecFilterScanPOST
#Default action when a filter is matched. In below example, mod_security
#will reject all invalid requests with status 403 and log this action
#Possible values : Discussed in later part of the article
SecFilterDefaultAction "deny,log,status:403"
#Disallows directory traversal
SecFilter "../"
#Deny all request containing /bin/bash string
#Possible values ON/OFF
SecFilter /bin/bash
#Allows to set debug log path
#Possible values – Debug log file path
SecFilterDebugLog /log/mod_debug_log
#Disallows directory traversal
#Possible values 1 and 4
#1 for production and 4 for testing
SecFilterDebugLevel 4

Processing Order

The Mod_security module will first look for the SecFilterEngine directive. Only if this directive is set to ON, will the mod_security module continue processing. Similarly, if SecFilterEngine is set to DynamicOnly and current request is for static resource, processing will be terminate immediately.

Now If SecFilterEngine is ON, mod_security initializes its structure. Mod-security reads the entire body part line by line and checks requests against rules configured in the module. If any part of the request fails validation, mod_security directly jumps to the default action (as set in the SecFilterDefaultAction directive.) For example, if a rule is configured to accept only numeric values then any attempt to send nonnumeric value will be rejected and default action will come in place.

Defining Your Own Rules

The best part of mod_security is its Rule engine. The module allows users to easily define and implement rules. Rules needs to be inserted in httpd.conf file as mentioned earlier. One can define a rule by a single keyword. The SecFilter directive performs a broad search against the request parameters.

Here is the Syntax for the SecFilter directive:

SecFilter <em>Keyword</em>

This keyword can be as simple as 100 or Select. The module will look for any occurrence of specified keyword in entire HTTP request; in this case 100 or Select.

To optimally use mod_security, use regular expressions to make search patterns effective and accurate. With the help of regular expression we can have filter on ranges, digits, wildcards or on combination. An example of regular expression is ^(|[0-9]{1,4})$ which will look for all numeric entries between 1 and 4 digits in length.

Broad rules are easy to write but they become a little complex at times. The wide use of broad rules eventually results in false-positive responses and sometime restricts legitimate users to make use of the system.

In order to fine tune your search pattern to create a powerful and more effective rule base, ModSecurity provides many advanced options. One of these is the SecFilterSelective directive. This directive allows to filter on CGI variables, such as QUERY_STRING, REMOTE_ADDR, PATH_INFO, REQUEST_URI, and TIME_YEAR. See ModSecurity documentation for complete list of CGI variables. The use of arguments is also supported in ModSecurity. Rules can be specified to check against arguments carried in any HTTP request. We will take an example to understand this feature in the later part of the article.

Available Actions

As seen in the earlier part of the article, there are a number of actions available in ModSecurity, a few of them are:

  • Allow: Allows matching requests through.
  • Deny: Stops the request outright, returns a HTTP 500 error code by default.
  • Status: Used to specify an alternate HTTP error code.
  • Redirect: Matching requests are redirected to the provided URL.
  • Log: Logs request only.
  • Nolog: Does not log request.
  • Chain: Allows you to create list of filters.

Now let's take a look at couple of examples to understand the SecFilterSelective directive:

SecFilterSelective REMOTE_ADDR "^192.168.53.$" log, chain
SecFilterSelective Request_URI "index.htm"
Redirect:http://test.com/home.htm

In above example we have created chain of two rules. First rule will check whether request is coming from 192.168.53.x subnet. If yes then the rule engine will pass control to the second rule. The Second rule checks to see what file is requested. If the requested file is index.htm, the user will redirect to an alternate location (home.htm).

SecFilterSelective ARG_username "^admin$" chain
SecFilterSelective Remote_ADDR "^192.168.52.4&"

In this example, first rule looks for the argument username carried in HTTP request. If the username starts and ends with admin then the second rule will be looked at. The second rule allows the request to be further analyzed if its destination address is 192.168.52.4.

Conclusion

Web Application Firewalls are an excellent addition to secure web servers from application layer attacks. A well configured WAF can protect web servers from almost all kind of application layer attacks including XSS, SQL Injection, and Parameter Manipulation attacks. With its ability to filter on any HTTP, HTTPS GET and POST request, we can address all malicious requests targeting our web servers. Support of Regex (Regular Expressions) allows security admin to create more powerful rule base.

WAF is not intended to take place of Firewall, IDS or IPS, it has an ability to filter HTTP traffic. Overall WAF is a great concept to secure web servers from Layer 7 attacks and it can secure badly coded applications to some extent.

References


Tags: Technical

About

balaji

SUBSCRIBE TO OUR BLOG

Buyers-Guide-Collateral

WHITEPAPER

Buyer’s Guide to Managed Detection and Response

Download
MDR

Get AI Powered

Managed Detection and Response

MDR-learmore-btn

 

MDR-Guide-Collateral

REPORT

AI-Driven Managed Detection and Response

Download Report
Episode

EPISODE-25

Red-LineAsset-6

Why Your ‘Likes’ on Facebook May Be Revealing Far More than You Thought

Click URL in the Post for the Full Podacst
  • FacebookAsset
  • LinkedinAsset
  • TwitterAsset