From: Phill Watkins <phill.watk...@gmail.com<mailto:phill.watk...@gmail.com>> Date: Tuesday, November 26, 2013 4:54 PM To: OWASP CRS Mailing List <owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>> Subject: [Owasp-modsecurity-core-rule-set] Location/LocationMatch failing to disable rules
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? Personally, I believe it is however it is visually more intuitive to group rules within Apache scope locations. The downside of that approach is what you are running into here. -Ryan 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.<http://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. ________________________________ 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
