TCP standard says (rfc 793, pg# 65), in this case the ACK
attacker should see RST, and there should not be any resources held on
passive opener side. as there is no SYN, SYN/ACK exchanged prior to this
ACK, the TCB should be in CLOSED state.
IMO, SYN cookies is the best solution for dealing with SYN
flooding. i agree, we write off on some fancy options like time stamping
etc. check out ftp://koobera.math.uic.edu/www/syncookies/archive for
details.
- pravin
~~~
you can not step into the same river again!
> There is also a DoS exploit for Firewall-1 that has been recently
> brought to my attention (pardon me if it has been out for a while). The
> sending of packets with the ACK flag set, but without a preceding SYN.
>
> SYN's are usually now given a relatively low time-out to defend against
> SYN flooding, until the ACK is sent and the SYN/ACK is received. Then
> the ACK packets get a larger (3600?) timeout.
>
> The "ACK attack" has the same effect as SYN floods, but use ACKs
> instead.
>
> What we do to watch for this, is we set up rules that drop/deny/ignore
> any ACK packets from a session that has not sent a preceding SYN packet.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
