Re: Intrusion Detection solutions compared...

• To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
• Subject: Re: Intrusion Detection solutions compared...
• From: Tim Newsham <newshamLAVA.NET>
• Date: Tue, 12 May 1998 08:58:56 -1000
• Comments: To: smcclureQUAKE.NET
• In-Reply-To: <199805111619.GAA00757haleakala.aloha.net> from "Stuart McClure" at May 10, 98 08:53:16 am
• Reply-To: Tim Newsham <newshamLAVA.NET>
• Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>

> For those of you interested in automatic intrusion detection solutions,
> you can checkout InfoWorld's recent comparison including two NT, one
> Unix, and one service provder solution.
>
> The comparison is at:
>
> http://www.infoworld.com/cgi-bin/displayTC.pl?/980504comp.htm

While this review has a good description of how several network ID
systems in the market may look to a network manager,  they do not
cover the severe limitations that an attacker may see.

Thanks to some insight from Marcus Ranum the review does point out
that it is much better for a manager to simply fix the number of
problems that could be detected rather than wait for an ID system
to observe someone exploiting them.  The review then goes on to
say that ID systems are useful none the less and describes the
security they offer as being

     ``based largely on the strength of its database of known
       attacks, and how current it is kept''

This would be true in an ideal ID system, but in practice the ID
system itself can be much less effective than the database of known
attacks would suggest.

Network ID systems for TCP/IP rely on information passing by on the network
to try to reconstruct what is happening at network end points.  Unfortunately
it is not always easy (perhaps not even possible) to reconstruct the
information seen at the endpoint from this limited amount of information.
To make matters worse, different endpoints may react differently to the same
data.  Since an ID system needs to know how an end point is acting in order
to properly assess the ramifications of the data, this can be a serious
problem.  And then there is the fallability of the ID system itself:  ID
systems are software products and like all software products, prone to error.
An attacker may use bugs found in an ID system to attack the ID system itself,
or may find a flaw that lets him sneak by it without being monitored.

All of these factors make network ID systems less effective than they
might otherwise appear to be.  The end result being that an attacker
may slip by a network ID system unnoticed while attacking computers which
the ID system purports to protect.  An attacker may also abuse such
proclaimed features as reactive measures to perform denial of service
attacks against your network, using your ID system against you.

These issues are looked into in more depth in a paper written by
Thomas Ptacek and myself.  In the paper we give concrete examples of
vulnerabilities we found in every product on the market that we looked at.
The paper can be found at www.securenetworks.com in the Technical Reports
section.

> Stuart McClure

                                          Tim N.

• Prev by Date: By-passing IIS ftp security
• Next by Date: Basic authentication, IIS 4.0 gives "the parameter is incorrect", LogonMethod=2 doesn't work.
• Prev by thread: Intrusion Detection solutions compared...
• Next by thread: By-passing IIS ftp security
• Index(es):
  • Date
  • Thread