文档介绍：深入了解DDOS与DDOS追踪~教育资源库
链级测试(Link Testing)
多数的追踪技术都是从最接近victim的路由器开始,然后开始检查上流数据链,直到找到攻击流量发起源。理想情况下,这种过程可以递归执行直到找到攻击源头。这种技术假设攻击一直保持活动直到完成追踪,因此很难在攻击结束后、间歇性攻击或对追踪进行攻击调整等情况进行追踪。包括下面两种链级测试:
1、Input debugging
很多路由器都提供Input debugging特性,这能让管理员在一些出口端过滤特定的数据包,而且能决定可以达到那些入口。这种特性就被用来作traceback:首先,victim在确定被攻击时,要从所有的数据包中描述出攻击包标志。通过这些标志,管理员在上流的出口端配置合适的Input debugging。这个过滤会体现出相关的input端口,这个过滤过程可以一直朝上流进行,直到能够到达最初的源头。当然这种工作很多依靠手工,一些国外的ISP联合开发的工具能够在它们的网络中进行自动的追踪。
但是这种办法最大的问题就是管理花费。联系多个ISP并同他们合作需要时间。因此这种办法需要大量的时间,而且几乎不可能完成。
2、Controlled flooding
Burch和 Ches的上级路由器开始依照路径图对上游的路由器进行控制的flood,因为这些数据包同攻击者发起的数据包同时共享了路由器,因此增加了路由器丢包的可能性。通过这种沿路径图不断向上进行,就能够接近攻击发起的源头。
这种想法很有独创性而且也很实际,但是有几个缺点和限制。最大的缺点就是这种办法本身就是一种DOS攻击,会对一些信任路径也进行DOS,这个缺点也很难用程序实施。而且,Controlled flooding要求有一个几乎覆盖整个网络的拓扑图。Burch和 Chesmary。要显示每个输入接口的更多的细节信息,输入命令sho就可以利用这些ICMP消息来重新构造攻击者的路径。这种方式同上面介绍的比较,有很多优点,但是也有一些缺点。比如:ICMP可能被从普通流量中过滤掉,并且,ICMP追踪消息还要同input debugging特性(将数据包同数据包input端口和/或者要到达的MAC地址关联的能力)相关,但是,可能一些路由器就没有这样的功能。同时,这种办法还必须有一种办法来处理攻击者可能发送的伪造ICMP Traceback消息。也就是说,我们可以把这种方式同其他办法一起使用来让跟踪机制更有效。(IETF iTrace)
这就是yawl说的IETF的工作组研究的内容,当时我给Bellovin提出一些意见,但是没有得到答案。比如:
1、尽管是随机1/20000发送追踪包,但是,对于伪造TRACEBACK的包情况下,对路由器的效率将有一定的影响。
2、追踪包的认证并不能解决伪造问题。因为要判别是否是伪造包,那么必须去认证,加大了工作量。
3、即便使用NULL 认证,同样能够达到目的(有认证的情况下)。而且也不会有太大影响。
4、Itrace的本来目的是去对付DOS的欺骗源问题,但是现在的设计仿佛让我们更关心的是路径而不是源头。难道路径比源头更对我们解决DOS问题有用么?
等等,还有一堆问题,都是我觉得iTrace将会面临的很难处理的问题。