ModSecurity FAQ
Version 1.0 / (September 28, 2007) Table of Contents
Many people have contributed to this FAQ:
If you do not see your name on this list and you have contributed to the faq, please email Ryan.Barnett@breach.com. Suggestions for enhancements of this document are always welcome. Please email them to the Mod-Security-Users mailing list. ModSecurity™is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure. Check either the open source website, http://www.modsecurity.org/ or the commercial Breach website, http://www.breach.com/ Other good resources are available in the source distribution, including the ModSecurity Reference Manual on the Documentation page - http://www.modsecurity.org/documentation/index.html. There is also a excellent mailing list, mod-security-users. You can find info on how to signup at http://lists.sourceforge.net/lists/listinfo/mod-security-users. You can also join the #modsecurity channel on irc.freenode.net. Yes, only subscribers are able to post messages. As mentioned in the previous section, you will need to visit the mail-list website to register. Yes. There is a good chance that the issue you are facing has already been discussed and, most likely, a fix has already been presented. You can review the mail-list archive online at the ModSecurity project site on SourceForge. You can alternatively use your favorite search engine and run a few selected queries for past message topic threads that are archived to the various mirror sites. For example, if you had a quesiton about PCRE and ModSecurity, you could use the following search in Google to find past mail-list threads on this topic. If you can not find an answer to your question after doing some research, you should then send an email to the mod-security-users mail-list.
Breach Security Network (BSN) is a free service portal application (registration required) that provides ModSecurity users with essential information and software related to ModSecurity. It provides a detailed list of known issues, fixed problems, and improvements for every release of ModSecurity. BSN also includes access to development releases of rule packages and a repository of archived ModSecurity webcasts. BSN is the best location to stay up to date on ModSecurity product news and security updates. The open source mod-security-users mail-list is "best effort" support meaning that we will aspire to respond to emails as quickly as possible however the actual response time may vary depending on factors such as time of day, time of week and complexity of the question. If your email is sent on the week-end or if your question involves setting up test systems, unique configurations or interactions with a custom application then it may take some time to respond. If you are running ModSecurity and feel that the open source support is not sufficient for your needs, then you may want to consider purchasing a commercial ModSecurity Support package from Breach Security. There is a common misconcpetion that ModSecurity can only be used for negative policy enforcement. This is not the case. ModSecurity does not have any default security model "out-of-the-box." It is up to the user to implement appropriate rules to acheive the desired security model. That being said, these are the security models which are most often employed:
There are many significant changes and enhancemnts in ModSecurity 2.0 over the 1.x branch, including:
For more information, it is suggested that you review the SecurityFocus interview that Ivan Ristic gave on ModSecurity 2.0 as it outlines these new features in more detail. Due to the many changes in the ModSecurity 2.0 rules language, you can not directly use existing rulesets. You will need to translate the functionality of any custom rules into the new rules language. A migration matrix is available here that will assist with this process. The installation
procedures for installing ModSecurity 2.0 has changed from
previous versions. It now includes a The term "embedded" simply refers to the fact that ModSecurity, running as an Apache module, is running inside the webserver process. Most WAFs function as totally separate hosts and sit in front of the web servers. Running in embedded-mode has some advantages and disadvantages that should be considered:
The only difference with this deployment vs. an embedded one is that Apache itself is configured to function as a reverse proxy.
Yes, Breach Security has developed the ModSecurity Pro Appliance line of products for the exact reason. Building a ModSecurity reverse proxy appliance is a non-trivial task as you need specific skill sets - expert in Apache, web application security, and ModSecurity. There are many advantages to using the commercial product including:
No. Every Ruleset can have false positive in new environments and
any new installation should initially use the log only Ruleset version
or if no such version is available, set ModSecurity to Detection only
using the You need to set the the following two directives:
You need to enable the debug log with
Using ModSecurity requires rules. In order to enable users to take full advantage of ModSecurity immediately, Breach Security Inc. is providing a free Core rule set. Unlike intrusion detection and prevention systems which rely on signature specific to known vulnerabilities, the Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. Breach Security can provide you with training and professional services to assist you in doing that. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity. Some of the advantages of using the Core Ruleset are outlined in this Blog post. For more information refer to the Core Rules project page. In order to provide generic web applications protection, the Core Rules use the following techniques:
In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site. Unfortunately, no. The Core Rules takes advantage of the ModSecurity 2.0 rules language and is therefore not backward compatible. The first issue to realize is that in ModSecurity 2.0, the
If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -
If you want to disable both the rule and audit engines, then you can optionally add another ctl action:
Yes there are. Many of these differences are outlined in the Migration Matrix document listed previously. Another common rule difference issue that arises is when you want to create white-listed ModSecurity rulesets which enforce that certain headers/variables are both present and not empty. In ModSecurity 1.x, you could create one rule that handles this while in ModSecurity 2.x you would need to write a chained rule. On the surface, you might think "The 1.x rules way is better since you only need 1 rule..." however you need to realize that anytime you have rules or directives that implicitly enforce certain capabilities you run the risk of having false positives as it could match things that you didn't want them to. For instance, what if you have a situation where certain web clients (such as mobile devices) legitimately include some headers, however they are empty? Do you want to automatically block these clients? With the ModSecurity 1.x Rule Language, you would have to remove the entire rule. With the ModSecurity 2.x Rule Language, however, you are able to create rules to more accurately apply the logic that you desire. Please refer to the following Blog post for more information. It is inevitable; you will run into some False Positive hits when using web application firewalls. This is not something that is unique to ModSecurity. All web application firewalls will generate false positives from time to time. The following Blog post information will help to guide you through the process of identifying, fixing, implementing and testing new custom rules to address false positives. Yes. Each and every rule that you implement will comsume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance. Fixing identified vulnerabilities in web application always requires time. Organizations often do not have access to a commercial application's source code and are at the vendor's mercy while waiting for a patch. Even if they have access to the code, implementing a patch in development takes time. This leaves a window of opportunity for the attacker to exploit. External patching (also called "just-in-time patching" and "virtual patching") is one of the biggest advantages of web application firewalls as they can fix this problem externally. A fix for a specific vulnerability is usually very easy to design and in most cases it can be done in less than 15 minutes. Breach Security will be holding a Virtual Patching webcast as part of the Breach Webinar Series on Wednesday, July 18, 2007. If you have more then 1 ModSecurity installation, you have undoubtedly run into issues with consolidating, analyzing and responding to alert messages. Unfortunately, the original "Serial" format of the audit log was multi-line with all records held within one file. This made remote logging difficult. What was really needed was to have a mechanism to send logs onto a centralized logging host made specifically for processing ModSecurity Alert data. This is the purpose of the open source ModSecurity Console. This product is provided free of charge to the community, with best-effort support available on the main ModSecurity mailing list. ModSecurity Console is suitable for test environments and only light production use. ModSecurity Console v1.0.2 is available for immediate download from Breach Security Network. The download includes a licence for up to 3 sensors that expires in July 2007. For a limited time Breach Security offers free perpetual licences for up to 3 sensors. To generate your own licence please follow the instructions on the home page of BSN. Please refer to the following Blog post on this topic. Although you can deploy the ModSecurity Console on the same host that is running ModSecurity, the recommended solution is to deploy the Console on a stand-alone server and then reconfigure your various ModSecurity hosts to send their logs across the network to the Console. This provides two benefits:
Unfortunately, it is relatively easy to overload the ModSecurity Conmmunity Console when you combine the following three factors: using the default Console configurations, having the ModSecurity Sensor configured to log alerts for all traffic and if your site has large amounts of traffic. In this type of situation, the Console MUI may become unresponsive. This is due to having too many open/active alert messages. So, what can you do about it? Read the following Blog posts to find steps to help alleviate these problems. If you are becoming frustrated with the performance of the open source Console and/or if you have more then 3 ModSecurity sensors to manage, you may want to consider taking a look at Breach's commercial ModSecurity Management Appliance that was just recently made available. It has many significant performance increases and is an enterprise class solution (it can manage up to 50 ModSecurity Sensors). Yes. If you already have a central Syslog infrastructure setup and/or if you are using some sort of SIM application (such as LogLogic, Intellitactics, etc...) then you might want to include the short version ModSecurity alert messages that appear in the Apache error_log file. You can easily reconfigure Apache to send its error logs through Syslog onto a remote, central logging server however the data being forwarded is a very small subset of the entire transaction. It is only a warning message and not enough information to conduct proper incident response to determine if there was a false positive or if it was a legitimate attack. In order to determine this information, you need access to the ModSecurity Audit log files. |
