Re: [mod-security-users] regular expressions

[Brian R. <Bri...@br...>]

I see your point, but ModSecurity does nothing without rules.  Most
rules are using PCRE.  Many issues that come up here are related to
regex problems because of a lack of understanding of PCRE and how to
write (fix or expand) regex rules .  I do not see any problem with regex
questions that relate and help with writing rules.

Of course you need to use your best judgment and keep the posts
ModSecurity related.

thanks,
-B

Terje Sannum wrote:
> Regexps can of course be hard to get into and understand, but IMO,
> please keep the list clean and send general regexp questions somewhere
> else...
> 
> -Terje
> 
> On Nov 9, 2007 7:01 PM, Brian Rectanus <Bri...@br...> wrote:
>> BTW All,
>>
>> Please continue to post questions as to what regex used in the rules
>> mean.  PCRE is hard to understand and follow at times.  They take a lot
>> of practice to write well and read correctly.  The Core Rules use very
>> complex regexes (further complicated by an optimizer) and many of them
>> are very difficult to read.
>>
>> Read up on the basics (http://perldoc.perl.org/perlre.html).
>>
>> If that does not answer your questions (and it is a very large topic).
>> I (or someone else here) would be happy to answer any PCRE questions.
>> Becoming proficient in regex writing (or even reading) will help you a
>> lot in rule writing.
>>
>> If there is need (or want), perhaps I can put up a blog on the topic.
>>
>> later,
>> -B
>>
>>
>> Brian Rectanus wrote:
>>> Hi Ken,
>>>
>>> Thanks for your feedback.  See my comments inline...
>>>
>>> Ken Senior wrote:
>>>> Can anyone give advice for demystifying regular expressions in
>>>> Modsecurity?  I know regular expressions in certain contexts, but not in
>>>> modsecurity.  It would be really nice to include at least something in
>>>> the manual on this.  For example,
>>>>
>>>> !^apache.*perl
>>>>
>>>> What does this mean?  Does it mean NOT matching "apache" OR "perl".  If
>>>
>>> The '!' negates the regex as your have correctly stated.  This is
>>> actually in the docs for SecRule, but needs improved.
>>>
>>> The '^' anchors the match to the start of the string.  The '.' means
>>> "any character" and the '*' means "zero or more of the preceding match"
>>> which is a '.' in this case and thus '.*' means "anything, including
>>> nothing".
>>>
>>> The entire regex means:
>>>
>>> Does not match the word "apache" at the start of the string followed by
>>> the word "perl" anywhere after that.
>>>
>>>> so, I'd like to add wget to the list.  So, would this be:
>>>>
>>>> !^apache.*perl.*wget
>>>
>>> An OR is '|'.  For example:
>>>
>>> !(?:^apache.*perl|wget)
>>>
>>> The '(?:<regex>)' groups a subregex without capturing the results.  A
>>> (<regex>) does the same, but captures the results.  The ?: version is
>>> just more efficient if you do not need the captured results.
>>>
>>> This regex then means:
>>>
>>> Does not match the word "apache" at the start of the string followed by
>>> the word "perl" anywhere after that NOR the word "wget" anywhere in the
>>> string.
>>>
>>> Hope that helps a bit.  But you should consider reading the perl
>>> compatible regular expressions docs.
>>>
>>> http://perldoc.perl.org/perlre.html
>>>
>>> -B
>>>
>>
>> --
>> Brian Rectanus
>> Breach Security
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> mod-security-users mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>>


-- 
Brian Rectanus
Breach Security