Partially on-topic, yes I have been working on a new feature within pulled pork what will automatically create predefined VRT rulesets of disabled  and enabled rules based on the requirements of the end user. <br><br>I.E. <br>
Security<br>Connectivity<br>Balanced<br><br>JJC<br><br><div class="gmail_quote">On Tue, Dec 29, 2009 at 3:07 PM, Matt Olney <span dir="ltr"><<a href="mailto:molney@...435...">molney@...435...</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So, a little bit about how the VRT approaches these older rules:<div><br></div><div>1)  There is a field in many rules called "metadata".  This field is used by our product to determine which rules to turn on and off for base rule sets.  I know that JJ (pulled pork) has been working on integrating a similar set of functionality into pulled pork.  But here is the important part, if there is no metadata then we've essentially said don't turn this rule on by default.</div>

<div><br></div><div>2)  We will also disable rules that we feel are particularly problematic, either false-positive wise, or performance wise.</div><div><br></div><div>3)  We generally only revisit rules when we get information from users that there is an issue (none reported on this rule), when there is unpdated functionality in snort that impacts the rule (note that this old rule uses the newer uricontent) or if we stumble across something in testing.  When we do this we typically disable, delete or modify the rule, although sometimes we do simply say the rule is what it is, and we can't change it without impacting functionality.</div>

<div><br></div><div>In this case I would simply say that you should disable the rule.  I certainly wouldn't go out and add a pcre check on this, as it isn't worth the additional overhead.  This would, in general, be part of the tuning process.</div>

<div><br>Now, with all of that said...I'm thinking we could probably disable this rule, I'll throw a bug entry together and make sure I'm not missing anything.<br><br>Matt</div><div><br></div><div><br></div><div>

<div class="gmail_quote"><div><div></div><div class="h5">On Tue, Dec 29, 2009 at 4:25 PM, Guise McAllaster <span dir="ltr"><<a href="mailto:guise.mcallaster@...2420..." target="_blank">guise.mcallaster@...2420...</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">
Here is another ancient rule that has some false positive:
<br> <br>alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI phf access"; flow:to_server,established; uricontent:"/phf"; nocase; metadata:service http; reference:arachnids,128; reference:bugtraq,629; reference:cve,1999-0067; classtype:web-application-activity; sid:886; rev:12;)
<br> <br>If people still care about this vuln, could we change it to be more robust?  I see it false positive on things like 'GET /foo/bar/PHFDD_user.js'.
<br> <br>Maybe something like this:
<br> <br>alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI phf access"; flow:to_server,established; uricontent:"/phf"; nocase; nocase; pcre:"/\/phf\/?\?/Ui"; metadata:service http; reference:arachnids,128; reference:bugtraq,629; reference:cve,1999-0067; classtype:web-application-activity; sid:886; rev:13;)
<br> <br>Similar simple file access rules could probably be modified in a similar manner (although I have not looked).<br><br>If people don't care about the rule, maybe we could prune it out along with all exploit specific rules that are over 10 years old.<br>


<br>Thanks.
<br><font color="#888888"> <br>Guise
<br>
</font><br></div></div>------------------------------------------------------------------------------<br>
This SF.Net email is sponsored by the Verizon Developer Community<br>
Take advantage of Verizon's best-in-class app development support<br>
A streamlined, 14 day to market process makes app distribution fast and easy<br>
Join now and get one step closer to millions of Verizon customers<br>
<a href="http://p.sf.net/sfu/verizon-dev2dev" target="_blank">http://p.sf.net/sfu/verizon-dev2dev</a> <br>_______________________________________________<br>
Snort-sigs mailing list<br>
<a href="mailto:Snort-sigs@lists.sourceforge.net" target="_blank">Snort-sigs@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/snort-sigs" target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-sigs</a><br>
<br></blockquote></div><br></div>
<br>------------------------------------------------------------------------------<br>
This SF.Net email is sponsored by the Verizon Developer Community<br>
Take advantage of Verizon's best-in-class app development support<br>
A streamlined, 14 day to market process makes app distribution fast and easy<br>
Join now and get one step closer to millions of Verizon customers<br>
<a href="http://p.sf.net/sfu/verizon-dev2dev" target="_blank">http://p.sf.net/sfu/verizon-dev2dev</a> <br>_______________________________________________<br>
Snort-sigs mailing list<br>
<a href="mailto:Snort-sigs@lists.sourceforge.net">Snort-sigs@...639...forge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/snort-sigs" target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-sigs</a><br>
<br></blockquote></div><br><br clear="all"><br>