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

| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [Snort-sigs] SID: 8440, Paul Schmehl |
|---|---|
| Next by Date: | [Snort-sigs] Bleeding Edge Threats Daily Signature Changes, bleeding |
| Previous by Thread: | Re: [Snort-sigs] SID: 8440, Paul Schmehl |
| Indexes: | [Date] [Thread] [Top] [All Lists] |