数据源缺陷分析

　　Chargen 反射攻击理论上应该是纯净的19 端口的UDP 流量，然而在实际的检测结果中却发现攻击流量里伴随着大量固定高端端口流量，这个现象在所有主节点的检测结果中普遍存在。为此，我们在江苏省网边界与流记录同一接口位置上采集了面向有Chargen 反射行为主机的全部原始报文与同一时间段获取的流记录进行对比分析，发现这是由于NBOS 所使用的由某个品牌路由器提供的流记录未能正确处理UDP 分片报文导致的，流记录将Chargen 反射中的分片报文作为普通报文进行处理。

　　图4 给出了一个具体的实例来说明这个问题。图中(a) 是路由器给出的原始流记录数据，显示源IP 为202.*.200.91 的地址使用30070 端口与185.*.104.70 的30464端口通信，而在同一时间段采集的原始报文序列中没有发现任何202.*.200.91 使用30070 端口与185.*.104.70 通信的报文，但报文序列中该地址发送过大量的UDP 分片报文，这些分片报文是202.*.200.91 的19端口回应Chargen 请求产生的。进一步分析其中的一个分片报文的内容( 图4(b)) 发现，若以普通UDP 报文结构来解析， 在UDP 分片报文源端口号位置的数据是0x7576，而这个16进制数所对应的十进制

　　值就是30070。用相似方法对其他分片报文进行解析可以获得另外几个端口。这个实验的结果说明为NBOS提供流记录的路由器，在流记录的输出过程中，把UDP 分片报文错误地处理成了正常的UDP 报文。

　　由于只有Windows 系统的UDP Chargen回复会产生报文分片，因此利用数据源的这个缺陷，我们可以判定参与Chargen 攻击主机的操作系统类型。

　　本文分析了一个在NBOS 平台上实现的Chargen 反射DDoS 检测算法，并用其对CERNET 中的Chargen 攻击现象进行了观测和统计。从实际的观测结果来看，这类攻击在CERNET 中相对多发。网络上的服务器对类似Chargen 协议管理松懈是这个现象的主要原因。实际上，对这个攻击的防范还是比较简单的，只要关闭19 端口就可以了。即使这个服务一定要开放，至少应该增加一个访问控制机制。

　　本文的另一个贡献是发现了某品牌路由器的流记录对UDP 报文分片的处理存在缺陷。

　　（作者单位为东南大学计算机科学与工程学院）