DDoS防护日志分析优化防御策略

DDoS防护日志不是用来证明“我们被打过”的，它是唯一能告诉你攻击者到底在利用哪条链路、哪个协议、哪个业务逻辑缺陷的原始证据。多数团队在攻击结束后只关心两件事：峰值流量有多大、扛住了没有。但真正决定下一次是否还能扛住的，是日志里那些没有被追问的细节。比如某个TCP端口的SYN包比例突然从正常的30%飙升到92%，比如某个API接口在攻击前48小时就被低速探测过，比如某个UDP反射源的地理分布高度集中在三个自治域。这些信息如果只躺在日志平台里，等于把下一次攻击的预警机会扔掉了。

DDoS防护日志通常不是单一文件，而是由多个层级产生的数据混合而成。最外层是网络层日志，包括流量采样数据（NetFlow、sFlow、IPFIX）、边界路由器ACL命中计数、上游运营商的黑洞触发记录。中间层是防护设备日志，包括抗D设备或云防护平台的清洗事件、丢弃包统计、连接跟踪表溢出记录。最内层是业务系统日志，包括Web服务器访问日志、负载均衡器连接日志、数据库慢查询和连接数异常。很多人只盯着防护设备的“攻击事件”看，但防护设备只能记录它识别出来的攻击，识别不出来的异常往往藏在最外层和最内层的日志对比里。

分析的第一步是把这三层日志的时间轴对齐。攻击的开始时间不能只看防护平台的告警时间，那个时间通常比实际攻击开始晚几十秒甚至几分钟。你要回到上游流量采样日志里，找到入向流量首次偏离基线的时间点。这个时间点往往对应着攻击者发起的第一波探测或低速攻击，而防护设备可能因为阈值设置较高而没有告警。把真实开始时间提前，你才能看到攻击的完整生命周期。

一个10Gbps的SYN Flood和一个10Gbps的UDP反射攻击，在总量上看起来一样，但对业务的影响和防御策略完全不同。分析日志时，第一件事是把入向流量按协议、目的端口、包速率、连接速率拆开。TCP攻击看SYN包速率和SYN/ACK比例，UDP攻击看目的端口分布和包长分布，HTTP攻击看请求URI分布、User-Agent分布、TLS指纹分布。如果日志显示攻击流量中UDP 80端口占比异常，但你的业务根本不对外开放UDP 80，那说明攻击者在用反射放大，源IP大概率是伪造的，这时候在边界做源IP信誉过滤比在防护设备上做深度检测更有效。

更关键的是找出攻击流量和正常流量的差异特征。这个特征不一定复杂，可能只是TTL值的分布不同。正常用户流量经过的跳数分布相对集中，而反射攻击的源IP来自全球各地，TTL分布非常离散。也可能只是TCP窗口大小的分布差异，攻击工具产生的TCP握手包窗口大小往往固定，而真实用户设备的窗口大小多样。把这些特征提取出来，就是你下一次可以提前下发的过滤规则。

很多DDoS防护失败的案例，问题不出在带宽，而出在连接跟踪表。无论是硬件防火墙还是Linux内核的conntrack模块，连接跟踪表的容量都是有限的。攻击者不需要打满带宽，只需要用大量伪造源IP的SYN包把连接跟踪表塞满，正常用户的连接就无法建立。日志分析时，要专门查看防护设备在攻击期间连接跟踪表的使用率和丢弃计数。如果使用率长时间超过85%，并且有大量conntrack entry处于SYN_RECV或UNREPLIED状态，说明攻击者就是在打状态表。

针对这种情况，优化策略不是加带宽，而是调整连接超时时间、对特定端口关闭连接跟踪、或者在边界路由器上先做一次无状态过滤。无状态过滤不消耗连接跟踪资源，可以在攻击流量到达有状态设备之前把明显伪造的包丢掉。比如源IP是保留地址、源IP是未分配地址段、源IP与目的IP相同的包，这些在边界直接丢弃，不需要进入连接跟踪。

网络层日志告诉你攻击有多大，业务层日志告诉你攻击在打谁。一个看似均匀分布到多个目的IP的DDoS攻击，在Web服务器日志里可能表现为对某个特定URI的请求量暴增。攻击者可能只针对一个搜索接口或者一个验证码接口做应用层消耗，因为这个接口的数据库查询特别重。如果只看网络层，你会以为攻击是分散的，实际上攻击者精确打击的是你业务链路上最脆弱的那一环。

分析业务日志时，重点看请求处理时间的分布变化。正常时期，某个接口的P99响应时间可能是200毫秒，攻击期间可能飙升到8秒。同时看错误码的分布，如果502和504错误大量出现，说明后端处理能力被打满，而不是网络层的问题。这时候优化防御策略的核心不是继续加大清洗能力，而是对这个接口做限流、缓存、或者临时降级。很多团队在攻击结束后只做了网络层的复盘，完全忽略了应用层的这些信号，结果下一次攻击者换一个接口，同样的故障再次发生。

分析日志的最终目的不是写报告，而是产出下一次可以直接使用的防御特征。这些特征分为几个层次。第一层是IP信誉特征，从日志中提取攻击源IP的ASN归属、IP段、地理位置，如果攻击源集中在少数几个ASN，可以在上游或边界对这些ASN做更严格的限速。第二层是协议行为特征，比如TCP选项组合、IP分片特征、UDP包长分布，这些可以用来写更精确的过滤规则。第三层是业务特征，比如某个URI的请求频率阈值、某个User-Agent的占比阈值，这些可以配置在WAF或应用层限流模块上。

一个常见的误区是只提取攻击期间的源IP列表，然后把这些IP加入黑名单。这种做法的有效期很短，因为攻击者会更换源IP。真正长期有效的是行为特征和协议指纹。比如某个攻击工具发出的HTTP请求，其Header顺序是固定的，Accept-Language的值是固定的，TLS握手的cipher suite顺序也是固定的。这些特征不会因为攻击者换IP而改变，把它们配置到防护策略里，下一次攻击刚开始就能被识别。

低速慢速攻击是最难从日志中发现的，因为它的每一项指标单独看都不超标。连接速率不高，带宽占用不大，请求频率也不突出。但如果你有历史基线，就能发现某个源IP的行为模式与正常用户有细微差异。比如正常用户的请求间隔是随机的，而慢速攻击的请求间隔是固定节奏的。正常用户在页面上的停留时间分布符合长尾分布，而攻击脚本的停留时间是均匀分布的。

建立基线不需要复杂的机器学习模型，只需要对关键指标做分时段的统计。每个小时的平均请求速率、连接持续时间的中位数、每个源IP的请求间隔方差，这些数据积累两周就能形成一个可用的基线。当某个源IP的行为偏离基线超过一定阈值时，即使它没有触发任何硬性告警，也应该被标记出来做进一步分析。很多高级攻击者会故意把攻击速率控制在告警阈值以下，但他们的行为模式无法完全模仿真实用户。

很多团队在攻击结束后想分析日志，发现只有聚合数据，原始包数据已经被丢弃了。聚合数据能告诉你攻击总量和大致类型，但无法做深入的特征提取。如果你有原始流量数据，哪怕是采样后的，也能在事后做协议分析、提取攻击工具指纹、甚至还原攻击者的攻击路径。建议至少保留7天的原始流量采样数据，采样比可以根据带宽成本调整，但至少要能还原出TCP握手和HTTP请求头。

同时要注意日志的时间戳精度。不同设备的时间戳精度不同，有的只到秒级，有的可以到毫秒级。如果时间戳精度不够，你无法判断两个事件之间的因果关系。比如一个连接被重置的时间和一个新连接建立的时间，如果只到秒级，看起来是同时发生的，但实际上可能相差几百毫秒。在分析攻击行为时，毫秒级的时间戳能帮你判断攻击者是在收到响应后才发起下一个动作，还是盲目地高速发包。

日志分析的价值最终要体现在自动化响应上。如果你能从历史攻击日志中提取出有效的过滤特征，下一步就是把这些特征配置到自动化防御流程里。比如当边界路由器检测到某个目的端口的UDP包速率超过基线5倍时，自动触发对该端口的限速。当防护设备发现某个源IP的连接跟踪表项数量超过阈值时，自动将该源IP加入临时黑名单。这些自动化策略不是凭空设定的，而是基于你对历史日志的分析得出的可靠阈值。

自动化响应的关键是分层触发。第一层是边界路由器的无状态过滤，处理最明显的攻击特征，响应速度最快。第二层是防护设备的有状态检测，处理需要连接跟踪才能识别的攻击。第三层是应用层限流和WAF规则，处理针对具体业务接口的攻击。每一层的触发条件都来自日志分析，而不是厂商的默认配置。厂商的默认配置是通用的，你的日志分析结论才是针对你业务的。

DDoS攻击不会只发生一次。攻击者在第一次攻击后会观察你的反应，调整策略，然后发起第二次攻击。如果你只在每次攻击后做应急处理，不做定期复盘，你的防御策略永远是滞后的。建议每月做一次日志回顾，即使这个月没有发生大规模攻击，也要看那些被标记为“异常但未达到告警阈值”的事件。这些事件可能是攻击者的前期侦察，也可能是下一次攻击的预演。

复盘时重点看三个问题：第一，这个月的流量基线有没有变化，如果有，是什么原因导致的，是业务增长还是攻击者长期的低速探测。第二，现有的过滤规则有没有误伤正常流量，如果有，哪些规则需要调整阈值。第三，防护设备有没有出现过资源瓶颈，即使没有造成故障，也要评估在更大规模攻击下是否会有风险。这三个问题的答案都藏在日志里，只看告警面板是找不到的。