If I'm understanding you correctly, for a 'good' TCP connection (ie. an
actual connection rather than a (spoofed) SYN packet), your IPS
essentially establishes the three-way-handshake with the originating
host and sets up a connection *before* actually establishing this
three-way handshake with the *real* destination host. Purely out of
(academic) interest, have you considered the implications of this to the
client host, as this is a non-standard use of TCP/IP?
As a purely hypothetical example (which I do have a fair amount
experience with the underlying technology of), it's assumptions such as
the above (that the successful negotiation of a three-way handshake
indicates that the host I'm wanting to talk to is there)
That isn't a purely valid assumption. TCP allows for reliable data
transport between hosts. But it doesn't guarantee reliable transport
between applications. Just because a host has completed the 3whs does
not mean the application serving the port is alive (it could be swapped
out permanently, the listen backlog may be full, it might be in the
process of dumping core...)
When you do protocol design that uses TCP as a transport layer you have
to build in messages over the TCP to indicated "upness" or "message
received". e.g. just because the host ACKd the data does not mean the
actual application has processed it or will ever process it.
A trivial example - and one which would almost certainly be considered
by savvy IT staff at any site with an IPS of this type installed, but
still. I'm more interested if you've considered the issue than anything
else, as I'm sure it's quite possible that this could be a more serious
issue than a few hours of wasted support time in some instances!
The achilles heal of syn-proxying are the TCP options. When the
firewall/IPS doing the syn-proxying spoofs the SYN|ACK as if it came
from the server it can not predict the actual TCP options the real
server would use. There are hacks to cache and re-use the server's last
"Maximum Segment Size" option and to allow the timestamp option to work
(for round-trip time estimation). But there is no good way to get TCP
MD5 Signatures to work with a syn-proxy. Hint: that means BGP is pretty
much screwed unless you're willing to trust the syn-proxy with the key.
.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
--------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
--------------------------------------------------------------------------
