防御CC攻击业务与防护平台联动告警

防御CC攻击从来不是靠某一台设备或某一个策略就能一劳永逸的事。真正麻烦的场景是：攻击流量已经打过来了，WAF在拦截，但业务服务器依然出现间歇性响应缓慢，或者部分接口开始返回499、502。这时候如果防护设备和业务系统各自为政，运维只能同时打开三四个监控面板来回切换，等定位到问题，用户可能已经流失了一批。把防护平台的告警能力与业务侧的健康检查、日志系统、自动化调度打通，形成联动告警，才是把CC防御从“被动挨打”提升到“主动收敛”的关键一步。

先说清楚一个误区。很多人以为CC攻击就是高频请求，限频就能解决。实际上现在大量CC攻击是慢速攻击、分布式低频攻击，甚至是针对特定动态接口的精准打击。比如攻击者用几万个肉鸡，每个IP每分钟只请求两三次，但每次都打在一个需要复杂数据库查询的搜索接口上。单看IP频率完全正常，WAF的速率阈值根本不会触发，但业务后端连接池已经被占满。这种情况下，只有业务侧能感知到“数据库慢查询激增”“线程池耗尽”“接口响应时间从200ms飙升到8秒”这类信号。防护平台如果收不到这些信号，策略就不会调整，告警也不会触发。

联动告警不是简单地把两边的告警推送到同一个群里。它的核心是把业务系统的运行指标作为防护策略的触发条件之一，同时把防护平台的拦截事件作为业务侧容量评估和流量调度的依据。具体落地时，需要打通三个层面的数据：防护平台的攻击检测事件、业务系统的实时性能指标、以及基础设施层的资源水位。

举个例子，一个电商网站在大促期间突然出现大量针对“库存查询”接口的请求。WAF层面看，每个IP的请求频率都不高，没有触发任何规则。但业务侧的应用性能监控显示，该接口的数据库连接数在30秒内从200飙升到2000，平均响应时间从300ms涨到6秒。如果联动机制存在，业务监控系统会立即把这个异常指标推送给防护平台，防护平台自动对该接口启用动态限速，比如对单IP对该接口的请求频率从每分钟60次临时下调到10次，同时触发告警通知。这个告警里同时包含业务指标快照和防护动作记录，运维看到后不需要再手动查日志，直接就能判断是CC攻击还是单纯的业务高峰。

第一种是基于日志的准实时联动。业务系统把访问日志、错误日志、慢查询日志实时写入消息队列，防护平台订阅这些日志流，通过预设的规则引擎做聚合分析。比如检测到某个接口在5分钟内出现超过500次响应时间大于3秒的请求，就自动触发防护策略变更。这种方式的优点是实现成本低，不需要业务代码做太多改造，缺点是存在秒级到分钟级的延迟，对于爆发速度极快的CC攻击可能来不及响应。

第二种是基于探针的实时联动。在业务应用进程内嵌入轻量级探针，实时采集线程池使用率、连接池占用、请求排队长度、GC停顿时间等指标，通过本地聚合后直接上报给防护平台的控制面。防护平台根据这些实时指标动态调整限速阈值、连接超时时间，甚至直接对特定URL启用挑战验证。这种方式的响应速度最快，可以做到亚秒级联动，但需要业务方配合部署探针，对性能也有一定损耗，需要做采样和熔断保护。

第三种是基于网关层的统一联动。如果业务流量统一经过API网关或负载均衡器，可以在网关层同时集成防护策略和业务健康检查。网关实时统计每个后端服务的请求成功率、响应时间分位数、连接池饱和度，当某个服务出现异常时，网关直接对该服务的入站流量执行限流、降级或隔离，同时把事件推送给防护平台做全局策略同步。这种方式对业务侵入最小，但要求网关本身具备足够的处理能力和扩展性，否则网关自身可能成为瓶颈。

很多团队做了联动，但告警发出来没人看，原因是告警内容太粗糙。一条合格的联动告警至少应该包含以下字段：触发时间、受影响的服务或接口、业务侧异常指标的具体数值和基线对比、防护平台当前执行的策略动作、攻击来源的IP段或地域分布、以及建议的下一步操作。比如“14:32:05 库存查询接口响应时间P99达到8.7秒，较基线上升2900%，数据库连接池使用率98%，已自动启用该接口单IP限速10次/分钟，拦截可疑请求1.2万次，来源IP主要集中在东南亚区域，建议检查是否有活动页被恶意刷取。”

这样的告警信息密度足够高，接收者不需要再打开任何监控系统就能做出判断。如果条件允许，还可以在告警里附带一个简短的上下文链接，点击后直接跳转到该时间段的联合分析视图，把防护日志和业务追踪链路放在同一个时间轴上展示。这比发一堆零散的截图有用得多。

联动告警的最终目标是自动化闭环：业务指标异常触发防护策略调整，防护策略生效后业务指标恢复，系统记录事件并生成报告。但在实际生产环境中，完全自动化的风险在于误判。比如一次正常的营销活动导致流量激增，业务指标短暂恶化，如果自动化策略过于激进，可能把真实用户误伤。因此需要设置分级响应机制：一级联动只做告警通知和策略建议，由人工确认后执行；二级联动对明确的高置信度攻击事件自动执行预设策略，同时发出告警；三级联动在极端情况下自动执行最严格的防护策略，比如全站启用JS挑战或临时封禁可疑IP段，并通知所有相关人员。

分级响应的依据可以来自历史基线学习和攻击特征匹配。比如某个接口在过去30天内从未出现过响应时间超过5秒的情况，突然在1分钟内出现上千次超时，且来源IP的地理分布与正常用户明显不同，这种就可以直接进入二级联动。而如果只是响应时间缓慢上升，没有明显的异常请求特征，则先进入一级联动观察。

假设你正在使用一套支持API的WAF或防护平台，业务侧有Prometheus监控和Alertmanager告警组件。以下是一个简化版的联动配置思路，用伪代码表示：

# 业务侧告警规则示例（Prometheus）
groups:
  - name: cc_attack_linkage
    rules:
      - alert: SlowQuerySurge
        expr: |
          rate(http_server_requests_seconds_sum{uri="/api/stock"}[1m]) /
          rate(http_server_requests_seconds_count{uri="/api/stock"}[1m]) > 3
        for: 30s
        labels:
          severity: critical
          linkage: enabled
        annotations:
          summary: "库存接口响应时间异常"
          action: "notify_waf"

# Alertmanager webhook 推送到防护平台
receivers:
  - name: waf_webhook
    webhook_configs:
      - url: "https://waf.example.com/api/v1/linkage/alert"
        send_resolved: false
        http_config:
          headers:
            Authorization: "Bearer YOUR_TOKEN"

防护平台收到webhook后，根据预设的联动策略执行动作。比如对/api/stock接口启用临时限速，将单IP每分钟请求数从默认的120次下调到20次，同时把该接口的挑战模式从“观察”切换为“拦截”。整个过程中，防护平台会生成一条联动事件记录，包含触发原因、执行的策略变更、影响范围，并通过邮件或即时通讯工具推送给人。

联动策略生效后，业务指标恢复，系统需要自动或半自动地回滚策略。如果回滚不及时，限速策略可能持续影响正常用户。建议为每条联动策略设置有效期，比如默认生效10分钟，到期后自动恢复原策略，同时再次评估业务指标。如果指标仍然异常，则延长有效期并升级告警级别。如果指标已经恢复，则自动回滚并记录事件。这个回滚逻辑必须在设计联动机制时就考虑进去，否则运维人员可能因为忙于处理其他事情而忘记手动恢复，导致业务长期处于过度防护状态。

另一个容易忽略的是联动告警的聚合与去重。一次CC攻击可能同时触发多个业务指标的异常，如果每个指标都单独推送告警，运维会被淹没。需要在联动层做事件聚合，把同一时间段内、同一服务或接口触发的多个异常指标合并为一条事件，附带所有相关指标的摘要。同时设置告警风暴抑制窗口，比如同一服务在15分钟内只发送一次联动告警，后续的指标变化通过更新同一条告警的状态来体现，而不是重复发送新告警。

从实际效果看，把业务侧的性能指标和防护平台的策略引擎打通之后，CC攻击的平均发现时间可以从分钟级压缩到秒级，误伤率也能明显下降。因为防护策略不再只依赖流量特征，而是有了业务真实状态的反馈。这种闭环一旦建立起来，防护系统就从静态的规则引擎变成了动态的自适应系统，这才是防御CC攻击的长期方向。