Firewall Wizards mailing list archives
Re: Important Comments re: INtrusion Detection
From: tqbf () secnet com
Date: Fri, 20 Feb 1998 15:43:28 -0600 (CST)
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"
Current thread:
- Re: Important Comments re: INtrusion Detection, (continued)
- Re: Important Comments re: INtrusion Detection tqbf (Feb 18)
- Re: Important Comments re: INtrusion Detection Paul M. Cardon (Feb 19)
- Re: Important Comments re: INtrusion Detection Jonathan Care (Feb 19)
- Re: Important Comments re: INtrusion Detection tqbf (Feb 18)
- Re: Important Comments re: INtrusion Detection Michael T. Stolarchuk (Feb 19)
- RE: Important Comments re: INtrusion Detection Kurt Ziegler (Feb 19)
- Re: Important Comments re: INtrusion Detection tqbf (Feb 19)
- Re: Important Comments re: INtrusion Detection Barney Wolff (Feb 20)
- Re: Important Comments re: INtrusion Detection Aleph One (Feb 20)
- Re: Important Comments re: INtrusion Detection marc (Feb 20)
- Re: Important Comments re: INtrusion Detection Barney Wolff (Feb 20)
- Re: Important Comments re: INtrusion Detection tqbf (Feb 20)
- Re: Important Comments re: INtrusion Detection Darren Reed (Feb 21)
- Re: Important Comments re: INtrusion Detection tqbf (Feb 21)
- Re: Important Comments re: INtrusion Detection Darren Reed (Feb 21)
- Re: Important Comments re: INtrusion Detection Darren Reed (Feb 21)
- Re: Important Comments re: INtrusion Detection Vern Paxson (Feb 21)