ACK Flood攻击特征分析与防御策略：识别与应对

做ACK Flood攻击特征分析与防御策略，第一步就是认准这组指纹：入方向带宽不高、CPU与会话表先打满、出方向RST暴涨。它不靠大流量堵塞线路，而是靠伪造大量未建连的ACK报文，迫使接收端反复遍历会话表、回送RST，把算力和出方向链路耗干。IETF RFC 4732对其机理有明确描述，AWS的DDoS弹性架构规范也给出了标准解法。

先分流：带宽不高却卡死，是ACK Flood、SYN Flood还是连接池泄漏

面对“服务器卡死但带宽不高”，先别急着下结论，用三组现象快速分流：

• 入方向带宽：ACK Flood通常平缓或偏低，SYN Flood也可能不高，但半连接队列会先满；
• 半连接队列：SYN Flood时明显堆积，ACK Flood不占半连接队列；对SYN Flood的防御可参考SYN Flood防御；
• 业务连接数曲线：连接池泄漏时已建连接数单调增长，攻击时则伴随大量未建连报文产生的RST回送。

结论：ACK Flood的核心特征不是带宽飙高，而是CPU和会话表先被打满，同时出方向RST速率异常。

攻击机理：伪造未建连的ACK为什么消耗的是CPU和出方向带宽

按照RFC 4732的定义，ACK Flood属于“状态检索消耗型”攻击。接收端收到ACK报文后，必须在连接跟踪表中检索该报文是否属于已建连接，未命中则回送RST。攻击者不断发送伪造ACK，让接收端持续做无效检索，消耗的是CPU算力与出方向带宽，而非入方向带宽。理解这一点，就能解释为什么入方向带宽不高、但服务器却已经动弹不得。

判据一：怎么抓包判断是不是ACK Flood（标志位、序号与源IP分散度）

抓包是判断ACK Flood最直接的手段。在服务器或防火墙的入方向抓包，重点看三个特征：

1. 标志位：大量纯ACK置位且无对应SYN前序；
2. 序号：报文序号与本地已建会话无法对应；
3. 源IP分散度：源IP高度分散，且每个源的发包量不大。

注意，单一指标不足以定论，要组合判断。比如业务正常时也会有空ACK，但不可能同时满足“无SYN前序”和“源IP高度分散”。

判据二：会话表增长曲线与检索开销怎么观测

在服务器与防火墙两侧分别观察连接跟踪表条目数。正常业务下，条目数随连接创建销毁呈自然波动；攻击时，新条目涌入但大多无法建立完整连接，表条目被无效项占据，检索命中率下降，内核软中断占比抬头。

观察思路：对比攻击前后“会话表条目数 / 检索命中率 / 软中断占比”三项基线。如果条目数快速攀升而命中率下降，同时软中断占比升高，通常是ACK Flood在消耗状态检索资源。

判据三：出方向RST速率与网卡PPS是否先于带宽打满

ACK Flood导致的回送RST会在出方向形成明显脉冲。监视项应聚焦“PPS”和“RST速率”，而不是Mbps。

建议以自身业务基线为准设定倍数型告警（如显著高于历史峰值并持续数分钟），不要照搬固定绝对值。绝对值意义不大，因为不同服务器的网卡和CPU性能差异很大。

有状态防火墙能防住ACK Flood吗：为什么它反而先成为瓶颈

回到ACK Flood攻击特征分析与防御策略这条主线，有状态防火墙的位置需要重新评估。有状态防火墙的强项是跟踪连接状态，但代价是每个报文都要做状态查找。ACK Flood正好命中这条最贵的路径——攻击不断制造未命中的查找，让防火墙的CPU先于业务耗尽。

更关键的是，当攻击包数打满网卡PPS或上联链路时，单机和单点设备都无法阻止上游拥塞。也就是说，有状态防火墙在某些场景下不仅防不住，反而成为第一个倒下的节点。

源站侧能做的三件事与它们的上限

在源站本地，有一些临时缓解手段：

这些动作只能争取时间，不能免疫。真正要解决的是把状态检索的压力从源站剥离。

把TCP终止与状态维护前移到边缘的分工方式

AWS官方白皮书给的架构是：由Anycast边缘承接TCP握手与TLS终止，再用SYN Proxy/Cookies这类无状态校验拦截未建连报文，源站安全组只放行边缘回源IP白名单。这样，ACK Flood在边缘就被识别并丢弃，源站CPU不再被迫做无效检索。同时，回源白名单收敛实现了源站隐藏——这一步至关重要：如果源站IP已泄露，攻击者可以直接绕过防御打源站，如何防止源站真实IP暴露 需要作为前置工作处理。

这项分工的本质，是把TCP终止和状态维护从源站转移到更靠近攻击者的边缘，让状态检索发生在“无状态校验”的廉价路径上。

RockCloud在边缘承载与源站回源收敛环节的落位

在上述架构中，RockCloud高防CDN搭配Anycast全球网络，承担边缘TCP连接承接与状态维护的角色。源站侧只需配合开放回源IP白名单，不直接暴露公网IP。该分工方式遵循的是与AWS白皮书相同的架构思路，具体能力边界以官方说明为准。

ACK Flood排查清单（可直接照做）

下面把前文的ACK Flood攻击特征分析与防御策略压缩成一份可照做的清单。顺序执行以下步骤，快速定位问题：

1. [ ] 对比入方向带宽与PPS：带宽正常但PPS接近网卡上限，优先怀疑ACK Flood；
2. [ ] 抓包看标志位与序号：纯ACK置位且无SYN前序，源IP高度分散；
3. [ ] 查会话表条目与命中率：条目数飙升但命中率下降；
4. [ ] 看出方向RST速率：是否异常暴涨；
5. [ ] 确认源站IP是否已泄露：若泄露，先做隐藏；
6. [ ] 核对回源白名单是否闭环：安全组是否只放行边缘回源IP。

如果按以上步骤确认是ACK Flood，且源站IP已泄露，建议参考DDoS应急响应先做止血，再评估是否把TCP终止前移到边缘。

常见问题

ack flood和syn flood有什么区别？

SYN Flood利用半连接队列，发送大量SYN不完成握手，耗尽半连接资源；ACK Flood发送伪造ACK，迫使接收端遍历会话表并回送RST，消耗CPU与出方向带宽。前者占内存与半连接数，后者占检索算力与出方向链路。延伸阅读可参考SYN Flood防御。

服务器cpu跑满但带宽不高是被攻击了吗？

不一定，但优先级很高。CPU跑满而带宽不高，除了ACK Flood，也可能是应用层CC攻击、数据库慢查询或业务逻辑死循环。建议结合抓包、会话表、出方向RST三项指标判断，不要只凭CPU现象下结论。

防火墙会话表被打满怎么办？

先临时调大连接跟踪表容量和超时时间，同时开启未用端口丢弃策略。但根本解法是把TCP终止前移到边缘，让源站和有状态防火墙不必承担未建连报文的检索压力，否则单机调优只是缓兵之计。

有状态防火墙能防住ack flood吗？

不能完全防住。有状态防火墙为了维护连接状态，每个报文都要做状态查找，ACK Flood正好消耗这条最贵的路径。当攻击包数打满网卡PPS或上联链路时，单机设备无法阻止上游拥塞。建议采用边缘无状态校验加源站回源白名单的架构。

大量RST包发出去是什么原因？

最常见的原因是接收端收到了未建连的TCP报文（如ACK Flood），按协议回送RST。也可能是本地连接跟踪表溢出，导致正常报文被判为未命中。如果RST速率异常高且伴随CPU高、入方向带宽不高，基本可判定为ACK Flood。