Skip to main content

OWASP - mod security and wordpress

Comments

80 comments

  • brianc
    OWASP ModSecurity Rule unusable My server updated to 11.48 and along came the new OWASP ModSecurity ruleset. The only problem is that it is completely unusable. My IP address has been blocked multiple of times doing routine work within WordPress and WHMCS. The only way I can access my sites is to completely disable the rule set. I check the logs and I cannot find which rules are triggering the block nor is anything showing up in any of the logs. The block is just as if I was blocked by a firewall which I am not because I checked both CSF and cPHulkd. I am also able to access WHM just not my two sites on the server. So I have some questions cPanel Techs: 1. How is this new ruleset blocking IPs? 2. Why is there no trace of rules being violated in the logs? There were two initial rules that I triggered that I was able to disable but the blocks continued but there were no more rules being listed.
    0
  • quizknows
    Re: OWASP ModSecurity Rule unusable There should definitely be information in the apache error_log or the modsecurity audit log. The OWASP rule set is a bit advanced... I didn't think they would include it in that form. I was hoping they would strip out some of the troublesome rules and test it better against common CMSes before simply putting it into WHM. I run a custom rule set, so I definitely will not be enabling the OWASP rules any time soon. They're good rules but generally there are at least 5-10 you need to disable for most modern CMS software to work; which ones you need to disable will vary based on the software you use for your site(s). It's important to note the ModSecurity itself only blocks requests, not IP addresses, but if you use CSF then LFD will block your IP for repeat modsecurity entries in the logs from your IP tripping rules. To be fair I think cPanel is on the right track, but there's a serious lack of knowledge in the industry surrounding ModSecurity in general. That is really sad, because it's honestly the best tool you can use to block a huge variety of attacks and exploit attempts against websites. The new tools, while useful, are still a bit tough to use without a good understanding of ModSecurity to begin with.
    0
  • cPanelMichael
    Re: OWASP ModSecurity Rule unusable Hello :) You mentioned checking log files. Did you check /usr/local/apache/logs/error_log or were there other log files that you checked? Thank you.
    0
  • brianc
    Re: OWASP ModSecurity Rule unusable I checked everything in /etc/httpd/logs and nothing showed up except the two previous hits. This is bad to have a rule totally block access to two sites and nothing shows in the log files. The only thing that allowed me access was disabling the entire ruleset. Brian [COLOR="silver">- - - Updated - - - I checked CSF and I was not being blocked by it. However I did disable it to make sure but nope, I was still being blocked.
    0
  • kernow
    Re: OWASP ModSecurity Rule unusable This rule set from OWASP is a load of rubbish. As soon as we enabled it clients complained of not being able to acces wp-admin or if they could they could'nt edit posts. Other clients said they were unable to make posts to wordpress sites. We have spent the last few hours disabling many of the rules. cpanel 11.48 release notes Through the guidance of OWASP, cPanel now distributes a curated set of these rules
    Did you not think to at least try these out on a production server?
    0
  • Echelon17
    OWASP: False Positives You guys really screwed the pooch with the latest release. The OWASP rules are terrible and it's pretty obvious they haven't been tested very well. Within minutes of activating it I've seen the following false positive ID's being triggered from a single Wordpress website: 950120 981257 981243 960015 981044 981049 950901 Can you please let us know who/where we report false positive ID's that require investigation?
    0
  • axwell
    Re: OWASP ModSecurity Rule unusable I have the same the issues. Rules are blocking a lot of legitimate users including me. Login stopped working in WHMCS on IE PIWIK Analytics stopped working Owncloud client no syncing anymore Pages are redirected in a infinite loop (sometimes) And a lot more... Rules are s*** The 2nd issue is with mod_ruid2, a lot of conflicts i had to disable (Jailshell) so modsecurity could write the files. The 3rd issue modsecurity can't write to secdatadir "ModSecurity: collection_store: Failed to access DBM file "/var/cpanel/secdatadir/ip": Permission denied" This is obviously a issue with user perm. The ip files are created after deletion with a virtualhostuser. (first serverd by apache?) After that the other users can't write to IP files. Solution is to allow other RWX. But is not normal.
    0
  • 4u123
    Re: OWASP ModSecurity Rule unusable Same issues here - mainly lots of sites with some sort of infinite redirect loop and PHP scripts with redirection limit errors too. I've had to disable the rules completely.
    0
  • Infopro
    Multiple ModSec related threads merged here.
    0
  • BobHoliday
    Yeah me too. Lots of sites killed for varying reasons so I've disabled OWASP. Does anyone know if the rules in CSF/LFD ModSec Control are automatically updated at all? I'm currently only using those but don't recall updating them for some time (ever). I like the idea of using OWASP but not if it's going to kill most of my sites, or parts of them. Mine are all custom made - not with CMS off the shelf stuff. About 50 of them. Too many to check in detail very often.
    0
  • Infopro
    Does anyone know if the rules in CSF/LFD ModSec Control are automatically updated at all? I'm currently only using those but don't recall updating them for some time (ever).
    CSF does not provide rules. ConfigServer ModSec control tool is for managing existing rules on your server. New or old rules and the configuration options it does provide. The new Mod Security implementation in cPanel does not replace your existing rules, it leaves them in place. These new rules just added will be updated with cPanel if you have updates enabled, here: WHM " Security Center " Manage Vendors You will need to track your hits a bit to see which rules are being tripped that you don't want to be, and take appropriate action: WHM " Security Center " Hits List Until you #remark out your own Includes for your existing rules, or just plain remove them, they are in play right along side the new rules provided by OWASP for cPanel.
    0
  • Brian
    The OWASP Rule Set is something that we definitely expect is going to further mature over the next weeks/months. When we investigated using a curated rule set for cPanel & WHM, we reached out to OWASP and asked them what they felt their biggest roadblock was. Unilaterally, the response was that they seem to never get much feedback on the ruleset which leaves them will similarly little to go on for curating problematic rules. We wanted to help out when we deployed OWASP on cPanel & WHM. With that, we've developed a reporting feature with the OWASP rule set in 11.48 so that users can directly send these reports to OWASP and they can resolve them. Right now this direct reporting feature is unavailable while OWASP is working to setup their end of the system to receive the reports cPanel users will submit. When this is available, you will notice a new "Report" button on each log entry in the ModSecurity Hits List page. The idea being, over time, the rule set becomes absolutely rock solid. This isn't to say that we didn't review the OWASP rule set or otherwise knowingly deployed a rule set that would cause wide spread problems. We did test the OWASP rule set internally with popular CMSs (like WordPress), popular forum software (like phpBB), and more. We did run into some initial problems and either make curation changes at the cPanel distribution level or OWASP themselves resolved them. So, when we deployed this rule set we did believe that a reasonable effort was made to make them work out-of-the-box. However, as many know, ModSecurity rules are rarely so cut and dry. It is not surprising that, despite our internal testing and exercising the rules against real world scripts, that there are still some rough edges. What I recommend is what we recommend on our ModSecurity OWASP CRS Rule Set page (this is the same article linked to from the feature showcase pop-up that alerts you to OWASP's availability)
    0
  • kernow
    Thanks for the explanation. Any chance cpanel could have a chat with Comodo WAF and add them as a vendor as their rules seem to work out of the box.
    0
  • quizknows
    ] We did test the OWASP rule set internally with popular CMSs (like WordPress), popular forum software (like phpBB), and more.

    Whoever did that testing was asleep at the wheel. I couldn't even access a wordpress or phpbb site without flagging ModSecurity errors; forget about POST requests. Hopefully we can help mature the rule set without everyone getting too frustrated to even want to use it any more. I feel like a LOT more QA or beta testing should have been done.
    0
  • Echelon17
    @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.
    0
  • Silver_2000
    Wow - Glad I posted and glad Im not the only one with issues
    0
  • Brian
    ]Thanks for the explanation. Any chance cpanel could have a chat with Comodo WAF and add them as a vendor as their rules seem to work out of the box.

    Given what we're doing with OWASP is more than just a copy/paste of the rule set and we have automation curation processes/steps to make sure the various paths/rules comply with cPanel & WHM systems, we are not currently considering additional cPanel distributed rule sets at this time. We evaluated Comodo WAF along with a few others when we initially started in on the project of including a rule set to cPanel & WHM, but ultimately we decided to go with OWASP for various reasons -- such as their creators' responsiveness and extensive history. However, this does not preclude Comodo WAF or any other organization/person from extending the same benefits that OWASP has if they choose to maintain it. Any individual/organization has the ability to create what's called a "ModSecurity Vendor". What this essentially means is they'd host a simple file that defines their ModSecurity Rule Set and where to get it. Then, any cPanel & WHM server owner can plug that URL into the ModSecurity Vendors section of WHM and receive auto-updates from the custom vendor. Hosting providers can even extend this to provide their own customers with a unified auto-synchronized auto-updated ruleset of their own or that supplements OWASP/other rulesets. I would definitely welcome Comodo WAF, ASL, and others participate in this functionality. The full process on how to create a ModSecurity Vendor is located here:
    0
  • kernow
    ] @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.

    That many eh? Thankfully we only had to remove 3 rules on our servers running WAF
    0
  • ashworth102680
    ]Thanks for the explanation. Any chance cpanel could have a chat with Comodo WAF and add them as a vendor as their rules seem to work out of the box.

    Seconded. I was about to ask the same thing!
    0
  • Echelon17
    ]That many eh? Thankfully we only had to remove 3 rules on our servers running WAF

    In their defence, they have been trying to update them and fix false positives as things progress, and the bulk of the reports I filed was just after they had launched the product so are potentially resolved now - but the same problem rings true; much more testing needs to take place. The biggest issue I faced with Comodo was how difficult and awkward it was to submit false positives, and how I never ever received any feedback from them saying it was resolved. Even their changelogs didn't specify if specific rules were fixed or not, and without any kind of transparency or disclosure, it makes it almost impossible to trust the rules and product. The biggest problem with these mod_security systems is that all you can do is report and disable a rule, which means you lose any benefit of that rule should it later be updated and corrected. In an ideal world, cPanel should try and implement a system where you report a rule as a false positive and it is temporarily disabled (globally) until next rule update, where hopefully it will be fixed. That way the rule is reactivated and you (hopefully) begin to see the benefits of it without the false positives being triggered. Otherwise you end up with systems that have a significant number of rules disabled just to avoid conflicts and you undermine the entire purpose of mod_security to begin with. @Brian: I see you responded to earlier comments, could you please let me know about the update process and Litespeed compatibility?
    0
  • Infopro
    In cPanel's defense, I think this new system is coming along very nice. It was needed, it's going to get better and we'll all be more secure because of it. In an ideal world, cPanel should try and implement a system where you report a rule as a false positive and it is temporarily disabled (globally) until next rule update, where hopefully it will be fixed. That way the rule is reactivated and you (hopefully) begin to see the benefits of it without the false positives being triggered.
    I like this idea. You might consider posting a Feature Request about this for consideration. It's this sort of thinking that will make the new system that much more robust.
    0
  • quizknows
    ]The biggest problem with these mod_security systems is that all you can do is report and disable a rule, which means you lose any benefit of that rule should it later be updated and corrected. In an ideal world, cPanel should try and implement a system where you report a rule as a false positive and it is temporarily disabled (globally) until next rule update, where hopefully it will be fixed. That way the rule is reactivated and you (hopefully) begin to see the benefits of it without the false positives being triggered. Otherwise you end up with systems that have a significant number of rules disabled just to avoid conflicts and you undermine the entire purpose of mod_security to begin with. @Brian: I see you responded to earlier comments, could you please let me know about the update process and Litespeed compatibility?

    1. That's what the 'rev' tag in rules is intended for; if a rule has an updated rev tag (revision) you should re-enable it to see if it works. Something automated for that would definitely be nice. 2. regarding Litespeed, I've done some testing with it before. The biggest problem is their documentation is nothing short of a complete void. They do not document ANYTHING useful about how they process modsec rules. They use their own engine to parse the config directives, but it doesn't log/complain about rules that won't work. Last time I tested it with atomicorp rules, about 90% of the stuff worked correctly, but the stuff that didn't was silent in the logs.
    ]In cPanel's defense, I think this new system is coming along very nice. It was needed, it's going to get better and we'll all be more secure because of it.

    The system itself is pretty nice; the rule set in its current form, not so much. I really do like the vendor idea, and the ability to whitelist rules via WHM without a 3rd party plugin. You are right, if this works out well, web hosting security as a whole should take a decent step forward. As far as the OWASP rules go though, this should be almost be labelled as a beta test; it's not production ready at all.
    0
  • m4f1aboy
    I have already configured OWASP on my production servers prior to the update and it was a pain to go through and build my whitelist.conf file to prevent false alarms. Here is what I have in my whitelist config file that has worked well with my production servers running WordPress. I hope this helps. The location for the config is located in: /usr/local/apache/modsecurity-crs/activated_rules/whitelist.conf If you don't already have a whitelist.conf just create one in a text editor and put in the activated_rules folder.
    SecRuleRemoveById 910006 # Google robot activity - Useful in someways but noisy for sites where you want them crawled SecRuleRemoveById 960015 # Request Missing an Accept Header - Allow for Google Reader SecRuleRemoveById 950901 # Another False One SecRuleRemoveById 981172 # SQL Injection False Positive SecRuleRemoveById 981319 # Breaks woocommerce SecRuleRemoveById 960009 # Request_Headers False Positive SecRuleRemoveById 981173 # False Positive that blocks admin scripts SecRuleRemoveById 981231 # False Positive SecRuleRemoveById 958291 # False Positive - WordPress SecRuleRemoveById 950109 # Breaks Steam Auth SecRuleRemoveById 970901 # Breaks forums when in deactive mode SecRuleRemoveById 973338 # Breaks disturbia admin functions SecRuleRemoveById 981243 # Breaks user edit if user has special characters in their name SecRuleRemoveById 981248 # WordPress Post Page SQL Injection. SecRuleRemoveById 981240 # WordPress Post Page SQL Injection. SecRuleRemoveById 950907 # WordPress Post Page SQL Injection. SecRuleRemoveById 981318 # WordPress Post Page SQL Injection. SecRuleRemoveById 981251 # WordPress Post Page SQL Injection. SecRuleRemoveById 981244 # WordPress Post Page SQL Injection. SecRuleRemoveById 981255 # WordPress Post Page SQL Injection. SecRuleRemoveById 981249 # WordPress Post Page SQL Injection. SecRuleRemoveById 981242 # WordPress Post Page SQL Injection. SecRuleRemoveById 973334 # WordPress Post Page SQL Injection. SecRuleRemoveById 973334 # WordPress Post Page SQL Injection. SecRuleRemoveById 981231 # WordPress Post Page SQL Injection. SecRuleRemoveById 973332 # WordPress Post Page SQL Injection. SecRuleRemoveById 973327 # WordPress Post Page SQL Injection. SecRuleRemoveById 973324 # WordPress Post Page SQL Injection. SecRuleRemoveById 973317 # WordPress Post Page SQL Injection. SecRuleRemoveById 973306 # WordPress Post Page SQL Injection. SecRuleRemoveById 973302 # WordPress Post Page SQL Injection. SecRuleRemoveById 958056 # WordPress Post Page SQL Injection. SecRuleRemoveById 958030 # WordPress Post Page SQL Injection. SecRuleRemoveById 958057 # WordPress Post Page SQL Injection. SecRuleRemoveById 981256 # WordPress Post Page SQL Injection. SecRuleRemoveById 959073 # WordPress Post Page SQL Injection. SecRuleRemoveById 959072 # WordPress Post Page SQL Injection. SecRuleRemoveById 950001 # WordPress Post Page SQL Injection. SecRuleRemoveById 973335 # WordPress Post Page XSS block. SecRuleRemoveById 973333 # WordPress Post Page XSS block. SecRuleRemoveById 973304 # WordPress Post Page XSS block. SecRuleRemoveById 973300 # WordPress Post Page XSS 403 block. SecRuleRemoveById 981243 # WordPress Post Page SQL Injection 403 block. SecRuleRemoveById 981246 # WordPress Post Page SQL Injection 403 block. SecRuleRemoveById 981245 # WordPress Post Page SQL Injection 403 block. SecRuleRemoveById 981257 # WordPress Post Page SQL Injection 403 block. SecRuleRemoveById 981173 # WordPress Post Page SQL Injection 403 block. SecRuleRemoveById 960024 # WordPress Post Page SQL Injection 403 block. SecRuleRemoveById 981317 # WordPress Post Page SQL Injection 403 block. SecRuleRemoveById 950006 # System Command Injection - Another rule that probably doesn't need to be disabled by everyone it stops .exe and various other extensions being passed in arguments. SecRuleRemoveById 981173 SecRuleRemoveById 981173 SecRuleRemoveById 981173 # Update Core SQL Injection SecRuleRemoveById 950005 # Remote File Access Attempt - Probably no need to be disabled by everyone; it allows me putting /etc/ and other linux paths in posts. SecRuleRemoveById 973301 # XSS SecRuleRemoveById 950109 # Multiple URL encoding SecRuleRemoveById 950117 # Remote File Inclusion Attack - Disable to allow http:// to be passed in args SecRuleRemoveById 950907 # System Command Injection SecRuleRemoveById 950005 # Remote File Access Attempt - Probably no need to be disabled by everyone; it allows me putting /etc/ and other linux paths in posts. SecRuleRemoveById 950006 # System Command Injection - Another rule that probably doesn't need to be disabled by everyone it stops .exe and various other extensions being passed in arguments. SecRuleRemoveById 959006 # SQL Injection Attack - SecRuleRemoveById 960008 # Request Missing a Host Header SecRuleRemoveById 960011 # GET or HEAD requests with bodies SecRuleRemoveById 960904 # Request Containing Content, but Missing Content-Type header SecRuleRemoveById 981173 # SQL Injection SecRuleRemoveById phpids-17 # Detects JavaScript object properties and methods SecRuleRemoveById phpids-20 # Detects JavaScript language constructs SecRuleRemoveById phpids-21 # Detects very basic XSS probings SecRuleRemoveById phpids-30 # Detects common XSS concatenation patterns 1/2 SecRuleRemoveById phpids-61 # Detects url injections and RFE attempts SecRuleRemoveById 950006 # System Command Injection - Another rule that probably doesn't need to be disabled by everyone it stops .exe and various other extensions being passed in arguments. SecRuleRemoveById 959006 # SQL Injection Attack - SecRuleRemoveById 960010 # Request content type is not allowed by policy - Allows for amongst other things spell check to work on admin area SecRuleRemoveById 960012 # Require Content-Length to be provided with every POST request - Same as above SecRuleRemoveById phpids-17 # Detects JavaScript object properties and methods SecRuleRemoveById phpids-20 # Detects JavaScript language constructs SecRuleRemoveById phpids-21 # Detects very basic XSS probings SecRuleRemoveById phpids-30 # Detects common XSS concatenation patterns 1/2 SecRuleRemoveById phpids-61 # Detects url injections and RFE attempts
    0
  • nunomigpe
    Hi all Until now i can say maybe i have false positives, but all ip"s i checked are from chine, lest europe, so maybe they are not so false positives, my server was being atack to clients using joomla 1.5, it was a mess. Now i think they are more secure. The thing i notice a lot is this message i don"t understand:
    Request: POST /wp-login.php Action Description: Access denied with redirection to using status 302 (phase 2). Justification: Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required.
    Sorry for my bad english
    0
  • Brian
    ] 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?

    Rule updates (regardless whether the built-in OWASP vendor we ship or a custom vendor) occur via the nightly cPanel Maintenance run. This means at most frequent, you will receive updates every 24 hours. You do, however, have the choice to manually fire an update check via: /scripts/modsec_vendor (Run the command manually to see your options for managing vendors via CLI, but it's essentially: /scripts/modsec_vendor update --auto) If there are no new rules upstream, you will not receive an update. On a per-vendor basis, you can choose to disable rule auto-updates. We don't anticipate anyone wanting/needing to do so, but we wanted the option available to users. The process for rule distribution goes like this:
      ]
    • OWASP makes a change upstream to their rule set
    • Our own cPanel, Inc. curation machine sees the upstream change and downloads the new payload
    • This same cPanel, Inc. curation machine applies certain changes to the stock ruleset (updating paths, excluding experimental rules, etc.)
    • That same machine, after validating the rule set as operational and not causing syntax/runtime errors against the current EasyApache build of Apache/mod_security, sends the rule set to cPanel mirrors
    • Upon end-user cPanel & WHM machines seeing this new payload during their nightly update check, it is grabbed and installed
    So to answer your question, the answer is we "both" maintain them in a way. However, we (cPanel) strive to only make changes to the rules that are cPanel specific and work with OWASP otherwise to have them make all other changes upstream.
    ] 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.

    We've made no specific accommodation for Litespeed in the curation and development of the new ModSecurity feature and the OWASP rule set. Therefore the only answer I can provide is that it's untested. It is unlikely that we will, on our own, attempt to curate a whole new adaptation of OWASP's ruleset for litespeed if their current rule set does not work with litespeed. If the OWASP ruleset is incompatible with litespeed, it would be at the choice of OWASP's creators to generate a new litespeed compatible ruleset. Should they do so, we would be more likely to consider adapting the feature to deploy it. It is more likely, however, that we'll adapt changes to the cPanel & WHM product and the ModSecurity user interface to not break under litespeed conditions. However, with this current release, we did not test nor make specific accommodation against litespeed. If you run into problems with litespeed, I encourage you to lodge feature requests regarding them with the specific compatibility issues you run into so that we can evaluate it.
    0
  • Echelon17
    ]1. That's what the 'rev' tag in rules is intended for; if a rule has an updated rev tag (revision) you should re-enable it to see if it works. Something automated for that would definitely be nice.

    Yep, thanks for the info. I was aware of the tag, but it's a pain having to check manually for updates to rules and re-enable them on a case by case basis :)
    ]2. regarding Litespeed, I've done some testing with it before. The biggest problem is their documentation is nothing short of a complete void. They do not document ANYTHING useful about how they process modsec rules. They use their own engine to parse the config directives, but it doesn't log/complain about rules that won't work. Last time I tested it with atomicorp rules, about 90% of the stuff worked correctly, but the stuff that didn't was silent in the logs.

    Indeed, Litespeed is/are annoying in that regard. They are making improvements though so hopefully we'll have a nearly identical implementation. @InfoPro: I've created a feature request here, if you wish to vote for it :) [url=http://features.cpanel.net/responses/mod-security-false-positive-reporting-system]Login Form | cPanel Feature Requests @Brian: Thank you very much for the detailed information about the update process, I appreciate it. I checked the wiki but couldn't find anything on there.
    0
  • studioq
    +1 for Comodo WAF - My issue is that I'm using WAF right now and I'm pretty scared of what would happen if I enabled the other ruleset with WAF in place.. I can I'll afford a days worth of crashes right now.
    0
  • Silver_2000
    ]I have already configured OWASP on my production servers prior to the update and it was a pain to go through and build my whitelist.conf file to prevent false alarms. Here is what I have in my whitelist config file that has worked well with my production servers running WordPress. I hope this helps. The location for the config is located in: /usr/local/apache/modsecurity-crs/activated_rules/whitelist.conf If you don't already have a whitelist.conf just create one in a text editor and put in the activated_rules folder.

    /usr/local/apache/modsecurity-crs/activated_rules/whitelist.conf I dont have that folder on my server
    0
  • quizknows
    ]this message i don"t understand:
    Request: POST /wp-login.php Action Description: Access denied with redirection to Request: GET / Action Description: Access denied with redirection to
    Sorry for my bad english

    This means the User-Agent of the request was "AppleWebKit Android" and the "pm" part is a match from a rule that uses a list of possible conditions to block for that specific header. That looks like a rule which blocks unwanted / malicious user agents. If you wish to allow that user agent you can whitelist or modify the rule.
    0
  • iso99
    I was glad to hear OWASP Modsec is now supported by cPanel, but still disappointed that most of the core rules that are problematic to popular CMSs are still there. Before this was a plugin, I installed it manually and a lot of Wordpress common features are blocked. Even a simple plugin for thumbnails to display images are filtered. I was whitelisting heavily and got tired eventually. I just removed it. I hope this is a good start to finally remove those rules.
    0

Please sign in to leave a comment.