Snort mailing list archives
Re: Thresholding the threshold
From: "Keith W. McCammon" <mccammon () gmail com>
Date: Fri, 6 Aug 2004 11:47:04 -0400
The problem is that last night for example, I got alerted 620 times in the matter of 5 minutes. There is no way to threshold the alert on a rule with threshold in it. Also, applying a global threshold doesn't help since local thresholding overrides it.
See the docs for thresholding. There are different types of threshold rules. You probably want the "both" type. You may need to tweak the rule (set the interval longer), though.
I think it's time to dive into portscan or flow-portscan preprocessor. Question: would they allow me to detect when there is a large number of SYNs sent to the SAME port? Because that's what i am trying to find.
You don't want flow_portscan. You're doing one-to-one or many-to-one detection, which is pretty much the reverse of a portscan (if you were scanning a network, you wouldn't try to connect to one destination host and port from 100 source hosts, just in case the destination host was picky!). Don't think portscan will work, either, as it takes as input the number of unique ports over a period of time. You only have one destination port. [Getting OT...] If I may, I'll make a suggestion that I made recently to someone with a similar problem. You're really looking for anomalous network traffic, as opposed to an attack. Perhaps something like NTop might help you to pinpoint the source and severity of these issues with a lot less work, and may also provide more useful data. If you screw with it long enough, you'll probably get Snort to tell you when one of these events begins. If you're careful, you can continue to receive non-flooding alerts for the duration of the event. But this will take some tweaking. Unless these misbehaving applications are doing some noticeable harm to your network, why not just use NTop to keep detailed connection, src/dest, and data transfer stats, and simply use that information to deal with the issue? It'll tell you the same thing: Host X is sending *way* too much traffic to Host Y, at this time, for this duration. Also, in response to your description of the problem, a firewall between your development and production segments would probably be advisable, and you might get some mileage there as far as SYN flood prevention/detection (more along the lines of prevention, I'm guessing). Hope this helps... Cheers Keith ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ 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
Current thread:
- Thresholding the threshold sekure (Aug 06)
- Re: Thresholding the threshold Keith W. McCammon (Aug 06)
- Re: Thresholding the threshold sekure (Aug 06)
- Re: Thresholding the threshold Keith W. McCammon (Aug 06)
- Re: Thresholding the threshold sekure (Aug 06)
- Re: Thresholding the threshold Keith W. McCammon (Aug 06)