CC 攻击的识别特征

CC 攻击麻烦在"像正常访问"：流量不大、请求合法，常规的带宽告警经常一声不响。但它有三个绕不开的特征，日志里仔细看就能现形。 第一个特征是 URL 高度集中。攻击者为了效率，通常反复请求同一个动态页面或接口，让数据库与脚本引擎反复执行同样的重活。在 Nginx 日志里按 URL 统计即可定位： awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head 如果某个动态 URL 的请求量在短时间内异常领先，而平时它的占比并不高，基本可以认定有问题。攻击者偶尔会轮换几个 URL，把统计窗口拉长到十分钟再看，集中的规律仍然藏不住。 第二个特征是源 IP 分散。为绕开单 IP 封禁，攻击者常用代理池轮换地址，单个 IP 的频率未必高，但独立 IP 总数会明显增多，而且多数是只出现这一次的"一次性访客"。统计独立 IP 数并与历史基线对比，异常增长就是信号；顺手看看这些 IP 的归属地分布，若与站点的正常受众明显不符，可疑度再加一级。 第三个特征是会话异常。真实用户会加载 CSS、JS、图片，会带着 Cookie 保持会话，会从列表页点进详情页；CC 攻击的请求往往只打一个 URL，不带 Referer，不加载任何静态资源，Cookie 也不回传。抽样看几十条请求的日志字段，这类"半截请求"的比例异常高时就要当心。需要提醒的是，三个特征不必凑齐才动手：URL 集中加会话异常两条同时出现，就值得先做限频观察，等三个特征全部坐实，攻击往往已经持续了半小时以上。 三个特征同时出现，基本可以判定为 CC 攻击。应对上，先对集中的 URL 与可疑会话做限频，再上验证码把脚本流量筛出去，把攻击请求挡在业务逻辑之前。高防云服务器配合 WAF 规则可以自动完成这层筛选；手动应急时，按上面的日志方法定位入口即可，比对着监控干着急有用得多。