Re: Important Comments re: INtrusion Detection

[tqbf () secnet com]

> One conclusion from this is might be that  an IDS is only truely
> possible if implemented as a proxy gateway of sorts or otherwise
> performs as a mediator of packets as a firewall might be expected
> to do.  Do you agree with this ?

Hesitantly. 

Remember, the problem we identified with sniffer-based ID systems is that
they can't reliably detect attacks that involve stream reassembly
(unfortunately, IP fragmentation means that most attacks fall into this
category). However, there are two gotchas here.

The first, and the answer you're likely to see from IDS vendors in the
near future, is that ID systems CAN detect patterns of "malicious
traffic". A stream of 8-byte fragments is never going to occur in reality.
Overlapping fragments with inconsistant data are going to be extremely
rare. Inconsistant TCP retransmits will never occur legitimately - oh
wait, yeah they will, ask Vern Paxson. =)

The point is that even though an IDS can't detect, say, a PHF attack
reliably anymore (and I don't believe the current sniffer-based IDS design
will ever be able to do this), it WILL be able to detect that abnormal
series of packets are being sent on the wire. The IDS can alarm on this,
rather than on the string "phf", and thus give you some measure of
accountability.

Of course, as we've been saying, this is not what ID systems have been
advertised as being capable of doing. I doubt highly they'd sell at all if
the sales engineers were forced to report "well, we can say 'ATTACK FROM
HOST A TO HOST C', but nothing more". This means that, against a skilled
attacker (or an unskilled one once the exploits become available), the ID
system's large arsenel of "signatures" becomes meaningless, because
there's only going to be a few different types of detectable attacks:

        "OVERLAPPING FRAGMENT ATTACK DETECTED"
        "OVERLAPPING TCP SEGMENT ATTACK DETECTED"
        "UNSEQUENCED RST DETECTED"

Etc, etc, etc. Don't even get me started on the reliability of real-time
session playback; the systems we have now don't even check TCP sequence
numbers.

The other gotcha is that you can use sniffers but not rely on them solely
for information. Vern Paxson's two amazing IDS problems are the
ambiguities stemming from the DF bit/MTU pair and the TTL. Both of these
cases involve backbone sniffers that are protecting hosts that can be 10
or 100 hops away. Both involve the question of "will this packet ever
reach it's destination", and both are ambiguous - if the TTL is too short,
the packet will expire before making it, and if the DF bit is set, the
packet may be too large to cross one of the hops. 

A naieve sniffer has no way of knowing whether the packet will make it,
because it has no knowledge of the network topology (ie, doesn't know the
number of hops to the destination, and doesn't know the MTU of each of
these hops). However, there's no rule that says you can't feed the IDS
this data. Someone could in theory design an IDS that has a secondary
source of information that provides it with a continuously updated,
quickly converging view of the topology, complete with MTU and bottleneck
bandwidth capacity. When this IDS has to wonder whether the packet makes
it to the destination, it can consult it's network map and get a very good
idea of whether it will.

This is the "secondary source of information" requirement we're noting for
sniffer-based ID systems. Any of the ambiguities our paper identifies can
be resolved with an appropriate secondary source of information, which
might be the network topology, or might be the OS running on every host.

I'd be surprised if someone didn't try to make this design work, since
this kind of IDS remains unobtrusive and keeps a good portion of the
reliability sniffer-based systems originally claimed to have. Of course,
these types of systems will always be less secure than proxy systems, but
this list should be very familiar with that issue. =)

-----------------------------------------------------------------------------
Thomas H. Ptacek                                        Secure Networks, Inc.
-----------------------------------------------------------------------------
http://www.enteract.com/~tqbf                           "mmm... sacrilicious"