[Snort-users] Thresholding the threshold

Keith W. McCammon mccammon at ...11827...
Fri Aug 6 11:13:01 EDT 2004

> > 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 agree, I could use type "both" and set the time interval to about 60
> seconds, which should limit the # of alerts i end up seeing to 1 per
> second, but that would mean that i'd get a lot more alerts, and the
> important ones may get suppressed. 20 SYNs in 60 seconds is not
> exactly the same as 20 SYNs in 1 second.  So it'll have to be a lot of
> guess work to get the # high enough not to FP.  Then again, the rates
> I am talking about here I might be able to tweak it just right.

Yeah, that was just a thought.  Either way you cut it, because of what
you're trying to do, you're going to have to 1) do some
experimentation and 2) deal with a lot of alerts.
> > 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.
> I do have ntop running on that segment, but all it was telling me was
> that the source and the destination exchanged 3.5MB over the course of
> that hour (it happened at night).  Nothing suspicious, tiny amount of
> traffic among thousands of other sessions between other hosts
> happening at the same time, taking up MUCH more bandwidth.  What it
> DIDN'T tell me was that this was ALL very short sessions in very short
> period of time, which was causing the router in the middle to spike in
> CPU utilization as it was trying to keep state for thousands of
> connections (which is what I was trying to find out in the first
> place).

This is where I'm losing you, I believe.  What exactly is it that
you're trying to determine?  Or, what's the specific goal of this
traffic analysis?

I assumed (yeah, I know what they say about that) that the purpose of
these alerts was to initiate notification of the owner of the
offending system, so that she could take corrective action.  And to do
that, you pretty much only need to know the address/name of the
offending system.

However, I'm getting the impression that you need to be more precise. 
If this is the case--you need specific times, counts, etc.--I think
your best bet is to log *all* traffic between these two networks and
extract the information that you require on the analysis side.  Note
that using log instead of alert will reduce the number of in-your-face
alerts, while still capturing the desired data.  Very handy when you
don't need all of the data right away.

At the current rate, you could spend a lot of time tweaking the rule
to generate the number of alerts that you desire, but you do so at the
risk of either FPs or FNs.  If your priority is accurate data, then
log it all and sort it out after the fact.  If your priority is a
manageable number of alerts, then you're probably going to have to
sacrifice some accuracy to prevent DoS'ing your analysis console.

If you choose to capture all data, you can use Sguil, SnortSnarf,
ACID, etc. to help you aggregate and make sense of the logs and
> > Also, in response to your description of the problem, a firewall
> > between your development and production segments would probably be
> > advisable
> I WISH it was that easy. :)

Yeah, I feel your pain.  Just figured I'd throw it out there!

More information about the Snort-users mailing list