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:
- Nachi false positives Martin Jr., D. Michael (Oct 29)
- Re: Nachi false positives Mark Nipper (Oct 29)
- Re: Nachi false positives Paul Schmehl (Oct 29)
- <Possible follow-ups>
- RE: Nachi false positives Martin Jr., D. Michael (Oct 30)