[Snort-users] Default Rules

Alex Kirk akirk at ...1935...
Mon Jun 21 09:16:47 EDT 2010


First off, nice email address. :-)

Now, to the meat of your questions here. The fact that you're on a small
network with just a few hosts is likely relevant to the number of alerts
you're seeing; the larger the network, generally the more events you get.
Since the goal of any IDS administrator is to tune their system to the point
that they get the minimum number of alerts - i.e. only those that are truly
relevant and actionable - you're actually probably starting from a good
position here.

Rules are commented out for a number of reasons. At the risk of tooting my
own horn here, you might want to read the blog post I put together back in
January that discusses this very issue:

http://vrt-sourcefire.blogspot.com/2010/01/vrt-guide-to-ids-ruleset-tuning.html

If there are rules that you think you might want to run that are commented
out now, feel free to turn them on - especially if they're protecting
against vulnerabilities that are likely present on your network, based on
the software you're running (i.e. the SQL servers you've mentioned). Since
you're on a small network, you can probably turn a large number of rules on
at once and still perform fairly well - you may just get buried in a pile of
irrelevant alerts if you're turning on things without thinking about them.

You may also wish to disable certain rules, based upon what you've got
running there. We try to design our defaults around "generic" networks, and
since every network is individual, we may have enabled things you don't
need.

Finally, as for testing rules - I sure wouldn't put an intentionally
unpatched box onto a production network, that's just asking for trouble. If
you want to go that route - which is quite legitimate if you're testing
things out - do it in an isolated environment, so you don't accidentally get
something nasty on your production boxes. Tools like Metasploit are probably
going to be your friend here, since they let you launch a number of attacks
easily.

On Mon, Jun 21, 2010 at 8:59 AM, Clue Store <cluestore at ...11827...> wrote:

> Hi All,
>
> I’m new to Snort, so take it easy :) I have enabled the portscan
> preprocessor and am detecting port scans from Nessus and Nmap, but if I
> disable that preprocessor, i’m not getting much else in the way of
> intrusions (this could be due to the fact that im only sniffing a small
> amount of traffic for a few hosts). I also see that alot of the rules are
> #‘d out, so they aren’t being used.
>
> 1. Should I uncomment out some of these some or all of the rules (for
> example, I have alot of different SQL servers on my network I want to
> protect). What about the bad-traffic.rules, etc??? Are these commented out
> due to too many false positives and noise???
> 2. What is a good way of testing some of the rules out?? Do I deploy an
> un-patched server with IIS and SQL for example that have known
> vulnerabilities?? Honeypots??
>
> Thanks,
> Max
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
>



-- 
Alex Kirk
AEGIS Program Lead
Sourcefire Vulnerability Research Team
+1-410-423-1937
alex.kirk at ...1935...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20100621/e584d041/attachment.html>


More information about the Snort-users mailing list