防御DDoS攻击提前做好流量基线监测

流量基线监测不是简单的“看看平时有多少访问”，而是要建立一套能够区分正常业务波动与攻击洪峰的量化模型。很多团队在遭遇DDoS攻击时陷入被动，根本原因在于没有提前回答三个问题：正常流量长什么样、峰值出现在什么时段、不同协议和URL的分布比例是多少。没有这些数据，当攻击流量涌入时，运维人员只能凭经验判断“好像不太对”，而攻击者恰恰利用这段判断延迟来扩大破坏效果。

建立流量基线需要从时间维度、协议维度、地理维度和行为维度同时入手。时间维度上，至少要保留三到六个月的流量历史数据，按分钟、小时、天、周四个粒度分别统计。分钟级数据用于捕捉突发流量，小时级数据反映业务高峰低谷，周级数据则能揭示周期性规律，例如每周一上午的登录高峰或周末的视频流量增长。很多企业只保存了汇总后的日均值，这在平时做容量规划勉强够用，但面对DDoS攻击时完全无法提供有效的对比基准。

协议维度的基线监测往往被忽视。一个典型的Web业务，正常状态下TCP握手包、HTTP请求、TLS握手、DNS查询之间的比例是相对稳定的。如果某天突然出现大量TCP SYN包但几乎没有后续HTTP请求，这很可能是SYN Flood攻击。同样，如果DNS查询量在非业务时段突然飙升，可能是DNS放大攻击的前兆。因此，基线不能只记录总流量，必须拆解到协议和包类型层面。

地理维度的监测同样关键。正常业务的访问来源分布通常集中在特定区域，例如国内用户占比超过90%，海外访问量长期维持在个位数百分比。当攻击发生时，流量来源地往往会出现异常偏移，比如突然有大量来自某个从未出现过的国家或地区的请求。提前记录正常的地理分布基线，可以让安全团队在攻击初期就通过来源异常快速触发告警。

行为维度的基线是最容易被忽略但价值最高的部分。正常用户访问网站时，页面停留时间、点击深度、请求间隔、会话时长等行为指标存在统计规律。DDoS攻击工具产生的流量往往在这些行为特征上与真实用户存在显著差异，例如请求间隔极其均匀、单个会话只请求一个固定URL、没有浏览器指纹或Cookie回传等。建立行为基线后，即使攻击者模拟了正常的协议和地理分布，也很难完全模仿真实用户的行为模式。

实现流量基线监测，首先需要解决数据采集问题。在交换机或路由器层面启用NetFlow、sFlow或IPFIX，可以获取到所有经过设备的流量元数据，包括源IP、目的IP、端口、协议、包数量和字节数。这种方式对业务系统无侵入，且能覆盖南北向和东西向流量。对于云上业务，各云平台通常提供VPC Flow Logs功能，可以记录虚拟机级别的流量信息，但需要注意开启后会产生额外的存储和查询费用。

在应用层，需要从负载均衡器、反向代理和Web服务器日志中提取更细粒度的信息。Nginx和Apache的访问日志记录了每个请求的URL、状态码、响应时间、User-Agent和Referer，这些数据是构建行为基线的基础。建议将日志实时推送到集中式日志平台，例如Elasticsearch或ClickHouse，以便后续进行聚合分析。日志保留周期至少为90天，存储成本与安全价值相比完全值得投入。

对于DNS流量，需要单独部署DNS日志记录。BIND和PowerDNS都支持查询日志输出，记录内容包括查询域名、查询类型、源IP和响应结果。DNS层面的异常往往是攻击的早期信号，例如大量不存在的域名查询可能预示着DNS隧道或随机子域名攻击。

流量基线不是一成不变的固定数值，而是需要持续更新的动态区间。最常用的方法是计算每个指标在历史同期数据的均值和标准差，然后设定正常范围为均值加减两到三个标准差。例如，过去30天每天下午三点的HTTP请求量均值为5000 QPS，标准差为800，那么正常范围可以设定为2600到7400 QPS。当实时数据超出这个区间时触发告警。

但简单的统计方法存在局限性。业务流量往往存在明显的趋势性变化，比如新产品上线后整体流量持续增长，或者营销活动期间出现预期内的流量高峰。如果基线不能适应这些变化，就会产生大量误报。解决方法是引入时间序列预测模型，例如Holt-Winters指数平滑或Prophet，根据历史数据预测当前时刻的预期流量值，并计算预测区间。当实际流量偏离预测区间超过阈值时告警，这样既能捕捉异常，又能适应业务的自然增长。

更新频率方面，建议每天凌晨重新计算一次基线模型，将前一天的数据纳入训练集。对于分钟级和小时级指标，使用滑动窗口方式更新，窗口长度至少为30天。同时需要设置人工干预机制，当发生已知的大型活动或业务变更时，可以临时调整基线阈值，避免误报淹没真实告警。

流量基线监测的核心指标可以分为三大类。第一类是流量总量指标，包括入站带宽、出站带宽、每秒包数、每秒新建连接数。这些指标反映攻击的整体规模，但单独看总量容易漏掉低速慢速攻击，因此必须结合其他指标综合判断。

第二类是协议分布指标，包括TCP SYN包占比、UDP包占比、ICMP包占比、分片包占比、异常标志位包占比。正常Web业务中TCP SYN包通常占总包数的5%到15%，如果这个比例突然超过40%，基本可以判定存在SYN Flood。UDP包在正常Web业务中占比通常很低，除非业务本身依赖UDP协议，否则UDP流量突增就是明确的攻击信号。

第三类是应用层指标，包括HTTP请求速率、HTTPS握手速率、特定URL的请求速率、非200状态码比例、请求URL的熵值。攻击者往往集中攻击某一个或几个URL，导致这些URL的请求量在短时间内暴增，而其他URL的请求量保持不变。URL熵值是一个非常有用的指标，正常访问的URL分布相对分散，熵值较高，而攻击流量集中在少数URL时熵值会急剧下降。

告警阈值的设计需要遵循“分级告警”原则。一级告警用于提示运维人员关注，阈值可以设定为基线均值加两倍标准差；二级告警要求安全团队立即介入，阈值设定为均值加三倍标准差；三级告警则触发自动缓解措施，阈值设定为均值加五倍标准差或超过历史最大值的1.5倍。同时，告警触发条件应要求异常持续至少30秒到1分钟，避免瞬时抖动导致误报。

流量基线监测的价值不仅在于检测攻击，更在于为防护策略提供精确的参数依据。例如，在配置防火墙或DDoS防护设备的速率限制规则时，应该基于基线的正常峰值来设定阈值，而不是拍脑袋定一个数字。如果某个API接口的正常峰值是200 QPS，那么速率限制可以设定为400 QPS，既能拦截异常流量，又不会影响正常业务。

对于基于地理位置的访问控制策略，流量基线可以提供哪些地区是真正的业务来源。如果过去90天内来自某个国家的请求量始终为零或极低，那么在攻击期间可以直接在边缘节点丢弃来自该地区的流量，而不用担心误伤真实用户。这种基于基线数据做出的决策比临时判断要可靠得多。

在CDN和边缘节点层面，基线数据可以帮助识别哪些源站IP是攻击者的真正目标。当攻击流量绕过CDN直接打到源站时，源站的入站流量会突然超过正常基线的数倍。如果源站部署了基于基线阈值的自动切换机制，可以在攻击初期就将流量牵引到清洗中心，缩短攻击影响时间。

流量基线监测系统不应该只是一个告警工具，而应该与自动化响应系统深度集成。当检测到流量超出基线阈值时，系统可以自动执行一系列动作：第一步是增加采样频率，从分钟级提升到秒级，获取更精细的攻击特征；第二步是将可疑源IP列表推送到边缘防火墙进行临时封禁；第三步是通知DNS服务商将受攻击域名切换到高防IP；第四步是触发业务降级策略，关闭非核心功能以释放资源。

实现自动化响应的前提是基线数据的准确性足够高，误报率控制在可接受范围内。如果基线本身不可靠，自动化响应反而会放大问题。因此，在部署自动化响应之前，需要经过至少一个月的观察期，统计告警的准确率和误报率，只有当准确率超过95%时才启用自动封禁等高风险动作。

另外，基线监测系统需要与业务监控系统打通。当业务指标如订单量、登录成功率、页面加载时间出现异常时，结合流量基线的偏离情况，可以更准确地判断是DDoS攻击还是业务系统自身故障。例如，如果流量没有明显变化但登录成功率骤降，可能是数据库或认证服务出现问题；如果流量暴增且登录成功率同步下降，则大概率是攻击导致资源耗尽。

很多团队在实施流量基线监测时容易陷入几个误区。第一个误区是只监控入站流量，忽视出站流量。DDoS攻击中的反射放大攻击会导致受害者的出站流量远大于入站流量，如果只盯着入站带宽，可能完全看不到攻击的存在。第二个误区是基线粒度太粗，只按天统计平均值，无法捕捉分钟级的突发异常。第三个误区是基线建立后从不更新，业务已经变化了但基线还停留在几个月前的状态，导致告警频繁误报或漏报。

实施建议方面，优先从网络层流量采集开始，因为这是成本最低、见效最快的方案。在核心交换机上启用NetFlow，将数据导入分析平台，先建立总流量和协议分布的基线。第二步再接入应用层日志，构建URL和用户行为基线。第三步引入自动化响应，逐步实现从检测到缓解的闭环。整个实施过程不需要一次性到位，可以按照网络层、应用层、自动化三个阶段的顺序推进，每个阶段都能产生实际的安全价值。

对于资源有限的中小企业，至少要做到保存30天以上的流量日志和访问日志，并定期计算关键指标的日均值和峰值。即使没有复杂的机器学习模型，简单的统计对比也能在攻击发生时提供重要的判断依据。流量基线监测的本质是用数据替代猜测，用历史规律识别当前异常，这是所有DDoS防御工作的起点。