[Snort-users] Default Rules
cluestore at ...11827...
Mon Jun 21 09:43:07 EDT 2010
Thanks for the quick reply. And yes, I am in the market to buy some Snort
clue today :)
The link you sent for the rule tuning is exactly what I was looking for.
I'll also check out Metasploit which looks like a great way to test.
And no, we had no plans to deploy those boxes on our production network. We
have a spare cable modem connection that we would put this on, so it will be
completely isolated from our production boxen.
Thanks again for the reply. Time to do some reading and get my learn on :)
On Mon, Jun 21, 2010 at 8:16 AM, Alex Kirk <akirk at ...1935...> wrote:
> 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:
> 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
> 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
> 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??
>> 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:
>> Snort-users mailing list
>> Snort-users at lists.sourceforge.net
>> Go to this URL to change user options or unsubscribe:
>> Snort-users list archive:
> Alex Kirk
> AEGIS Program Lead
> Sourcefire Vulnerability Research Team
> alex.kirk at ...1935...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-users