金融网站被慢速CC攻击缠上，核心排查逻辑是“先看连接层异常，再查应用层日志，最后做流量指纹比对”，优先从服务器并发连接数、请求间隔特征和API接口响应时间三处入手，而不是一上来就换IP或加带宽。慢速CC与普通DDoS不同，它模仿真人访问节奏，单个IP请求频率极低，但大量IP同时“慢悠悠”地啃食连接池和CPU，金融类网站的交易查询、登录验证、行情接口尤其容易被打瘫。
慢速CC攻击和普通CC攻击到底有什么区别
攻击特征的三个关键差异
普通CC往往是短时间高频请求,监控面板上QPS曲线像尖刺一样冲高，防火墙规则一限速就能压住，慢速CC则相反，它的请求间隔可能拉长到十几秒甚至几分钟，单IP看起来“人畜无害”，但架不住同时有几百上千个IP在保持连接。
- 连接时长异常：大量TCP连接处于ESTABLISHED状态但数据传输极少，
netstat -an | grep ESTAB | wc -l数值远超正常业务峰值。 - 请求间隔规律化：正常用户点击有随机性，慢速CC的请求间隔往往呈现固定周期，比如每15秒请求一次登录接口。
- 目标接口集中：金融网站被慢速CC缠上后，攻击者通常盯着登录、注册、行情查询、转账验证这几个消耗数据库资源的接口反复“温柔”请求。
为什么金融网站特别容易中招
金融类页面本身响应链路长,一次登录要查用户表、验密码、记日志、发短信验证码，单次请求的服务器开销是普通静态页面的几十倍，业内专家指出，攻击者正是利用这个特点，用极低频率的请求拖垮应用层线程池，而网络层流量看起来完全正常，行业共识认为，金融行业网站遭遇的慢速攻击中，相当一部分会伪装成正常移动端User-Agent，绕过基础特征匹配。
金融网站被慢速CC缠上后怎么排查：从连接层到应用层的完整路径
第一步：锁定连接层异常
登录服务器后先别急着翻应用日志,连接层的数据最直观，执行以下命令快速摸底：
ss -s查看当前总连接数、TIME_WAIT和ESTABLISHED分布，如果ESTABLISHED数量是平时峰值的数倍且来源IP分散，基本可判定有慢速连接占用。netstat -anp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -50统计连接数最多的前50个IP，慢速CC的IP往往每个只占几个连接，但总量惊人。ss -tn state established '( dport = :443 )' | wc -l单独看443端口的活跃连接，金融网站HTTPS流量占大头，这个数字异常增长就是信号。
如果发现大量IP集中在某几个C段,且每个IP的连接存活时间超过业务正常会话时长，先记录下来，下一步去应用层验证。
第二步：应用层日志比对请求指纹
连接层只能说明“有异常”，应用层日志才能确认“是不是攻击”，重点看三个维度：
- 请求间隔分布：从Nginx或应用日志中提取同一接口的请求时间戳，计算相邻请求的间隔方差，正常用户方差大，慢速CC的方差小得离谱，间隔值高度集中。
- User-Agent与Referer组合：慢速CC常复用同一套UA字符串，但Referer可能为空或伪造，金融网站正常访问登录页一般有站内跳转来源，攻击请求往往直接打接口。
- Cookie与Session行为：正常用户会携带完整会话，慢速CC可能每次请求都新建会话，导致后端Session存储暴涨。
实操路径：用 awk 从access.log中筛出登录接口的请求，按IP分组统计请求次数和平均间隔。grep '/api/login' access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20，如果某个IP请求次数不多但持续数小时不断，配合间隔分析就能坐实慢速特征。
第三步：后端资源消耗定位
慢速CC的杀伤力最终体现在后端,打开top看CPU的si（软中断）和wa（IO等待）占比，如果si高说明网络层包处理压力大，wa高则可能是数据库被慢查询拖住，再结合mysqladmin processlist观察是否有大量状态为“Sending data”或“Waiting for table metadata lock”的查询，且这些查询对应的SQL正是登录或行情接口。
金融网站被慢速CC缠上后,一个典型现象是：前端Nginx的QPS只有几百，但后端应用服务器的线程池已经打满，数据库连接数逼近上限，这时候别急着重启，先把SHOW PROCESSLIST的结果和Nginx日志时间戳对齐，找出是哪些请求在“占着茅坑不拉屎”。
慢速CC排查中容易踩的三个坑
坑一：只盯流量图不看连接状态
很多运维第一反应是看带宽监控,慢速CC的带宽占用往往很低，流量图风平浪静，于是误判为“没事”，实际上连接池和线程池已经在报警，等用户端出现超时反馈时，业务损失已经发生。
坑二：用高频限速规则去套慢速攻击
普通CC防护规则通常设“单IP每秒超过X次请求就封”，慢速CC的请求频率远低于阈值，规则完全不触发，正确的做法是加“单IP并发连接数上限”和“会话存活时间异常检测”，而不是一味调低频率阈值。
坑三：封IP封到正常用户
慢速CC的IP池可能混有正常用户的代理出口,一刀切封C段会误伤，建议先做行为指纹聚类，把“请求间隔方差极小+UA固定+无Referer”的请求打标签，按标签限速而非按IP封禁。
金融行业网站防慢速CC的加固建议
接入层：连接数治理比限速更有效
在Nginx或负载均衡层设置limit_conn和limit_req组合策略，重点限制单IP的并发连接数而非请求速率，金融网站可参考：单IP并发连接不超过20个，单IP对登录接口的请求间隔低于5秒的做会话校验挑战。
应用层：给关键接口加“人机校验”闸门
登录、注册、行情查询接口在检测到异常会话特征时，弹出滑块验证或短信二次验证，慢速CC的攻击脚本通常不具备处理动态验证的能力，这一招能过滤掉较大比例的自动化请求，且对正常用户体验影响可控。
监控层：把“连接存活时长”纳入告警
常规监控盯QPS和响应时间,建议增加“平均连接存活时长”和“单IP请求间隔方差”两个指标，当连接存活时长中位数突然拉长、间隔方差骤降时触发告警，比等业务超时再排查提前不少。
据工信部相关监测数据,近年来针对金融行业的自动化攻击中，慢速类攻击占比呈上升趋势，传统基于频率阈值的防护手段拦截率有限，行为特征分析成为主要补充手段。
关于金融网站慢速CC排查的常见问题
慢速CC攻击排查一般需要多长时间能定位？
如果连接层和应用层日志采集完整,通常1到2小时内可完成初步定位，关键卡点往往在日志字段缺失，比如Nginx默认日志没记录请求间隔的精确毫秒值，需要临时开启$request_time和$upstream_response_time变量，建议金融网站平时就把这两个字段纳入日志格式，排查时直接可用。
金融网站被慢速CC攻击后要不要直接换IP？
不建议,慢速CC的IP池通常很大，换IP只能短暂缓解，攻击者很快会跟到新IP，正确顺序是先做连接层限流和应用层指纹拦截，把攻击成本抬高，同时保留原IP观察拦截效果，如果攻击量级超出单机防护能力，再考虑接入高防清洗，但清洗策略要针对慢速特征定制，不能套用普通DDoS的流量清洗模板。
慢速CC和正常业务慢查询怎么区分？
看请求来源的分布规律,正常慢查询的发起IP分散且与业务活跃时段吻合，慢速CC的发起IP往往集中在少数C段且全天候均匀分布，另一个区分点是SQL指纹：正常慢查询的SQL语句多样，慢速CC打过来的请求对应的SQL高度重复，基本就是登录验证或行情查询那几条固定语句，把SHOW PROCESSLIST里的SQL做哈希聚类，重复率异常高的那一组就是攻击流量。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/793037.html
