Skip to main content

Advice on modsecurity response when rule is hit

MarkoTitel
Hi, I've been playing with modsecurity past few days. My experiment mostly is posting illegal requests to a website and checking audit log for rule HIT. I am confused on how ModSecurity should work. For example: I do simple GET http://example.com/?q=%22%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E
And ModSecurity audit log detects this rule. But I still get a "part" of the website loaded. Anyone can freely test this website with illegal request to see what I mean. Thanks

Comments

6 comments

Date Votes
  • fuzzylogic
    To troubleshoot your issues I need to be able to duplicate the problem. Could you please confirm the exact name of the ruleset you are using (copy it and paste it to your reply) Copy it from the Vendor column of... Home " Security Center " ModSecurity" Vendors " Manage Vendors page Does your server respond with a 200, 301 or 403 http response for this request? You can see this in your browser webmaster tools or in the audit_log. Do you have a 403.shtml file in place to handle 403 responses?
    0
  • MarkoTitel
    Sorry for lack of info. Sometimes I forget the most important parts. I use
    0
  • Infopro
    No need for the domain name here. He's asking about the specific rule.
    0
  • dalem
    works without issue on our servers get a 404/403
    0
  • fuzzylogic
    I tested this on a domain on a cPanel server with "COMODO ModSecurity Apache Rule Set" as the only rule set enabled. For the first test I appended /?q=">
    to the https domain name (to avoid .htaccess redirect). The server responded with a 403 http status code and served my 403.shtml file. Second test was identical except that I deleted the 403.shtml from the web root. The server responded with a 301 http status code It then redirected to the same uri with a status code of 403 and served the contents of the sites home page. This second test seems to duplicate the way #MarkoTitel's server responded. If the modsec_audit.log is examined for this 2nd test it shows only 1 rule being hit ([id "212000">). This was unexpected because if the "COMODO ModSecurity Apache Rule Set" was operating in anomaly mode (which I know cPanel OWASP ModSecurity Core Rule Set V3.0 is by default), then I would expect 3 or 4 rule hits for a request like this. It also shows the message for this rule hit as "Message: Access denied with code 403 (phase 2)." This too is unexpected if the ruleset is running in anomaly mode I would expect this rule to accrue points to an anomaly score which would be used later in modsecurity's execution to block the request with a blocking rule that measures the anomaly score. If rule 212000 is examined it is found to have the "block" disruptive action. A disruptive action is any of the following, allow, block, deny, drop, pass, pause, proxy, redirect If one of these is not present when a request matches a rule then the SecDefaultAction will be used. SecDefaultAction "phase:1,deny,log" SecDefaultAction "phase:2,deny,log" is set at the start of /etc/apache2/conf.d/modsec_vendor_configs/comodo_apache/00_Init_Initialization.conf BUT SecDefaultAction is not being used in this case. So a partial answer to your question is that the unexpected serving of your home page when the request should have been blocked was due to the missing 403.shtml file to serve for a 403 http status. I cant explain why your (and my) servers respond with 301 instead of 404 for the missing 403.shtml file. Also, unrelated to this problem, Comodo rule set does not operate in anomaly mode. So expect 1 rule hit = blocked request with this rule set. Also unrelated to this problem I discovered my version of "COMODO ModSecurity Apache Rule Set" was 1 year out of date. It was not updating because it was not enabled (a feature not a bug) The version on your server can be found by reading the contents of /etc/apache2/conf.d/modsec_vendor_configs/comodo_apache/rules.dat Current version is 1.191 It can be updated by enabling the rule set in cPanels WHM Modsecurity Vendors then running /usr/local/cpanel/scripts/modsec_vendor update --auto
    0
  • cPanelMichael
    So a partial answer to your question is that the unexpected serving of your home page when the request should have been blocked was due to the missing 403.shtml file to serve for a 403 http status. I cant explain why your (and my) servers respond with 301 instead of 404 for the missing 403.shtml file.

    Hello @fuzzylogic, Regarding your quote above, we actually have an internal case open (EA-7960) to investigate the cause of this issue. It's reproducible when rules like this are enabled in the .htaccess file: RewriteEngine On RewriteCond %\{REQUEST_FILENAME} !-f RewriteCond %\{REQUEST_FILENAME} !-d RewriteRule . /index.php [L]
    I'll follow this case and update this thread with the outcome once it's solved. Thank you.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post