Snort mailing list archives

RE: Nachi false positives


From: "Martin Jr., D. Michael" <martinm () montevallo edu>
Date: Thu, 30 Oct 2003 14:09:00 -0600



The rule has worked great for us here but it is good to know that the
false positives are explainable.  As you know, in a University setting
the problems are more often the student computer for which we have
little control of and not just the outside world.  (I would be
interested in any other University type rules you might have developed
or could suggest.)

As for setting-up thresholds, I am very new to Snort and will have to do
some research on that.  I don't presently know how or where to start.

Thanks,

Michael Martin
University of Montevallo

-----Original Message-----
From: Paul Schmehl [mailto:pauls () utdallas edu] 
Sent: Wednesday, October 29, 2003 8:52 PM
To: Martin Jr., D. Michael; snort-users () lists sourceforge net
Subject: Re: [Snort-users] Nachi false positives

--On Wednesday, October 29, 2003 10:04 AM -0600 "Martin Jr., D. Michael"

<martinm () montevallo edu> wrote:

I have been using the rule I've seen out there for detecting the
Nachi/Welchi virus for some time with excellent results.  Lately, for
some reason, I have been getting what appear to be some false
positives.
When I trace where the packet was going it goes to 207.188.7.125 which
tracks down to realcomlvs.real.com (Real Player).  Could this be a
natural byproduct of RealPlayer?  Any ideas?

I wrote that rule, and I've been getting "false positives" with it all 
along.  The reason for that is that Nachi uses the built-in ping
function 
of Windows, so many things could trigger it.  The difference between an
fp 
and an infection is obvious, however, because infections will generate 
packets at a very high rate, on the order of 150,000 to 250,000 per
hour.

If you're using snort 2.02, you could write some thresholding bits into
the 
rule that would fix those.  I'm still on 2.0 (hopefully not much longer,

just too darn many fires to put out), so I haven't fiddled with it yet. 
I'm not real familiar with the thresholding rules yet, but I suspect 
something on the order of 500 alerts in 60 seconds would eliminate 
everything but infections.

It looks like you could add "threshold: type limit, track by_src, count 
500, seconds 60;" added to the rule might suppress everything but real 
infections.  You could probably lower count to 250 and still not get any

fps.  (A "normal" infection would generate around 2500 alerts a minute
or 
more.)

Erek, correct me if I'm wrong on the syntax.

Paul Schmehl (pauls () utdallas edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
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: