[Snort-devel] Defeating the anti-IDS tools...
agetchel at ...358...
agetchel at ...358...
Sun Apr 1 21:13:28 EDT 2001
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
E-mail agetchel at ...358...
> -----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
> 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
> 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.
More information about the Snort-devel