[Snort-sigs] SID: 8440
patrik.israelsson at ...1288...
Tue Apr 24 18:56:20 EDT 2007
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 :-)
More information about the Snort-sigs