Re: Important Comments re: INtrusion Detection

[tqbf () secnet com]

Barney Wolff Thursday Feb 19 1998

> But why would it need to? Overlapping fragments are "never" produced
> by accident or misconfiguration, and can therefore always be taken as
> an attack signature.

First off, a nit: overlapping fragments with inconsistant data are never
going to be the valid output of a TCP/IP stack. I don't know that the same
is true of all overlapping fragments. I used to be comfortable making
claims like "this will never happen", but then I learned about Vern
Paxson's work, and now I try to be more careful.

That said, you're right. Overlapping fragments can always be taken as an
attack signature by an ID system. The problem with that is that if you
give up as soon as you see overlapping fragments, you haven't detected the
"real" attack. ID systems have arsenals of hundreds of attack signatures
designed to detect specific attacks against end-systems. If all you can
detect are the attacks against the IDS, those signature databases aren't
worth much.

This would be why we keep saying "our problems make it difficult to detect
SPECIFIC attacks", rather than "ANY attack". 

> Are you really intending to say that if I'm dumb
> enough to use an attack that works on OS-X against a host running OS-Y,
> the IDS should ignore me until I smarten up?

When we discuss issues like overlapping fragments, we're not dealing with
attacks that "work against Windows NT but not against 4.4BSD". What we're
dealing with is a stream of traffic that will be interpreted at the IP
layer in two different ways.

If you want to call a stream of ambiguous traffic an "attack", that's
fine, but a stream of overlapping fragments is not "an attack against
Windows NT" or "an attack against 4.4BSD". It's an attack against an
intrusion detection system, based on the fact that the IDS can't possibly
reconstruct the traffic reliably unless it knows what operating system is
running on the destination host.

> What's being missed here, imho, is that the great majority of attacks
> use packets/streams that lie far outside the boundaries of legitimate
> use, despite perhaps being legal IP or TCP.

This isn't being missed at all. The problem here is that what we're
talking about is "legal IP" and "legal TCP", as defined by the TCP/IP
implementations of various operating systems. The traffic may be obviously
illegitimate (ie, a stream of inconsistant overlapping fragments), but
it's not easy to filter on (what happens when we start dealing with TCP
ambiguities?), so you must deal with it somehow.

> As with firewalls, it can be useful to think about IDS as "deny what I
> don't recognize as permitted" rather than "permit what I don't recognize
> as denied".

I agree entirely, and this is why I like the proxy IDS model. A proxy can
"deny" anything it doesn't recognize. A passive IDS can't. 

> Products that trade off the false alarm rate vs the missed attack rate
> in different ways can compete in the marketplace, without being in any
> universal sense fatally flawed.

I don't know that we're discussing attacks that have some probability less
than 1 of succeeding, and hence I don't like discussing this problem in
terms of "a tradeoff with the missed attack rate". Anyone with the right
software can evade all the commercial passive network ID systems right now
(unless I'm not keeping up on the vendor fixes to the problems we brought
up). If you think "safe against anyone who can't read a paper and write
TCP/IP code" is an acceptable threat model, that's fine. I suspect that
it isn't for most people.

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