Hehhehe, while my job at Reflex is leading our IPS development, my
research at the GTISC is a bit more pure -- I hope my somewhat
theoretically-minded answer earlier didn't paint me an ivory
towerist :D
Nah. I think my eyes just glazed over after the first few greek
letters ;-)
The real benefit of a full fledged TCP state machine is knowing when to
expire an idle connection. If we expire a connection too early, then
the next packet that comes in on it will appear to be a new connection
and several things may happen:
You list several problems with timing out sessions too early, but none
with timing them out too late. For the sake of argument, what problems
do you see with simply idling out via necessities of LRU applied to a
fixed-size flow cache (obviously, sessions could still be closed based
on 4-way TCP teardown, RST abortion or SYN/OOW xmit, modulo the guesswork
typically involved in such)? A much less intensive state machine can be
developed in this case, if one's merely concerned with the problems
you've raised (I noted several other benefits from a detection
standpoint in my earlier answer).
Fixed-sized state tables are absolutely awful when done in software.
They're trivial to DoS if you can predict the re-hash path or if they
degenerate to a linked list off a hack bucket. My classic example was
on a Sun Ultra 10 440Mhz with a meg of cache. Ten packets a second took
the box to its knees when the rehash path was 4,000 elements long.
They can be great if done right in hardware (yes, I'd be Intel or AMD's
bestest friend if they put a general purpose CAM table in their
chipsets, and especially for a TCAM). There were some great debates a
few years ago about syn-flood handling that directly apply here; they
culminated in the ideas of random early drop and syn cookies. A LRU
replacement policy gives the worst behavior since an attacker can flood
your state table with new connections and all of the previous valid
connections will be discarded. For beefy state size to bandwidth
numbers, it takes less than 10% of the bandwith to DoS the state table.
To be honest, there is only one problem with timing out states too late.
You risk running out of memory.
The way we solved this at NFR is to never expire idle TCP states. If we
have the memory to hold fifty bazillion states in a red-black tree, then
we'll hold onto fifty bazillion states even though they have been idle
for months. Then when we run out of memory, we'll pressure the TCP
state table to throw away some connections. It makes it much harder for
an attacker evade the IDS with attacks against the state table when he
doesn't know how much he has to send and can't predict what will get
thrown away.
In the OpenBSD's PF firewall we solved it a different way. The timeout
expiration values can adapt to how full the state table is. The closer
the state table is to being full, the quicker states will expire. And
the timeouts are heavily skewed in favor of fully established
connections. For example the timeout for the SYN|ACK may have been
reduced all the way down to one second but the idle timeout for a fully
established session will only be down to about 45 minutes.
3) you lose the TCP window scale value
4) the connection will break if you only allow state creation on a SYN
5) any sequence number modulation will break the connection
6) any TCP timestamp modulation will probably break the connection
Are these not issues arising from the use of a half-hearted attempt at
TCP tracking, as opposed to a lack thereof in toto?
#3 is necessary to do any sequence number tracking. Which you need to
do in order to safely deal with ICMP error messages that correspond to a
TCP connection. There was an RFC about the security affects of these on
Aug 4th or 6th.
#4 ya, that one is for half-hearted TCP tracking. But it is necessary
for little things like NAT.
5 and 6 are enforcing basic TCP security for host TCP stacks which don't
do it good enough. Michal Zalewski has a few great papers out on how
bad most peoples' TCP initial sequence number generation is.
.mike
frantzen@(nfr.com | cvs.openbsd.org | w4g.org)
PGP: CC A4 E2 E8 0C F8 42 F0 BC 26 85 5B 6F 9E ED 28
