On 5/24/10, Brian Rectanus <Brian.Rectanus@...> wrote:
> On 05/24/2010 01:03 PM, KT wrote:
>> On 5/24/10, Brian Rectanus <Brian.Rectanus@...> wrote:
>>> On 05/24/2010 10:32 AM, KT wrote:
>>>> On 5/24/10, Brian Rectanus <Brian.Rectanus@...> wrote:
>>>>>
>>>>> On 05/22/2010 10:05 AM, KT wrote:
>>>>>> Is there any semantic difference between the following two? Thanks.
>>>>>>
>>>>>> SecRule REQUEST_URI "^/$" "chain,skipAfter:END_CHECK"
>>>>>> SecRule REMOTE_ADDR "^127\.0\.0\.1$"
>>>>>>
>>>>>> SecMarker END_CHECK
>>>>>
>>>>> This is correct. If you had "deny" in SecDefaultAction, then the
>>>>> skipAfter should override it.
>>>>>
>>>>>> SecRule REQUEST_URI "^/$" "chain"
>>>>>> SecRule REMOTE_ADDR "^127\.0\.0\.1$" "skipAfter:END_CHECK
>>>>>>
>>>>>> SecMarker END_CHECK
>>>>>
>>>>> This one should not work at all (syntactically incorrect as skipAfter
>>>>> is
>>>>> a disruptive action and it should not have been allowed in a chain).
>>>>> It is a bug. It will also fail if a non-"pass" is the default action.
>>>>> This is because the skipAfter will not override it like the first
>>>>> example.
>>>>>
>>>>> Use the first as I will "fix" the second to not work in the next
>>>>> release
>>>>> ;)
>>>>>
>>>> Thank you for the insight. I came up with the second form after
>>>> looking through the rules in OWASP CRS 2.0.6 (e.g.
>>>> modsecurity_crs_60_correlation.conf ,
>>>> modsecurity_crs_21_protocol_anomalies.conf) where skipAfter is used in
>>>> later rules of a chained ruleset. Should I file a bug report for it
>>>> there?
>>>> Thanks again.
>>>> KT
>>>
>>> Ug. If it is in CRS, then I'll have to keep it around until 2.6. It
>>> all comes down to this not making any sense and the "deny" and
>>> "skipAfter" conflicting (it only makes sense with a "pass"):
>>>
>>> SecRule TARGET1 "regex1" "chain,deny,..."
>>> SecRule TARGET2 "regex2" "skipAfter:12345"
>>
>> I understand. I had a few custom rules I already corrected.
>
> I am going to take back what I said temporarily. Talking this over
> w/Ryan, it looks like CRS compensated for a bug in ModSecurity. It
> looks like you have to do it the CRS way until a bug in ModSecurity is
> fixed. This is because ModSecurity is failing to run all the chain
> rules before firing the skipAfter. I did not notice this in my initial
> testing. I filed a new bug that will be partially fixed in the next 2.5
> release and full fixed in 2.6.
>
> https://www.modsecurity.org/tracker/browse/MODSEC-159
>
> -B
>
> --
> Brian Rectanus
> Breach Security
>
I see. I will revert to 'workaround" form until it is resolved. Thanks again.
Regards
K

On Tuesday 25 May 2010 14:54:41 John Li wrote:
> Hi,
>
> The php-ids rules from core rule set are giving me a lot of headache and I
> am wondering if I can just completely remove them since there is no PHP
> applications behind ModSecurity.
>
> Thanks a lot for your advice.
>
The phpids filters are created by converting the default_filters.xml file from the phpids
site - https://svn.php-ids.org/svn/trunk/lib/IDS/default_filter.xml
The attacks that are detected in this file are not php-specific and are relevant to all web
platforms. The XSS and SQLi rules in the phpids filters provide increased protections vs
what we had in the CRS.
-Ryan
> --
> John Jun Li
> jli@...<mailto:jli@...>
>
> My Blog: http://www.jlisbz.com
> My LinkedIn Profile: http://www.linkedin.com/in/johnjunli

On Tuesday 25 May 2010 15:51:13 John Li wrote:
> Hi,
>
> I found CRS generated quite a lot of alerts for the requests to static
> content so I created a rule to just allow them.
>
> SecRule REQUEST_URI
> "^(?:/javascripts|/favicon\.ico|/images|/stylesheets|/logos|/documents|/st
> atic)" "phase:1,allow,ctl:auditEngine=off"
>
> My assumption is the static content access should have very little chance
> to cause security issue of the web application. Can you please let me know
> if there is any potential risk? Is this a good practice in WAF?
>
This is fine and it will cut down on the logging and false positives. You just want to
make sure that you get your list of static files set correctly.
> BTW, is there a document to explain the CRS rule set in more detail?
>
Check out the CRS project page on the OWASP site and sign up for the CRS mail-list -
http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
-Ryan
> Thanks.
>
> --
> John Jun Li
> jli@...<mailto:jli@...>
>
> My Blog: http://www.jlisbz.com
> My LinkedIn Profile: http://www.linkedin.com/in/johnjunli

Hi,
I found CRS generated quite a lot of alerts for the requests to static
content so I created a rule to just allow them.
SecRule REQUEST_URI
"^(?:/javascripts|/favicon\.ico|/images|/stylesheets|/logos|/documents|/static)"
"phase:1,allow,ctl:auditEngine=off"
My assumption is the static content access should have very little chance to
cause security issue of the web application. Can you please let me know if
there is any potential risk? Is this a good practice in WAF?
BTW, is there a document to explain the CRS rule set in more detail?
Thanks.
--
John Jun Li
jli@...
My Blog: http://www.jlisbz.com
My LinkedIn Profile: http://www.linkedin.com/in/johnjunli

Hi,
The php-ids rules from core rule set are giving me a lot of headache and I
am wondering if I can just completely remove them since there is no PHP
applications behind ModSecurity.
Thanks a lot for your advice.
--
John Jun Li
jli@...
My Blog: http://www.jlisbz.com
My LinkedIn Profile: http://www.linkedin.com/in/johnjunli

I am running the CRS set. Odd that it is not stopping the scan from tagging that issue.. Ill have to do some research and figure it out.
thanks
Mike
On May 25, 2010, at 9:57 AM, Ryan Barnett wrote:
> On Tuesday 25 May 2010 12:47:45 Michael Warchut wrote:
>> I was trying to get a TRACE/TRACK block implemented this morning on a new
>> server and for the life of me could not get it to work properly.
>
> What is the exact rule you are testing? If you are using the CRS these request methods
> should already be flagged by rules in the 30 file. My guess is that you are writing a rule
> in phase:2 in which case comes too late in the Apache request cycle and Apache will handle
> it. If you place the rule in phase:1 it should work.
>
>> Upon
>> looking in the debug log I see thousands of these..
>>
>> Rule execution error - PCRE limits exceeded
>>
>> What causes this and how can I squelch it. It seems to be breaking my WAF.
>>
> These are generated by the converted phpids filters and the errors will pop up based on the
> user input. You can either increase the SecPcreMatchLimit/SecPcreMatchLimitRecursion
> directive settings or comment out the specific phpids rules that are generating the errors.
>
> -Ryan
>
>> Thanks
>>
>> Mike
>>
>>
>> ---------------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> mod-security-users mailing list
>> mod-security-users@...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> Commercial ModSecurity Appliances, Rule Sets and Support:
>> http://www.modsecurity.org/breach/index.html

On Tuesday 25 May 2010 12:47:45 Michael Warchut wrote:
> I was trying to get a TRACE/TRACK block implemented this morning on a new
> server and for the life of me could not get it to work properly.
What is the exact rule you are testing? If you are using the CRS these request methods
should already be flagged by rules in the 30 file. My guess is that you are writing a rule
in phase:2 in which case comes too late in the Apache request cycle and Apache will handle
it. If you place the rule in phase:1 it should work.
> Upon
> looking in the debug log I see thousands of these..
>
> Rule execution error - PCRE limits exceeded
>
> What causes this and how can I squelch it. It seems to be breaking my WAF.
>
These are generated by the converted phpids filters and the errors will pop up based on the
user input. You can either increase the SecPcreMatchLimit/SecPcreMatchLimitRecursion
directive settings or comment out the specific phpids rules that are generating the errors.
-Ryan
> Thanks
>
> Mike
>
>
> ---------------------------------------------------------------------------
> ---
>
> _______________________________________________
> mod-security-users mailing list
> mod-security-users@...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Appliances, Rule Sets and Support:
> http://www.modsecurity.org/breach/index.html

I was trying to get a TRACE/TRACK block implemented this morning on a new server and for the life of me could not get it to work properly. Upon looking in the debug log I see thousands of these..
Rule execution error - PCRE limits exceeded
What causes this and how can I squelch it. It seems to be breaking my WAF.
Thanks
Mike

Hi Christian!
Am 25.05.2010 um 06:24 schrieb Christian Kuersteiner:
>
> I use Apache with mod_proxy to relay all web related traffic through it.
> ModSecurity has two main objectives in this setup right now. Block
> unwanted/dangerous requests made by the scanner (e.g. logout, delete,
> etc.). The other one is log the whole requests and responses.
> Blacklisting works as expected but I don't get the whole requests and
> responses logged. More or less I just get the headers logged.
> I have "SecAuditLogParts ABCDEFGHZ" in my conf file. Are there some
> special settings needed to log everything? Is it even possible to log
> the whole raw request and response with ModSecurity? Any pointers how to
> achieve this?
For logging more than just the headers, you'd probably need to enable the
rule-engine as well, especially telling it to parse/access the request body.
Otherwise this will not be logged:
SecRuleEngine DetectionOnly
SecRuleRequestBodyAccess On
SecRuleResponseBodyAccess On
Regards,
Chris

You might like to experiment with SecDebugLogLevel. See more info at
http://www.modsecurity.org/documentation/modsecurity-apache/2.5.12/modsecurity2-apache-reference.html#N105B3
On Mon, May 24, 2010 at 9:24 PM, Christian Kuersteiner <ckuerste@...>wrote:
> Hi there,
>
> I am working on a project where we use ModSecurity in conjunction with
> the vulnerability scanner OpenVAS. The goal is to enhance OpenVAS to
> handle web application scanning in a better way.
>
> I use Apache with mod_proxy to relay all web related traffic through it.
> ModSecurity has two main objectives in this setup right now. Block
> unwanted/dangerous requests made by the scanner (e.g. logout, delete,
> etc.). The other one is log the whole requests and responses.
> Blacklisting works as expected but I don't get the whole requests and
> responses logged. More or less I just get the headers logged.
> I have "SecAuditLogParts ABCDEFGHZ" in my conf file. Are there some
> special settings needed to log everything? Is it even possible to log
> the whole raw request and response with ModSecurity? Any pointers how to
> achieve this?
>
> Thanks Christian
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> mod-security-users mailing list
> mod-security-users@...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Appliances, Rule Sets and Support:
> http://www.modsecurity.org/breach/index.html
>
--
Gaurav Kumar
Founder, Pivotal Security LLC
Cell# (425) 686-9695

Hi there,
I am working on a project where we use ModSecurity in conjunction with
the vulnerability scanner OpenVAS. The goal is to enhance OpenVAS to
handle web application scanning in a better way.
I use Apache with mod_proxy to relay all web related traffic through it.
ModSecurity has two main objectives in this setup right now. Block
unwanted/dangerous requests made by the scanner (e.g. logout, delete,
etc.). The other one is log the whole requests and responses.
Blacklisting works as expected but I don't get the whole requests and
responses logged. More or less I just get the headers logged.
I have "SecAuditLogParts ABCDEFGHZ" in my conf file. Are there some
special settings needed to log everything? Is it even possible to log
the whole raw request and response with ModSecurity? Any pointers how to
achieve this?
Thanks Christian