绕过防护的慢速连接怎么识别和处理，慢速攻击防御方法有哪些

慢速连接攻击属于典型的“低速率拒绝服务”手法，它绕过的不是应用防火墙，而是TCP协议栈的超时机制和并发连接上限，识别关键在于“合法请求，非法行为”，处理核心在于“资源隔离”和“层级限速”，而非单纯丢弃数据包。

慢速连接攻击是怎么绕过传统防护的

传统DDoS防护以流量清洗为主,判断依据是“短时间内的巨大流量”，但慢速连接攻击完全反着来它用极低的带宽，维持海量半开连接，把服务器的并发连接池慢慢占满，行业共识认为，这类攻击真正可怕的地方在于：中间设备（如负载均衡、WAF）默认信任完整的三次握手，而慢速连接是“握手后迟迟不发送数据”或“发送数据但极慢”，这让防护设备误认为是“正常用户网速慢”。

慢速连接攻击的伪装逻辑

攻击者把TCP窗口调小,以每秒几十比特的速率发送数据，让服务器以为对端只是“弱网用户”，但真实用户不会花十分钟发完一个HTTP头，这里给出几种具体场景：

• Slowloris：打开大量连接，每个连接只发一小部分HTTP头，然后间隔很长时间才补充下一个头字段
• Slow POST：在Content-Length里声明一个较大的请求体，但实际发送速度极慢
• 慢速读：服务器响应已经生成，攻击者却迟迟不读走数据，让服务器的发送缓冲区填满

业内专家指出,识别慢速连接的最佳维度不是“速率”而是“时间”，普通用户一个TCP连接的生命周期通常只有几秒到几十秒，但慢速连接可以把单个连接的有效数据吞吐压到每秒不足1个字节，同时把连接存活时间拉长到数小时之久。

慢速连接攻击怎么识别：从现象到本质

第一步：从服务器状态看异常特征

运行以下命令,观察系统层面的反常信号：

netstat -nt | grep -i 'tcp' | wc -l
netstat -nt | awk '{print $6}' | sort | uniq -c | sort -nr

如果出现SYN_RECV和ESTABLISHED的数量同时飙升，且SYN_RECV占比变大，说明有大量半连接涌入，再配合ss -s查看总的socket数量，如果远远超出日常基线，就有理由怀疑慢速连接。

从Nginx日志中抓取慢速连接特征

正常用户的访问日志会显示完整的响应码和字节数,慢速连接攻击的日志往往有这些特征：

• 大量请求的request_time超过120秒但没有正常结束
• status为499（客户端关闭）的记录占比异常偏高
• 同一个源IP出现大量“请求头不完整”的记录

在Nginx配置中开启慢速请求日志识别参数：

log_format slow '$remote_addr - $remote_user [$time_local] '
               '"$request" $status $body_bytes_sent '
               '$request_time $http_user_agent';
access_log logs/access.log slow if=$request_time > 30;

通过这个日志,你能直接筛出所有耗时超过30秒的请求。

第二步：用抓包确认攻击类型

系统日志只能负责报警,抓包才能定性，在服务器网卡上执行：

tcpdump -i eth0 -n port 80 -w slow.pcap &

然后用Wireshark打开抓包文件,重点看三个特征：

• TCP窗口值：攻击者的通告窗口往往只有几百字节，正常浏览器通常默认64KB
• 数据包间隔：同一连接上相邻数据包的到达时间间隔在数十秒甚至数分钟



• 请求头不完整：大量TCP流只有GET / HTTP/1.1加几个头部字段，后面就是漫长的停顿

抓包分析是判断“误伤”和“有意攻击”的裁决依据，有一种情况需要特别注意：某些物联网设备或老版本HTTP客户端也可能表现得很像慢速攻击，比如路由器固件的定时同步请求，此时要结合源IP的地理位置和“新建连接频率”来综合判断。

处理慢速连接攻击：四层拦截架构

处理策略必须分层,因为攻击者可能同时从多个维度开火，下面这四层方案是经过生产环境验证的组合拳。

第一层：系统内核参数调优

内核参数是防御慢速连接的地基,编辑/etc/sysctl.conf：

net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.ip_local_port_range = 1024 65535
net.netfilter.nf_conntrack_max = 1048576

然后执行sysctl -p生效。

这里的核心逻辑是缩短SYN确认的重试次数和降低TIME_WAIT的连接驻留时间，让系统能更快回收被占用的连接资源，但单靠内核参数并不能识别慢速连接，它解决的只是“清理”问题。

第二层：Nginx的慢速连接防护配置

Nginx是抵御慢速攻击的主战场,以下是关键配置区块：

http {
    client_body_timeout 10s;
    client_header_timeout 10s;
    send_timeout 10s;
    keepalive_timeout 15s;
    keepalive_requests 100;
    limit_conn_zone $binary_remote_addr zone=perip:10m;
    limit_conn perip 20;
    limit_req_zone $binary_remote_addr zone=reqlimit:10m rate=2r/s;
    limit_req zone=reqlimit burst=5 nodelay;
}

逐项拆解：

• client_body_timeout 10s表示Nginx在两次读取请求体之间的间隔超过10秒即断开连接，这对Slow POST攻击是致命打击
• client_header_timeout 10s确保请求头必须在10秒内送达完整，直接废掉Slowloris
• send_timeout 10s控制服务器发送响应数据的间隔上限，对慢速读攻击有效
• 双层限流确保单个IP在合理时间内最多建立20个并发连接,每秒最多发起2个请求

在server块里做精细管控

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://backend;
        proxy_connect_timeout 5s;
        proxy_read_timeout 10s;
        proxy_send_timeout 10s;
    }
}

反向代理场景下的超时参数更严格,因为Nginx代后端服务器承担了抵御风险的任务。

第三层：使用fail2ban做动态封禁

fail2ban是识别慢速连接后的第一道自动响应机制,安装后创建过滤规则：

[slowloris]
enabled = true
filter = slowloris
action = iptables-multiport[name=slowloris, port="80,443"]
logpath = /var/log/nginx/access.log
maxretry = 3
findtime = 60
bantime = 86400

创建过滤器文件/etc/fail2ban/filter.d/slowloris.conf：

[Definition]
failregex = ^<HOST> . "(GET|POST).request_time=([0-9]+.)?[0-9]+

这个方案的局限在于：fail2ban通过分析日志来行动，属于事后补救，真正的慢速连接攻击每分钟新增的连接数不高，日志量不大，fail2ban需要额外配置“要求下载间隔超过某阈值才触发”的规则。

第四层：云厂商高防IP的流量调度

如果攻击规模超出单机防御上限,就需要在DNS侧切换流量，将域名解析切换到高防IP后，在高防控制台手动配置“高级防护策略”，参考以下参数：

• TCP连接空闲超时：5秒
• HTTP头完整度校验：开启
• 请求速率限制：5次/秒/源IP
• 开启“源站保护”模式

高防IP能在攻击流量到达源站之前完成清洗,但代价是响应时间增加20至40毫秒（属正常范围）。

慢速连接攻击防护工具有哪些可以选

除了Nginx自家能力,第三方防护组件同样值得纳入防御体系。

常见开源工具对比如下：

HAProxy是值得重点关注的一个方案，它的优势在于连接管理与超时控制做得比Nginx更细，可以作为前置网关：

global
    maxconn 50000
    timeout connect 5s
    timeout client 10s
    timeout server 10s
    timeout http-request 10s
frontend http-in
    bind :80
    timeout client 5s
    backlog 4096
    capture request header Host len 32
    http-request track-sc0 src if { src_conn_rate(0) gt 10 }
    http-request deny if { src_conn_cur(0) gt 50 }

HAProxy能直接跟踪每个源IP的连接创建速率和当前并发连接数，一旦超过阈值立刻拒绝，比Nginx的limit_conn模块更加灵活。

慢速连接攻击的日常防御基线与误伤规避

慢速连接攻击不仅只有在攻击时才需要防御,设定好日常基线能大幅缩短“识别到处理”的时间。

建立源IP画像

• 维护内部白名单,办公网出口IP、内部监控系统、第三方支付回调IP免于限速
• 对来源IP建立独立画像,比如正常用户从同一IP建连的频率在每分钟3至10次之间
• 标记已知IDC机房的IP段,对来自云主机IP段的请求执行更严格的超时策略

区分“攻击误报”的常见场景

慢速连接防御最怕的就是误伤正常用户,以下几种情形容易导致误报：

• 弱网用户：移动信号不好的用户，TCP握手后可能确实需要几秒才能发送数据，但通常不会超过15秒
• 老年机/低端安卓设备：性能和内存有限，处理请求内容耗时较长
• 下载类用户：下载速度受限于带宽，服务器发出的数据TCP窗口长期为0
• WebSocket长连接：这是最容易误伤的场景，WebSocket设计上就要求长时间保持连接，并且连接上有长期空闲期

处理这种场景的方式是：仅对HTTP构造型的慢速连接做封禁，对建立了WebSocket升级成功的连接放行，在Nginx中通过map指令精准区分：

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}
# WebSocket连接不受慢速连接规则限制
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

周期性的防护演练

每季度做一次慢速连接模拟攻击测试,推荐使用开源压测工具slowloris.pl进行模拟：

perl slowloris.pl -dns example.com -port 80 -timeout 5 -num 1000

观察服务器可用连接数是否下降,如果模拟攻击期间Nginx的active connections数量超过正常值80%以上，说明防御参数有误，需要立即复盘调整。

慢速连接攻击怎么防御才算完整收尾

一次完整的防御收尾不只是封IP那么简单,攻击结束后需要做三件事：

第一,复盘Nginx访问日志，提取所有被拒绝的IP段和恶意特征，将特征固化到WAF规则中。

第二,检查Web服务的资源占用情况，慢速连接攻击虽然不消耗大量CPU，但会大量占用内存，攻击后如果系统内存使用率居高不下，需要重启Nginx以释放耗尽的连接池，常见操作：

nginx -s reload
# 或
systemctl restart nginx

第三,调整监控阈值，如果SYN_RECV数量的历史基线是“低于200”，而本次攻击峰值到了“2000”，建议将监控触发阈值设为“高于基线的5倍”，以避免频繁误报。

慢速连接攻击虽然伪装巧妙,但它的本质是“用时间换资源”，只要把你的超时控制参数和源IP画像建立起来，防护逻辑就会清晰很多，防御此类攻击的关键永远是：摸清正常行为基线，然后把异常拦截在执行层完成，这也是所有开源防护工具的共同设计哲学。

慢速DDoS攻击怎么防御才能不影响正常用户体验

慢速DDoS攻击与正常弱网用户之间没有明确边界,为了兼顾防护和体验，需要做到两点，第一，将超时参数设置在使用场景的“合理区间”而非理论最小值，例如同时在线人数较高的站点，client_header_timeout建议设置为15秒而不是5秒，第二，对首次触发限速规则的源IP先执行“延时响应”策略，即人工延迟100毫秒至500毫秒再回复，如果后续请求仍在阈值内则自动放行，通过这种“先警告后处罚”的渐进式策略，绝大多数正常访问不受影响，而攻击者会因为请求频繁失败而放弃攻击。

看服务器CPU占用率能发现慢速连接吗

慢速连接攻击基本不消耗CPU,这类攻击的特点是占满连接槽和文件描述符，而不是消耗计算资源，所以排查时看CPU占用率没有参考意义，重点关注内存占用和并发连接数，统计显示，相当一部分Web应用在慢速连接攻击期间的CPU占用率始终低于5%，但对外服务已经可用性为零，使用ss -s和free -m查看系统层面的连接数和内存消耗，才是快速定位慢速连接的正确路径。

慢速连接攻击的防护交给CDN能解决吗

CDN能在边缘节点拦截一部分慢速连接攻击,因为CDN的防护节点分布广泛，单个节点可承受的连接数远高于源站，但CDN处理慢速连接的能力存在明显短板：CDN的回源策略默认要求源站必须维持更长超时时间，如果攻击流量绕过了CDN节点直接命中源站IP，防护就形同虚设，更稳妥的做法是让源站只允许CDN回源IP段访问（防火墙加入白名单策略），同时源站自身的Nginx保留超时限制参数，形成越靠近源站阈值越严的双层防护结构，据国内一家中型云计算服务商公开的技术白皮书信息，采用该策略后源站遭遇慢速连接攻击时的存活时间从十几分钟提升到数小时以上，安全隐患得到有效控制。