IDS mailing list archives
Re: IDS: Snort detecting distributed syn floods
From: Mike Frantzen <frantzen () nfr com>
Date: Mon, 24 Jan 2005 11:50:06 -0500
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. --------------------------------------------------------------------------
Current thread:
- IDS: Snort detecting distributed syn floods THolman (Jan 17)
- Re: IDS: Snort detecting distributed syn floods Tim (Jan 17)
- Re: IDS: Snort detecting distributed syn floods nick black (Jan 19)
- Re: IDS: Snort detecting distributed syn floods James Eaton-Lee (Jan 23)
- Re: IDS: Snort detecting distributed syn floods Mike Frantzen (Jan 24)
- Re: IDS: Snort detecting distributed syn floods James Eaton-Lee (Jan 24)
- Re: IDS: Snort detecting distributed syn floods James Eaton-Lee (Jan 24)
- Re: IDS: Snort detecting distributed syn floods nick black (Jan 19)
- Re: IDS: Snort detecting distributed syn floods Tim (Jan 17)
- <Possible follow-ups>
- RE: IDS: Snort detecting distributed syn floods THolman (Jan 20)