11_asl_data_loss.conf and Tomcat

[rhopek]

We're finding the final rule in that set has severely hampered our ability to use Tomcat. We have a custom module in our control panel that talks to the Tomcat Manager application on another server to get status info, list contexts and provide start/stop/restart control. The requests don't provide any "errors", yet modsec is intercepting the responses and throwing 404s so that the returned data never gets populated in our module. It's also preventing certain user application from working properly. For example, here a basic "valid" struts request that rule intercepted (once we disabled the rule, the page loaded fine):

[Mon Jul 25 06:18:05 2011] [error] [client xx.xx.xx.xx] ModSecurity: Access denied with code 404 (phase 4). Pattern match "<title>Apache Tomcat.*Error report" at RESPONSE_BODY. [file "/etc/httpd/modsecurity.d/11_asl_data_loss.conf"] [line "77"] [id "361019"] [msg "Atomicorp.com UNSUPPORTED DELAYED Rules: Potential Error Message with sensitive information sent from tomcat"] [severity "ALERT"] [hostname "www.xxxxxxxxxxxx.com"] [uri "/home.do"] [unique_id "GgrhL0AWarMAAFSGX9gAAAAE"]

The page itself did not contain "Apache Tomcat" in the title tag.

Any thoughts?
roho

[mikeshinn]

Thank you for your question, it would be helpful if we could see the full modsecurity audit record. Could you post that here or email it to us?

If you need instructions as to how to provide that, please follow the process here:

https://www.atomicorp.com/wiki/index.ph ... _Positives

[rhopek]

Actually, we've discovered this one was legit and the user pasted the wrong entry into the ticket they opened with us. The issue with the Tomcat Manager module was fixed by passing a valid UserAgent string (as it was failing 20_asl_useragents.conf), and since we have a unique string that is a portion of the backend URL that the module uses, we added a LocationMatch for the string in the URL to a 00_asl_custom_exclude.conf file for good measure. All appears to be working now.

Thanks.