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

 

[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?

 

[MarkoTitel]

Sorry for lack of info. Sometimes I forget the most important parts.
I use COMODO ModSecurity Apache Rule Set

I see cpanel has removed the domain name. If you don't mind I will post it. - Removed - and you add the request part.

I get 404 on some assets but still it is not working like I would anticipate.

 

[Infopro]

No need for the domain name here. He's asking about the specific rule.

 

[dalem]

works without issue on our servers get a 404/403

 

[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="><script>alert(1)</script>

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

 

[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.