Re: Content-prefixed PCREs

Joel Esler via Snort-sigs <[email protected]>
Newsgroups gmane.comp.security.ids.snort.sigs
Message-ID <[email protected]>
This is easy to test and confirm with the rule performance calculator if you don’t believe me.  

I realize that you may not know who I am if you are new here, but I’ve spent the better part of the last 20 years work with Snort and it’s engine and rule language. 

— 
Sent from my  iPhone

> On Feb 24, 2022, at 04:44, Danilo Sartori <[email protected]> wrote:
> 
> Thanks for your reply, but can you explain better your opinion?
> 
> If I take just the "SNORT Users Manual" into consideration, I can find
> no indication that the pcre is anchored to the previous content option.
> Is the regexp search supposed to start from where the match of the
> preceding content started?
> 
> 
>> On 23/02/2022 22:05, Joel Esler wrote:
>> No, this is a good thing.  The content gives the engine a place to do the initial match in the packet contents.  The regex is anchored on the content in order to execute faster and reduce false positives.  This is the way rules SHOULD be written.
>> 
>> —
>> Sent from my  iPhone
>> 
>>>> On Feb 23, 2022, at 16:00, Danilo Sartori<[email protected]>  wrote:
>>> 
>>> Hi there,
>>> 
>>> I've noticed that many signatures have a design pattern made of a
>>> content followed by a pcre having that same content as a prefix, just
>>> like the following:
>>> 
>>>> alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (
>>>> msg:"SERVER-WEBAPP SolarWinds Network Configuration Manager remote
>>>> file include attempt"; flow:to_server,established; http_uri;
>>>> content:"/Orion/NCM/Admin/S
>>>> ettings/VulnerabilitySettings.aspx",fast_pattern,nocase;
>>>> http_client_body; content:"txtUrl=",nocase;
>>>> pcre:"/txtUrl=[^&]*?(https?|ftp)(%(25)?3a|\x3a)(%(25)?2f|\x2f)/im";
>>>> metadata:policy max-detect-ips drop,polic
>>>> y security-ips drop; service:http; reference:cve,2020-27871;
>>>> classtype:web-application-attack; sid:58589; rev:1; )
>>> In principle this looks like a bad choice because the literal content
>>> might be stripped out of the regexp imposing the sequentiality with:
>>> 
>>>> pcre:"/^[^&]*?(https?|ftp)(%(25)?3a|\x3a)(%(25)?2f|\x2f)/imR";
>>> Maybe there is a good reason for such a common practice?
>>> 
>>> 
>>> Thanks
>>> 
>>> _______________________________________________
>>> Snort-sigs mailing list
>>> [email protected]
>>> https://lists.snort.org/mailman/listinfo/snort-sigs
>>> 
>>> Please visithttp://blog.snort.org  for the latest news about Snort!
>>> 
>>> Please follow these rules:https://snort.org/faq/what-is-the-mailing-list-etiquette
>>> 
>>> Visit the Snort.org to subscribe to the official Snort ruleset, make sure to stay up to date to catch the most <a href=" https://snort.org/downloads/#rule-downloads">emerging threats</a>!
_______________________________________________
Snort-sigs mailing list
[email protected]
https://lists.snort.org/mailman/listinfo/snort-sigs

Please visit http://blog.snort.org for the latest news about Snort!

Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette

Visit the Snort.org to subscribe to the official Snort ruleset, make sure to stay up to date to catch the most <a href=" https://snort.org/downloads/#rule-downloads">emerging threats</a>!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.