ModSecurity Framework Supports Web Application Security Core Rule Set

The latest version of ModSecurity, an open source web application firewall (WAF), supports Core Rule Set (CRS) that can be used for defining the rules to provide protection from zero day and other security vulnerabilities found in web applications. ModSecurity project team released version 2.5.10 of the firewall framework which also includes features like parallel text matching, Geo IP resolution, credit card number detection, support for content injection, automated rule updates, and scripting.

ModSecurity can be used for manually creating security filters, identifying attacks and implementing positive security input validation. There is also a new API for the Lua language that offers the developers a scripting platform for implementing complex logic to secure web applications.

ModSecurity Core Rules version 2.0, released last month, is an event-based programming language and includes the processing steps to look at any part of the transaction, transform the data to counter evasion, and to combine rules to form complex logic. Unlike other intrusion detection (IDS) and prevention (IPS) systems, which rely on signature specific to known vulnerabilities, the Core Rules are based on generic rules in order to provide protection from security vulnerabilities often found in web applications, which are in most cases custom coded. Core Rules framework uses the following techniques to provide web applications protection:

• HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
• Common web attacks protection - detecting common web application security attacks.
• Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
• Trojan protection - Detecting access to Trojan horses.
• Error hiding - Disguising error messages sent by the server.

InfoQ spoke with Ryan Barnett, director of application security research at Breach Security and the project lead of ModSecurity, about the new features and how ModSecurity compares with other web application firewall products.

How does ModSecurity framework compare with other Web Application Firewall solutions especially those based on hardware appliances, such as Cisco, Imperva, and Breach?

There are a number of differences between open source ModSecurity vs. other commercial offerings.
Hardware appliances vs. software solutions: ModSecurity is a software web application firewall engine that is an Apache module. This means that it is embedded within the destination web server instead of being deployed upstream on a separate device. It is possible, however, to configure Apache as a reverse proxy and achieve similar functionality however ModSecurity itself does not handle this aspect.

Advantages of software WAF solutions: There are some large scale deployment scenarios where distributing the WAF functionality within the destination web servers is more practical vs. horizontally scaling external hardware devices. Another advantage of being embedded is that you no longer need to deal with SSL decryption as the web server handles that pre-processing and passes the data off to ModSecurity decrypted.

Disadvantages of software WAF solutions:

• May not be feasible to add new software to web servers
• Will consume local resources
• Latency impact - many commercial WAF appliances can be deployed out-of-line in a sniffing mode which provides access and visibility to HTTP transactions without impacting the latency by being inline.

Advanced Functionality - commercial vs. open source: ModSecurity has an advanced rules language and a Lua API to allow for complex logic. It is possible to create both negative security (look for known bad input) and positive security (only allow known good input) rules for input validation types of protections. The main limitation with this approach is that ModSecurity does not have an automated method for creating these rules so it is a manual process. This is feasible only in one of two scenarios:

A. If the web application does not change frequently, or
B. In response to vulnerability scanning reporting where targeted positive security can be utilized.

ModSecurity is a fantastic tool for item B when used as a virtual patching solution to known issues. High-end commercial WAFs have automated learning and profiling mechanisms to create these positive security profiles and learn the expected interactions between clients and web apps.

Is the network router a better place to manage the security than a web server (Apache)?

It depends on the situation. Centralizing the implementation of security policies, log analysis and reporting is a good thing. From a technical perspective, however, ensuring that you are evaluating the data in the same context as the protected web application is critical and therefore getting closer to or inside an application is ideal. This lessens the likelihood of false negatives.

Does ModSecurity run on non-Apache web servers like Microsoft IIS and other web servers?

Not at this time, however that is in our roadmap. Our first goal is to make ModSecurity pluggable into IIS (as an ISAPI filter).

Can you elaborate on the new features in Core Rule Set project and how they help developers and web admins protect web applications against security vulnerabilities.

The new Core Rules Set (CRS) has many updates:

• Increased protection from attacks such as Cross-site Scripting (XSS), SQL Injection and Remote File Inclusions (RFI).
• Snort web attack signatures - Includes a large rule set of converted Emerging Threats' Snort web attack signatures and Breach Security Labs will continue to periodically release new signatures.
• Collaborative rules - Now operates in a collaborative fashion where all CRS rules can set transactional variables to specify what rule matched, the location of the match and what payload data matched.
• Anomaly scoring - Each rule now contributes to the overall anomaly score and users can choose what threshold is appropriate for their site.
• Easier exception handling - Users are now able to add in their own local exceptions to override the CRS checks without needing to edit the rules themselves.

What are the best practices and gotchas the network admins and developers should keep in mind when looking for a web app firewall solution?

Review the OWASP Best Practices: Use of Web Application Firewalls document. It includes tremendous information for evaluating if/when/how a WAF may help your organization.

Review the WASC Web Application Evaluation Criteria (WAFEC) document. This document outlines different WAF functionality. You should pick the features that are important to you and then use that as the basis for your WAF evaluations.

Setup a process for Incident Handling based on the data gathered by the WAF. Now that you have insight into the HTTP traffic, you will find out all sorts of things that you were previously missing. You need to ensure that you have an escalation plan in place for acting upon the new data received.

What is the future road-map of ModSecurity project?

In the long term - we are looking to make ModSecurity a self-contained library that will be able to plug into any number of different applications. Breach Security is actively participating in the Open Information Security Foundation's (OISF) project to create a new network intrusion detection system and we will be working on the HTTP engine. Much of this work will be incorporated back into ModSecurity development.