[Snort-users] Using Snort & DB to remove false alarms
Kreimendahl, Chad J
Chad.Kreimendahl at ...4716...
Thu Apr 8 08:41:17 EDT 2004
So you're saying create a second rule to return the first packet
response on every HTTP request so you can verify what the return value
was in order to eliminate harmless attacks.
I understand the desire to see if someone is attacking, regardless of
success... But for some of us that makes entirely too much noise to be
useful. I'd be fine if all of that I recommended could be done with
tagging, but it can't.
From: Michael Boman [mailto:michael at ...3137...]
Sent: Tuesday, April 06, 2004 6:44 AM
To: Sean Wheeler
Cc: Snort Users
Subject: Re: [Snort-users] Using Snort & DB to remove false alarms
On Tue, 2004-04-06 at 18:16, Sean Wheeler wrote:
[ ... ]
> Imagine a frontend : Show me alerts using "weed out the obvious" Y/N ?
> Script does the "weeding" as described above prior to displaying the
> Taking it further :
> You could use threshold suppression aswell, so you no longer see
> Webserver A
> because "weeding" figured out the Webserver A is not vulnerable to
> attack sig X.
> It would be possible using the above methodogoly abeit 1/2 days work
> point, we can use snort itself as one mechanism for identifying "false
> Your thoughts ??
I believe this intelligence should sit at the front end (or somewhere
between Snort and front end), and not in Snort. Snort should concentrate
on detecting as much as possible as fast as possible, and let other bits
and pieces do the rest (that's why barnyard was created in the first
place, so Snort doesn't need to worry about talking to databases etc).
Once in the post-processing/front end stage an alert should never be
hidden from an analyst. Just because the attack didn't succeed doesn't
mean it never took place.
But using visual means to describe the outcome of the attack is OK, just
that I am against hiding alerts from the analyst.
More information about the Snort-users