You might have help me with that.

Set debug to 5 and ended up with a 20000 line file after the first 403
error.

If that's what you need then I'll upload somewhere for you.

Thanks.
On 25 Nov 2013 23:28, "Jose Pablo Valcárcel Lázaro" <
pablo.valcarcel1...@gmail.com> wrote:

> Could you post denied trace?
> Maybe you could copyright that rule in customized, comment original rule
> and try to edit on customized to avoid triger with client specific
> request.
>
> Kind regards
> El 25/11/2013 21:28, "Phill Watkins" <phill.watk...@gmail.com> escribió:
>
>> Thanks replying.
>>
>> I'm using CRS version 2.2.8 with ModSecurity 2.7.5. As far as I can tell
>> the rule has already been updated as per your example.
>>
>> I tried using Directory instead of Location but it didn't work and I kind
>> of understand this since Subsonic is essentially being accessed by proxy
>> (AJP connector).
>>
>> Your nesting idea will work but will have the effect of disabling the
>> rule globally if mod_jk is enabled, which I'm trying to avoid.
>>
>> Rule ID 330792 is from the Atomicorp (now defunct) delayed rules. I was
>> using this as an example to show that I've successfully used Location to a
>> disable a rule for Subsonic before. Sorry for the confusion.
>>
>> Regards
>>
>>
>> On 25 November 2013 17:46, Jose Pablo Valcárcel Lázaro <
>> pablo.valcarcel1...@gmail.com> wrote:
>>
>>> Sorry, I was wrong. You should be able to use location match as you have
>>> written.
>>>
>>> You should be able to comment original rule 330792 but instead
>>> disabling at all, copy it into a customized.conf rules and try to rewrite
>>> rule to bypass what is triggering that rule, in your case:
>>>
>>> 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"]
>>>
>>> I´m watching that is not 330792 rule id, instead it seems 960010 rule
>>> id on /etc/apache2/owasp-modsecurity-crs/activated_
>>> rules/modsecurity_crs_30_http_policy.conf and it´s blocked because of 
>>> Request
>>> content type is not allowed by policy.
>>>
>>>
>>> It could be a older bug depending on mod_security rule version you are
>>> using:
>>>
>>> http://web.archiveorange.com/archive/v/eCIWmXcpDxoRYUESRQEg
>>>
>>>
>>>
>>>
>>>
>>> There is a bug in that rule as it is missing a "chain" action on the 2nd
>>> SecRule.  The
>>> rule should be this -
>>>
>>> SecRule REQUEST_METHOD "!^(?:GET|HEAD|PROPFIND|OPTIONS)$"
>>> "phase:2,chain,t:none,pass,nolog,auditlog,msg:'Request content type is
>>> not allowed
>>> by
>>>
>>> policy',id:'960010',tag:'POLICY/ENCODING_NOT_ALLOWED',tag:'WASCTC/WASC-20',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/EE2',tag:'PCI/12.1',
>>> severity:'4',logdata:'%{matched_var}'"
>>>         SecRule REQUEST_HEADERS:Content-Type "^([^;\s]+)" "chain,capture"
>>>                 SecRule TX:0 "!@within
>>> %{tx.allowed_request_content_type}"
>>> "t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.
>>>
>>> warning_anomaly_score},setvar:tx.policy_score=+%{tx.warning_anomaly_score},setvar:tx.
>>> %{rule.id}-POLICY/CONTENT_TYPE_NOT_ALLOWED-%{matched_var
>>> _name}=%{matched_var}"
>>>
>>> This issue has already been reported in JIRA
>>> (https://www.modsecurity.org/tracker/browse/CO...) and fixed in CRS
>>> v2.0.6.  You can
>>> manually add the "chain" action to your rule to fix the issue now.
>>>
>>> -Ryan
>>>
>>> Which mod_security rule version are you using?
>>>
>>> Kind regards,
>>>
>>>
>>> 2013/11/25 Jose Pablo Valcárcel Lázaro <pablo.valcarcel1...@gmail.com>
>>>
>>>> Or simply try to nest as follows:
>>>>
>>>> <IfModule mod_jk.c>
>>>>  JkMount /subsonic ajp13_worker
>>>> JkMount /subsonic/* ajp13_worker
>>>> <IfModule mod_security2.c>
>>>>  SecRuleRemoveById 330039
>>>> </IfModule>
>>>> </IfModule>
>>>>
>>>> Kind regards,
>>>>
>>>>
>>>> 2013/11/25 Jose Pablo Valcárcel Lázaro <pablo.valcarcel1...@gmail.com>
>>>>
>>>>> In mod_security migration matrix table you will see features against
>>>>> different mod_security versions:
>>>>>
>>>>> https://github.com/SpiderLabs/ModSecurity/wiki/ModSecurity-Migration-Matrix
>>>>>
>>>>> Ability to manage rules in Apache Scope locations
>>>>> SecFilterRemove is now SecRuleRemoveById or SecRuleRemoveByMsg.
>>>>> SecFilterImport is no longer supported.
>>>>>
>>>>> So following that feature, I guess location directive you just can
>>>>> only use to disable rules.
>>>>>
>>>>> If you want to enable a specific rule, you should develop within
>>>>> specific rules and disable in all domains you don´t need to check it.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>>
>>>>> 2013/11/25 Jose Pablo Valcárcel Lázaro <pablo.valcarcel1...@gmail.com>
>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> I have seen rules to disabling by id as follows:
>>>>>>
>>>>>> <IfModule security2_module>
>>>>>>  <Directory /local/home/username/example.net>
>>>>>>         SecRuleRemoveById 330039
>>>>>>  </Directory>
>>>>>> </IfModule>
>>>>>>
>>>>>> Have you try with  apache Directory directive?
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>>
>>>>>> 2013/11/25 Phill Watkins <phill.watk...@gmail.com>
>>>>>>
>>>>>>>  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.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
_______________________________________________
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

Reply via email to