正常情况下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,这样的攻击就会一直存在。而且防止前提必须是“已经受到了攻击”之后,即只能医治,无法预防。

发表评论

电子邮件地址不会被公开。 必填项已用*标注