Snort mailing list archives
Re: Snort and real-time alerting
From: Eric G <eric () nixwizard net>
Date: Mon, 28 May 2012 12:58:55 -0400
On Thu, May 24, 2012 at 3:40 PM, JJC <cummingsj () gmail com> 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 talking about. 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 those environments) -- Eric http://www.linkedin.com/in/ericgearhart
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Snort-users mailing list Snort-users () 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 Please visit http://blog.snort.org to stay current on all the latest Snort news!
Current thread:
- Re: Snort and real-time alerting, (continued)
- Re: Snort and real-time alerting Lay, James (May 23)
- Re: Snort and real-time alerting Jeronimo L. Cabral (May 23)
- Re: Snort and real-time alerting Lay, James (May 23)
- Re: Snort and real-time alerting Jeremy Hoel (May 23)
- Re: Snort and real-time alerting JJC (May 23)
- Re: Snort and real-time alerting waldo kitty (May 24)
- Re: Snort and real-time alerting JJC (May 24)
- Re: Snort and real-time alerting Jeronimo L. Cabral (May 28)
- Re: Snort and real-time alerting waldo kitty (May 28)
- Re: Snort and real-time alerting Jeronimo L. Cabral (May 29)
- Re: Snort and real-time alerting Eric G (May 28)