IDS mailing list archives
Re: IDS: Snort detecting distributed syn floods
From: James Eaton-Lee <james.mailing () gmail com>
Date: Mon, 24 Jan 2005 17:53:00 +0000
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. --------------------------------------------------------------------------
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)