ACK Flood攻击是在TCP连接建立之后，所有的数据传输TCP报文都是带有ACK标志位的，主机在接收到一个带有ACK标志位的数据包的时候，需要检查该数据包所表示的连接四元组是否存在，如果存在则检查该数据包所表示的状态是否合法，然后再向应用层传递该数据包。如果在检查中发现该数据包不合法，例如该数据包所指向的目的端口在本机并未开放，则主机操作系统协议栈会回应RST包告诉对方此端口不存在。
这里，服务器要做两个动作：查表、回应ACK/RST.这种攻击方式显然没有SYN Flood给服务器带来的冲击大，因此攻击者一定要用大流量ACK小包冲击才会对服务器造成影响。按照我们对TCP协议的理解，随机源IP的ACK小包应该会被Server很快丢弃，因为在服务器的TCP堆栈中没有这些ACK包的状态信息。但是实际上通过测试，发现有一些TCP服务会对ACK Flood比较敏感，比如说JSP Server，在数量并不多的ACK小包的打击下，JSP Server就很难处理正常的连接请求。对于Apache或者IIS来说，10kpps的ACK Flood不构成危胁，但是更高数量的ACK Flood会造成服务器网卡中断频率过高，负载过重而停止响应。可以肯定的是，ACK Flood不但可以危害路由器等网络设备，而且对服务器上的应用有不小的影响。
抓包：
如果没有开放端口，服务器将直接丢弃，这将会耗费服务器的CPU资源。如果端口开放，服务器回应RST.
利用对称性判断来分析出是否有攻击存在。所谓对称型判断，就是收包异常大于发包，因为攻击者通常会采用大量ACK包，并且为了提高攻击速度，一般采用内容基本一致的小包发送。这可以作为判断是否发生ACK Flood的依据，但是目前已知情况来看，很少有单纯使用ACK Flood攻击，都会和其他攻击方法混合使用，因此，很容易产生误判。
一些防火墙应对的方法是：建立一个hash表，用来存放TCP连接“状态”，相对于主机的TCP stack实现来说，状态检查的过程相对简化。例如，不作sequence number的检查，不作包乱序的处理，只是统计一定时间内是否有ACK包在该“连接”(即四元组)上通过，从而“大致”确定该“连接”是否是“活动的
金盾防火墙在默认的设置下就能很有效的防御此类攻击，见下图：
金盾防火墙的“防护参数”面板，其中的“ACK保护触发”这个设置项就是专门针对此类攻击的防御设置，默认配置下就能很好的防御UDP Flood类型的攻击了。可以参考：金盾软件防火墙部分界面截图与功能介绍
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
优惠提前知
服务更全面
行业资讯通
新一代云安全引领者
闽公网安备 35020302000839号
公安机关联网备案号 35020301000110
潘成豪
13055239889