This tutorial is currently undergoing the transition from CRS3 to CRS4, some things may fail to work as advertised. Christian Folini 2026-01-22<\/strong><\/p>\n We will take a vanilla installation of the OWASP ModSecurity Core Rule Set<\/em> (CRS) troubled by a large number of false positives and tune away the unwelcome alarms, so we get a clearer view on the real attackers.<\/p>\n A fresh installation of the CRS will typically have some false alarms. In some cases, namely at higher paranoia levels, there can be thousands of them. In the previous tutorial<\/a>, we saw a number of approaches for suppressing individual false alarms with the help of rule exclusions. What we\u2019re missing is a strategy for coping with false alarms on a scale and this tutorial will show you one. It is obvious, reducing the number of false alarms is the prerequisite for lowering the CRS anomaly threshold and this, in turn, is required in order to use ModSecurity<\/em> to actually ward off attackers. And only after the false alarms really are disabled, or at least curtailed to a large extent, do we get a clear picture of the real attackers.<\/p>\n During the tutorial we will also learn to use a handy tool that will assist you with the writing of rule exclusions.<\/p>\n There is no point in learning to fight false positives on a lab server without traffic. What you need is a real set of false alarms. I have prepared a script that performs 10,000 requests against a host. The requests are extracted from a browser session and transformed into curl requests so you can run them easily. When used against CRS v3.3.2, you will get exactly the alerts, this tutorial is based on.<\/p>\n If you do not want to run the script yourself, then you can also download the example logs from my run.<\/p>\n How did I arrive with this traffic generator script? After all, it is difficult to provide real production logs for an exercise due to all the sensitive data in the logs. So, I went and created false positives from scratch in my browser. With the Core Rule Set 2.2.x, this would have been simple, but with the 3.3 release (3.3.2 to be exact), most of the false positives in the default install are now gone. What I did was set the CRS to Paranoia Level 4 and then install a local Drupal site. Afterwards, I published a couple of articles about SQL injections and then read the articles in the browser, combined with the casual search for individual SQL statements. And this, I repeated up to 10,000 requests. All very harmless in reality, but very alarming for CRS.<\/p>\n Drupal and the core rules are not really in a loving relationship. Whenever the two software packages meet, they tend to have a falling out with each other, since CRS is so pedantic and Drupal\u2019s habit of having square brackets in parameter names drives CRS crazy. However, the default CRS3 installation at Paranoia Level 1 and especially the optional Drupel rule exclusion package (see the But things look completely different when you do not use these exclusion rules. And if you raise the Paranoia Level to 4, you will get plenty of false positives. For the 10,000 requests in my test run, I received over 28,000 false alarms and I expect the same number for your setup. That should do for a training session.<\/p>\n The problem with false positives is they can flood you like an avalanche and you won\u2019t know where to start to clean up. What you need is a plan and there is no official documentation proposing one. So here we go: This is my recommended approach to fighting false alarms:<\/p>\n What does that mean? The default installation comes in blocking mode and with an anomaly threshold of 5 for the requests. This is a very good configuration, but it\u2019s an overambitious start on an existing production server. The risk is that a false positive raises an alarm, the wrong customer is affected, a phone call to a manager ensues and you are forced to switch off the Web Application Firewall immediately. In many installations I have seen, this was the end of the story.<\/p>\n Don\u2019t let a badly tuned system catch you like this. Instead, start with a high threshold for the anomaly score on a new installation to test the water. Let\u2019s say 10,000 for the requests and also 10,000 for the responses for symmetry\u2019s sake (in practice, the responses do not score very high). That way no customer is ever going to be blocked, while you get reports of false alarms and enough time to weed them out.<\/p>\n If you have a proper testing program, this is all performed during an extensive testing phase, so the service never hits production without a strict configuration. But if you start with ModSecurity on an existing production service, starting out with a high threshold in production is the preferred method with minimal interruption to existing customers (zero impact, if you work diligently).<\/p>\n The problem with integrating ModSecurity in production is the fact that false positives and real alarms are intermixed. In order to tune your installation, you need to separate the two groups to really work on the false positives alone. This is not always easy. Manual review helps, restricting to known IP addresses, pre-authentication, testing\/tuning on a test system separated from the internet, filtering the access log by country of origin for the IP address, etc\u2026 It\u2019s a large topic and making general recommendations is difficult. But please do take this seriously. Years ago, I demonstrated the exclusion of a false positive in a workshop – and the example alarm I used turned out to be a real attack. Needless to say, I learned my lesson.<\/p>\n There is another question that we need to get out of the way: Doesn\u2019t disabling rules actually lower the security of the site? Yes it does, but we need to keep things in perspective. In an ideal setup, all rules would be intact, the paranoia level would be very high (thus over 200 rules in place) and the anomaly limit very low. Still, the application would run without any problems or false alarms. This sounds too good to be true because in practice, this won\u2019t work outside of the rarest of cases. If we raise the anomaly threshold, then the alerts are still there, but the attackers are no longer affected. If we reduce the paranoia level, we disable dozens of rules with one setting. If we talk to the developers about changing their software so that the false positives go away, we spend a lot of time arguing without much chance of success (at least in my experience). So disabling a single rule from a set of 200 rules is the best of all the bad solutions. The worst of all the bad solutions would be to disable ModSecurity altogether. And outcome is very real in many organizations absent tangible results in terms of security. So I would rather disable individual rules based on a false positive than run the risk of being forced to kill the WAF.<\/p>\n The character of the application, the paranoia level and the amount of traffic all influence the amount of false positives you get in your logs. In the first run, a couple of thousand or one hundred thousand requests will do. Once you have that in your access log, it\u2019s time to take a look. Let\u2019s get an overview of the situation: Let\u2019s look at the example logs!<\/p>\n There is the ModSecurity Audit log of course, but I rarely look at it unless I have a very specific interest. For most of the cases, the ModSecurity alert message in the error log is all I need. But this is not where I start. Let\u2019s look looking at the access log first. We defined the log format in a way that gives us the anomaly scores for every request and that\u2019s exactly what we will be using at this stage.<\/p>\n In the previous tutorial, we used the script modsec-positive-stats.rb<\/a>. We return to this script with the example access log as the source and the alias What are we doing?<\/h3>\n
Why are we doing this?<\/h3>\n
Requirements<\/h3>\n
\n
\n
crs-setup.conf<\/code> file and this blog post<\/a> for details) wards off almost all of the remaining false positives with a core Drupal installation.<\/p>\nStep 1: Defining a Policy to Fight False Positives<\/h3>\n
\n
Step 2: Getting an Overview<\/h3>\n
alscores<\/code> that is part of the alias package introduced in tutorial number 5; it extracts the incoming and outgoing anomaly score of a request, separated by a semicolon:<\/p>\n<\/a>$><\/span> cat<\/span> tutorial-8-example-access.log |<\/span> alscores<\/span> |<\/span> modsec-positive-stats.rb<\/span><\/span>\n<\/a>INCOMING<\/span> Num of req. |<\/span> %<\/span> of req. |<\/span> Sum<\/span> of % |<\/span> Missing<\/span> %<\/span>\n<\/a>Number<\/span> of incoming req. (total) |<\/span> 10000<\/span> |<\/span> 100.0000%<\/span> |<\/span> 100.0000%<\/span> |<\/span> 0.0000%<\/span><\/span>\n<\/a><\/span>\n<\/a>Empty<\/span> or miss. incoming score |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 0.0000%<\/span> |<\/span> 100.0000%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 0 |<\/span> 5014<\/span> |<\/span> 50.1399%<\/span> |<\/span> 50.1399%<\/span> |<\/span> 49.8601%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 1 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 50.1399%<\/span> |<\/span> 49.8601%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 2 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 50.1399%<\/span> |<\/span> 49.8601%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 3 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 50.1399%<\/span> |<\/span> 49.8601%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 4 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 50.1399%<\/span> |<\/span> 49.8601%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 5 |<\/span> 3562<\/span> |<\/span> 35.6200%<\/span> |<\/span> 85.7599%<\/span> |<\/span> 14.2401%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 6 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 85.7599%<\/span> |<\/span> 14.2401%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 7 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 85.7599%<\/span> |<\/span> 14.2401%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 8 |<\/span> 1<\/span> |<\/span> 0.0100%<\/span> |<\/span> 85.7700%<\/span> |<\/span> 14.2300%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 9 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 85.7700%<\/span> |<\/span> 14.2300%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 10 |<\/span> 2<\/span> |<\/span> 0.0200%<\/span> |<\/span> 85.7899%<\/span> |<\/span> 14.2101%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 11 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 85.7899%<\/span> |<\/span> 14.2101%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 12 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 85.7899%<\/span> |<\/span> 14.2101%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 13 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 85.7899%<\/span> |<\/span> 14.2101%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 14 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 85.7899%<\/span> |<\/span> 14.2101%<\/span><\/span>\n<\/a>Reqs<\/span> with incoming score of 15 |<\/span> 0<\/span> |<\/span> 0.0000%<\/span> |<\/span> 85.7899%<\/span>