Issues with modsecurity OWASP and false positives.
I see in /usr/local/apache/logs/error_logs a lot of error messages. Here's a small chunk.
I believe the ones from 127.0.0.1 are false positive. I believe a cPanel script is checking /whm-server-status to make sure the server is up but there's maybe something wrong with the request header in the script and because of it, perhaps a false positive is being triggered. I'd like to safely figure out how to whitelist this, so I don't see the log filled with these error messages whenever 127.0.0.1 tries connecting to /whm-server-status. I think the answer lies within the /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf file but I'm not sure how to properly write a rule. Can someone show me what I'd need to put in there? I've also sent this message to the OWASP mailing list and if I get an answer from them, I'll update this message with that answer. Thank you!
[Mon Jul 18 19:19:34.821609 2016] [:error] [pid 6823] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"> [line "317"> [id "960009"> [rev "1"> [msg "Request Missing a User Agent Header"> [severity "NOTICE"> [ver "OWASP_CRS/3.0.0"> [maturity "9"> [accuracy "9"> [tag "Host: "> [tag "application-multi"> [tag "language-multi"> [tag "platform-multi"> [tag "attack-protocol"> [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA"> [tag "WASCTC/WASC-21"> [tag "OWASP_TOP_10/A7"> [tag "PCI/6.5.10"> [hostname "franklin.example.com"> [uri "/"> [unique_id "V41kBmjudWkAABqnkC4AAAAE">
[Mon Jul 18 19:19:34.822806 2016] [:error] [pid 6823] [client 127.0.0.1] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/RESPONSE-80-CORRELATION.conf"> [line "35"> [id "981204"> [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5): Request Missing a User Agent Header"> [tag "Host: "> [tag "event-correlation"> [hostname "franklin.example.com"> [uri "/index.html"> [unique_id "V41kBmjudWkAABqnkC4AAAAE">
[Mon Jul 18 19:20:01.427810 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"> [line "283"> [id "960008"> [rev "2"> [msg "Request Missing a Host Header"> [severity "WARNING"> [ver "OWASP_CRS/3.0.0"> [maturity "9"> [accuracy "9"> [tag "Host: "> [tag "application-multi"> [tag "language-multi"> [tag "platform-multi"> [tag "attack-protocol"> [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_HOST"> [tag "WASCTC/WASC-21"> [tag "OWASP_TOP_10/A7"> [tag "PCI/6.5.10"> [hostname "franklin.example.com"> [uri "/whm-server-status"> [unique_id "V41kIWjudWkAABqjYU0AAAAA">
[Mon Jul 18 19:20:01.427892 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"> [line "317"> [id "960009"> [rev "1"> [msg "Request Missing a User Agent Header"> [severity "NOTICE"> [ver "OWASP_CRS/3.0.0"> [maturity "9"> [accuracy "9"> [tag "Host: "> [tag "application-multi"> [tag "language-multi"> [tag "platform-multi"> [tag "attack-protocol"> [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA"> [tag "WASCTC/WASC-21"> [tag "OWASP_TOP_10/A7"> [tag "PCI/6.5.10"> [hostname "franklin.example.com"> [uri "/whm-server-status"> [unique_id "V41kIWjudWkAABqjYU0AAAAA">
[Mon Jul 18 19:20:01.428676 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/RESPONSE-80-CORRELATION.conf"> [line "35"> [id "981204"> [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5): Request Missing a User Agent Header"> [tag "Host: "> [tag "event-correlation"> [hostname "franklin.example.com"> [uri "/whm-server-status"> [unique_id "V41kIWjudWkAABqjYU0AAAAA">
[Mon Jul 18 19:20:34.546597 2016] [:error] [pid 6820] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"> [line "299"> [id "960015"> [rev "3"> [msg "Request Missing an Accept Header"> [severity "NOTICE"> [ver "OWASP_CRS/3.0.0"> [maturity "9"> [accuracy "8"> [tag "Host: 127.0.0.1"> [tag "application-multi"> [tag "language-multi"> [tag "platform-multi"> [tag "attack-protocol"> [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"> [tag "WASCTC/WASC-21"> [tag "OWASP_TOP_10/A7"> [tag "PCI/6.5.10"> [hostname "127.0.0.1"> [uri "/whm-server-status"> [unique_id "V41kQmjudWkAABqkc0UAAAAB">
[Mon Jul 18 19:21:34.542318 2016] [:error] [pid 6821] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"> [line "299"> [id "960015"> [rev "3"> [msg "Request Missing an Accept Header"> [severity "NOTICE"> [ver "OWASP_CRS/3.0.0"> [maturity "9"> [accuracy "8"> [tag "Host: 127.0.0.1"> [tag "application-multi"> [tag "language-multi"> [tag "platform-multi"> [tag "attack-protocol"> [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"> [tag "WASCTC/WASC-21"> [tag "OWASP_TOP_10/A7"> [tag "PCI/6.5.10"> [hostname "127.0.0.1"> [uri "/whm-server-status"> [unique_id "V41kfmjudWkAABqlx7cAAAAC">
[Mon Jul 18 19:22:34.564614 2016] [:error] [pid 6822] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"> [line "299"> [id "960015"> [rev "3"> [msg "Request Missing an Accept Header"> [severity "NOTICE"> [ver "OWASP_CRS/3.0.0"> [maturity "9"> [accuracy "8"> [tag "Host: 127.0.0.1"> [tag "application-multi"> [tag "language-multi"> [tag "platform-multi"> [tag "attack-protocol"> [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"> [tag "WASCTC/WASC-21"> [tag "OWASP_TOP_10/A7"> [tag "PCI/6.5.10"> [hostname "127.0.0.1"> [uri "/whm-server-status"> [unique_id "V41kumjudWkAABqmocAAAAAD">
[Mon Jul 18 19:22:51.937856 2016] [:error] [pid 6823] [client 169.54.244.75] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"> [line "317"> [id "960009"> [rev "1"> [msg "Request Missing a User Agent Header"> [severity "NOTICE"> [ver "OWASP_CRS/3.0.0"> [maturity "9"> [accuracy "9"> [tag "Host: ip-104-238-117-105.ip.secureserver.net"> [tag "application-multi"> [tag "language-multi"> [tag "platform-multi"> [tag "attack-protocol"> [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA"> [tag "WASCTC/WASC-21"> [tag "OWASP_TOP_10/A7"> [tag "PCI/6.5.10"> [hostname "ip-104-238-117-105.ip.secureserver.net"> [uri "/"> [unique_id "V41ky2judWkAABqnkC8AAAAE">
[Mon Jul 18 19:23:34.612950 2016] [:error] [pid 6819] [client 127.0.0.1] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"> [line "299"> [id "960015"> [rev "3"> [msg "Request Missing an Accept Header"> [severity "NOTICE"> [ver "OWASP_CRS/3.0.0"> [maturity "9"> [accuracy "8"> [tag "Host: 127.0.0.1"> [tag "application-multi"> [tag "language-multi"> [tag "platform-multi"> [tag "attack-protocol"> [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"> [tag "WASCTC/WASC-21"> [tag "OWASP_TOP_10/A7"> [tag "PCI/6.5.10"> [hostname "127.0.0.1"> [uri "/whm-server-status"> [unique_id "V41k9mjudWkAABqjYU4AAAAA">
I believe the ones from 127.0.0.1 are false positive. I believe a cPanel script is checking /whm-server-status to make sure the server is up but there's maybe something wrong with the request header in the script and because of it, perhaps a false positive is being triggered. I'd like to safely figure out how to whitelist this, so I don't see the log filled with these error messages whenever 127.0.0.1 tries connecting to /whm-server-status. I think the answer lies within the /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf file but I'm not sure how to properly write a rule. Can someone show me what I'd need to put in there? I've also sent this message to the OWASP mailing list and if I get an answer from them, I'll update this message with that answer. Thank you!
-
Hello, This is a recent update on the feature request site for updating ModSecurity CSR3. Update ModSecurity Vendor OWASP to OWASP ModSecurity Core Rule Set (CRS) 3 benny@cpanel.net[/EMAIL] . 1 hour ago Good news everyone! Our development team is working on this now, and we are hoping to deliver it in version 64!
Thanks cPanel Crew, danielpmc0 -
The reason so many people are having so many problems with false positives is because this older version of the CRS that cPanel is using was released (by OWASP then by cPanel) with the configuration set to use Tradition or Self-Contained mode blocking (one hit equals a block) rather than Collaborative Detection mode (which increments a score with each rule hit until a score threshold is reached). If you read the rules they were quite obviously written to be run in Collaborative Detection mode. It only needs three lines of modsecurity_crs_10_setup.conf to be edited to turn on Collaborative Detection mode in cPanel's current version of the CRS rules. - lines 74 and 75... SecDefaultAction "phase:1,log,redirect:'http://%{request_headers.host}/',tag:'Host: %{request_headers.host}'" SecDefaultAction "phase:2,log,redirect:'http://%{request_headers.host}/',tag:'Host: %{request_headers.host}'"
replace with...SecDefaultAction "phase:1,pass,nolog,auditlog" SecDefaultAction "phase:2,pass,nolog,auditlog"
- line 135 uncomment rule 900004...SecAction "id:'900004', phase:request, nolog, pass, t:none, setvar:tx.anomaly_score_blocking=on"
I copied the file modsecurity_crs_10_setup.conf then renamed it before making these edits to the new renamed file. Then go to WHM=>Security Center=>Modsecurity Vendors=>OWASP ModSecurity Core Rule Set=>Edit Button Turn OFF the modsecurity_crs_10_setup.conf file. Turn ON your new conf file. Thats it. I had the same problem as Ken Swarthout with cPanel's whm-server-status Requests from 127.0.0.1 where rules were triggered by poorly written HTTP Headers. this rule is more specific than Ken's# Rule to allow cPanel whm-server-status requests with missing mandatory headers. SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" \ "msg:'Matched 127.0.0.1 and matched whm-server-status. Disabling rules 960008 960009 960015 and 981204',\ phase:1,\ id:8888777,\ t:none,\ pass,\ nolog,\ chain" SecRule REQUEST_URI "@contains whm-server-status" \ "t:none,\ ctl:ruleRemoveById=960008,\ ctl:ruleRemoveById=960009,\ ctl:ruleRemoveById=960015,\ ctl:ruleRemoveById=981204"
WordPress load-scripts issues were fixed by the rule...# Rule to allow /wp-admin/load-scripts.php requests without triggering rules. # SecRule REQUEST_URI "@contains /wp-admin/load-scripts.php" \ "msg:'Disabled rules 981247 981176 and 981204 for /wp-admin/load-scripts.php',\ phase:1,\ nolog,\ pass,\ ctl:ruleRemoveById=981247,\ ctl:ruleRemoveById=981176,\ ctl:ruleRemoveById=981204,\ id:'8888778'"
All other log events were basically all True Positives even though most were non blocking due to not reaching the Collaborative Detection mode thresholds.0 -
The OWASP ModSecurity Core Rule Set team have changed the default configuration of the current version of the CRS to run in Collaborative Detection mode. That is the main change to achieve the 90% reduction in False Positives. They have also rewritten most of the rules to take into account (not trigger) most of the false positives. They have also renumbered all the IDs. The project is ) for it and uploaded the two to my server into a directory named modsec. I then went to... WHM=>Security Center=>Modsecurity Vendors=>Add Vendor button the entered the url of the yaml file into the Vendor Configuration URL textfield. Load then Save. The new vendor will now be available in the Vendors section. Disable cPanel OWASP CRS. Enable Third Party OWASP CRS. Thats it. If you want to try mine, yaml is at... - Removed - That is stock standard configuration. (Looking good for when cPanel gets this ruleset) The only False Positive I have had to deal with is once again the whm-server-status requests. All the rule ids have changed so it needs a new rule to make this work... # Rule to allow cPanel whm-server-status requests with missing mandatory headers. # SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" \ "msg:'Matched 127.0.0.1 and matched whm-server-status. Disabling rules 920280 and 920280',\ phase:1,\ id:8888776,\ t:none,\ pass,\ nolog,\ chain" SecRule REQUEST_URI "@contains whm-server-status" \ "t:none,\ ctl:ruleRemoveById=920280,\ ctl:ruleRemoveById=920350"
I'm running mostly WordPress sites but the logs are quiet with this config. All hits so far have been True Positives.0 -
Here is a more reliable version of that rule for matching the request file. # Rule to allow cPanel whm-server-status requests with missing mandatory headers. SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" \ "msg:'Matched 127.0.0.1 and matched whm-server-status. Disabling rules 920280 and 920350',\ phase:1,\ id:8888777,\ t:none,\ pass,\ log,\ chain" SecRule REQUEST_FILENAME "whm-server-status$" \ "t:none,\ ctl:ruleRemoveById=920280,\ ctl:ruleRemoveById=920350"0 -
Here are better versions of the two rules above (more reliable at matching the request filename) # (cPanel old CRS rulset) # Rule to allow cPanel whm-server-status requests with missing mandatory headers. # SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" \ "msg:'Matched 127.0.0.1 and matched whm-server-status. Disabling rules 960008 960009 960015 and 981204',\ phase:1,\ id:8888777,\ t:none,\ pass,\ log,\ chain" SecRule REQUEST_FILENAME "whm-server-status$" \ "t:none,\ ctl:ruleRemoveById=960008,\ ctl:ruleRemoveById=960009,\ ctl:ruleRemoveById=960015,\ ctl:ruleRemoveById=981204"
And a better version of the WordPress load-scripts issue...#(cPanel old CRS rulset) # Rule to allow load-scripts.php requests without triggering rules. # SecRule REQUEST_FILENAME "load-scripts.php$" \ "msg:'Disabled rules 981247 981176 and 981204 for load-scripts.php',\ phase:1,\ nolog,\ pass,\ ctl:ruleRemoveById=981247,\ ctl:ruleRemoveById=981176,\ ctl:ruleRemoveById=981204,\ id:'8888778'"0 -
FuzzyLogic, Why did you remove the yaml URL? I want to try it. Is it because it could be a security threat? For example, you could modify them in such a way where you could allow yourself to bypass anyone's modsec configuration, if you wanted to, even though you wouldn't, and decided against sharing, thinking maybe other people who were malicious would get the idea and do exactly that? Thanks for sharing. I'll update my configuration for the 127.0.0.1 whitelisting stuff. I don't know a lot about the rules, and I've written a couple, but I think it takes a good amount of time to truly understand modsec and all the configuration variables and how it works, and that's just something I don't really have now, free time. Thanks again!!!! 0 -
Hey Spork, The .yaml link was moderated (not by me). It is understandable I guess, the .yaml has a link to a .zip of the rules directory located off-site from cpanel.net, so could be considered a support hazard or even worse a security risk. I started off writing a how-to, then had a rush of blood to the head and thought it would be easier to just link to my setup. I'm glad I took the time learn how to create my own vendor and will curate my own rule set from here on. cPanel has released their curated version of the CRS version3.0.0 with the cPanel 64 update. It has rules 920350, 942110 and 942150 commented out, and 4 .conf files deleted from the CRS. REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf Needs a rule to turn it on. Copy 900130 from crs-setup.conf, uncomment it, add it as a new rule to WHM=>Security Center=>Modsecurity Tools=>Rules=>Add Rule REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf Needs a rule to turn it on. Same as DRUPAL REQUEST-911-METHOD-ENFORCEMENT.conf REQUEST-932-APPLICATION-ATTACK-RCE.conf I'm sure someone must have had False Positives to justify these changes, but I have not experienced any problems with these rules or .conf files so I will continue using them. 0 -
I know this is a bit older of a thread now, but isn't there a way for cPanel to just add a proper header to whatever script is accessing whm-server-status? Than we wouldn't need to add an exclusion to conf files for 127.0.0.1? Everyone running cPanel right now that has ModSec enabled will either get their logs filled with these messages or they'll have to create the conf file and enable the ruleset. Wouldn't it just be easier if cPanel updated their scripts to provide the proper header? I had the old conf file in, before cPanel updated the ModSec rules and I just realized that it was no longer working, because the rule IDs have changed a bit, so I had to come back here and refresh my memory on how we worked around the problem originally. 0 -
I know this is a bit older of a thread now, but isn't there a way for cPanel to just add a proper header to whatever script is accessing whm-server-status? Than we wouldn't need to add an exclusion to conf files for 127.0.0.1?
There's an internal case open to address that issue. You can monitor the following thread for updates: Apache Status page fails after 64 update Thank you.0 -
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. 0 -
.... 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.0
Please sign in to leave a comment.
Comments
41 comments