Re: Post connection SYN

[Raghuveer <raghub () intotoinc com>]

We have observed a few cases with PAC in PPTP running on top of security 
devices, using the same source port upon reboot. This causes Firewall to 
drop the connection request treating it as Post Connection SYN  attack.

Raghuveer.B


At 09:55 AM 10/17/2003 -0400, Paul Robertson wrote:
> 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