Re: IDS: Snort detecting distributed syn floods

• Previous message: Mike Frantzen: "Re: IDS: Snort detecting distributed syn floods"
• In reply to: Mike Frantzen: "Re: IDS: Snort detecting distributed syn floods"
• Next in thread: James Eaton-Lee: "Re: IDS: Snort detecting distributed syn floods"
• Reply: James Eaton-Lee: "Re: IDS: Snort detecting distributed syn floods"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: Mike Frantzen <frantzen@nfr.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.
--------------------------------------------------------------------------

• Previous message: Mike Frantzen: "Re: IDS: Snort detecting distributed syn floods"
• In reply to: Mike Frantzen: "Re: IDS: Snort detecting distributed syn floods"
• Next in thread: James Eaton-Lee: "Re: IDS: Snort detecting distributed syn floods"
• Reply: James Eaton-Lee: "Re: IDS: Snort detecting distributed syn floods"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]