CC攻击利用慢速POST耗尽连接

CC攻击中的慢速POST耗尽连接，本质上是一种利用HTTP协议合法交互规则，通过极致拖延任务完成时间来压垮服务器连接池的精准打击。它不像洪水攻击那样依赖海量带宽，而是用极低的成本制造大量“悬而未决”的连接，让正常用户无法建立新的TCP握手。攻击者构造一个完整的HTTP POST请求头，声明一个很大的Content-Length值，随后以极慢的速度（例如每10秒甚至30秒发送一个字节）发送请求体。服务器的worker线程或进程被这些慢连接长期霸占，直到连接数上限被触及，服务彻底瘫痪。

要理解这种攻击为什么致命，需要先拆解Web服务器处理POST请求的工作模型。当客户端发起一个POST请求，服务器在读取完请求头后，会根据Content-Length分配一个接收缓冲区，并保持连接打开状态，等待剩余数据到达。在请求体完全接收之前，这个连接无法被释放，对应的线程或进程也无法处理其他请求。常见的服务器如Apache的prefork模式、Tomcat的线程池，都会为每个连接分配独立的计算资源。攻击者正是瞄准了这个“等待数据”的时间窗口。他们同时发起数千个慢速POST连接，每个连接都声明一个巨大的Content-Length，比如1024000字节，然后以每秒1字节的速度发送。这样一来，服务器的最大并发连接数很快就被这些僵尸连接填满，而攻击端只需要维持极低的发包速率，连家庭宽带都能轻松发起致命打击。

慢速POST攻击有多个变种，核心都是拖延HTTP请求的完成时间。第一种是经典的慢速发送请求体，攻击者使用定制脚本，在发送完请求头后，通过sleep函数控制每个数据包的发送间隔。第二种是慢速HTTP头攻击，虽然不直接属于POST攻击，但常与慢速POST组合使用，攻击者在发送请求头时故意不发送结束标志（两个连续的CRLF），每隔一段时间发送一个无意义的Header行，让服务器一直等待头部结束。第三种是分块传输编码的滥用，攻击者在请求头中声明Transfer-Encoding: chunked，然后以极慢的速度发送每个chunk，或者发送一个巨大的chunk大小声明但缓慢发送数据。更隐蔽的做法是随机化发送间隔，让基于固定超时阈值的防护策略难以命中。攻击工具也从早期的Slowloris演化出了更复杂的定制化脚本，能够模拟真实浏览器的TLS指纹和HTTP头顺序，让简单的特征检测失效。

识别慢速POST攻击不能仅靠日志分析，因为请求本身是合法的，日志中只会显示大量状态码为200但传输时间极长的POST请求。关键指标在于连接持续时间与数据传输速率的比值。一个正常用户上传数据，即使网络状况不佳，数据传输速率也会有自然的波动，但整体会在合理范围内。而慢速POST攻击的连接，其数据传输速率会呈现极低且稳定的特征，例如长时间维持在每秒几个字节。你可以通过分析TCP连接的状态来发现异常，在Linux服务器上使用ss -tan命令查看ESTABLISHED状态的连接，重点关注Recv-Q列不为零且长时间不变的连接。另一个关键指标是服务器的连接数使用率，如果并发连接数突然飙升并长时间维持在最大值附近，而请求量并没有显著增加，几乎可以确定遭遇了慢速连接耗尽攻击。Nginx和Apache的status模块能提供实时的连接状态数据，结合自定义脚本监控每分钟的新增连接数和平均连接持续时间，能有效发现攻击苗头。

防御慢速POST攻击的第一道防线在Web服务器本身。对于Nginx，需要精细调整几个核心参数。client_body_timeout指令控制读取请求体的超时时间，默认60秒，建议根据业务实际情况调整为10到15秒。client_header_timeout控制读取请求头的超时，同样应该收紧。更重要的是client_max_body_size，虽然它控制的是请求体大小上限，但配合client_body_timeout使用，可以防止攻击者声明巨大Content-Length后缓慢发送。一个典型的Nginx防御配置如下：

http {
    client_body_timeout 10s;
    client_header_timeout 10s;
    client_max_body_size 10m;
    keepalive_timeout 30s;
    send_timeout 10s;
    
    # 限制每个IP的并发连接数
    limit_conn_zone $binary_remote_addr zone=perip:10m;
    limit_conn perip 20;
    
    # 限制请求速率
    limit_req_zone $binary_remote_addr zone=reqlimit:10m rate=30r/s;
    limit_req zone=reqlimit burst=20 nodelay;
}

对于Apache，需要启用mod_reqtimeout模块并配置合理的超时参数。在Apache 2.4版本中，RequestReadTimeout指令可以分别设置请求头和请求体的超时时间：

    RequestReadTimeout header=10-20,MinRate=500 body=15-30,MinRate=500

这个配置表示请求头必须在10到20秒内接收完毕，且最低速率不低于500字节每秒；请求体必须在15到30秒内接收完毕，同样有最低速率限制。如果客户端发送数据的速度低于这个阈值，连接会被强制关闭。对于IIS服务器，可以通过高级设置中的connectionTimeout和headerWaitTimeout参数来控制，但粒度不如Nginx和Apache灵活，通常建议在IIS前端部署反向代理来增强防护能力。

Web服务器层面的防护需要操作系统内核参数的配合才能发挥最大效果。Linux内核的TCP协议栈提供了多个对抗慢速连接的关键参数。net.ipv4.tcp_syn_retries控制SYN重试次数，降低这个值可以减少半连接攻击的持续时间。net.core.netdev_max_backlog和net.core.somaxconn分别控制网卡接收队列和监听队列的最大长度，适当增大这些值能提升突发连接的容纳能力。但对抗慢速POST攻击最直接的内核参数是net.ipv4.tcp_keepalive_time、net.ipv4.tcp_keepalive_intvl和net.ipv4.tcp_keepalive_probes。通过缩短TCP keepalive探测的发起时间和间隔，服务器可以更快地发现并清理僵死连接：

net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 3

这样配置后，一个无响应的连接最多在600+15*3=645秒后就会被系统清理。对于更激进的防护需求，可以将tcp_keepalive_time进一步缩短到120秒甚至更低。需要注意的是，过于激进的keepalive设置可能导致移动网络或卫星链路等长延迟环境下的正常用户被误断，需要在安全性和可用性之间找到平衡点。

将反向代理层作为防护屏障，是目前最有效的慢速POST攻击防御手段之一。HAProxy和Nginx作为反向代理时，可以承担请求缓冲的角色。反向代理先完整接收客户端的请求体，然后再转发给后端服务器。这样一来，后端服务器接收到的都是已经完整缓冲的请求，慢速客户端无法直接占用后端连接。HAProxy的配置中，timeout client和timeout server分别控制客户端侧和服务器侧的超时，通过设置较短的timeout client，可以快速断开慢速连接：

frontend web_front
    bind *:80
    mode http
    timeout client 10s
    timeout server 30s
    default_backend web_back

backend web_back
    mode http
    balance roundrobin
    timeout connect 5s
    timeout server 30s
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check

云服务商提供的负载均衡器通常也具备连接清洗能力，它们会在前端维持大量连接，只将完整的请求转发到源站。如果你的业务部署在云上，开启负载均衡器的连接保护功能是最省心的方案。对于自建机房，使用LVS的DR模式配合Nginx反向代理，可以构建多层缓冲体系，LVS在四层快速转发，Nginx在七层做请求缓冲和过滤，形成立体的慢速连接防护架构。

即使有完善的服务器和网络层防护，应用层代码也需要具备防御意识。很多开发者习惯在POST接口中直接读取整个请求体，然后进行业务处理，这恰好给了慢速POST攻击可乘之机。正确的做法是在应用框架层面设置请求体读取的超时时间。以PHP为例，可以在php.ini中设置max_input_time，限制脚本解析输入数据的最长时间。对于Java的Spring Boot应用，可以通过server.tomcat.connection-timeout参数设置连接超时，同时利用Filter或Interceptor在请求进入Controller之前检查请求体的接收状态。更彻底的方案是实现请求体的异步读取，使用非阻塞I/O在读取数据的同时设置定时器，一旦超时立即中断连接并释放线程资源。对于文件上传等必须接收大量数据的场景，应该实现上传进度的监控，如果发现上传速率异常低，主动拒绝该请求并记录来源IP。

当攻击规模超出单机防护能力时，需要引入流量清洗机制。专业的抗DDoS设备或高防IP服务能够在网络边缘识别并拦截慢速连接攻击。这些设备通常采用行为分析算法，通过机器学习模型判断一个连接的传输模式是否异常。它们会综合评估连接的持续时间、平均传输速率、速率波动幅度、请求头特征等多个维度，对慢速POST攻击的识别准确率远高于简单的阈值判断。在自建防御体系中，可以结合iptables的recent模块和自定义脚本实现简易的自动化封禁。当监控脚本发现某个IP的慢速连接数超过阈值时，自动将该IP加入iptables的DROP规则：

# 监控脚本示例逻辑
# 使用ss和awk统计每个IP的ESTAB连接数
ss -tan state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | while read count ip; do
    if [ $count -gt 30 ]; then
        iptables -A INPUT -s $ip -j DROP
        echo "$(date) Blocked $ip with $count connections" >> /var/log/slowpost.log
    fi
done

这种脚本可以通过crontab定期执行，配合iptables的规则过期机制，实现动态的临时封禁。更成熟的方案是集成Fail2ban，编写自定义的filter规则来解析慢速POST的特征日志，实现自动化的检测和封禁循环。

慢速POST攻击发生时，最明显的现象是网站访问变慢或完全无法打开，但服务器CPU和内存使用率可能并不高。这是因为资源耗尽发生在连接层面而非计算层面。因此，监控体系必须覆盖连接层面的指标。关键监控项包括：服务器的并发连接数及变化趋势、连接持续时间分布、每个IP的连接数Top排行、Nginx或Apache的活跃连接与等待连接比例。Prometheus配合Node Exporter和Nginx Exporter可以构建完善的连接监控体系。当检测到连接数异常飙升时，应急响应流程的第一步是在负载均衡或反向代理层开启严格的超时策略，必要时临时降低client_body_timeout到5秒甚至更低。第二步是分析访问日志，提取攻击来源IP的特征，在防火墙上进行封禁。第三步是检查后端服务器的连接池状态，重启被耗尽连接的服务进程。整个响应过程应该提前制定SOP文档，并通过定期演练确保团队能在5分钟内完成初步遏制。

慢速POST攻击的防御是一个纵深防御体系，没有任何单一措施能够完全杜绝这种攻击。最有效的策略是从网络层到应用层构建多层防线：在边缘网络部署流量清洗或高防服务，在反向代理层设置严格的客户端超时和请求缓冲，在Web服务器层配置合理的超时参数和并发限制，在操作系统层启用TCP keepalive并调优内核参数，在应用层实现请求读取的超时控制和速率监测。每一层都能拦截一部分攻击，多层叠加后可以大幅降低攻击成功的概率。对于大多数业务来说，投入产出比最高的方案是使用Nginx作为反向代理，配置10秒左右的client_body_timeout，同时开启limit_conn和limit_req模块进行并发和速率限制。这套组合拳能够抵御绝大多数中低强度的慢速POST攻击，且几乎不需要额外的硬件投入。