This has solved my problem. Thank you and everyone who has chimed in on this.
One last question though. Is this generally a better approach than using Location, LocationMatch etc to disable rules? On Tuesday, November 26, 2013, Ryan Barnett wrote: > Hey Phil, > Based on the info you gave about your setup, I think I know what the issue > might be. First of all, take a look at this Apache request flow diagram on > the ModSecurity Reference Manual Wiki page - > > https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Processing_Phases > > This diagram shows where ModSecurity's Phase hooks are. With this as a > visual backdrop, now understand that if you place any ModSecurity rules or > directives inside Apache scope locations (<Location>, <LocationMatch>, > <Directory>, etc…) then they will only be available to ModSecurity in > Phase:2 (Fixup hook). The issue, most likely, is that your AJP proxying is > happening before the Fixup Phase:2 hook so your rules/exceptions are not > working. > > What I recommend for you situation would be to use SecRules + > ctl:ruleRemoveById action in Phase:1 instead of nesting them within Apache > scope locations. Something like this (untested) added to a > modsecurity_crs_15_custon.conf file so that it runs before the rest of the > CRS rules - > > SecRule REQUEST_FILENAME "@beginsWith /subsonic/" > "id:1234,phase:1,t:none,nolog,pass,ctl:ruleRemoveById=330792" > > One other note – you might need to recompile with > "--enable-request-early" to get this to work in the "post-read-request" > hook ( > https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Configure_ModSecurity > ) > > Hope this info helps. > > -- > Ryan Barnett > Trustwave SpiderLabs > ModSecurity Project Leader > OWASP ModSecurity CRS Project Leader > > > From: Phill Watkins <phill.watk...@gmail.com> > Date: Monday, November 25, 2013 6:45 AM > To: OWASP CRS Mailing List < > owasp-modsecurity-core-rule-set@lists.owasp.org> > Subject: [Owasp-modsecurity-core-rule-set] Location/LocationMatch failing > to disable rules > > Hi, > > For some reason I'm struggling to to disable rules using > SecRuleRemoveById inside a Location or LocationMatch. > > I can disable rules globally (which isn't ideal) so I know the directive > works but I don't know why Apache doesn't act upon the > Location/LocationMatch. > > One of the applications on my web server that I'm trying to disable a > rule for is Subsonic. Subsonic requires Tomcat and is a connected to Apache > via the AJP connector module. > > I have successfully disabled one of the Atomicorp delayed rules in the > past like this: > > <IfModule mod_jk.c> > JkMount /subsonic ajp13_worker > JkMount /subsonic/* ajp13_worker > <Location /subsonic/upload.view> > SecRuleRemoveById 330792 > </Location> > </IfModule> > > I am now trying to disable rule 960010 from the CRS for the entire > application because of too many false positives. > > I have tried <Location /subsonic/> as well as multiple regular > expressions for days but nothing works. > > Here is an example from the audit log: > > --35e37e6c-A-- > [12/Nov/2013:12:19:05 +0000] UoIcuX8AAQEAAAJ3AQgAAAAA hidden 45509 hidden > 443 > --35e37e6c-B-- > POST /subsonic/dwr/call/plaincall/nowPlayingService.getNowPlaying.dwr > HTTP/1.1 > Host: hidden > Connection: keep-alive > Content-Length: 214 > Origin: https://hidden > User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, > like Gecko) Chrome/30.0.1599.114 Safari/537.36 > Content-Type: text/plain > Accept: */* > Referer: https://hidden/subsonic/right.view? > Accept-Encoding: gzip,deflate,sdch > Accept-Language: en-GB,en-US;q=0.8,en;q=0.6 > Cookie: player-656c6c6965=6; player-73727661646d=6; > JSESSIONID=088A746CDC6B4356A388E7C1D44EEE6A.ajp13_worker; > player-7068696c6c=9; compact_display_state=false > > --35e37e6c-F-- > HTTP/1.1 403 Forbidden > Vary: Accept-Encoding > Content-Encoding: gzip > Content-Length: 221 > Keep-Alive: timeout=5, max=88 > Connection: Keep-Alive > Content-Type: text/html; charset=iso-8859-1 > > --35e37e6c-H-- > Message: Access denied with code 403 (phase 1). Match of "rx > ^%{tx.allowed_request_content_type}$" against "TX:0" required. [file > "/etc/apache2/owasp-modsecurity-crs/activated_rules/modsecurity_crs_30_http_policy.conf"] > [line "64"] [id "960010"] [rev "2"] [msg "Request content type is not > allowed by policy"] [data "text/plain"] [severity "CRITICAL"] [ver > "OWASP_CRS/2.2.8"] [maturity "9"] [accuracy "9"] [tag > "OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag > "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] > Action: Intercepted (phase 1) > Stopwatch: 1384258745437774 1085 (- - -) > Stopwatch2: 1384258745437774 1085; combined=426, p1=363, p2=0, p3=0, p4=0, > p5=63, sr=48, sw=0, l=0, gc=0 > Producer: ModSecurity for Apache/2.7.5 (http://www.modsecurity.org/); > OWASP_CRS/2.2.8. > Server: Apache > Engine-Mode: "ENABLED" > > --35e37e6c-Z-- > > I'd be grateful of any advice. > > Thanks for your time. > > > ------------------------------ > > This transmission may contain information that is privileged, > confidential, and/or exempt from disclosure under applicable law. If you > are not the intended recipient, you are hereby notified that any > disclosure, copying, distribution, or use of the information contained > herein (including any reliance thereon) is strictly prohibited. If you > received this transmission in error, please immediately contact the sender > and destroy the material in its entirety, whether in electronic or hard > copy format. >
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
