Re: Important Comments re: INtrusion Detection

[tqbf () secnet com]

> I would disagree, as this conclusion would not take into account the need 
> for a secondary source of information regarding the hosts which are 
> possible targets.  There is a strong need for context to be able to 

Believe it or not, the proxy solution actually solves quite a number of
problems. I spent about 40 minutes yesterday trying to explain to Kurt
Ziegler at AbirNet (who steadfastly believes that there's no difference
between a sniffer and a proxy [after all, they see the same packets!]) why
this was; hopefully, he reads Firewall-Wizards and will see this message,
because I don't want to type it in again. =)

All of the exploitable OS-inconsistancy-driven problems we found involved
the interpretation of abnormal streams of packets (if there were
inconsistancies in the handling of NORMAL packet streams, the OS vendors
would quickly become aware of the problem and fix it). 

A proxy gateway has the distinct advantage of being a connection endpoint.
In the terminology I've been using lately, I'd say that a proxy-sniffer is
an ACTIVE (not passive) monitor. Say we have hosts A (the attacker), B
(the proxy monitor), and C (the target). When A sends a packet to C, in a
proxy configuration, it actually winds up sending the packet to B. B does
NOT simply forward the packet to C; rather, it interprets the packet,
figures out what it thought host A meant by the packet, and then sends
host C a NEW packet REPRESENTING WHAT IT THOUGHT HOST A MEANT.

For instance, say we have some hypothetical bug that allows us to send
phantom pings to Linux hosts (and only Linux hosts) by mucking up the
ICMP checksum. Let's also assume that it's of critical importance that the
IDS accurately detect when attackers are trying to ping the hosts it's
watching. Host A sends one of these ICMP wackygrams to host C; if it's a
Linux box, it will get a response back, and if it's not, it'll get
nothing; either way, the packet LOOKS invalid and thus probably will not
get detected.

Host B, our active IDS, receives the ICMP packet. Because it's a proxy,
the packet does not simply get forwarded through host B. Instead, host B
examines the packet and tries to determine what host A meant to say with
the packet. In this case, the IDS can make two determinations; either host
A sent a meaningless packet (due to the bad checksum), or it intended to
send a normal ICMP ping and something got screwed up in transit.

Host B's job here is to come up with a NEW packet that accurately
represents what host A was trying to say, but that host B is absolutely
sure will be interpreted as expected by any operating system. In this
case, host B can either drop the packet (believing it to be meaningless),
or it can send host C an ICMP echo request with a valid checksum, in which
case host C will certainly accept the packet (unless it's filtering them
or running pingd --- so we haven't solved all the problems =]).

The point is that because host B interprets the packet and only allows
host C to receive packets which have clear, unambiguous meaning to both
the IDS and the endpoints, it's much more difficult to exploit OS
inconsistancies between host B and host C.

A practical (and more involved) example involves IP fragmentation. Host A
sends host C a packet fragmented into 8 and 16 byte overlapping fragments.
Ha! There's no way any IDS is going to accurately reassemble this
mishmash! Hell, the attacker would be surprised if host C managed to get
it right.

Well, that doesn't matter when you have an active monitor, because the
active monitor isn't going to let host C see a stream of overlapping
fragments. Instead, it's going to reassemble the frags itself and send
host C it's interpretation of the reassembly of the fragments. 

The technique seems even more useful with TCP streams. The problem with
TCP monitoring is that it involves two different machines with different
TCP driver implementations that ocassionally don't even see the same
packets on the wire to take a stream of TCP data packets, reassemble them,
and come up with the same data. When you start to push the limits of the
TCP protocol, this becomes very, very difficult.

Proxies help here. Instead of host A sending wacky TCP data packets to
host C, hoping to foil host B by confusing it about proper reassembly, 
it instead winds up making a complete TCP connection only with host B.
Nothing host A can do with the TCP handshake can fool host B, because a
connection to host C only occurs after one has completed with host B.
Nothing in the data stream can confuse host B, because host B reassembles
and then retransmits in new TCP packets. Host B is now a TCP endpoint, not
a TCP midpoint. I see most of the problems we identified in the paper
going away in this scenario.

One other big win that Darren Reed identified at Usenix was that a proxy
IDS can't drop packets. You can't overload it and sneak packets past that
way. If the IDS can't read the packet, it doesn't get proxied. 

There are still problems that need to be solved here. The most obvious is
that the IDS is no longer "unobtrusive", and it can actually bottleneck
the network, unlike ID systems (which, when bogged down, simply fail to
work reliably). There are also subtle problems at the protocol level, such
as end-to-end acknowledgement. However, the firewall community has made
this work; I'd be surprised if the IDS community couldn't too.

Comments/input/insults/derision welcome.

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