正常情况下TCP/IP协议中SYN握手大致上如此：

正常情况下TCP/IP协议中SYN握手大致上如此：

1. A（发起者）发送一个SYN给B（接收者）
2. B回复SYN-ACK给A
3. A回复ACK给B
4. 连接成功！

这个过程的缺陷是，如果A是有恶意的来源，始终不停的发送SYN给B，那么B就会不停的建立起空连接（未完成的连接）等待A的ACK响应，只要A不回应，B的空连接就会不断的消耗资源，直至无法响应。

这个缺陷事实上不是操作系统级别、防火墙级别的缺陷，而是来自于TCP/IP协议本身的设计缺陷。

看了一下NetScreen的Screen安全策略中有针对它设计的SYN COOKIE设置。

个人理解下来这是一个很讨巧的方法，但是略显笨拙：

1. NS之外的A发送了一个SYN请求给内网的B
2. NS截获了这个请求，没有直接将数据包转发给B，而是自己生成了一个假冒的SYN_ACK包回复给A
3. A回复了ACK，成功完成握手
4. NS将之前的SYN请求发送给B
5. B发送SYN-ACK
6. NS回复ACK
7. NS搭建A到B的正式通道

这种方式类似于中间人的方式实现连接，一定程度上是可以保护B不受攻击的侵扰。但事实上如果这时的A有足够的资源，完全可以让NetScreen建立的空连接达到无法响应的程度，这样实现的效果反而远远大于直接对B发起的攻击。

对于类似的方法，Netscreen没有响应的设置，相应的文档上也没有给出解释。个人认为，NS应该是有一种判断机制，比如说时间或者频率。正常情况下是允许ACK回复延时的，但延时到了一定程度，或者这个来源不停的建立这种通信达到一个阀值，NS将会启动处理机制将A拉黑，同时关闭所有与A有关的连接。

总的来说，SYN-ACK-ACK攻击属于不对等攻击，与DDOS，泪滴等攻击一样，发起攻击的成本要远远低于预防攻击的成本，这是TCP/IP的缺陷，只要不放弃TCP/IP，这样的攻击就会一直存在。而且防止前提必须是“已经受到了攻击”之后，即只能医治，无法预防。