Re: Post connection SYN

[Paul Robertson <proberts () patriot net>]

On Fri, 17 Oct 2003, Raghuveer wrote:

> Hi,
> I would like to know how SPI-firewall/IDS would handle the following
> scenario.
>
> Setup:
> A server, Public-Server1, is hosted behind a firewall/IDS capable of
> detecting post-connection SYN attack. A remote PC in the Internet,
> Remote-Client2, connects to Public-Server1 on TCP port 80 (and source port
> TCP1024).
>
> Details:
> Upon establishment of connection, Remote-Client2 gets rebooted without a
> normal shutdown and then starts a fresh connection to Public-Server1. This
> time it so happens that the new connection is generated with the same
> selector information (Src IP, DstIp, SPrt, Dprt & protocol). This
> connection request (SYNC) would be treated by the firewall device as post
> connection SYN attack and might drop the connection request. The client is
> not aware of this and keeps trying until the request times out.
> There are certain protocols that might work on fixed source & destination
> ports. In such cases, the chances of firewall/IDS detecting the connection
> request as post connection SYN could be quite high.
> How can SPI-firewalls/IDS in general handle such genuine scenarios at the
> same time avoid potential attacks?

Let me get this straight-

You're worried about a machine connecting to an HTTP server once, 
rebooting, then sending another single SYN packet to initiate a new 
connection?  That's not enough out of spec from non-persisitant HTTP to 
worry about other than the artificial constraint of having the PC use the 
exact same ephemeral port each time.  Finally, reboot times are long 
enough that protective devices shouldn't be tuned to accept a chain of 
events so fragile as that as malicious.  Anything which did would be 
setting itself up for a DoS attack rather easily.

Non-persistant HTTP generates a new SYN for each connection, and that's 
for every page, as well as every image and other MIME content on the page, 
the only difference being that the ephemeral port changes with each 
request.  I think it's difficult to manufacture a scenerio where that's an 
issue.  SYN attacks are _flood_ attacks, one extra SYN isn't "interesting" 
enough to trigger protection- often machines will send multiple SYNs if 
they don't get the SYN/ACK back quickly enough.  In the case of HTTP/1.0, 
every hit after the initial one is a post-connection SYN.  

Finally, any attacker silly enough to SYN after a connect deserves the 
tracking down that's going to happen.

Since SYN floods are flood attacks, protection against them really needs 
to have some rate-based measurement which should be adjustable (high 
volume sites can see rates which would be above normal, and low volume 
sites can get the same symptoms if they suddenly become high volume 
sites.)

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards