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: