欢迎关注:1，欢迎关注本博客，你可点击右手边的【QQ邮件订阅】订阅本博客！2，本博客推出江湖救急计划，主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析，如有需要，请在江湖救急计划页面给我留言！

ACK flood攻击的影响

作者：易隐者 发布于：2012-10-8 10:14 Monday 分类：网络安全

       我们在分析ACK flood攻击对端系统和中间系统的影响之前，首先需要了解端系统和中间系统一般情况下是如何处理其收到的ACK报文。

端系统对ACK flood报文的处理

       端系统在收到一个ACK报文时，如果目的端口未开放，那么端系统会直接向源IP发送RST报文，其交互过程大致如下图所示： 

点击查看原图

       如果端系统的相关端口是对外开放的，那么其在收到ACK报文时，首先会检查这个ACK报文是否属于TCP连接表中的一个已有连接（这个过程会对端系统主机CPU资源造成一定的消耗），如果是的话，则正常处理，如果不属于任何一个已有连接，那么端系统会向源IP发送RST报文，交互过程如下图所示： 

点击查看原图

       根据上面两个过程的分析，我们可推论ACK flood攻击对端系统性能的影响并不会非常大，至少跟SYN flood（端系统需要给每个SYN报文分配相应连接表空间，会消耗端系统内存资源）攻击相比，其攻击效果似乎难上台面。

中间系统对ACK flood报文的处理

       路由器和防火墙的工作机制决定了路由器和防火墙在处理ACK报文的时候是完全不同的，我们分别将路由器与防火墙对ACK flood攻击的处理过程做简单描述。
       路由器是网络层的设备，其主要功能是选路和转发，其选路的依据大部分都是基于网络层信息（目的IP、源IP等），因此路由器在处理ACK报文的时候，其并不关心它是不是ACK报文，它主要关心其目的地址，需要根据其目的地址来进行选路，如果ACK flood攻击的目的主机都是固定的，那么路由器其实只需要在收到第一个ACK flood攻击报文时，调用CPU资源实现选路和转发，后续的ACK flood攻击报文由于目的主机是固定的，其甚至不需要调用CPU资源，直接使用快速转发表即可实现对ACK flood报文的转发，路由器对ACK报文的处理过程大致如下： 

点击查看原图

       防火墙对ACK报文的处理主要跟连接状态表有关，防火墙在收到ACK报文时，首先检查该ACK报文是否属于连接状态表中的已有连接，如果是，防火墙转发该ACK报文，如果未命中任何一个已有连接，防火墙会将该ACK报文丢弃，如下图所示： 

点击查看原图

ACK Flood攻击对系统的影响

       由此来看，ACK flood攻击对端系统与中间系统的影响相对于其他攻击来说都不是非常明显，至于网上有相关资料讲其需要配合SYN flood攻击产生较好的攻击效果，原因为针对防护SYN flood攻击的一种技术 ——SYN cookie技术。
       当某些启用SYN cookie技术进行SYN flood攻击防护的中间设备（专业抗DOS设备、防火墙、IPS、负载均衡、路由器等），在收到ACK报文时，需要计算cookie值，这个过程会消耗一部分中间设备的CPU资源，如果大量的ACK报文过来的话，很可能很快就会导致设备资源耗尽，达到拒绝服务的效果。

关于SYN cookie的工作机制，我在互联网上找到一篇文章，文章链接为：
http://blog.csdn.net/force_eagle/article/details/5348946，作者：droplet，现全文引用至此：

“

点击查看原图

Cookie如何计算？
cookie = MD5(srcip,dstip,sport,dport)
端口是否需要考虑哪？没有端口的话，可以少一点计算。
Syn-cookie是无状态的，在Gateway上，不会保存任何与connection相关的东西，所以不会占用gateway的资源，缺点就是需要计算cookie，CPU占用会高一点。
如果不考虑端口的话，cookie是不是可以cache哪，如果cache了，就有查找的开销，并不一定比MD5的hash快多少。
在Syn-cookie之前，先要检查一下srcip是不是spoofing的，这里需要做一个反向的路由查找，看看是不是从错误的接口进来的，也可以确认一下源地址是否可达。
是不是也应该做一个源端口的检查哪？如果是0~1024的端口，就默认是非法的，因为这些端口在操作系统里面，一般是保留的，不会分配给应用程序。
Syn attack是否有signatue? 不同的syn flood工具，生成的工具包，应该有一定的模式，如果能够找到这个signature，就可以通过signature来直接drop这个syn，不用再做syn-cookie的检查了。
Syn-cookie会strip掉client和server的tcp option，对client，可疑在cookie里面带上tcp option，但是对server来说，就比较难办一点。strip掉tcp option，对connection的性能有影响。
对syn-flood的防范，目前还是threshold based，因为不能区分正常包和攻击包，但是如果能够定义攻击的signature，就可以做signature based的防范，这样可以更有效一点。”

       在这里有个疑问，启用SYN cookie技术的中间设备在收到SYN报文的时候会建立cookie序列，在收到ACK报文的时候会计算cookie是否合法，那么是不是任何一个ACK报文都计算cookie值呢？从全文的描述来看，应该是在收到三次握手的最后一个ACK报文时才进行计算。
       如果是对所有ACK报文都进行cookie值计算，这个中间设备对SYN cookie技术的实现是不是非常不科学呢？如果仅针对三次握手时的第三个ACK报文进行cookie值计算，那么中间设备应该直接丢弃随机伪造的ACK flood攻击报文。如果是丢弃随机伪造的ACK flood报文，那么对中间设备资源的消耗也是有限的。

        需要申明的是，以上仅为我个人站在技术原理的角度作出的推论，实际环境下没有亲见ACK flood攻击带来的影响。欢迎各位兄弟姐妹一起做进一步的探讨。

阅读全文>>

标签: TCP RST 防火墙 ACK flood SYN flood 连接表 SYN cookie ACK报文 连接状态表

评论(1) 引用(0) 浏览(20591)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1