RockCloud-基石云安全-官方博客
检查连接状态层是第一步，不要先翻访问日志。当运维发现服务器响应变慢、连接数堆积但带宽和QPS都不高时，慢速CC攻击的判定入口必须从日志层换到连接状态层。这是因为攻击者在请求头或Body发完之前，Web服务器根本不会生成访问日志记录，基于QPS阈值的检测在此场景下整体失效。本文围绕怎么判断是不是慢速CC攻击，给出可直接执行的观测指标与场景化处置路径。
慢速CC为什么在access.log里查不到
慢速攻击的隐蔽性源于Web服务器的日志写入时机。以Slowloris为例，攻击者建立大量TCP连接后，周期性发送不完整的HTTP请求头并维持Keep-Alive，使连接长期存活但请求始终处于“未完成”状态。由于请求头未结束，Nginx或Apache不会触发日志记录动作，access.log自然看不到这些恶意请求。这直接解释了为什么“查CC就翻access.log找高频IP”是主流误区：慢速攻击的流量特征不在请求速率，而在连接占用时长。判定必须转向连接状态层，观察长期ESTABLISHED、未完成请求以及worker连接与文件描述符的增长曲线。
连接数堆积但带宽QPS不高先排掉哪些非攻击原因
在下判定前，需先排除业务自身或网络环境导致的连接堆积，避免误判。不同原因在连接分布上有可辨识差异：
| 非攻击原因 | 连接分布特征 | 辨识要点 |
|---|---|---|
| 应用连接池未释放 | 源IP集中在内网应用服务器 | 连接状态多为ESTABLISHED但Recv-Q/Send-Q为空 |
| 后端依赖响应变慢 | 连接等待集中在特定接口路径 | 数据库或第三方接口监控同步出现延迟 |
| Keep-Alive参数过长 | 空闲连接数高但无数据交换 | 连接超时后正常关闭，无持续数据写入 |
| 健康检查与爬虫长连接 | 源IP为固定监控或爬虫网段 | UA可识别，请求最终会完成 |
| 内网弱网客户端 | 连接建立慢但最终成功 | 仅影响特定办公网段，非公网分散IP |
若排除上述场景后连接仍持续堆积且无业务对应关系，才进入慢速CC判定流程。
判据一：ss -tan 里长期ESTABLISHED与未完成请求怎么读
使用 ss -tan 统计各状态连接数是核心观测动作。重点关注三个维度：按源IP聚合的ESTABLISHED数量、连接建立时长、Recv-Q/Send-Q队列分布。慢速CC的核心指纹是“连接长期存活但请求始终未完成”，表现为大量ESTABLISHED连接的Recv-Q持续有少量数据写入但无完整请求，Send-Q保持非零等待响应。需连续多次采样看趋势，单次快照可能受瞬时波动干扰。若发现少量IP撑起大量长期ESTABLISHED连接且队列数据缓慢增长，即指向慢速攻击。这一排查方法直接回应了 ss -tan 大量ESTABLISHED连接怎么排查 的实操疑问。
worker连接占用与文件描述符增长曲线
第二组判据聚焦进程资源消耗形态。Nginx的active connections与reading状态计数、Apache worker占用率、进程FD数量是核心指标。慢速攻击下，这些指标呈阶梯式持续上升且不回落，因为连接位被占死后不会主动释放；而正常业务峰值表现为随流量涨落的平滑曲线。若worker占用率持续接近上限但QPS无对应增长，说明线程被不完整请求阻塞。文件描述符增长若与ESTABLISHED连接数同步线性上升且无关闭事件，进一步佐证连接耗尽型攻击。需将资源曲线与连接状态采样时间对齐，避免将内存泄漏误判为攻击。
单IP连接数与请求头到达速率的分界
灰区处理是判定难点。真实弱网用户也会连接慢，但表现为连接数少、请求最终会完成、UA与路径分散；慢速攻击则是少量IP撑起大量并发连接，请求头以固定节律缓慢续写且始终不结束。区分维度包括：单IP连接数阈值（需结合业务基线）、请求头到达速率的规律性、连接存活时长分布。不要单凭连接数拉黑，需交叉验证请求是否最终完成。若连接在超时前始终无法完成请求且速率呈机械规律，攻击概率远高于弱网。
慢速CC、HTTP Flood、SYN Flood与连接池泄漏对照
| 攻击/故障类型 | 带宽 | QPS | 连接状态分布 | access.log可见性 | CPU/内存表现 | 恢复方式 |
|---|---|---|---|---|---|---|
| 慢速CC | 低 | 低 | 大量长期ESTABLISHED | 不可见 | 连接耗尽但CPU不高 | 收紧超时+边缘缓冲 |
| HTTP Flood | 中 | 高 | 正常ESTABLISHED+TIME_WAIT | 可见高频IP | CPU随QPS飙升 | 限流+验证码 |
| SYN Flood | 高 | 无 | 大量SYN_RECV | 不可见 | 内存耗尽 | 四层清洗 |
| 连接池泄漏 | 低 | 低 | 内网IP ESTABLISHED | 不可见 | 内存缓慢增长 | 重启应用 |
需注意指标组合的交叉验证：慢速CC与连接池泄漏在连接状态上相似，但源IP分布与请求完成度是区分关键；HTTP Flood与慢速CC的QPS差异是首要分流依据。
源站超时收紧与limit_req限流的延缓边界
源站侧处置只能延缓线程耗尽，无法根除攻击。收紧请求头/请求体读取超时、限制单IP并发连接、使用 ngx_http_limit_req_module 基于漏桶按 $binary_remote_addr 控制处理速率并配合burst/nodelay平滑合法突发，超限返回429或503，是标准手段。但这些措施的能力上限在于：攻击者仍可通过调整发送速率绕过超时，或通过分布式源IP规避单IP限流。真正的断点在于连接能否被完整缓冲后再回源，源站侧无法实现这一点。
按场景选做法：自建源站、动态API与已挂CDN
| 场景 | 优先动作 | 判定复核信号 | 持续观测指标 |
|---|---|---|---|
| 单机自建Nginx/Apache | 收紧超时+limit_req+单IP并发限制 | ESTABLISHED连接数下降 | worker占用率、FD数量 |
| 动态API业务 | 接口级限流+请求体大小限制+超时收紧 | 未完成请求队列清空 | 接口P99延迟、连接池使用率 |
| 已挂CDN仍被直连 | 源站IP白名单+防火墙限制+CDN回源鉴权 | 公网直连连接归零 | 源站入站连接数、CDN回源错误率 |
| 非HTTP自有协议 | 四层高防IP+协议合规校验 | 异常连接终止率上升 | 四层连接数、协议解析失败率 |
针对已挂CDN仍被直连的场景，需优先排查源站真实IP是否泄露，可参考 如何防止源站真实IP暴露 中的隐藏方案。对于WebSocket长连接业务，慢速攻击特征与HTTP不同，需结合 WebSocket长连接DDoS攻击防护方案 中的连接状态判据进行交叉验证。
常见问题
网站很卡但带宽和QPS都不高是什么原因
优先排查慢速连接耗尽。慢速CC攻击通过不完整请求霸占连接线程，导致带宽QPS低但连接数堆积。需检查ss -tan中长期ESTABLISHED连接与worker占用曲线，排除连接池泄漏与后端依赖慢响应后，若连接呈阶梯上升且不回落，基本可判定为慢速攻击。
access.log看不到请求但连接数很高怎么回事
这是慢速CC的典型特征。请求头未结束前Web服务器不写日志，导致access.log“隐身”。需转向连接状态层，用ss -tan统计ESTABLISHED连接时长与Recv-Q数据速率。若大量连接长期存活但请求未完成，且源IP分布异常，即可确认日志层检测失效。
ss -tan 大量ESTABLISHED连接怎么排查
连续采样3次以上，按源IP聚合统计连接数与建立时长。重点关注Recv-Q持续有数据但无完整请求、Send-Q非零等待响应的连接。区分弱网用户：攻击连接速率呈固定节律且始终不完成，弱网连接最终会成功。不要单凭连接数拉黑，需交叉验证请求完成度。
慢速CC攻击和HTTP Flood有什么区别
核心差异在请求完成度与日志可见性。HTTP Flood发送完整高频请求，QPS飙升且access.log可见；慢速CC发送不完整请求，QPS低且日志不可见。连接状态上，HTTP Flood正常ESTABLISHED+TIME_WAIT，慢速CC为长期ESTABLISHED+未完成队列。处置上，限流对HTTP Flood有效，对慢速CC需收紧超时+边缘缓冲。
高防CDN能防慢速CC攻击吗
能，但前提是请求在边缘被完整缓冲。慢速攻击的断点在于连接是否被完整缓冲后才回源，RockCloud 高防CDN 的边缘清洗层可将完整请求缓冲、连接终止与慢速回收前移，源站仅保留回源收口。但若源站仍开放公网端口，攻击者可绕过CDN直连，此时需配合 CDN安全加速 中的源站隐藏策略，否则边缘防护会被穿透。
建议先按文中的连接状态判据完成一次现场判定，确认是慢速连接耗尽后再决定处置层级；若源站超时与并发限制已收紧但连接仍被占满，可评估把请求缓冲与连接终止前移到边缘，并联系 RockCloud 技术支持核对回源收口配置。
评论(0)