Re: Firewall vs. IPS - Differences now (ISS, Intrushield 2.1?)

[Mike Frantzen <frantzen () nfr com>]

> On Aug 18, 2004, at 2:29 PM, Joel Snyder wrote:
> > To get into the firewall sweepstakes, you have to start with stateful 
> > packet inspection, not the weak crap you get for free in some freeware 
> > firewalls, but something that watches sequence numbers and the *full* 
> > TCP state machine, plus options, defragmentation, all that jazz.
> A genuine (non-rhetorical) question:
> Why do we think this is true?

This is going to be an extremely controversial answer that the security
purists probably will not like.  But they're fun to piss off so here goes.

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:
  1) it gets logged as a different connection
  2) it gets NATs to a different IP or port
  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
  
When you know what state a connection is in, you can statistically
determine the timeouts.  For instance almost all SYNs are followed by a
SYN|ACK within 120 seconds.  The SYN|ACK will be followed by an ACK
within 30 seconds....

> What are the security benefits of watching sequence numbers, the TCP 
> state machines, and options? (Sidenote: someone should do a quick study 
> to see how many "stateful firewalls" properly implement TCP PAWS --- 
> like every modern OS TCP stack does).

Lol.  Dug Song and his love of PAWS is rubbing off on you.

But ya, I implemented PAWS checks in OpenBSD's PF as an interaction
between the scrubber and the TCP state code.  Was able to use the
timestamp as an extension of the sequence numbers to make blind data
injection much harder.  We know that the TCP timestamp will be less than
the last value echoed by the other endhost (conventional PAWS).  But the
trick is that the RFC limits the timestamp clock to 1KHz max so we know
the timestamp will not have increased by more than 1,000 * idle seconds.

.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