Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Snort-Signatures
[Top] [All Lists]

Re: [Snort-sigs] SID: 8440

Subject: Re: [Snort-sigs] SID: 8440
Date: Wed, 25 Apr 2007 00:56:20 +0200
On Tuesday 24 April 2007 19.23, Paul Schmehl wrote:
For what it's worth, I've deactivated this sig since long since it was
giving  way too many false positives. We run NIDS services for a whole
bunch of  companies and this sig has triggered massively on our sensors
in pretty much  every network we've connected them to. So I'm fairly
confident that what  you're seeing is not clients trying to exploit a
vulnerability, rather they  are just going about their usual business and
this Snort sig is interpreting  it incorrectly.

The sig is doing precisely what it's supposed to be doing.  The question
is, is what it's being asked to do correct?  And if so, why are clients
routinely trying to overflow a buffer?  Is it a massive misinterpretation
of the protocol?  Is the sig written incorrectly?

I'm hesitant to disable alerts simply because they're noisy.  I prefer to
know why they're noisy and correct the problem.

Aye, I agree with you there. I'm not saying all noisy rules should be 
discarded per se, and it's very good that you're bringing this up - I've been 
curious myself why this sig is giving so many false positives. What I'm 
saying is simply that - it IS giving many false positives, that is, I've seen 
it alert on traffic from common legit clients of all kinds. While it's 
certainly possible that the rule is correctly written and all clients are 
misinterpreting the protocol, I'd say it's not very likely. Again, that in 
itself is of course not really enough to supress the rule altogether. It's 
always best to learn what the rule is doing instead, only problem is that 
doing that for every rule giving false positives would be _very_ time 
consuming. So I'm looking forward to the answer :-)

Regards,
Patrik

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs

<Prev in Thread] Current Thread [Next in Thread>