[Snort-devel] Defeating the anti-IDS tools...
kmx at ...309...
Sun Apr 1 22:59:49 EDT 2001
Personally I think a preprocessor is going in the wrong direction. This is not
something that should be handled by snort. This should be handled by outside
processing. If you tune your IDS correctly and place it in your network
correctly these attacks will never happen.
In my opinion the real problem is snort doesn't have a way to know what traffic
is valid for your network. So administrators have to tune the device and many
people are too lazy or not experienced enough to do this. So they use the
default vision.conf rules and call it a day. They then wonder why they are
getting an arse load of false positives. This is because 90% of the rules in
vision.conf probably don't apply to their network.
So here is a quick suggestion. Along with the scoring system people are
developing we can create a flag that says "This rule applies to my network
YES/NO" Then it's really easy to filter all the traffic if you are logging to a
database. This will detect things like snot and other traffic generation
attacks and it will filter out lots of the crap.
Data mining is the key to detecting these things easily, not preprocessors.
agetchel at ...358... wrote:
> Hi Kevin,
> Personally, I don't think that using a diversion alerting system
> such as this will cause engineers to brush off alerts created by this
> preprocessor, but rather get them to look deeper into the alerts which were
> logged during this time period. If the reason they aren't looking at these
> is an under-staffing issue, or similar, than that's a whole separate problem
> and obviously can't be handled programmatically. Let's design the software
> for the perfect world, so if the organization using the product has the
> capability to take advantage of it, they can do so. There's no reason to
> not include a feature because _some_ shops don't have the capacity to use
> it. I think everyone who uses Snort would agree with you (as do I) that
> this is not the perfect solution to this problem, and realizes that there
> may be network and IDS design issues, but at least it would give us a
> _basic_ tool to effectively detect these _types_ of attacks.
> Stateful inspection is something that has to come to Snort, as well
> as other IDS's, if they want to remain legitimate players in the IDS market.
> Especially in the face of an ever increasing level of advanced intrusion
> techniques. This, however, from my limited familiarity of the Snort
> code-base, would entail an almost complete rewrite of the source. Not
> something I think the coders are willing to jump on so quickly. =)
> This would be an interesting subject to discuss in further in depth
> face-to-face. Is anyone here going to be at the SANS conference in
> Baltimore during the middle of May? Maybe we could do a BOF session?
> Abe L. Getchell - Security Engineer
> Division of System Support Services
> Kentucky Department of Education
> Voice 502-564-2020x225
> E-mail agetchel at ...358...
> Web http://www.kde.state.ky.us/
> > -----Original Message-----
> > From: Kevin Timm [mailto:ktimm at ...364...]
> > Sent: Sunday, April 01, 2001 6:46 PM
> > To: agetchel at ...358...
> > Cc: snort-devel at lists.sourceforge.net
> > Subject: RE: [Snort-devel] Defeating the anti-IDS tools...
> > If used in that manner I think it is a good idea, however I think just
> > tagging the diversionary tag doesn't do anything to really
> > deal with the
> > human issues. The human issues are that it is going to
> > overload the analyst
> > center. Will they be able to sift thru the information in a
> > timely manner to
> > mitigate the risk of the attack. Will they start to ignore
> > diverssonary
> > attacks because of the great amount of effort involved in
> > analyzing the
> > data. For these reasons it is better to fix the real problem.
> > In a perfect
> > world an IDS could detect attacks and then take response
> > through resetting
> > connections, changing access policies, routing offenders to
> > black holes and
> > what not. IDS is not approached a perfect world though so
> > most automated
> > response techniques are not used unless the chance of flase
> > positives is
> > extremly low. These diversionary attacks defeat any chance of
> > effective
> > automated response. To fix this some options are
> > 1., Correct use of filtering on routers (the chance of this
> > happening is
> > small unless you have an initiative similiar to spam in that some
> > organization contantly checks routers for improper filtering and then
> > creates a sort of real time black list.)
> > 2., Statefull inspection on an IDS.
> > I think the best way would be for a bunch of really smart IDS
> > people to get
> > together and make a list of every possible option, then
> > decide which are the
> > most effective to implement.
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
More information about the Snort-devel