[Snort-devel] Defeating the anti-IDS tools...
ktimm at ...364...
Sun Apr 1 18:46:13 EDT 2001
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.
From: agetchel at ...358... [mailto:agetchel at ...358...]
Sent: Sunday, April 01, 2001 3:05 PM
To: ktimm at ...364...
Cc: snort-devel at lists.sourceforge.net
Subject: RE: [Snort-devel] Defeating the anti-IDS tools...
I guess I didn't clearly convey what the purpose of what this
preprocessor was. The purpose is not to keep alerts from being logged in
the normal fashion, but to supplement that information with another log
entry in a separate log saying 'you should probably look at the alerts
generated during this time period because someone may be running a
diversionary tool against your network'. This would simply be an
informational preprocessor and not alter the way alerts are handled in any
fashion. This preprocessor would give you the additional benefit of
alerting you to the fact that there may very well be a large burst of
legitimate attacks being launched against your network. I agree with you
that proper network and IDS design can aid in keeping diversionary tools
from effecting your network integrity, the preprocessor I describe would
simply offer a nice safety net.
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 2:07 PM
> To: agetchel at ...358...; snort-devel at lists.sourceforge.net
> Subject: RE: [Snort-devel] Defeating the anti-IDS tools...
> The danger with a diversionary pre-proccessor or in just
> assuming someone is
> using an anti IDS tool is that legitimate attacks can be
> hidden within the
> diversionary storm. The only way to truly fix the problem is
> to rethink IDS
> design. A quick solution is to place an IDS outside of a
> statefull firewall
> and on inside of a firewall. Use the one outside of the
> firewall strinctly
> for capacity planning, invetigations, and denial of service
> conditions, and
> use the internal IDS for alerting engineers.
> -----Original Message-----
> From: snort-devel-admin at lists.sourceforge.net
> [mailto:snort-devel-admin at lists.sourceforge.net]On Behalf Of
> agetchel at ...358...
> Sent: Sunday, April 01, 2001 1:33 AM
> To: snort-devel at lists.sourceforge.net
> Subject: Re: [Snort-devel] Defeating the anti-IDS tools...
> Hi all,
> Well, there have been some interesting responses to my original
> e-mail. It seems the general consensus is that doing something
> programmatically within Snort to specifically detect these sorts of
> diversionary tactics using some sort of rules wouldn't come
> without risks...
> of course. It might cause alerts not to be generated or
> marked falsely as
> 'diversionary tool generated'. Matt W. (kmx at ...309...)
> mentioned that
> it's obvious when someone is using one of these tools, as you
> will see Snort
> detect a large number of attacks in a very short period of
> time. Might it
> be useful to include a preprocessor in Snort which keeps a
> separate log file
> for detecting this type of activity? Something along the
> lines of what the
> portscan preprocessor does? A line in the snort.conf file would look
> something like:
> preprocessor diversion-tool: 300 5 diversion-tool.log
> This definition would state that if Snort detected
> three hundred or
> more alerts in five seconds, create a log entry in
> diversion-tool.log that
> the threshold has been tripped and someone may be running a
> tool against your network. This would being doing the same
> thing that Matt
> uses the data mining tools for, except it would be automatically
> accomplished and logged by Snort.
> I'm not even going to pretend to be an even moderately skilled
> programmer in this area, the only programming I do is writing
> my own network
> auditing tools in console Java. So I guess I'm going to leave the
> programming up to someone else on this one if there seems to be enough
> interest. Although I suppose I could always kludge my way
> through it... =)
> 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/
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
More information about the Snort-devel