精准甄别正常流量与CC攻击流量方法

正常业务流量与CC攻击流量在数据特征上存在本质差异，但很多运维人员仍然只盯着总请求数或带宽峰值来判断，这种做法在攻击初期几乎无效。CC攻击的本质是消耗应用层资源，它模拟的是正常用户的HTTP请求行为，所以从总量上看可能并不夸张，真正能暴露它的是请求的分布、来源特征、资源消耗比例和会话行为。判断的第一步不是看“流量有多大”，而是看“谁在消耗你的动态资源”。

最直接的排查起点是实时监控Web服务器的动态请求占比。静态资源（图片、CSS、JS）消耗的服务器资源很低，而动态请求（PHP、JSP、API接口、数据库查询）才是CC攻击的主要目标。如果你的服务器CPU或数据库连接数突然飙升，但静态资源请求量没有同步增长，反而动态请求的占比异常升高，这就已经是一个强信号。正常用户访问一个页面会同时拉取大量静态文件，而CC攻击工具往往只请求一个URL，尤其是那些会触发数据库查询的搜索接口、登录接口或列表页。

第二个关键指标是请求来源的IP分布。正常流量来自大量分散的IP，单个IP的请求频率有限，而CC攻击无论是直接攻击还是代理攻击，都会在某个维度上表现出集中性。你需要统计单位时间内每个IP的请求次数、每个IP的User-Agent种类、每个IP的Cookie有效性。一个正常浏览器访问网站时，会携带完整的浏览器指纹，包括一致的User-Agent、正确的Referer、支持Cookie和JavaScript。而多数CC攻击脚本使用固定的User-Agent，或者根本不会执行JavaScript，也不会携带有效的会话Cookie。

请求频率是最直观但最容易误判的指标。不能简单设定“每秒超过N次就封禁”，因为企业出口NAT环境下，一个IP后面可能有几百个真实用户。正确的做法是结合请求路径和资源类型来判断。例如，同一个IP在短时间内反复请求同一个需要数据库查询的动态URL，且请求间隔高度均匀，这几乎可以确定是脚本行为。正常用户的请求间隔是随机的，会有人类思考和阅读页面的时间，而攻击脚本的请求间隔往往呈现出机械化的规律性。

另一个容易被忽视的特征是HTTP请求头的完整性。正常浏览器的请求头包含Accept、Accept-Language、Accept-Encoding、Connection、Referer等多个字段，且字段值符合浏览器规范。大量CC攻击工具为了追求发包效率，会精简请求头，只保留最基本的Host和User-Agent，甚至User-Agent也是固定的。你可以通过分析日志中请求头的字段组合来识别异常流量。如果某个IP的请求头字段数量明显少于正常值，或者User-Agent与Referer的组合不符合逻辑（例如Referer是空但User-Agent声称是浏览器），就需要重点关注。

CC攻击最难以伪装的是业务逻辑层面的行为。正常用户在网站上的行为是有路径的：先访问首页，再浏览列表页，然后进入详情页，可能还会搜索、登录、下单。这些行为之间存在时间顺序和逻辑关联。而CC攻击工具通常直接命中目标URL，跳过了前置页面，也没有后续的关联操作。你可以在Nginx或应用层记录每个会话的访问路径，如果大量请求的会话中只有单一URL的访问记录，没有前置页面也没有后续跳转，这些流量就非常可疑。

Cookie和会话状态是另一个高价值的判断维度。正常用户在访问动态页面时，会携带服务器下发的会话标识，并且这个标识在多次请求中保持一致。CC攻击工具如果不处理Cookie，每次请求都是无状态的，服务器会为每个请求创建新的会话，这会导致应用服务器的会话表迅速膨胀。你可以监控应用服务器中活跃会话的数量和创建速率。如果活跃会话数在短时间内暴增，但对应的业务操作（登录、下单、评论）并没有同步增长，说明大量会话是攻击流量产生的空会话。

在实际操作中，你可以通过分析Nginx或Apache的访问日志来快速识别CC攻击。以下是一段用于统计单个IP对特定动态URL请求频率的Shell命令，可以在服务器上直接运行：

# 统计过去1分钟内请求次数最多的前20个IP
tail -n 100000 /var/log/nginx/access.log | awk -v date="$(date '+%d/%b/%Y:%H:%M' -d '1 minute ago')" '$4 ~ date {print $1}' | sort | uniq -c | sort -rn | head -20

# 统计请求特定动态接口的IP分布
grep "/api/search" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# 统计User-Agent分布，识别异常集中的UA
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

这些命令能帮助你快速定位异常来源，但真正的精准甄别需要更细粒度的分析。你需要关注请求的响应状态码分布。正常流量中，200状态码占绝大多数，404和304的比例相对稳定。CC攻击如果命中不存在的URL，会产生大量404；如果命中需要权限的URL，会产生大量403或302。状态码的异常分布本身就是一种信号。另外，响应体大小的分布也值得关注。如果大量请求返回相同大小的响应体，且这个响应体是动态生成的错误页面或空数据，说明这些请求很可能是攻击流量。

当攻击规模较大或攻击模式变化较快时，人工分析日志的效率会严重不足。这时候需要引入自动化的识别机制。一种实用的方法是对每个请求提取多维特征，包括IP地址、请求路径、请求方法、User-Agent、Referer、Cookie长度、请求间隔、响应状态码、响应体大小等，然后基于这些特征构建正常流量的基线模型。当某个IP或某组请求的特征显著偏离基线时，系统自动触发告警或限速。

在实际工程中，不需要一开始就上复杂的深度学习模型。基于统计的异常检测方法往往已经足够有效。例如，你可以计算每个IP在过去5分钟内的请求频率、请求路径的熵值、User-Agent的多样性。正常用户的请求路径熵值较高，因为他们会访问不同的页面和资源；而CC攻击的请求路径熵值极低，因为它们只打一个或少数几个URL。同样，正常IP的User-Agent多样性也较高，因为一个NAT出口后面可能有不同浏览器和设备的用户，而攻击IP的User-Agent通常只有一种。

被动分析日志只能识别已经发生的攻击，而主动的挑战机制可以在流量到达应用服务器之前就将其拦截。最常用的方法是JavaScript跳转验证。在流量进入应用服务器之前，先返回一个包含JavaScript代码的中间页面，这段代码会设置一个特定的Cookie并自动跳转到原始目标URL。正常浏览器会自动执行这段JavaScript并携带新Cookie重新请求，而绝大多数CC攻击工具不会执行JavaScript，因此无法通过验证。这种方法对用户体验的影响很小，正常用户几乎无感知，但对攻击工具的拦截效果非常显著。

另一种主动验证方法是基于浏览器指纹的挑战。在用户首次访问时，服务器收集浏览器的Canvas指纹、WebGL指纹、字体列表等信息，生成一个唯一的设备标识。后续请求必须携带这个标识，否则视为异常。这种方法比单纯的Cookie验证更难绕过，因为攻击工具要模拟完整的浏览器指纹成本很高。不过需要注意的是，这种方法可能会误伤一些隐私保护插件用户，需要在安全性和用户体验之间做平衡。

精准甄别正常流量与CC攻击流量不是单一技术手段能完成的，它需要多层防御体系的配合。第一层是网络层的流量清洗，通过分析TCP连接的特征（如SYN包速率、连接建立后的行为）来过滤明显的攻击流量。第二层是应用层的请求分析，也就是前面提到的基于日志、会话、业务逻辑的识别方法。第三层是挑战验证机制，对可疑流量进行主动验证。第四层是业务层的限流和降级，对核心接口设置独立的限流阈值，当流量超过阈值时自动触发降级策略，保证核心业务可用。

在实际部署中，你还需要注意一个关键问题：攻击者会不断调整策略来绕过你的检测规则。因此，识别规则不能是静态的，需要根据攻击模式的变化动态更新。建议建立一套流量基线的自动学习机制，定期更新正常流量的特征模型，同时收集攻击样本用于训练和优化检测规则。只有把被动分析和主动防御结合起来，才能在攻击发生时快速响应，同时最大限度地减少对正常用户的影响。

最后要强调的是，精准甄别的核心目标不是“识别出所有攻击流量”，而是“在不影响正常用户的前提下，尽可能多地拦截攻击流量”。过度严格的规则会误伤正常用户，过度宽松的规则又会让攻击流量穿透。你需要根据业务的实际承受能力和用户群体的特征，找到一个合适的平衡点。这个平衡点不是一成不变的，需要在运行过程中不断调整和优化。