慢速攻击检测模型要把连接时长和速率放在同一张特征表里联合判断，单看QPS或单看连接数都容易漏；用“长连接+低速率+请求间隔异常”做连接画像，再让规则兜底、模型打分，落地更稳。
慢速攻击为什么不能只看请求速率
慢速攻击的麻烦在于“看起来不忙”，连接建起来了，请求也发了，但发送速度极慢，传统阈值盯着每秒请求数、带宽峰值，往往等不到明显流量洪峰，等业务侧感觉到卡顿，连接池可能已经被占住。
慢速攻击的“慢”藏在哪里
常见形态包括慢速请求头、慢速请求体、慢速读响应，攻击端保持连接不断开，用很小的发送速率拖住服务端工作线程或连接资源，据工信部公开的网络安全态势信息，慢速连接类攻击在部分行业事件中反复出现，防护难点集中在连接生命周期，而不是瞬时流量峰值。
连接时长与速率分别暴露什么信号
连接时长看的是连接活了多久、空闲多久、请求之间隔多久。请求速率看的是单位时间内的请求数、字节数、完成请求比例，两者单独看都有盲区：
- 只有长连接：视频、WebSocket、长轮询也会长连接，不能一刀切。
- 只有低速率：正常用户读页面也可能低速率，误报压力大。
- 长连接叠加低速率、请求间隔忽长忽短、未完成请求偏多，才更像慢速攻击。
联合检测的逻辑：长连接不等于攻击，低速率也不等于安全
模型侧要把连接按源IP、目的端口、URL、User-Agent等维度聚合，每个连接窗口内计算一组特征：平均连接时长、连接时长方差、平均请求间隔、请求间隔方差、每秒新建连接数、每秒请求数、平均响应字节、未完成请求占比，规则引擎先筛掉明显异常，模型再对灰区连接打分，这样比单阈值更稳。
连接时长与速率联合检测慢速攻击方案对比
规则引擎：上线快，适合兜底
规则思路直接：连接时长超过业务基线、请求速率低于基线、并发连接数偏高、请求头迟迟不完整，就告警或限速，优点是可解释、响应快，缺点是阈值需要按业务调，遇到大文件上传、长轮询容易误伤，业内专家指出，慢速攻击检测的第一道防线通常不是复杂模型，而是能快速执行的连接级规则。
统计基线：成本低，但要冷启动
按业务历史数据算P95、P99连接时长和请求速率，用偏离程度打分，适合日志已经集中化的团队，难点是冷启动和节假日波动，可以先按URL分组做基线，再逐步加入源IP画像。
机器学习：适合复杂业务，维护要跟上
孤立森林、LOF、时序聚类都可以用，但输入特征要包含连接时长和速率，模型输出异常分，不直接阻断，先进入观察名单，维护成本主要在特征回填、误报标注和模型更新。
| 方案 | 上线速度 | 误报控制 | 维护成本 | 适合场景 |
|---|---|---|---|---|
| 规则引擎 | 快 | 依赖阈值调优 | 低 | 中小站点、应急兜底 |
| 统计基线 | 中等 | 中等 | 中等 | 日志集中、业务波动有规律 |
| 机器学习 | 偏慢 | 较好但需标注 | 高 | 多业务线、复杂连接行为 |
联合方案更实际：规则负责快，统计基线负责稳，模型负责灰区。
慢速攻击检测模型怎么结合连接时长与速率
采集字段：连接级与请求级都要有
Nginx侧建议日志格式包含$remote_addr、$request_time、$upstream_response_time、$connection、$connection_requests、$http_user_agent、$request_uri，系统侧用ss和netstat补连接状态，示例：
ss -tan state established '( sport = :80 or sport = :443 )'
ss -tani | awk '{print $1,$2,$5}'
netstat -anp | grep ':443' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
日志落到ClickHouse或Kafka后,按分钟窗口聚合，连接级字段看存活时长，请求级字段看速率。
算特征：先把连接画像做出来
可按源IP+目的端口做5分钟滑动窗口，计算：
- 连接时长均值与方差
- 请求间隔均值与方差
- 每秒新建连接数
- 每秒请求数
- 未完成请求占比
- 平均响应字节
伪SQL思路：
SELECT remote_addr,
avg(request_time) AS avg_rt,
stddevPop(request_time) AS rt_std,
count() / 300 AS req_rate,
avgIf(1, upstream_response_time = 0) AS unfinished_ratio
FROM nginx_log
WHERE ts > now() - INTERVAL 5 MINUTE
GROUP BY remote_addr
HAVING avg_rt > 30 AND req_rate < 2
这里阈值只是示例,实际要按业务P95基线调。连接时长明显偏高、请求速率明显偏低、请求间隔方差偏大，三条同时出现时优先级最高。
模型判定：规则兜底+模型打分
规则层先处理明确异常：请求头超时、连接数超限、未完成请求比例持续偏高，模型层用联合特征输出0到100分，超过70进入观察，超过90触发限速或挑战，响应动作分层：
- 观察模式：只记录，不阻断。
- 限速模式：按源IP限制并发连接和请求速率。
- 挑战模式：对可疑源弹验证码或要求重试。
- 阻断模式：联动WAF或防火墙封禁。
Nginx可先加client_header_timeout 10s; client_body_timeout 10s; keepalive_timeout 30s;，再用limit_conn_zone和limit_req_zone限制单IP连接与速率，上线前用灰度流量验证误报。
响应动作要分层
不要一上来就封IP,慢速攻击的源IP可能来自代理池，误封会伤正常用户，先告警、再限速、最后阻断，对API、上传、长轮询、WebSocket单独建白名单，模型分数只作为辅助，最终动作由规则和业务标签共同决定。
电商网站慢速攻击检测部署场景怎么落地
网关层先挡，源站层补刀
电商大促时,网关层先做连接数限制、请求头超时、最小速率限制，源站层用日志和模型补查慢速连接，商品详情页、购物车、下单接口分开建基线，避免用同一套阈值。
误报压制靠业务白名单
把长轮询、WebSocket、大文件上传、监控探针、合作方IP段加入白名单，白名单不是永久放行，而是单独建检测策略，业务标签要跟URL和User-Agent关联，避免误伤移动端弱网用户。
灰度上线与回滚路径
先在观察模式跑一段时间,对比告警量和业务投诉，确认误报可接受后，切限速模式，配置版本化管理，保留一键回滚，灰度期间重点看下单转化和接口成功率，别只盯安全告警数。
慢速攻击检测系统多少钱才合理
成本构成拆开看
成本主要在采集节点、日志存储、检测规则与模型开发、告警响应人力，日志量越大、保留时间越长，存储成本越高，模型越复杂，标注和调优人力越多。慢速攻击检测系统多少钱没有统一报价，通常由节点数、日志量、检测复杂度和服务响应级别决定。
自建和采购怎么选
小团队可以先用Nginx日志+ClickHouse+规则脚本起步，成本集中在人力，中大型团队若多业务线、多地域，采购成熟系统更省维护，选型时先做POC：用历史慢速攻击样本回放，看漏报和误报，再看响应动作是否支持灰度。
北京慢速攻击检测模型服务商怎么选
在北京选型时,优先看本地化响应、私有化部署能力、是否支持连接级特征采集、能否对接现有WAF和日志平台，行业共识认为，慢速攻击检测效果不只取决于模型算法，还取决于数据采集粒度和业务白名单维护，要求服务商提供可验证的POC方案，不接受只看演示大屏。
慢速攻击检测模型结合连接时长与速率常见问题
慢速攻击检测模型一定要用机器学习吗？
不一定,规则加统计基线能覆盖多数常见慢速攻击，机器学习适合连接行为复杂、误报压力大的场景，前提是特征采集到位，尤其是连接时长、请求间隔和未完成请求比例。
连接时长阈值设多长比较合适？
没有万能值,先按业务P95连接时长做基线，把显著超过基线且请求速率偏低的连接筛出来，长轮询、WebSocket、上传接口单独设策略，不要和普通页面共用阈值。
慢速攻击检测系统多少钱，小团队能自建吗？
小团队可以用Nginx日志、ClickHouse和规则脚本先做观察模式，成本主要是服务器和人力，采购系统按节点、日志量和服务级别计价，先跑POC验证漏报误报，再决定预算更稳妥。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/785216.html
