DDoS攻击防御攻击预警阈值设置技巧

预警阈值设置的本质不是找一个“安全数值”，而是建立一套能区分正常业务波动与攻击流量的判定逻辑。阈值设高了，攻击流量混在正常请求里漏进源站；设低了，促销活动或爬虫抓取都会触发误报，运维整天疲于应对。真正有效的阈值配置必须基于基线数据，而不是拍脑袋写个100Mbps或10万QPS。先做流量基线采集，至少覆盖两周时间，包含工作日、周末、夜间低谷和业务高峰，统计出不同时段的连接数、每秒请求数、新建连接速率、包速率和带宽占用。取95分位值作为参考上限，阈值通常设置为该分位值的1.2到1.5倍，既留出正常抖动空间，又能在异常抬升时快速触发。

不要只盯着总带宽。DDoS攻击类型多样，SYN Flood打的是新建连接速率，CC攻击打的是特定URL的请求频率，UDP反射攻击打的是包速率和带宽。如果只设置带宽阈值，一个低速但高并发的CC攻击可能带宽没跑满，源站却已经耗尽连接资源。建议至少设置四层指标：带宽利用率、包速率、新建连接速率、并发连接数。每一层再按协议和端口细分，例如TCP包速率阈值与UDP包速率阈值分开设置，因为UDP反射攻击的包速率往往是正常业务的几十倍，混在一起会掩盖异常。对于Web业务，还要单独监控HTTP请求速率和特定URL的访问频率，CC攻击往往集中在登录接口、搜索接口或验证码接口。

固定阈值最大的问题是无法适应业务变化。大促期间流量可能是平时的五倍，按平时基线设置的阈值会疯狂误报；凌晨三点流量极低，按白天峰值设置的阈值又形同虚设。动态阈值方案有两种实现路径。第一种是基于时间片的自动调整，把一天划分为多个时段，每个时段根据历史数据计算独立阈值，夜间阈值自动降低，高峰阈值自动上调。第二种是基于算法的异常检测，例如计算当前流量与过去一小时滑动窗口均值的偏离度，偏离超过200%且持续60秒以上才触发告警和清洗。第二种方式对运维能力要求更高，但误报率明显更低。实际部署中可以将两种方式结合，时间片阈值作为兜底，偏离度检测作为快速触发条件。

业务在增长，用户行为在变化，三个月前的基线数据可能已经完全失真。很多团队设置完阈值后就不再调整，结果要么频繁误报，要么攻击漏过。建议每月重新计算一次基线，或者在重大版本上线、市场投放活动后立即重新采集。基线漂移的典型信号是告警频率突然增加或减少，如果某周告警次数比上周多了三倍，先别急着判断攻击，检查业务是否有活动或新功能上线。另一个容易被忽略的是TLS握手速率。现在HTTPS普及，很多DDoS攻击直接打TLS握手，消耗CPU资源。TLS握手速率阈值应该单独设置，正常用户访问一个页面只会握手一次，而攻击工具可能在短时间内发起大量握手请求却不完成后续请求。

清洗设备或云防护平台的阈值配置界面通常提供多个参数。源IP连接数限制是防CC的重要手段，单个源IP对80或443端口的并发连接数超过50就应触发限制，正常浏览器访问一个网站很少同时建立超过20个连接。但要注意NAT出口场景，同一个公司或学校出口可能几百人共用IP，源IP连接数限制设太低会误伤。这种情况下可以结合请求速率和请求内容判断，例如单个IP对同一URL的请求频率超过每秒10次且持续10秒以上，基本可以判定为自动化攻击。SYN报文速率阈值一般设置为正常峰值的3倍以上，因为SYN Flood攻击的报文速率通常是指数级增长，3倍阈值能在攻击初期就触发响应。UDP包速率阈值要更谨慎，DNS查询、视频流、游戏业务都有较高的UDP包速率，需要按业务类型单独分析。

告警阈值应该低于清洗阈值。告警的目的是提醒运维人员关注，清洗则是自动触发流量牵引和过滤。如果两者使用同一个阈值，要么告警太晚失去意义，要么清洗太敏感影响正常用户。建议告警阈值设置为基线峰值的1.3倍，清洗阈值设置为1.8倍到2倍。告警触发后运维有几分钟时间判断是攻击还是业务波动，如果确认是攻击可以手动触发清洗，或者等待自动清洗阈值触发。对于明确的高危攻击类型，例如NTP反射攻击的特定端口流量，可以直接设置较低的自动清洗阈值，因为这类流量几乎没有正常业务可能。

触发阈值后系统执行什么动作，比阈值本身更重要。常见的动作包括限速、丢弃、挑战验证和黑洞路由。限速适合应对突发流量尖刺，把超过阈值的流量暂时排队或丢弃，保护源站不被瞬间打垮。丢弃策略要区分协议，TCP流量直接丢弃会导致用户重连，体验变差；UDP流量丢弃影响相对较小。挑战验证适合HTTP层攻击，对可疑IP弹出验证码或JS挑战，正常用户可以通过，攻击工具无法完成验证。黑洞路由是最后手段，当攻击流量超过清洗能力时，将目标IP的流量全部丢弃，保证机房其他业务不受影响。黑洞路由的触发阈值应该设置得非常高，通常是带宽上限的80%以上，因为一旦黑洞，该IP上的所有业务都不可用。

假设一个日均UV在50万左右的电商网站，正常业务带宽峰值约800Mbps，包速率峰值约30万pps，新建连接速率峰值约2万cps，并发连接数峰值约15万。告警阈值可以设置为：带宽1Gbps、包速率40万pps、新建连接速率3万cps、并发连接数20万。清洗阈值设置为：带宽1.5Gbps、包速率60万pps、新建连接速率5万cps、并发连接数30万。HTTP请求速率告警阈值设为每秒8万次，清洗阈值设为每秒12万次。单个源IP并发连接数限制为50，单个源IP对同一URL请求速率限制为每秒5次。SYN报文速率告警阈值设为正常峰值的2.5倍，清洗阈值设为4倍。这些数值需要根据实际业务调整，但比例关系可以参考。

配置完阈值后必须验证有效性。最直接的方式是使用压测工具模拟攻击流量，观察清洗设备是否按预期触发。测试时要注意从外网发起，模拟真实攻击路径，不要从内网测试，因为内网流量可能不经过清洗设备。压测流量要从小到大逐步增加，记录触发告警和清洗时的实际流量值，与配置值对比。如果实际触发值比配置值高很多，说明流量统计口径有差异，需要调整。另一个验证方法是回放历史攻击流量，把之前捕获的攻击pcap文件重放到测试环境，检查阈值是否能准确识别。对于动态阈值算法，需要注入模拟的业务波动数据，确认算法不会把正常增长误判为攻击。

最常见的错误是把阈值设置成固定数值后长期不调整。第二个错误是只监控入方向流量，忽略出方向流量。很多反射型DDoS攻击的入方向流量巨大，但出方向流量很小，如果只看出方向会漏掉攻击。第三个错误是把清洗设备的阈值设置得比源站承受能力还高，清洗还没触发源站已经挂了。正确的做法是先测试源站的实际承受上限，清洗阈值必须低于这个上限的80%。第四个错误是忽略DNS防护。DNS服务器被攻击时，即使Web服务器正常，用户也无法解析域名。DNS查询速率阈值需要单独设置，正常DNS查询速率很低，攻击时可能瞬间飙升几百倍。第五个错误是阈值触发后只做告警不做自动响应，攻击发生在凌晨时运维人员可能不在线，等看到告警时攻击已经造成长时间中断。

不同业务模块对流量特征的敏感度不同。登录接口对并发连接数敏感，搜索接口对请求速率敏感，文件下载接口对带宽敏感，API接口对新建连接速率敏感。如果所有接口共用一套阈值，要么保护过度要么保护不足。建议对核心接口单独设置阈值，例如登录接口的请求速率阈值设为全站平均值的十分之一，因为登录接口的正常请求频率远低于浏览页面。对于API业务，要监控响应时间与请求速率的关系，当请求速率未超阈值但响应时间显著增加时，可能意味着攻击流量已经消耗了大量后端资源，此时应触发降级策略，例如对非核心API限速或返回缓存数据。

阈值设置的目标不是追求零误报，而是在误报与漏报之间找到业务可接受的平衡点。过于激进的阈值会导致正常用户在业务高峰期被拦截，造成直接营收损失。过于保守的阈值则让攻击流量长驱直入。建议定期分析误报记录，统计被清洗设备拦截的流量中有多少比例最终被确认为正常用户。如果误报率超过5%，说明阈值偏紧，需要适当放宽。如果攻击漏过次数每月超过一次，说明阈值偏松，需要收紧。这个平衡点需要根据业务容忍度确定，金融类业务可能宁可误报也不漏过，内容类业务则更在意用户体验，宁可漏过少量攻击也不愿误伤用户。

阈值配置不是一次性工作，需要建立监控机制。每周检查一次各阈值的触发频率和触发时长，如果某个阈值从未触发过，可能设置过高或监控指标没有实际意义。如果某个阈值每天触发多次且每次都是误报，需要分析原因并调整。同时要关注阈值触发后的清洗效果，攻击流量被清洗后源站负载是否恢复正常，正常用户访问是否受到影响。这些数据反馈到阈值配置中，形成持续优化的闭环。对于使用云防护服务的团队，还要定期与服务商沟通阈值策略，因为服务商的默认阈值可能不适合你的业务模型，需要根据实际流量特征定制。