Skip to main content

OWASP - mod security and wordpress

Silver_2000
I updated Cpanel to the version that supports OWASP and enabled it Everything seemed fine on most sites until I tried to edit a wordpress page Various issues including unable to edit pages - editing pages results in odd behavior when I disabled the ruleset - wordpress went back to normal The mod security logs showed that the text I was trying to add to a wordpress page matched some rules
958977 PHP injection attack Function name found CRITICAL 302 Request: POST /wp-admin/post.php Action Description: Access denied with redirection to http://domain.com/ using status 302 (phase 2). Justification: Matched phrase "\"" at ARGS:content.
The text I was trying to post had no code or special charcters in it. It was simply about 5 paragraphs describing some recent work. now Im a little concerned that OWASP replaced previous rulesets ... Searched for OWASP and wordpress issues and didnt find anything specific

Comments

80 comments

Date Votes
  • Infopro
    ]/usr/local/apache/modsecurity-crs/activated_rules/whitelist.conf I dont have that folder on my server

    Ignore that suggestion if you're using the new cPanel ModSecurity implementation. Rules you disable are added to this file I believe: modsec2.cpanel.conf The docs may be of some use in explaining this new setup I think: OWASP ModSecurity CRS - cPanel Knowledge Base
    0
  • Silver_2000
    ]Ignore that suggestion if you're using the new cPanel ModSecurity implementation. Rules you disable are added to this file I believe: modsec2.cpanel.conf The docs may be of some use in explaining this new setup I think: OWASP ModSecurity CRS - cPanel Knowledge Base

    thank you for telling me to RTFM but those docs dont mention modsec2.cpanel.conf and the top of the modsec2.cpanel.conf file says ## This file is automatically generated from the data kept in ## ## /var/cpanel/modsec_cpanel_conf_datastore. ## ## ## ## Manual changes made directly here will be lost when the ## ## file is regenerated.
    it looks based on your link like it might be here modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf Other rules may incorrectly flag some traffic as bad (false positive). The rules in this configuration file detects those false positives and allows the traffic to pass through.
    for the next guy who googles this here are the file locations : /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-01-COMMON-EXCEPTIONS.conf /usr/local/apache/conf/modsec2.cpanel.conf /usr/local/cpanel/shared/templates/modsec2.cpanel.conf.tmpl in /usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/ there are 2 files with that name REQUEST-01-COMMON-EXCEPTIONS.conf files REQUEST-01-COMMON-EXCEPTIONS.conf.BAD dated 12/18 which is interesting since it was just installed the format of the exceptions isnt all that inituitive and isnt covered by RTFM This file is used as an exception mechanism to remove common false positives # that may be encountered. # # Exception for Apache SSL pinger # SecRule REQUEST_LINE "@streq GET /" "phase:1, id:'981020', t:none, pass, nolog, chain" SecRule TX:REAL_IP "@ipMatch 127.0.0.1,::1" "t:none, ctl:ruleEngine=Off, ctl:auditEngine=Off" # # Exception for Apache internal dummy connection # SecRule REQUEST_LINE "^(GET /|OPTIONS \*) HTTP/1\.[01]$" "phase:1, id:'981021', t:none, pass, nolog, chain" SecRule TX:REAL_IP "@ipMatch 127.0.0.1,::1" "t:none, chain" SecRule REQUEST_HEADERS:User-Agent "^.*\(internal dummy connection\)$" "t:none, ctl:ruleEngine=Off, ctl:auditEngine=Off"
    At the end of the day Im interested in securing my server AND allowing common apps like wordpress to work Ill keep an eye on this for a usable solution
    0
  • Infopro
    ]thank you for telling me to RTFM but those docs dont mention modsec2.cpanel.conf

    Nor did you.
    ] and the top of the modsec2.cpanel.conf file says ...

    At bottom it says: ## ModSecurity disabled rules:
    And is why I mentioned it.
    ]/usr/local/apache/modsecurity-crs/activated_rules/whitelist.conf I dont have that folder on my server

    The link I provided doesn't mention that path anywhere, that's why you don't have it on your server. It does mention where the rules are located though and is why I linked you to it, in an effort to answer the question about the whitelist directory location. At this point with this being a bit new to all of us, RTFM is not such a bad suggestion although I didn't suggest it to you.
    0
  • sonicthoughts
    ]@Brian: Thanks for your response. I look forward to a 'report' feature, since I have a feeling it's going to be used quite heavily when live... Can you tell us more about how the rule updates will work? I see there's an option to keep them automatically updated, but how and when will this trigger? Via regular automatic updates like cPanel presently does, or will it only update via EasyApache? Who is maintaining these rule updates? Yourself or OWASP? Can you also tell us more about how compatible these rules are with Litespeed? Litespeed does not have the same mod_security implementation that Apache does, obviously, so it may be useful for multiple sets of rules depending on which software is installed. I understand you're currently not likely to support Litespeed, but it's something to bear in mind given the large number of hosting providers using it. In regards to testing the rules against Wordpress etc, I'm sorry but you really couldn't have tested them for very long or even at all. Every single server I deployed the rules on was throwing up huge numbers of false positives. From things like busier sites triggering DoS warnings to people literally being unable to login to their admin pages on quiet sites, or make very basic edits to posts in their blogs because the rules thought they were SQL injecting themselves. I think my personal favourite was that one customer accessed their Wordpress site backend without the 'www' prefix and because Wordpress was set to use the www prefix, it redirected them to a login page on the www. variant of the domain. The current rules considered that a cross-site attack (because the referer didn't match) and blocked it completely, denying access to the site for the client. If you're going to release, or at least provide rules like these, whoever is maintaining them really needs to test them thoroughly and ensure that they work "out of the box" on common software such as WHMCS, Joomla, Wordpress, et all. I know that's hard to do unless you test on a production server, but some of the false positives here are very obvious and simple stuff. @kernow: With respect, Comodo's WAF rules are also a mess and have an insane number of false positives with them out of the box. I've personally reported in the region of 40-50 false positives rules to them in the last 6 months alone. I see the potential benefit of adding them as a vendor, but they are by no means a perfect ruleset provider.

    This is EXACTLY my concern! Wasted a lot of time with preserving old rules, poor documentation and false positives! [COLOR="silver">- - - Updated - - - Here is the irony: The goal of these rules it to enforce automated protection, but the lack of proper management, documentation and recommendations will lead to disabling rules or ignoring them ... worst scenario.
    0
  • quizknows
    ] Rules you disable are added to this file I believe: modsec2.cpanel.conf

    That is correct. If you use the WHM interface to whitelist a rule, it will add a "SecRuleRemoveByID #######" line to modsec2.cpanel.conf to disable the rule.
    0
  • Silver_2000
    ]Nor did you. At bottom it says: And is why I mentioned it. The link I provided doesn't mention that path anywhere, that's why you don't have it on your server. It does mention where the rules are located though and is why I linked you to it, in an effort to answer the question about the whitelist directory location. At this point with this being a bit new to all of us, RTFM is not such a bad suggestion although I didn't suggest it to you.

    Here is how I read what you posted Ignore that suggestion if you're using the new cPanel ModSecurity implementation. Rules you disable are added to this file I believe: modsec2.cpanel.conf
    "on your server you would need to edit this file to add your disabled rules " But the file itself says dont edit it ... The docs may be of some use in explaining this new setup I think: OWASP ModSecurity CRS - cPanel Knowledge Base
    " Go here to read the damned manual. " That link has almost no helpful information about how to disable rules Keep in mind we arent all "Info Pros"
    0
  • quizknows
    If you need to disable rule IDs, doing it through the WHM GUI should add the correct lines to modsec2.cpanel.conf for you. Otherwise, modsec2.user.conf is there to be edited by the user. For many years we have just managed our customers modsec2.user.conf files for them but called a custom.conf as an "includes" so they could add rules. If you wanted to do your own exemptions by hand, you can edit modsec2.user.conf unless your host has a note in the file stating otherwise.
    0
  • Silver_2000
    ]If you need to disable rule IDs, doing it through the WHM GUI should add the correct lines to modsec2.cpanel.conf for you. Otherwise, modsec2.user.conf is there to be edited by the user. For many years we have just managed our customers modsec2.user.conf files for them but called a custom.conf as an "includes" so they could add rules. If you wanted to do your own exemptions by hand, you can edit modsec2.user.conf unless your host has a note in the file stating otherwise.

    Im the host default the cpanel file states ## This file is automatically generated from the data kept in ## ## /var/cpanel/modsec_cpanel_conf_datastore. ## ## ## ## Manual changes made directly here will be lost when the ## ## file is regenerated.
    Ive wasted a lot of time directly editing config files over the years just to have it wiped by cpanel So Ive learned to heed the warnings
    0
  • quizknows
    modsec2.user.conf is there for you to edit all you want. It will not be over-written, unlike modsec2.conf or modsec2.cpanel.conf. Also, this thread is pretty important. If you've enabled the OWASP vendor in the last couple days your ModSecurity might not be doing anything at all right now. upcp seems to be removing the configs from modsec2.cpanel.conf.
    0
  • Infopro
    ]... Keep in mind we arent all "Info Pros"

    Neither am I. Its a nickname. I try and help where I can. Re: ModSecurity question (in WHM 11.48) - cPanel Forums And there is no cap P in it. It's Infopro, short for Information provider. That link has almost no helpful information about how to disable rules
    That wasn't the question I was answering. Please see the earlier posts again. That link tells you were the files are located, and nowhere there does it mention the whitelist file that you mentioned you did not have on your server. Thanks.
    0
  • Echelon17
    ]This is EXACTLY my concern! Wasted a lot of time with preserving old rules, poor documentation and false positives! Here is the irony: The goal of these rules it to enforce automated protection, but the lack of proper management, documentation and recommendations will lead to disabling rules or ignoring them ... worst scenario.

    Indeed, this imo is the biggest problem with any and all mod_security implementations. If a vendor rule doesn't work, as a provider you just have to disable it for the clients sake. You then have to report the false positive and in a few days you'll forget all about it. When the rule eventually gets fixed, because you've forgotten about it, it will remain disabled anyway That's why I proposed a different system here; [url=http://features.cpanel.net/responses/mod-security-false-positive-reporting-system]Mod_Security False Positive Reporting System | cPanel Feature Requests Please vote on the request if you are interested.
    0
  • quizknows
    I like the idea, though usually, disabling a rule per URI is a bit better than globally. I.E. if the rule breaks stuff in wp-admin, just do SecRuleRemoveByID ##### This way, the rule is still active for all other areas of the site / server. You'll notice the atomic rules for example have a ton of specific exclusions that disable rules for certain file names. This is necessary in any good rule set.
    0
  • Echelon17
    ]I like the idea, though usually, disabling a rule per URI is a bit better than globally. I.E. if the rule breaks stuff in wp-admin, just do SecRuleRemoveByID ##### This way, the rule is still active for all other areas of the site / server. You'll notice the atomic rules for example have a ton of specific exclusions that disable rules for certain file names. This is necessary in any good rule set.

    A false positive is a false positive. It means the rule doesn't work, so allowing it elsewhere is likely to increase the risk of further false positives somewhere else. Once the vendor fixes the rule, they can incorporate the URI into their own whitelist rules, if necessary.
    0
  • quizknows
    ]A false positive is a false positive. It means the rule doesn't work, so allowing it elsewhere is likely to increase the risk of further false positives somewhere else. Once the vendor fixes the rule, they can incorporate the URI into their own whitelist rules, if necessary.

    I've managed modsecurity rules for a major hosting provider for many years, and actually, I've found the opposite to be true. Some rules (like SQL injection rules for example) need to be disabled for forum software but work great elsewhere. Using the locationmatch to disable a rule just for the script it's causing problems with has had a very good track record of working for us and our customers. If enough customers whitelist a rule for a specific script, then we add that exclusion to our rule set which we provide our customers. And yes, the vendor should be doing the location-specific exclusions in most cases. I was just saying that the majority of the time the false positives caused by a rule really only affect a few URIs (or even a single URI). If the false positive report included the audit log data, this should be sufficient for any rule author to fix the rule or make the necessary exclusions. For the purposes of your proposed reporting system, a global disable until the next rev tag on the rule is probably fine. It seems to be a sensible solution and you've got my vote on that.
    0
  • Echelon17
    ]I've managed modsecurity rules for a major hosting provider for many years.

    OK. And? Your personal experience and history are irrelevant to this discussion. Why are you bringing them up? Managing modsecurity rules is not a distinguished, difficult or complex task. Some rules (like SQL injection rules for example) need to be disabled for forum software but work great elsewhere. Using the locationmatch to disable a rule just for the script it's causing problems with has had a very good track record of working for us and our customers.
    Yes and that may very well be the case for you and your own experiences. The point is, if a rule is written correctly you won't need to implement your own locationmatch workarounds in this fashion. That's the purpose of the report feature coming soon. You report these problems to the vendor and they can make accommodations for specific scripts and installations. This helps everyone. If a rule is broken to the extent you are applying numerous locationmatch disables to your configurations so that it makes your scripts work, I'd have to argue that you're doing things wrong. I understand you're making the best of a bad situation and rather than disabling the rule globally you'd prefer to have it disabled in some places instead of every place, but that's really not benefiting you at all. A broken rule is a broken rule, and if it's broken in one place and whitelisted, it's likely broken in others. You just don't know yet. Perhaps it's not even protecting you from anything. And yes, the vendor should be doing the location-specific exclusions in most cases. I was just saying that the majority of the time the false positives really only affect a few URIs (or even a single URI).
    If a rule is broken and reporting false positives, I'd much rather disable it globally until it is fixed than disable it for one path, then another when it's reported broken again, and then another, and so on, and so forth... Did you read the feature request I posted? It makes far more sense than implementing your own custom locationmatch disables. In the system I propose; if a rule is broken it can be fixed by the vendor, and then automatically reactivated after the next rule update. In your situation, you'd need to manually check each and every rule update against your custom disables and then figure out if they can be reactivated or not. Otherwise, when a fix comes out, you'll still be disabling it and have zero protection from it at all.
    0
  • quizknows
    I only mentioned my experience to let you know that I'm not speculating with what I say. I work with ModSecurity every day. And actually, I do know if rules are still protecting. I use AuditConsole to aggregate audit log data from thousands of sites so I can see rules being tripped in real time. It makes it very easy to see attacks being blocked, or false positives that occur. It's actually an awesome piece of software and I recommend it to anyone who manages ModSecurity on multiple hosts. Anyway, ultimately you make good points and your system does make sense. I even voted on your feature request. For this situation it is certainly a sensible solution. Cheers.
    0
  • Echelon17
    ]I only mentioned my experience to let you know that I'm not speculating with what I say. I work with ModSecurity every day.

    I didn't claim you were speculating anything. It seemed very defensive of you to mention your position and history, and honestly read very much like an attempt for you to try and suggest your opinion is more valid than others. Completely unnecessary. We're having a discussion, not a measuring contest ;) EDIT: Please, stop editing your posts if possible. It makes it extremely difficult to follow this thread in any sane manner if you do that.
    0
  • quizknows
    I can get a bit defensive regarding ModSecurity, and for that I apologize. I'm very passionate about it because I see every day how much it helps our customers, and I just want it to work well for everyone. With a sample size of just 50 servers, I see close to 300,000 audit log entries per day, and that's with LF_MODSEC enabled. Without LF_MODSEC it's literally millions. Edit: Sorry for all the edits. I'm just saying that many rules are fixed by disabling them for certain scripts, even in the atomicorp rules (which IMO are the best vetted rules available). I'd rather have protection on the other URLs even if the rule is "broken" as you put it. WAF rules are often not one-size-fits-all, a little customization is a healthy thing for certain environments. I have gigs worth of logs to prove that "broken" rules protect a ton of other URLs even if they're disabled for a script or two, or even entire directories. Take a look through the atomicorp rules; there are tons of URI based exceptions for a lot of the rules. So yes, the vendor should handle fixing that, but in the interim if I see a rule doing good work elsewhere I'm not going to globally disable it.
    0
  • Dhaupin
    Hey all, thanks for taking the time to get OWASP rolling. I realize alot of folks are having wordpress issues. I would like to drop a note about the level of action its taking with Google and Bingbot. In verbose-only mode, the logs are filled with denies to both bots. Granted we are using HTTPBL integrate, but it seems the conf's are set too hardcore out-of-the-box when using that: 66.249.65.176 (googlebot) - 981204: Inbound Anomaly Score Exceeded (Total Inbound Score: 5): HTTP Blacklist match for client IP 157.55.39.155 (bing) - 981140: Request from Known Malicious Client (Based on previous traffic violations). 157.55.39.155 (bing) - 981175: Request Denied by IP Reputation Enforcement
    0
  • headsup
    cPanel get getting better, both UI and features and frankly, this is one the most best thing cPanel has delivered so far. However, the deployment of what could have been a source of joy to many users wasn't really thought out well beforehand. Not only that these OWASP Rules didn't work with most of the scripts out there which accounts for a greater part of those uses cPanel, there was no warning or "use at your risk" mail that ought to have accompanied this roll-out. I mean, cPanel ought to have a mass email list for all its roots users who will then get advance warning when these or any updates comes on stream. We will have to disable this pending resolution as it really wreaked havoc on our installs. Took much time to figure out that this, was the cause. You can also list out the rules that might redeem the situation for now pending that time. Good move, bad roll-out.
    0
  • kdean
    cPanel does have a mailing list you can opt-into. https://cpanel.net/mailing-lists/ They also have a changelog RSS feed: [url=http://atom.cpanel.net/changelog/cpanel-changelog.atom]cPanel & WHM Change Log Feed or you can manually look at the changelogs: https://documentation.cpanel.net/display/ALD/Change+Logs
    0
  • nimonogi
    Latest release full of false positive.
    0
  • cPanelMichael
    ]Latest release full of false positive.

    Could you elaborate on this? For instance, is this a different report compared to what's already been mentioned on this thread? Thank you.
    0
  • xanubi
    ]Could you elaborate on this? For instance, is this a different report compared to what's already been mentioned on this thread? Thank you.

    Oh yes, full of false positives! First no one tell us, that we need to configure /usr/local/apache/conf/modsec_vendor_configs/OWASP/modsecurity_crs_10_setup.conf Then, if you want antivirus Check, you need to add to modsec2.user.conf this: SecRequestBodyAccess On SecRequestBodyLimitAction ProcessPartial SecResponseBodyLimitAction ProcessPartial ** and here the virus check rule Then Wordpress, Prestashop and Joomla, have lots and lots of problems with false positives!! My list now of exceptions is huge, and i'm not seeing the end of it, every day new situations with this 3 scripts happens, and this rules doesn't have brute force protection. The list of exceptions:
    SecRuleRemoveById 950001 SecRuleRemoveById 950109 SecRuleRemoveById 950901 SecRuleRemoveById 958056 SecRuleRemoveById 958030 SecRuleRemoveById 958057 SecRuleRemoveById 958030 SecRuleRemoveById 958977 SecRuleRemoveById 959073 SecRuleRemoveById 959072 SecRuleRemoveById 960024 SecRuleRemoveById 960915 SecRuleRemoveById 970015 SecRuleRemoveById 970901 SecRuleRemoveById 973335 SecRuleRemoveById 973333 SecRuleRemoveById 973340 SecRuleRemoveById 973342 SecRuleRemoveById 973343 SecRuleRemoveById 973304 SecRuleRemoveById 973334 SecRuleRemoveById 973332 SecRuleRemoveById 973327 SecRuleRemoveById 973324 SecRuleRemoveById 973300 SecRuleRemoveById 973302 SecRuleRemoveById 970003 SecRuleRemoveById 973317 SecRuleRemoveById 973306 SecRuleRemoveById 913342 SecRuleRemoveById 973350 SecRuleRemoveById 950907 SecRuleRemoveById 981205 SecRuleRemoveById 981251 SecRuleRemoveById 981244 SecRuleRemoveById 981255 SecRuleRemoveById 981249 SecRuleRemoveById 981242 SecRuleRemoveById 981231 SecRuleRemoveById 981256 SecRuleRemoveById 981243 SecRuleRemoveById 981245 SecRuleRemoveById 981246 SecRuleRemoveById 981257 SecRuleRemoveById 981173 SecRuleRemoveById 981318 SecRuleRemoveById 981317 SecRuleRemoveById 981248 SecRuleRemoveById 981240 SecRuleRemoveById 981204 SecRuleRemoveById 950109 SecRuleRemoveById 950901 SecRuleRemoveById 950911 SecRuleRemoveById 958977 SecRuleRemoveById 958979 SecRuleRemoveById 960010 SecRuleRemoveById 960915 SecRuleRemoveById 973337 SecRuleRemoveById 973338 SecRuleRemoveById 973340 SecRuleRemoveById 973342 SecRuleRemoveById 973343 SecRuleRemoveById 981176 SecRuleRemoveById 981214 SecRuleRemoveById 981240 SecRuleRemoveById 981243 SecRuleRemoveById 981245 SecRuleRemoveById 981246 SecRuleRemoveById 981248 SecRuleRemoveById 981257 SecRuleRemoveById 950901 SecRuleRemoveById 960915 SecRuleRemoveById 973337 SecRuleRemoveById 973343 SecRuleRemoveById 981240 SecRuleRemoveById 981246 SecRuleEngine Off SecRuleRemoveById 200002 SecRuleRemoveById 960010 SecRuleRemoveById 960912 SecRuleRemoveById 950901 SecRuleRemoveById 958977 SecRuleRemoveById 958979 SecRuleRemoveById 960915 SecRuleRemoveById 973340 SecRuleRemoveById 973343 SecRuleRemoveById 973350 SecRuleRemoveById 981257 SecRuleRemoveById 981261 SecRuleRemoveById 981243 SecRuleRemoveById 981245 SecRuleRemoveById 981248 SecRuleRemoveById 960010
    Also, this version of OWASP is BETA!! if you go to github, you'll see this rules on the DEV/BETA brunch. The stable actual rules are here:
    0
  • sonicthoughts
    ] However, the deployment of what could have been a source of joy to many users wasn't really thought out well beforehand. Not only that these OWASP Rules didn't work with most of the scripts out there which accounts for a greater part of those uses cPanel, there was no warning or "use at your risk" mail that ought to have accompanied this roll-out.

    The bottom line is: Please bundle BETTER rules and process for dealing with them. This is the WORST scenario because people end up turning off security due to false positives. That is exactly what happened with most of the big cyberhacks (target, home depot, banks, etc.) that you hear about. They all got a WARNING but it was lost in thousands of FALSE POSITIVES. I applaud Cpanel for taking a big step in security, but please do this properly. If the goal is to have a checklist of modsec support included then you have that, if it is to ensure secure systems then please consider how this impacts users in real world scenarios.
    0
  • sonicthoughts
    ]Multiple ModSec related threads merged here.

    Actually there are several of these floating about. I'm sure there are many more :) While I applaud Cpanal's efforts in improved modsec rule integration I'm very concerned that you have lowered the security level of many sites. After countless hours battling with modsec and having your support say they couldn't help further, I have turned them off completely. I'm trusting that soon Cpanel will either issue a patch or viable workaround and focus on delivering a usable interface and rule set. OWASP does not help most people. I know understand why there are so many other rule vendors. Most folks are not modsec experts. Perhaps a collaboration with Comodo or another org would help. I'm struggling with modruid2 compatability, geoip compatibility and loads of false positives. that is way too much of a headache for something as important as this. Thanks again for keeping us updating (in this thread?) and consider some suggested temporary steps to address the issues above.
    0
  • cPanelMichael
    The reporting functionality for OWASP is now implemented (though the update may take some time to reach all of the mirrors). You can check if your server has updated the vendor file to then see the report button with the following command:
    grep report_url /var/cpanel/modsec_vendors/meta_OWASP.yaml
    You will see the following output if you are using the updated vendor file:
    # grep report_url /var/cpanel/modsec_vendors/meta_OWASP.yaml report_url: https://www.modsecurity.org/rule_issue_report/cPanel/report/new
    If it's not yet updated, then you can wait for it to update during your nightly cPanel update, or by running the following command:
    /scripts/modsec_vendor update OWASP
    Note that as mentioned, you may need to allow some time for the update to reach the mirror your server uses. Once it's updated, a "Report this hit" option is available on the ModSecurity Tools page when "More" is pulled down. You will also have the option to disable the rule as you submit the report. Thank you.
    0
  • Vliegtuig
    Not sure if I am the only one with this problem, but when reporting a rule, I get the following error:
    The system was unable to submit the request: curl: (22) The requested URL returned error: 500 Internal Server Error
    An additional side-effect of this error: we cannot disable it through the web interface. In particular, we are receiving a *lot* of false positives caused by rule 950901, which looks for SQL tautologies. This rule seems to be very outdated because it lacks word boundaries. This problem ahs been discussed here in 2013:
    0
  • wrender
    I feel your pain of the ModSecurity OWASP false positives. It seems to be that especially with WordPress there are a lot of false positives with different plugins (Probably same reason it always gets hacked). I don't think it is really either a problem with cPanel, or with ModSecurity though. The OWASP rules for ModSecurity are designed to provide "Generic Attack Detection" so naturally they are going to block out some good web traffic to valid applications too as they are overly secure. In this case they seem to be so secure they create a lot of false positives which is a nightmare for a small business to whitelist. For us a couple of setups that are working well: Option 1 - (Commercial rules, with some basic OWASP rules enabled). 1. Buy a subscription to the Trustwave Commercial ModSecurity rules (Or other commercial mod security rule vendor), and run their application specific rules in conjunction with some of the base OWASP rules in anomaly detection mode. For example with these rules loaded in your ModSecurity Vendor Configuration: modsecurity_crs_10_setup.conf (Set to run in Anomaly Detection Mode by uncommenting that line, and increasing the 255 character limit line to something higher like 512). rules/REQUEST-01-COMMON-EXCEPTIONS.conf rules/REQUEST-10-IP-REPUTATION.conf rules/REQUEST-12-DOS-PROTECTION.conf rules/REQUEST-13-SCANNER-DETECTION.conf rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf rules/REQUEST-21-PROTOCOL-ATTACK.conf rules/REQUEST-49-BLOCKING-EVALUATION.conf rules/RESPONSE-59-BLOCKING-EVALUATION.conf rules/RESPONSE-80-CORRELATION.conf 2. And enable these commercial rules in the bottom of your /usr/local/apache/conf/modsec2.user.conf file:
    # Include Trustwave Commercial Modsecurity Rules Include conf/slr_vuln_rules/modsecurity_slr_10_ip_reputation.conf Include conf/slr_vuln_rules/modsecurity_slr_46_known_vulns.conf Include conf/slr_vuln_rules/modsecurity_slr_50_malware_detection.conf Include conf/slr_vuln_rules/owasp_crs_integration/application_specific/*.conf Include conf/slr_vuln_rules/botnet_attacks/*.conf Include conf/slr_vuln_rules/dos_attacks/*.conf Include conf/slr_vuln_rules/webshell_backdoors/*.conf
    * I think this method will always be a better way, because you are basically paying for a commercial rule set that will always have better protection with almost no false positives. (you get what you pay for!) Option 2 - (Only OWASP Rules Loaded) 1. Enable all of the OWASP rule sets in your ModSecurity Vendors. 2. Create a whitelist repository, and start whitelisting any false positives for each application. (I would strongly recommend setting up an AuditConsole server, as it will really help with this). I"ve started an OWASP whitelist repository here: /https://github.com/wrender/modsecurity-whitelist-apps If anyone is able to help contribute I think it would be very helpful to anyone running ModSecurity with all of the OWASP rules enabled. ** This is the very labor intensive way, because there are a lot of different false positives depending on which web applications you are running.
    0
  • Infopro
    What good does yet another github project for modsec accomplish? OWASP needs reports of false positives to make the rules any better, and you're hoping to get folks to contribute to your repository and theirs (I guess) or just yours? What good does running a paid version ($495 bucks a year?) and a free version accomplish, really? * I think this method will always be a better way, because you are basically paying for a commercial rule set that will always have better protection with almost no false positives. (you get what you pay for!)
    We're getting what we paid for right now. And, it sucks. These OWASP rules just plain suck. Untested it seems on just about everything. But with our help! Things will improve over time. This, from Brian Oates from cPanel on the EDGE mailing list, just today: One of our original goals with the OWASP ModSecurity Rule Set distribution was to provide OWASP"s maintainers with constant feedback from server owners utilizing the rule set so that it could be consistently improved upon. Lack of rule set feedback was one of OWASP"s maintainers' chief frustrations that they communicated to us. Therefore, both ourselves and OWASP would like to encourage everyone to utilize this reporting feature.
    OWASP's github is all but dead as far as feedback, so are their mailing lists from what I can tell. But hey, lets fragment the discussion into yet another github repository anyway, why not? Personally, I've got more important things to be doing than assisting OWASP and cPanel to come up with a basic set of rules that work. I may try them again at some point after you guys get the bugs worked out of them, but for now, hell no. The way things are going, that might be years from now, one rule ID at a time. cPanel's implementation of this new ModSec setup is coming along great, I'm really enjoying seeing the efforts here to make all this easier for us. But, the OWASP rulesets are the weakest, untested, part of the equation right now. And, it seems for some time to come, going by the public feedback I've been reading. Sign up for and follow the OWASP repository on GitHub and their mailing list. No worries, both are very low traffic.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post