On Tue, 2005-01-18 at 18:37 +0000, nick black wrote:
- Should the three-way handshake complete, the IPS SNAT's a
connection to the original dest, claiming to be the source.
The server will respond; should it not, the IPS can attempt
to determine why, perhaps lowering RED/etc thresholds if the
server appears already overwhelmed. If the server does indeed
respond with a SYN-ACK, the IPS need merely apply a constant
delta to SN's in both directions.
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?
I'm guessing that if the real destination host doesn't respond, you're
simply resetting the TCP connection, but depending upon the protocol and
application, this could prove extremely confusing to pieces of software
coded with the assumption that (as per the way that TCP is supposed to
work) the successful negotiation of a three way handshake indicates that
the destination host is there. I can't think of any specific examples
(not that I'd have many to hand in any case - my coding of anything
involving sockets has been extremely sparse) of this breaking anything
in production, but it's quite possible that this could break
applications which rely on this assumption - causing erroneous results,
unnecessary allocation of resources, unpredictable error messages from
client software, etc.
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) which dictate
error codes; for a VPN client which thinks that it's established a
connection with a VPN server (but where the VPN server is in fact
unavailable), this could cause at least a little wasted time debugging
the connection (again, given the assumption that the VPN server is
responding and the connection isn't negotiating, rather than that the
whole server is unavailable). Executives get frustrated when they can't
access their e-mail from the airport lounge in their hour's layover when
they thought they'd be able to! ;)
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!
Slightly off-topic for the original poster, but I let my curiosity get
the better of me, and I'm always on the look out for people breaking
TCP/IP to lambaste (just kidding!) ;)
- 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.
--------------------------------------------------------------------------
