[Snort-sigs] Ultimate Rule List

Moyer, Shawn SMoyer at ...758...
Tue May 20 21:04:03 EDT 2003


As another poster stated, there really is no ultimate ruleset; pretty much
everything needs to be tuned for your specific environment. 

Personally what I do is maintain a list of "problem" sid's or high-false
sid's that don't work for my environment in a disabled.rules file, grep -v
those out of my ruleset, and then maintain a site-specific set of rules in
local.rules that contains either "pass" rules for certain things that are
noisy in specific instances (say to a certain host), or custom alerts for
things that are, again, specific to my environment. This process doesn't
take long, maybe a week or two, and the end result is that you have an IDS
that actually lets you know about useful stuff that's going on.

Spend some time reading through snort.conf to reflect your environment, read
through the FAQs and other docs on the website, and by all means submit any
fixes, additions, or complaints about totally useless rules to this list
(and yes, certainly there are some out there).

FWIW, you'd have the exact same problem with a $30K closed-source,
closed-sig IDS, without the ability to get under the hood and fix or tune
things to your satisfaction. Instead, you'd be waiting weeks for an update
or spending hours on the phone with tech support. The beauty of Snort (and
OSS in general) is that the tools are all there for you to make it do
exactly what you want, for your specific scenario, as long as you're willing
to spend the time and brainpower to get it there.




--shawn



> -----Original Message-----
> From: Greg Powell [mailto:gpowell at ...1523...]
> Sent: Monday, May 19, 2003 9:47 AM
> To: snort-sigs at lists.sourceforge.net
> Subject: [Snort-sigs] Ultimate Rule List
> 
> 
> In theory is there an ultimate rule set that could be written 
> to reduce
> false positives? I am trying to understand if most of the 
> current rules are
> written to catch as many intrusions as possible by using a 
> small set of
> rules. Does anyone see it as possible to write a large set of 
> rules that
> could limit the number of false positives?
> 
> My assumptions are that some false positives are generated by 
> the fact that
> the rules are too loose. I would like to be the first to 
> indicate that I may
> be wrong in this assumption (so let me know if this is not 
> the case). If
> this is true then could there be some larger set of more 
> refined rules that
> would better block each intrusion?
> 
> I do understand that there may be a cpu/memory consumption 
> trade off but I
> am not sure I understand how large that impact would be.
> 
> Greg
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: If flattening out C++ or Java
> code to make your application fit in a relational database is 
> painful, 
> don't do it! Check out ObjectStore. Now part of Progress Software.
> http://www.objectstore.net/sourceforge
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> 




More information about the Snort-sigs mailing list