On Mon, 2005-01-24 at 11:50 -0500, Mike Frantzen wrote:
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.
Yup - but at the same time, I find it highly unlikely that every
programmer has considered this in his or her use of TCP - part of my
reason for inquiring is that - in borderline cases like this where a
network appliance's behaviour isn't strictly 'correct' (or 'normal') -
coding which is a little sub-par can often fall down. I didn't mean to
imply that any mission-critical application which assumes 100%
reliability of TCP is coded based on a set of valid assumptions!
That said, as you're probably coming from a domain owned by a company
selling products which secure businesses, however technically correct
you are, if your technically correct product causes breakage because of
the shoddy (or borderline) coding of a business's software package, the
implementation of said technically correct product is still a bad move
for the business, no matter how good/well coded it is! 'Valid' and 'Good
for Business' (or 'Practical') are frequently quantified in very much
different ways, and can sometimes prove somewhat difficult to reconcile!
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.
Hadn't mentally approached the issue in quite that way; although I
suppose that this serves an excellent example to my point - although in
this case, the issues (MSS/MD5 sigs) are slightly different to the point
I'd raised (applications incorrectly assuming the up-ness of a
destination host based on the successful negotiation of the three-way
handshake), the basic principle is much the same.
- James.
--------------------------------------------------------------------------
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.
--------------------------------------------------------------------------
