[Snort-users] Snort and real-time alerting
eric at ...15503...
Mon May 28 12:58:55 EDT 2012
On Thu, May 24, 2012 at 3:40 PM, JJC <cummingsj at ...11827...> wrote:
> I understand what you are saying, and in theory it can certainly
> provide some insight into attacks against what it is that "you" are
> "trying" to "protect".. that said.. why are you even allowing mysql
> from the outside in your example, seems like a bad practice in the
> first place, this is the kind of thing that generic firewalls and
> logging thereof are for, no? That type of thing notwithstanding, if
> you can turn on more rules and look at traffic that may be "real"
> attack traffic against things that "you" "don't" have, and still be
> able to manage your alert volume, then more power to ya, I say if it
> works for you then stick with it.. certainly not my methodology though
> and I don't see how it's scalable in an environment with significant
> traffic volume and a potentially large attack surface.
I've thought long and hard about this problem as well, and while I've got
less rules applied to my edge sensors, I have inside sensors that still
have a broader rulebase enabled, for the very reason waldo kitty states...
what about insiders? What if someone drops a rogue AP in front of a printer
in the building, and is stupid enough to just start throwing attacks
blindly at servers? Heck, what if someone in tech support boots from a
BackTrack livecd because they're feeling leet this week, and decides to
just throw some random Metasploit modules at the server farm? What if a box
gets successfully hit with a RAT? Sure, I should see the "Hack style RAT
outbound connection" alert fire off, but it would give me a bigger warm and
fuzzy if I can also see what they were able to attempt to do on the inside.
If they're dumb enough to throw Wordpress attacks at a printer device then
at least I'll know... IMO you can't just assume "well I block 1433 and 3306
at the edge firewall, so I don't need any SQL rules." Especially if you've
got your Snort devices in passive IDS mode...
I completely understand the false positive "noise" argument however, and to
counteract that a bit I do have policies that slice up the inside network
in a way where I can disable rules that generate "noise" for specific
$HOME_NETs I have defined. If an alert fires off for a CVE from 2001 for a
product that we don't even have, then yes I go ahead and disable that rule
(I tend to disable instead of suppress, because I think suppressions still
have an impact on Snort's performance, they just don't alert, right?)
I'd still rather have servers defined as $HOME_NET in one policy,
workstations defined as HOME_NET in another policy, a DMZ defined as
HOME_NET in another, etc. I disable or threshold rules based on alerts that
I've seen, and go from there. The painful "time tradeoff" of tuning out
noisy rules (or suppressing out NOP sled rules when the destination is a
file server and exes get uploaded to there all day and generate lots of
FPs, for example) is worth it, in my humble opinion. And we do have a
pretty significant amount of traffic flowing around on the inside... this
isn't 5 folks plugged into one file server and a cable modem that I'm
I will admit that I don't rely on just Snort rules for figuring out if
there's a legitimate incident happening on the network (SIEM correlation
helps with that a lot), so maybe my environment is unique as compared to
the SMB market (where there's no budget, and Snort being free is the best
thing since sliced bread - I've been there, so my hat's off to you guys in
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-users