[Snort-users] Thresholding the threshold

Keith W. McCammon mccammon at ...11827...
Fri Aug 6 08:48:00 EDT 2004

> 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

Hope this helps...



More information about the Snort-users mailing list