Too many false positives to list

[Ed-AITpro]

Without all out ranting here and exploding like I feel like exploding it would be great if you could provide some sort of Mod Security whitelisting method that could be used in a WordPress Plugin's code to tell Mod Security not to falsely flag every single thing as a threat. The problem with trying to deal with all the false flags in Mod Security is this > A customer contacts me and I confirm that yep this is another case of Mod Security falsely seeing a threat. The functionality of my plugin is broken of course during the process of getting the end user to contact their web host support folks. 9 times out of 10 the web host support folks have no idea what they are doing and the problem goes unsolved. I have literally had 1,000's of end users abandon my plugin due to Mod Security incorporated into newer cPanel versions. Mod Security itself is great. The available methods to fix Mod Security problems is a nightmare for everyone involved.

I'm not sure if there is a way to safely create a usable bypass or whitelisting method for Mod Security from a website vs doing config changes server-side. What I mean by safely is that if a hacker can use the whitelisting/bypass method then that renders Mod Security ineffective. Let's say a Mod Security whitelisting method/bypass was created with certain conditions such as "if the WordPress plugin is installed on the website then it is safe to assume it is not a threat" You would of course convert that statement into a code if statement.

Personally I think it was a huge mistake for cPanel to include Mod Security without also supplying pre-built tools for end users so that they could fix Mod Security problems themselves. Contacting web host support does not work 9 times out of 10 because web host support techs do not know what they are doing. The majority of the time they respond back with something like we have fixed the SecRules that were causing the problem or we disabled Mod Security for this site or hosting account and neither are true in 90% of all the cases i have been dealing with for the past year. so that tells me the web host support techs have no idea how to actually fix Mod Security problems or how to disable Mod Security.

I'm keeping this as civilized as possible, but I am at my wits end with this stuff. I have lost a very significant amount of end users, customers, time and money. I don't actually expect you to do anything at all to make this nightmare more reasonable so I think the only solution is going to be to use some sort of encryption methods to bypass Mod Security altogether. What is absolutely overkill insanity to me is that Mod Security reads the body content of plugin page if a form is submitted from that page. Seriously??? see this Mod Security disaster below.

[Tue Aug 13 16:35:12.108856 2019] [:error] [pid 8344:tid 2036] [client 127.0.0.1:58098] [client 127.0.0.1] ModSecurity: Warning. Pattern match "(?i)(?:supplied argument is not a valid MySQL|Column count doesn't match value count at row|mysql_fetch_array\\\\(\\\\)|on MySQL result index|You have an error in your SQL syntax;|You have an error in your SQL syntax near|MySQL server version for the right ..." at RESPONSE_BODY. [file "C:/xampp/apache/modsecurity/owasp-modsecurity-crs/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf"] [line "373"] [id "951230"] [msg "mysql SQL Information Leakage"] [data "Matched Data: Warning: JavaScript is disabled in your Browser</span><br />BPS plugin pages will not display visually correct and all BPS JavaScript functionality will not work correctly.</div></noscript>\\x0a\\x0a\\x09\\x09\\x0a\\x09\\x09<script type=\\x22text/javascript\\x22>\\x0a\\x09\\x09/* <![CDATA[ */\\x0a\\x09\\x09jQuery(document).ready(function($){\\x0a\\x09\\x0a\\x09\\x09\\x09$(\\x22html, body\\x22).animate({ scrollTop: \\x2250px\\x22 }, 400, function(){\\x0a \\x09\\x09\\x09\\x09$(\\x22html, body\\x22).animate({ scrollTop: \\x22..."] [severity "CRITICAL"] [ver "OWASP_C [hostname "demo9.local"] [uri "/wp-admin/admin.php"] [unique_id "XVNJLzsBsvuo17DcrKWzkwAAAIg"], referer: http://demo9.local/wp-admin/admin.php?page=bulletproof-security%2Fadmin%2Fquarantine%2Fquarantine.php

[Tue Aug 13 16:35:12.292363 2019] [:error] [pid 8344:tid 2036] [client 127.0.0.1:58098] [client 127.0.0.1] ModSecurity: Warning. Matched phrase "Call to undefined function" at RESPONSE_BODY. [file "C:/xampp/apache/modsecurity/owasp-modsecurity-crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf"] [line "47"] [id "953100"] [msg "PHP Information Leakage"] [data "Matched Data: Call to undefined function found within RESPONSE_BODY: <!DOCTYPE html>\\x0a<!--[if IE 8]>\\x0a<html xmlns=\\x22http://www.w3.org/1999/xhtml\\x22 class=\\x22ie8 wp-toolbar\\x22\\x0a\\x09lang=\\x22en-US\\x22\\x09>\\x0a<![endif]-->\\x0a<!--[if !(IE 8) ]><!-->\\x0a<html xmlns=\\x22http://www.w3.org/1999/xhtml\\x22 class=\\x22wp-toolbar\\x22\\x0a\\x09lang=\\x22en-US\\x22\\x09>\\x0a<!--<![endif]-->\\x0a<head>\\x0a<meta http-equiv=\\x22Content-Type\\x22 content=\\x22text/html; charset=UTF-8\\x22 />\\x0a\\x09<title>Quarantine ~ B..."] [severity "ERROR"] [ver "OWASP_CRS/3.1.1"] [tag "application-multi"] [tag "language-php"] [tag "platform-multi"] [tag "attack-disclosure"] [tag "OWASP_CRS/LEAKAGE/ERRORS_PHP"] [tag "WASCTC/WASC-13"] [tag "OWASP_TOP_10/A6"] [tag "PCI/6.5.6"] [hostname "demo9.local"] [uri "/wp-admin/admin.php"] [unique_id "XVNJLzsBsvuo17DcrKWzkwAAAIg"], referer: http://demo9.local/wp-admin/admin.php?page=bulletproof-security%2Fadmin%2Fquarantine%2Fquarantine.php

[Tue Aug 13 16:35:12.299370 2019] [:error] [pid 8344:tid 2036] [client 127.0.0.1:58098] [client 127.0.0.1] ModSecurity: Warning. Pattern match "(?:\\\\b(?:f(?:tp_(?:nb_)?f?(?:ge|pu)t|get(?:s?s|c)|scanf|write|open|read)|gz(?:(?:encod|writ)e|compress|open|read)|s(?:ession_start|candir)|read(?:(?:gz)?file|dir)|move_uploaded_file|(?:proc_|bz)open|call_user_func)|\\\\$_(?:(?:pos|ge)t|session))\\\\b" at RESPONSE_BODY. [file "C:/xampp/apache/modsecurity/owasp-modsecurity-crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf"] [line "76"] [id "953110"] [msg "PHP source code leakage"] [data "Matched Data: session_start found within RESPONSE_BODY: <!DOCTYPE html>\\x0a<!--[if IE 8]>\\x0a<html xmlns=\\x22http://www.w3.org/1999/xhtml\\x22 class=\\x22ie8 wp-toolbar\\x22\\x0a\\x09lang=\\x22en-US\\x22\\x09>\\x0a<![endif]-->\\x0a<!--[if !(IE 8) ]><!-->\\x0a<html xmlns=\\x22http://www.w3.org/1999/xhtml\\x22 class=\\x22wp-toolbar\\x22\\x0a\\x09lang=\\x22en-US\\x22\\x09>\\x0a<!--<![endif]-->\\x0a<head>\\x0a<meta http-equiv=\\x22Content-Type\\x22 content=\\x22text/html; charset=UTF-8\\x22 />\\x0a\\x09<title>Quarantine ~ BPS Pro Automa..."] [severity "ERROR"] [ver "OWASP_CRS/3.1.1"] [tag "app [hostname "demo9.local"] [uri "/wp-admin/admin.php"] [unique_id "XVNJLzsBsvuo17DcrKWzkwAAAIg"], referer: http://demo9.local/wp-admin/admin.php?page=bulletproof-security%2Fadmin%2Fquarantine%2Fquarantine.php

[Tue Aug 13 16:35:12.319318 2019] [:error] [pid 8344:tid 2036] [client 127.0.0.1:58098] [client 127.0.0.1] ModSecurity: Warning. Operator GE matched 4 at TX:outbound_anomaly_score. [file "C:/xampp/apache/modsecurity/owasp-modsecurity-crs/rules/RESPONSE-959-BLOCKING-EVALUATION.conf"] [line "69"] [id "959100"] [msg "Outbound Anomaly Score Exceeded (Total Score: 13)"] [tag "anomaly-evaluation"] [hostname "demo9.local"] [uri "/wp-admin/admin.php"] [unique_id "XVNJLzsBsvuo17DcrKWzkwAAAIg"], referer: http://demo9.local/wp-admin/admin.php?page=bulletproof-security%2Fadmin%2Fquarantine%2Fquarantine.php

[Tue Aug 13 16:35:12.320289 2019] [:error] [pid 8344:tid 2036] [client 127.0.0.1:58098] [client 127.0.0.1] ModSecurity: Warning. Operator GE matched 4 at TX:outbound_anomaly_score. [file "C:/xampp/apache/modsecurity/owasp-modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "96"] [id "980140"] [msg "Outbound Anomaly Score Exceeded (score 13): PHP source code leakage; individual paranoia level scores: 13, 0, 0, 0"] [tag "event-correlation"] [hostname "demo9.local"] [uri "/wp-admin/admin.php"] [unique_id "XVNJLzsBsvuo17DcrKWzkwAAAIg"], referer: http://demo9.local/wp-admin/admin.php?page=bulletproof-security%2Fadmin%2Fquarantine%2Fquarantine.php

[Ed-AITpro]

FYI all of the data in those error messages was stripped out. So yeah you are just left with the base Mod Security error, which is useless pretty much just like Mod Security. There I said it.

[Ed-AITpro]

Now this was only occurring in my WordPress plugin then I would just think that I suck at coding, but when I look around I can literally find 100's and probably more like 1,000's of WordPress plugins that Mod Security breaks. To me that classifies as a disaster.

[Ed-AITpro]

If were easy, simple and quick to fix Mod Security false flags then Mod Security would be awesome, but unfortunately that is where Mod Security has failed in a very big way. At this point Mod Security is a menace and not a help.

[Ed-AITpro]

One final thing from me and I'll go my merry way and start redesigning my plugin to evade Mod Security. Ironically my WordPress plugin is a security plugin that uses some features that are almost identical to what Mod Security is doing. The difference between my security plugin and Mod Security is that I have also provided whitelisting tools within my plugin that a user can use to quickly fix anything that my plugin is mistakenly blocking. If a similar set of whitelisting tools was included in cPanel then once again Mod Security would be awesome instead of a menace.

[dune73]

Hello @Ed-AITpro, I'm sorry for the (huge) inconvenience and I feel your pain.

The problem here is that we have certain assumptions on how people should be running CRS to minimize the pain and then hosters just ignore these and you are pretty much on your own.

The 3 alerts you submitted above all seem to relate to response body inspection. The quickest way to get rid of these is to disable response body inspection at the engine level: SecResponseAccess off.

CRS comes with a set of rule exclusions (~ Whitelistings) aimed at Wordpress. Base Wordpress, that is. This means we know the false positives that a basic Wordpress installation generates and you can get rid of these by enabling said rule exclusions. However, this does not cover the myriads of plugins, in fact it does not even cover the top ten plugins everybody uses. We had hoped that the Wordpress community would take it from the base installation rule exclusions to those plugins they thought important. But no effort from that side so far. So we returned to what we know best: Writing rules to protect websites from generic attacks.

If you are interested to improve the situation and help us to cover Wordpress plugins in our rule exclusion package, then we'd be happy to support and guide you.

Now there are semi-automatic ways that help you generate the rule exclusions to get rid of these false positives. The process and the tools behind are all explained at https://www.netnea.com/apache-tutorials/, namely tutorial 8.

For starters, I recommend to raise the anomaly threshold for incoming and outgoing requests from the default to a very high level (on any new installation). That way you see the alerts, you can tune them away, while your users are not noticing ModSec is even there. Then, when you are confident that most of the FPs are gone, you slowly lower the anomaly threshold over multiple iterations until you reach the default value of 5 (4 for outgoing responses) again.

And finally: We are the OWASP ModSecurity Core Rule Set project. We are separate from the ModSecurity project. But reading through your message, I think you are actually only taking offense with our rules and not the engine itself.

[Ed-AITpro]

Thanks for responding. I apologize for letting my emotions get the better of me and venting my frustrations, which is not conducive or constructive to anyone. I've had them bottled up for a long time and honestly am just upset at myself for waiting so long hoping that this cPanel Mod Security CRS thing would work itself out over time. I know better than that. ;)

I have Mod Security with CRS installed on a Local Dev server and it is very impressive with a very extensive accumulation of every attack vector under the sun. I'm not complaining whatsoever about Mod Security or CRS in general.

Really it just comes down to cPanel's decision to offer Mod Security with CRS to the public without providing a simple way for end users to fix any issues or problems that arise. If cPanel had pre-built and included a Mod Security toolset in cPanel that allowed users/customers to whitelist or remove individual secRules then I would not be contacting you or cPanel about this stuff. Passing blame on anyone is not constructive, but pointing out a glaring problem is constructive. I've already contacted cPanel and pointed this out, but without being too cynical I understand why cPanel did what they did and it is simply an image and marketing thing - ie "cPanel now comes with built-in website security".

Overall I believe web hosts and cPanel come out ahead, but I have had numerous users and customers ask me which web hosts do not have Mod Security CRS so that they can switch to that web host. Go Daddy cPanel hosting does not have Mod Security CRS, which is the host that I am using. So I have been recommending Go Daddy hosting to anyone who asks me for a web host change/move recommendation that does not have Mod Security CRS.

Anyway since fine tuning Mod Security CRS on my Local Dev server would only work for me and not the 1,000's of my plugin users on various web hosts using varying CRS rules and configs. then what I am doing is identifying all the things that CRS is seeing as a threat in order to redesign my plugin so that CRS no longer detects any false alerts. I thought about creating a list of all the false alerts with the ID numbers so that I could have a general email that I could pass on to my users which they could then pass on to their web hosts. That would be a waste of time and would not be a good solution for a couple of reasons: Even pointing out the exact error messages to web host support techs and providing them with all the exact necessary information for which CRS secRules to whitelist or exclude has not been working for the last year. Well ok 10% of the time the problem gets resolved. The other obvious reason to redesign my plugin instead trying to keep track of secRule false alerts is I assume you are continuing to add new secRules. So that would mean constant maintenance time for me to keep retesting each new CRS ruleset.

So yeah the only logical and sensible solution is to redesign my plugin so that Mod Security CRS does not detect any false alerts or anything at all for that matter - problem solved.

Thanks again for responding and the current CRS ruleset is very impressive.

[dune73]

Thank you for following up, Ed. It is true that the cPanel integration is but minimal. Also cPanel used to work with the ModSec developers directly and that did not work out so well. We have met the cPanel guys last year when they attended the CRS community summit and we hope they will be back this year (September 24 in Amsterdam), so we can get serious about improving the integration so people get exactly what you asked for. I think you got this completely right. I really think cPanel tries to do the right thing, but it takes some resources and some serious knowledge. They are but a fairly small company after all and their business is highly competitive.

While we are really conservative about adding new rules or changing their behaviour, we do add new rules to new major versions. 3.2.0 (planned for September) will thus bring new rules. 3.1.1, the latest stable release, did not however. Point releases are purely releases fixing false positives and errors in the functioning of the rule set.

But it is true that working around CRS in a way that makes sure your plugin does nothing that raises suspicion is the best way to stay out of trouble. At times it is really hard that we are blocking perfectly reasonable requests, but it is really because they look like they might be a PHP injection or a linux RCE.

With that being said, we are getting relatively few FPs here on github. We generally try to act on them, but without people submitting their problems, we can't really help them.

And finally: When we took over the sleeping CRS project, the rules were in a fairly messy state. We've been cleaning this up, weeding out FPs and generally making integration easier. But we are nowhere near the goal, but we appreciate constructive feedback like your follow up message. Thank you.

[Ed-AITpro]

Well 99% of what cPanel has done and created is absolutely incredible. Personally I think cPanel is the best web host backend toolset out there. I fairly regularly login to customer's web host control panels and have first hand experience with navigating a lot of them and cPanel is the most intuitive and feature packed toolset of all of them in my opinion. So yeah cPanel just dropped the ball on the Mod Security CRS thing simply because they did not provide a pre-built Mod Security toolset to fix issues, but everything else about cPanel is awesome. ;)

My security plugin also detects false positives that exactly simulate attack vectors. So yeah is just the nature of the beast. It is much easier for me to provide whitelisting and exclusion tools in my plugin because everything is happening at the client side vs server-side. So yeah to reiterate the only real problem that is going on and what is missing with cPanel Mod Security CRS and is once again simply an easy way to fix any issues that arise.

Well I think there are probably a lot more folks out there that have not reported issues to you guys. The number I use (relative to the total number of my user base) is that for every one person that complains about something in my plugin there are probably 1,000 other people that never say anything to me, but have the same complaint. It took me a year to say anything and even then I only said something out of pure frustration. I already know what needs to be done so there was really no reason to contact cPanel or you guys at all. If you do some google searches for search terms that are relative to Mod Security and WordPress Plugins or use this search: site:wordpress.org Mod Security you can get a real picture of the scope of CRS issues/problems. Most folks are not aware that Mod Security and CRS are 2 completely different things. So searching using CRS search terms will probably not produce that many search results.

I think you guys are doing an amazing job and service and eventually the only real problem - a simple way to fix any issues/problems - will be resolved.

[Ed-AITpro]

On a positive and off topic note, I am actually having some fun redesigning my plugin by creating text box Forms that are updated in real time using Event Listeners that encrypt and decrypt data using pure js.

[Ed-AITpro]

Ok so the most critical forms now completely evade ModSecurity altogether using encryption and will no longer be broken by ModSecurity, but I have some less important forms that ModSecurity is still falsely detecting critical issues. This one is an absolute joke to be honest with you: "ModSecurity: Warning. Matched phrase ".htaccess" at ARGS:filename." Are you kidding me??? That's like saying Critical Warning "air detected". Come on man. I think you guys might be going overboard on what you are detecting. That is as bad as malware scanners detecting the legitimate PHP base64_decode() function and calling it "malicious". Ok so yeah you detected an .htaccess file, but what about checking the actual file for anything malicious. How can you call any .htaccess file malicious or generate a Critical Severity warning just because you matched the phrase ".htaccess"???? That is insane.

[Ed-AITpro]

Wow ok so the Rule is checking the outputted "success message", which contains this success phrase: Your currently active root htaccess file has been updated. I assume this ridiculousness is occurring because I am checking with the content body filter on, which obviously just grabs random Source Code and tries to magically interpret what it means. Brilliant stuff.... not.

[Ed-AITpro]

What the hell does this error mean? I tried looking at the CRS SecRule code and it does not make any sense at all to me. ModSecurity: Warning. Operator GE matched 5 at TX:anomaly_score. file "C:/xampp/apache/modsecurity/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf" id "949110" tag "attack-generic"

[csanders-git]

You sure have quite the thread here and while I appreciate your enthusiasm I must question if writing long text blocks is the best way to allow us to assist you.

Generally I'll talk to the two most recent points. Not allowing htaccess is not akin to air, instead these are apache configuration files and are not designed to be typically accessible. As per the blocking evaluation. This indicates that multiple other rules have fired and the culmination of those rules have caused a block. This is part of anamoly detection.

[Ed-AITpro]

"instead these are apache configuration files and are not designed to be typically accessible." What? That does not make any sense. WordPress ships with a default .htaccess file that users can edit. .htaccess files are very common and used by anyone and everyone these days. They can be used anywhere and everywhere under a hosting account structure. Are you thinking of conf files?

Ok so how do I track down what CRS is seeing as a problem or security risk or whatever. I'm ok with changing success message in Forms to generic success messages such as: "Success!" to get around this ridiculousness - "ModSecurity: Warning. Matched phrase ".htaccess" at ARGS:filename."

[Ed-AITpro]

Got another obscure error message and the SecRule code does not tell me what CRS is specifically checking. SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@pmf lfi-os-files.data" \

ModSecurity: Warning. Operator GE matched 5 at TX OS File Access Attempt;

What does this mean???????

[Ed-AITpro]

If these things were only happening just to me and not millions of people using cPanel then I would just start commenting out SecRules, but since i get contacted daily by my users about things that are being broken by ModSecurity CRS rules and doing Google searches shows that 100's if not 1,000's of other plugin and theme authors are dealing with this nightmare as well. Sure would be nice if you guys would create a simple client side bypass method. I was having fun creating Forms that evade ModSecurity CRS rules, but these latest CRS errors are just plain stupid. What I have found is that if I encrypt data in a Form and save the encrypted data in the Database and then get the data from the DB and decrypt it for use in file writing then ModSecurity CRS rules do not detect anything or break anything. The particular Form I am working on now needs to allow users to edit files directly. I could of course add intermediary steps in the background using the method that evades ModSecurity CRS rules entirely, which it looks like I'm going to have to do just to get around all this absolute ridiculous FUBAR MESS!

[Ed-AITpro]

Ok take back anything positive I said previously about your CRS Ruleset. The more I look at it the more I am convinced it is an absolute disaster. Jesus Christ.

[Ed-AITpro]

"...anomaly mode is the default and recommended mode, since it gives the most accurate log information...". Really? How come it does not tell me anything useful then? I have no idea how to troubleshoot things because anomaly mode does not tell me anything I can use.

[Ed-AITpro]

Just tried using Debug Mode. It tells me the exact same thing as DetectionOnly tells me = absolutely nothing useful.

[Ed-AITpro]

No wonder web host techs are rarely (10% of the time at best) able to solve any ModSecurity CRS problems. How can you solve a problem if you don't know what is causing the problem. Very basic stuff. Too bad CRS does not incorporate that very basic fundamental concept. What an absolute disaster.

[Ed-AITpro]

Ok I figured out how to get CRS to do something useful. I found the SecRule that is malfunctioning and changed nolog to log. What I found is very disturbing and upsetting. The CRS SecRule considers these things as LFI attacks:

Warning. Operator LT matched 2 at TX:executing_paranoia_level. A Request to: uri "/wp-admin/admin-ajax.php" - counts 2 times as an LFI attack on lines 132 and 133 A Request to uri "/wp-cron.php" - counts 2 times as an LFI attack on lines 132 and 133 A Request to uri "/wp-admin/admin.php" - counts 2 times as an LFI attack on lines 132 and 133 A Request to uri "/favicon.ico" - counts 2 times as an LFI attack on lines 132 and 133

These are all legitimate Requests. This is an absolute disaster. You guys seriously need to fix CRS.

[Ed-AITpro]

So all my redesign changes in my plugin using encryption work perfectly to evade your CRS nightmare and now what I am facing is something that is fundamentally how WordPress works in general. That is not something that I can get around because I have tested several other WordPress plugins by saving option settings in those other plugins and the same FUBAR CRS SecRule is malfunctioning. So in general you have a HUGE FAILURE occurring in CRS 3.x. I'm surprised you are not getting flooded with angry complaints, but I assume those complaints are going to web hosts who are probably either disabling ModSecurity altogether or at least disabling Anomaly BS.

[Ed-AITpro]

Anyway I am relieved that my plugin is ok and CRS is taking a big steaming pile. What I can do now is just refer web hosts to this GitHub post so that they know what in CRS needs to be done, which is disable Anomaly crap so that they won't have to deal with angry customers all day calling about ModSecurity CRS breaking stuff.

[Ed-AITpro]

Hmm now there is something else in CRS that is malfunctioning and no information on what the root cause is. What a surprise. Anyway I have found a method that works to evade ModSecurity that works perfectly for all my critical Forms. So I will simply have to design all my plugin Forms to use that method since ModSecurity CRS tends to block legitimate Form processing in general.

[Ed-AITpro]

To web hosts: Anomaly Scoring help info can be found here > https://www.modsecurity.org/CRS/Documentation/anomaly.html. The help information does not clearly state that the default Critical Anomaly Scoring level is set to 5 and uncommenting the Anomaly Scoring settings allows you to change the default scoring levels to a higher scoring level. By default the Anomaly Scoring settings are commented out in the csr-setup.conf file.

[gotwf]

Recent discussion in another developer focused community concludes: "cPanel (and Docker) is(are) for those who either don't know how or are too lazy to be sysadmins". That cPanel has become ubiquitous notwithstanding, cPanel is also a for profit entity that takes from FOSS but gives very little back. In other words; parasites. Hence, I would encourage owasp developers not to focus too much of their limited resources on catering to such, as cPanel should be the primary point of contact for cPanel's lamer implementation of owasp-crs.

Agreed that rolling out modsecurity and owasp-crs is not for the faint of heart. But neither is securing web content in the age of an Internet run amuck and rampant with various bad actors ranging from script kiddies to organized crime to Nation/State sponsored cyber terrorism. The security bar is thus commensurately quite high. I am not a developer, nor associated w/the project in any way, but rather a grateful, if still wet behind the ears, implementer. I have had my challenges rolling this out, not the least of which is dated and/or incomplete/conflicting documentation scattered about the 'net. So yeah, I've had to put in a bit more effort than big company dot com pseudo "FOSS" projects that sponsor technical documentation writers. But I am also "old skool" and done my homework and legwork before bothering/whinging to the project's gracious dev heads cuz... they've got better things to do w/limited time and resources than to hold the hands of lazy, entitlement PAB's.

Yeah, I can be an arse in my directness but some things need to be said. That said.. heh... it would be cool if there was a bit more "support" via irc, as not all of us are into the slack scene and reluctant to file a bug report about every bump in our roads.

tl;dr

Securing stuff on the modern web is not a simple point and click operation. Self described "pro's" may want to ante up rather than bitch. Or maybe opt for something "simpler" like fail2ban.

Peace

[Ed-AITpro]

Well imagine if creating ModSecurity CRS whitelist rules was simple - then there would be absolutely no problem at all. In my security plugin I put major emphasis on designing it so that troubleshooting and problem solving takes only a few minutes even for non-technical folks. Brilliance is creating something complex that is simple enough for anyone to use. Creating some complex that is complex to use - yeah not so brilliant. ;)

[Ed-AITpro]

Imagine if ModSecurity CRS had a user friendly GUI - Now that would be brilliance. ;)

[dune73]

Dear @Ed-AITpro,

We are sorry that CRS does not work for you. As we have explained above, false positives are a nuisance and we are aware of the fact that they are painful for you and other users. That's why we welcome actionable bug reports, ideally with log excerpts or summaries that we can work with (maybe check out other issues where this is done in an exemplary way).

There is plenty of documentation around namely on our website https://coreruleset.org, in the crs-setup.conf and a series of canonical tutorials at https://netnea.com/apache-tutorials that go to great lengths to explain what this is all about, why CRS behaves the way it does and how to tackle false positives effectively.

However, we are volunteer developers just like you. We are dedicating our spare time to this project. So if people are not paying us, then we expect at least some respect for our work. We won't take your rants and your swear words. In fact your attack is very personal and this is quite novel for us and I will not continue this discussion.

I will now close this issue. If you want to work with us, then please open a new issue and include your (sanitized) logs or join us on owasp.slack.com in the channel coreruleset.

Good night, dune73, CRS co-lead