Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: [Snort-users] ICMP issues in VPN
From: Keith W. McCammon (mccammongmail.com)
Date: Fri Jul 23 2004 - 12:10:38 CDT
> I would think that this is a false type positive, as these machines in
> question (MS SQL, Domain Controllers, Root Servers, and the IP addresses
> correspond to the IP addrs of these machines. How does one normally deal
> with a situation like this (i.e. - disregard ICMP for both networks which
> are 172.21.x.x and 10.1.1.x), etc?
You can deal with these in a number of ways:
You can write pass rules to disregard ICMP traffic to and from these
hosts. This is fast and dirty. The reason that I say "dirty" is
because you're likely going to end up passing on all ICMP traffic to
and from these hosts, which will get rid of these FPs, but may also
result in future, legitimate events not being logged.
You can suppress these events. This will allow you to get rid of
these specific events, without ignoring ICMP (or some subset of ICMP)
traffic to and from these hosts altogether. In most cases, this is
what folks recommend and end up implementing. Also worth noting that
this doesn't require you to change your rules, which is cool.
You can set a threshold for these alerts. You can tell, by looking at
your logs, how often these specific events occur. And based on the
number of these alerts that you see within a given period of time, you
can play around with the threshold levels until these alerts stop
This is obviously not the fastest way to get things done, but is
preferable to choices 1 and 2. The reasoning here is that
thresholding will do away with your day-to-day FPs (related to this
rule), but will not prevent Snort from generating an alert if there is
a drastic increase in these events.
For instance, let's assume that you get an average of 1 alert per
minute. You don't care about these, and that's all well and good.
With choice 1, you'll never see this event again (for these hosts).
Choice 2 will do the same as 1, using a more explicit (read: probably
better, long term) method. Choice 3 will do the same as 2 most of the
time. However, should you start to see 20 or 30 of these events per
minute (which would be abnormal and probably worth a brief
investigation), you *will* see the alert.
END BORING EXPLANATION
In the end, it comes down to personal preference, and your need for
accuracy (or your obsession with perfection). Any of these will do.
I'd use choice 3, if you can gauge these effectively. If the event
interval is inconsistent, use 2. If you just want them gone forever
and don't care, use 1.
> p.s. - Does the snort mailing list deal well with HTML stuff, due to the
> fact that I sent an email from my home system (outlook express) and it got real
> sick (got a reply back from da mailing list, even)?
Not sure how the list deals with it, but most people just plain hate
it, which may be reason enough to avoid using it here :)
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
Snort-users mailing list
Go to this URL to change user options or unsubscribe:
Snort-users list archive: