DDoS防护阈值合理设置避免误拦截问题

做运维和安全的朋友经常陷入一个两难的境地：阈值设高了，攻击流量长驱直入，服务器CPU瞬间飙红，业务瘫痪；阈值设低了，正常的大流量业务请求被当作攻击清洗，客户投诉电话被打爆。这本质上不是防护设备能力不行，而是在“一刀切”的阈值策略上偷了懒。要解决误拦截，必须放弃那种“拍脑袋定一个数值”的原始方法，转而建立基于业务画像的动态基线体系。

很多人以为DDoS防护就是简单的“水龙头原理”，流量超过管子粗细就关阀门。实际上，主流的DDoS防护系统，无论是硬件清洗设备还是云防护中心，核心机制都是基于Netflow、sFlow或镜像流量的采样分析。系统会对数据包进行深度检测，区分SYN Flood、ACK Flood、UDP Flood、DNS Query Flood以及HTTP/HTTPS的应用层攻击。误拦截往往不是发生在带宽总量超标，而是发生在特征匹配过于严苛。比如一个正常的JSON接口因为业务高峰期请求包体较大，被HTTP慢速攻击策略误判；或者视频直播平台的突然推流，被UDP反射放大策略命中。要避免这种情况，你必须先搞清楚防护策略里的“阈值”到底针对的是什么维度，是每秒包数（pps）、每秒比特数（bps）、每秒新建连接数（cps），还是并发连接数。

最致命的错误就是把阈值设成一个固定值，比如“带宽超过500Mbps就清洗”。这种做法完全忽略了业务的潮汐效应。正确的做法是开启学习模式。在业务完全干净、无攻击的时间段，让防护系统连续学习至少7天，最好覆盖一个完整的业务周期，包含工作日、周末以及营销活动日。系统会计算出不同时段各项指标的基线。例如，一个电商平台凌晨3点的正常流量可能只有50Mbps，而上午10点大促时正常流量可能高达2Gbps。如果你设了一个1Gbps的固定阈值，凌晨的攻击漏掉了，上午的正常用户却被拦在门外。动态阈值应当设置为基线峰值的1.5倍到3倍，并配合突发容忍机制。如果基线是平滑的，突然出现一个尖锐的脉冲，即使没超过绝对阈值，也应该触发挑战验证，而不是直接丢包。

全局阈值是最粗糙的手段。真正精细化的防护必须分层设置。在传输层，需要区分TCP和UDP。对于TCP协议，要重点关注SYN包速率与RST包比例。如果你的业务是标准的HTTP服务，突然涌入大量非标准端口的TCP SYN包，那显然是攻击，但这不应该影响80端口和443端口的正常握手。对于UDP协议，如果你只有DNS服务，那么清洗设备就应该只放行53端口的UDP流量，并对非业务端口的UDP包执行严格限速甚至直接丢弃，而不是等UDP总流量超标再清洗。在应用层，针对HTTP/HTTPS，必须开启特征白名单。比如你的API只接受GET和POST请求，那么在防护策略中就要明确阻断PUT、DELETE、OPTIONS等方法的请求。对于Cookie和User-Agent，可以设置合规性检查，丢弃那些明显带有扫描器特征或空UA头的请求，而不是单纯看请求频率。

现在绝大多数业务都上了HTTPS，这给阈值设置带来了巨大挑战。如果防护设备不解密，它看到的只是加密的乱码，只能基于包速率和连接数做粗暴限制，误杀率极高。比如正常的TLS握手重协商，在不解密的情况下看起来就像突发流量。为了精准防护，建议将SSL证书导入清洗设备进行解密检测，但这会带来性能损耗和合规风险。一种折中的方案是采用“指纹识别”。不解密，但提取Client Hello包中的JA3指纹。如果某个指纹在短时间内发起了海量的TLS握手请求，且不完成后续握手，这显然是SSL Flood攻击。你可以设置阈值：单个源IP的TLS握手速率超过每秒50次，或者同一JA3指纹的总握手请求超过基线10倍，就触发验证码或阻断。这样既保护了用户隐私，又精准识别了攻击工具的特征。

不要只盯着流量数值，来源的属性同样关键。如果你的业务只服务于国内用户，那么在清洗策略中直接对境外IP执行严格的访问控制，能瞬间过滤掉90%的海外僵尸网络流量。但这不能一刀切，需要配合白名单，比如把海外分支机构的办公IP、CDN回源IP段全部加入白名单。利用威胁情报库，对已知的扫描器IP、代理IP、Tor出口节点进行信誉标记。对于信誉低的IP，即使它的请求速率没有超过绝对阈值，只要高于平均基线，就可以优先进行人机识别。这能有效解决那种“低速慢扫”式的精准打击，这种攻击往往流量不大，但消耗数据库连接池，单靠包速率阈值根本看不出来。

这是最容易引发大面积误拦截的重灾区。当业务前面套了CDN或反向代理，清洗设备看到的源IP全是CDN节点的IP。如果你对某个CDN节点IP限制了连接数，后果是这个节点背后成千上万的正常用户全部无法访问。解决这个问题必须依赖“传递真实IP”的技术。对于HTTP层，确保CDN开启了X-Forwarded-For头或X-Real-IP头，并在清洗设备上配置信任这些头字段，让策略基于X-Forwarded-For中的客户端真实IP来计算频率，而不是基于CDN节点IP。对于四层转发，则需要使用Proxy Protocol协议。如果这些都没配置，那你设置的任何基于IP的频率阈值都是无效且危险的，因为一个CDN节点可能承载几十万并发用户，你的阈值根本顶不住这种规模。

白名单是防误杀的终极保险，但白名单不能滥用。如果直接把整个核心业务服务器IP段加白，那攻击者直接打你白名单里的IP，防护就形同虚设。白名单应该细粒度化。首先是“业务特征白名单”，比如支付回调接口，虽然流量极小，但至关重要。可以针对这个特定URL路径设置白名单，允许其不受全局频率限制，但依然受包特征合法性检查。其次是“协议指纹白名单”，比如内部微服务之间的RPC调用，通常带有特定的Header或私有协议头，可以识别这些特征后直接放行。最后才是“IP白名单”，且IP白名单要定期审计，移除不再使用的地址。对于移动APP业务，可以在APP端植入动态签名算法，请求时在Header中带上时间戳和签名，清洗设备验证签名通过后，将该请求标记为“可信客户端”，从而在后续的频控策略中给予更高的容忍阈值。

任何阈值调整都不应该直接全量发布，那是赌博。正规的流程是在防护设备上开启“旁路检测”或“只告警不阻断”模式。先让新策略跑几天，观察告警日志。重点关注那些被新策略命中但最终业务没受影响的告警，这些就是潜在的误杀点。分析这些误杀请求的特征，是某个地区的运营商IP被误封了，还是某个接口的正常突发被限制了。针对这些误杀，调整策略中的例外规则。在确认无误后，再开启灰度清洗，比如只对1%的流量执行阻断，观察业务指标，确认无异常后再逐步放大到10%、50%直到全量。这种谨慎的操作能避免那种“一上策略就断网，一回滚就挨打”的运维惨剧。

人肉看日志调阈值的速度太慢了。当业务出现突发流量，比如突然上了热搜，运维如果还在睡觉，系统就会自动把热搜流量清洗掉，造成巨大损失。必须建立自动化反馈机制。将清洗设备的日志与业务监控系统打通。当清洗设备检测到流量超标准备清洗时，自动查询业务监控API。如果业务监控显示此时业务请求量、用户登录数、订单量都在同步正比增长，且错误率没有飙升，系统应自动判断为正常业务增长，临时自动上调清洗阈值或自动将触发清洗的源IP段加入白名单。反之，如果业务监控显示请求量暴涨但订单量、登录量暴跌，错误率飙升，则确认为攻击，维持甚至加强清洗力度。这种基于业务指标的反馈，是解决误拦截的最高效手段。

当你接到误杀投诉时，第一时间不是去改阈值，而是抓包取证。以下是一段在Linux服务器上抓取被拦截特征的简单脚本思路，用于分析是否因特定标志位被误杀：

# 抓取来自防护设备清洗后回注的流量，分析RST包比例
tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-rst) != 0' -c 1000 -w rst_dump.pcap

# 分析高频访问的源IP，看是否属于CDN节点
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20

# 检查应用日志中特定接口的请求频率，判断是否被频控
tail -n 10000 access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -10

通过这些数据，你可以直观地看到，是不是因为某个接口被扫到了高频访问阈值，或者是不是CDN节点因为RST包过多被误判为攻击源。

最终你会发现，DDoS防护的本质不是一堵墙，而是一个智能过滤器。误拦截造成的业务中断，其损失往往比小流量攻击造成的卡顿更严重。把阈值设置在“刚好比正常业务高峰高一点”的位置，配合多维度的特征组合检测，才能在不影响用户体验的前提下把攻击流量拒之门外。定期复盘清洗日志，找出那些被拦截的合法流量特征，持续优化你的策略集，这才是防护运营的核心价值，而不是买一个设备放在机房就万事大吉。