Issues with modsecurity OWASP and false positives.

[nibb]

Disabling rules globally is not something I feel comfortable doing. Sadly, some users have constant problems with the basic OWASP rules, and they just disable Mod Security in their cPanel account.

There are two things which I think cPanel lacks in this regard.

First, there is no way for users to see which rules they are triggering with mod security. This is a very poor implementation by cPanel because they created a whole page and icon that can only do one single thing, Disable/Enable Mod Security. (talking about cPanel user side)

Personally, I think that page should also display the last rules triggered in the domain so users can be informed of why they are receiving an error on their sites, and at least open a support ticket with the rule in question.

Second, maybe a bit more complicated, rules should be disabled per domain or cPanel account, not globally. So if a user triggers a rule over and over again, he can disable it from his cPanel account, and it will only disable that particular rule for that domain, but still, leave all other rules and mod security on. In the worse case, a user can still disable mod security completely for this domain like he can today.

I suspect Mod Security has little use if people just turn it off or cPanel admins start to disable more and more rules. The reason is that in shared hosting, the more accounts you host, the more websites will trigger different rules. Eventually, as admin, you will end up disabling almost everything if you want to make users happy. This is why it should be per account.

 

[Spork Schivago]

....
Second, maybe a bit more complicated, rules should be disabled per domain or cPanel account, not globally. So if a user triggers a rule over and over again, he can disable it from his cPanel account, and it will only disable that particular rule for that domain, but still, leave all other rules and mod security on. In the worse case, a user can still disable mod security completely for this domain like he can today.

Personally, I don't think rules should be disabled unless absolutely necessary. For example, with the whm-server-status problem, the correct way to fix the issue is to add a proper header to the script that accesses the page, which I believe cPanel is discussing internally. The way I fixed it (with the help of the people on the ModSec mailing list and with the help from people on this forum) is to ONLY disable the rule IF the remote IP address is the local loopback interface IP address (127.0.0.1) AND whm-server-status is the page being requested. That way, just this false positive is dealt with and the rule that is being triggered still works for outside traffic.

If my memory serves, I think the ModSec mailing list was looking for "false positive" reports with the new rule set. They rewrote it in such away where the majority of false positives were properly handled. If you're seeing any repetitive false positives in your logs, perhaps you should post it on the ModSec mailing list to let them know? With the whm-server-status, you wouldn't post that there because ModSec is doing what it's supposed to do. We call it a false positive because it's harmless, but the rule checks to see if there's a proper header, there isn't, so it throws a warning message. For something like that, cPanel has to fix it, not ModSec.

I originally found the rules overwhelming and had trouble writing them, but after doing a good bit of research, I learned a little. ModSec is extremely powerful and there's definitely a lot to learn! There's some free e-books that have been written to help people understand. If you're interested, I can try tracking them down. Someone on the ModSec mailing list posted about one they wrote not too long ago, for the CRS3. If you do run into false positives, feel free to post here too, I'll try to help the best I can and I'm certain other cPanel users will help even more.