Snort mailing list archives

Re: Thresholding the threshold


From: "Keith W. McCammon" <mccammon () gmail com>
Date: Fri, 6 Aug 2004 14:12:17 -0400

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
alerts.
 
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!


-------------------------------------------------------
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: