链级测试 (Link Testing)
多数的追踪技术都是从最接近victim的路由器开始，然后开始检查上流数据链，直到找到攻击流量发起源。理想情况下，这种过程可以递归执行直到找到攻击源头。这种技术假设攻击一直保持活动直到完成追踪，因此很难在攻击结束后、间歇性攻击或对追踪进行攻击调整等情况进行追踪。包括下面两种链级测试：
1、Input debugging
很多路由器都提供Input debugging特性，这能让管理员在一些出口端过滤特定的数据包，而且能决定可以达到那些入口。这种特性就被用来作traceback：首先，victim在确定被攻击时，要从所有的数据包中描述出攻击包标志。通过这些标志，管理员在上流的出口端配置合适的Input debugging。这个过滤会体现出相关的input端口，这个过滤过程可以一直朝上流进行，直到能够到达最初的源头。当然这种工作很多依靠手工，一些国外的ISP联合开发的工具能够在它们的网络中进行自动的追踪。
但是这种办法最大的问题就是管理花费。联系多个ISP并同他们合作需要时间。因此这种办法需要大量的时间，而且几乎不可能完成。
2、Controlled flooding
Burch和 Cheswick提出的方法。这种方法实际上就是制造flood攻击，通过观察路由器的状态来判断攻击路径。首先应该有一张上游的路径图，当受到攻击的时候，可以从victim的上级路由器开始依照路径图对上游的路由器进行控制的flood，因为这些数据包同攻击者发起的数据包同时共享了路由器，因此增加了路由器丢包的可能性。通过这种沿路径图不断向上进行，就能够接近攻击发起的源头。
这种想法很有独创性而且也很实际，但是有几个缺点和限制。最大的缺点就是这种办法本身就是一种DOS攻击，会对一些信任路径也进行DOS，这个缺点也很难用程序实施。而且，Controlled flooding要求有一个几乎覆盖整个网络的拓扑图。Burch和 Cheswick也指出，这种办法很难用于DDOS攻击的追踪。这种方法也只能对正在进行攻击的情况有效。
现在CISCO的路由器的CEF（Cisco Express Forwarding）实际上就是一种链级测试，也就是说，要用CEF追踪到最终源头的话，那么整个链路上的路由器都得使用CISCO的路由器，而且支持CEF。就得要Cisco 12000或者7500系列的路由器了。（不知道现在怎么样，没查最新的CISCO文档），但是要用这个功能是很费资源的。
在CISCO路由器（支持ip source-track的路由器）上IP源追踪以下面的步骤实现：
1、当发现目的被攻击，打开整个路由器上对目的地址的追踪，输入命令 ip source-track。
2、每个Line Card为要追踪的目的地址创建特定的CEF队列。对于line card或者端口适配器用特定的ASIC作包转换，CEF队列用于将包置入line card或者port adapter的CPU。
3、每个line card CPU收集关于要追踪目的的通讯信息
4、所产生的数据定时导出到路由器。要现实这些流信息的摘要，输入命令：show ip source-track summary。要显示每个输入接口的更多的细节信息，输入命令show ip source-track
5、统计被追踪的IP地址的细目表。这可用于上游路由器继续分析。可以在当前路由器上关闭IP source tracker，输入命令：no ip source-track。然后在上游路由器上再打开这个功能。
6、重复步骤1到5，直到找到攻击源。
这差不多能够解答securitytest提的了吧。
Logging
这种方法通过在主路由器上记录数据包，然后通过数据采集技术来决定这些数据包的穿越路径。虽然这种办法可以用于对攻击后的数据进行追踪，它也有很明显的缺点，比如可能要求大量的资源（或者取样），并且对付大量数据的综合问题。
ICMP追踪
这种方法主要依靠路由器自身产生的ICMP跟踪消息。每个路由器都有很低的概率（比如：1/200000），数据包可能会把内容复制到一个ICMP消息包中，并且包含了到临近源地址的路由器信息。当flood攻击开始的时候，victim就可以利用这些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将会面临的很难处理的问题。
数据包标记
这种技术构想（因为现在没有实用）就是要在现有协议的基础上进行修改，而且修改很小，不象iTrace的想法，个人认为比iTrace更好一些。这种追踪技术有很多细节研究，形成多种标记算法，但是最好的还是经过压缩的边缘取样算法。
这种技术原理就是修改IP头中，重载其中的identification域。也就是如果没有使用到identification域的话，将这个域定义为标记。
将16bit的idnetification分成：3bit的offset（可允许8次分片）,5bit的distance，以及8bit的边缘分片。5bit的distance可以允许31级路由，这对于目前的网络来说已经足够了。
标记和重构路径的算法是：
Marking procedure at router R: Path reconstruction procedure at victim v: let FragTbl be a table of tuples(frag,offset,distance) |
实验室情况下这种标记技术只需要victim能够抓到1000到2500个包就能够重构整个路径了，应该说结果是很好的，但是没有投入到实用中，主要是需要路由器厂商和ISP支持。
差不多ip traceback的已经实用的技术和实验室技术，或者已经死掉的，就主要是这些，虽然还有其他的一些。
已经很长时间没有搞DDOS防范这一块了，国内也有黑洞这样的产品，以前也了解一些国外的，比如floodguard、toplayer、radware等。受securitytest提示，又了解到riverhead的，我就立刻看了看他们的白皮书。
因为前面bigfoot提出的主要是ip traceback的题目，securitytest也又到防御的问题。针对DDOS的问题ip traceback和Mitigation是不一样的，ip traceback主要是进行追踪，因为DDOS主要是spoof，而很难判别到真正的攻击源，而且如果能够很容易找到真正的攻击源，不仅仅对付DDOS，对付其他的攻击也很有帮助，比如法律问题等。而Mitigation是从受害者的角度，因为victim一般是没有能力去调查整个网络，找出source，而且，即便能够找到source，也得有法律或者一些沟通的手段来让source停下来（攻击的source并不是source的攻击者），这种意味着大量的沟通、跨ISP、跨过等类似的非技术问题，所以，通常很难处理。但是从victim的角度来说，必须得有所解决办法，所以就需要Mitigation。
这又正好是我以前研究的范围，所以，又会说出一大堆。对于Mitigation，其实，技术的根本就是要能从众多的流量中将攻击包和合法包分离出来，把攻击包抛弃掉，让合法包通过就性了。这就是根本，所以实际运用的技术就是要如何尽可能识别出攻击包，而又尽可能小地影响正常包。这又得来分析DDOS（甚至DOS）的方式和原理。基本又下面几种形式：
1、系统漏洞形成的DOS。这种特征固定，检测和防御也容易
2、协议攻击（一些跟系统处理相关，一些跟协议相关）。比如SYN FLOOD，碎片等。特征还好识别，检测和防御相对容易。比如SYN COOKIE、SYN CACHE，碎片可以抛弃。比如land攻击、smurf、teardrop等
3、bandwidth FLOOD。垃圾流量堵塞带宽，特征不好识别，防御不容易
4、基本合法的FLOOD。比3更难了，比如分布的Slashdot 。
实际的DDOS，一般都是多种方式结合的。比如SYNFLOOD，可能同时是bandwidth FLOOD。
影响防御的主要因素就是看特征是否能得到，比如1、2就相对好解决，一些基本不影响的使用的FLOOD，则可以很好被抛弃，比如ICMP FLOOD。但是，攻击发包工具如果将数据包更能伪装成合法包，那么就很难识别出来了。
一般的Mitigation方法也就是：
1、Filter。对于特征明显的，比如一些蠕虫等，在路由器上就可以搞定。当然，过滤是最终解决办法，只要识别出了攻击包，就是要把这些包过滤掉。
2、随机丢包。跟随机算法相关，好的算法可以让合法包受到更小影响
3、SYN COOKIE、SYN CACHE等特定防御办法。针对一些固定的攻击手段来防御和过滤。比如ICMP FLOOD、UDP FLOOD。SYN COOKIE等都是避免spoof问题，至少TCP还有三次握手，所以还好判断SPOOF
4、被动消极忽略。可以说也是一种确认是否被欺骗的办法。一般正常连接失败会重新尝试，但是攻击者一般不会尝试的。所以可以临时抛弃第一次连接请求而接受第二次或者第三次连接请求。
5、主动发送RST。对付SYN FLOOD的，比如一些IDS上。当然，实际不是有效的。
6、统计分析和指纹。这本来是研究的主要内容，但是最后陷入了算法牛角尖，因为主要是一个算法问题。通过统计分析的角度来得到指纹，然后根据指纹来抛弃攻击包，也是一种异常检测的技术。说得很简单，但是要不影响合法包也不容易，不至于变成了随机丢包。（其实当时考虑太过复杂，非得要详细分析出攻击包和合法包，实际不需要，只要过滤掉足够的攻击包，即便让攻击包通过，但只要不造成DOS就可以了。）这也是很多研究者研究的主要课题，目的也就是识别攻击包。
现在在回到securitytest提到的riverhead。关于riverhead的技术，我都只是从他们的白皮书上了解到的，但根据我的分析技术方法都没有超出上面提到的范围。
riverhead的核心方案就是检测 Detection、转移 Diversion 和 缓解 Mitigation，也就是检测到攻击，然后将流量转移到他们的产品guard上，然后通过guard进行Mitigation。
它的实现步骤，就是：
因为没有图，所以先定义一下，才能说清楚：
#靠近分布式拒绝服务源头的路由器为 远端路由器
#靠近受害者的路由器为 近端路由器
#Riverhead的Guard设备附属安装的路由器为 附属路由器
防御的步骤
1、首先检测到有DDOS发生，并了解到victim
2、Guard发送BGP通告到远端路由器（在victim的BGP通告设置前缀，并得到比原始BGP通告更高的优先权），表示从远端路由器到victim有新的路由，并且路由到Guard的loopback interface，所有到victim的都经过附属路由器转移到了Guard上
3、Guard检查流量，并且清除其中的攻击流量，然后把安全的流量转发到附属路由器上，在回到victim
其中核心就是Guard，技术就是白皮书中描述的MVP架构（Multi-Verification Process），也就是下面5个层次
过滤(Filtering) ：这个模块包含静态和动态的DDOS过滤。静态过滤，拦截non-essential流量，可以是用户定义的，或者是riverhead默认提供的。动态过滤则基于行为分析和流量的细节分析，通过增加对可疑流量的确认或拦截已经确认的恶意流量，来进行实时更新
反欺骗(Anti-Spoofing)：这个模块验证进入系统的数据包是否被欺骗的。Guard使用了独有的、有专利的源验证机制来避免欺骗。也通过一些机制来确认合法流量，消除合法数据包被抛弃
异常检测（Anomaly Recognition）：该模块监视所有没有被过滤和反欺骗模块抛弃的流量，将流量同平常纪录的基线行为进行比较，发现异常。基本原理就是通过模式匹配，区别来自black-hat和合法通讯之间的不同。该原理用来识别攻击源和类型，而且提出拦截这类流量的指南。
异常检测包括： 流量分类： |
协议分析（Protocol Analysis）：本模块处理异常检测中发现的可疑的应用方面的攻击，比如http攻击。协议分析也检测一些协议错误行为。
流量限制（Rate Limiting）：主要是处理那些消耗太多资源的源头流量。
所以，实际上最主要的内容就是异常检测中的统计分析，但是从上面看似乎没有多少特别的地方，但是，一定有很好的算法。比如FILTER，实际是对付一些很熟悉的有明显特征的攻击，反欺骗，就是对付syn flood这样的，说不定也是一个syn cookie模块，，但也许有更专利的技术。协议分析其实应该来说就比较弱了，但可以针对一些常见协议中的特定攻击，检测识别一些协议错误行为只是协议校验，这个很简单。流量限制则就是一种随机丢包，最无奈的办法，所以也是最后一个层次了。
因为这个产品主要是作Mitigation的，而不是ip traceback。但是可以判定还是有重要的问题，比如：
1、如何对付真正的bandwidth flood。如果路由器是千兆的，但是，攻击流量已经占了90%，只流下10%让合法使用，路由器已经先与Guard开始进行随机丢包了。（没办法，这是所有防御技术的瓶颈）
2、真正的攻击。真正的攻击是很难或者无法识别的。比如，基本跟正常形式一样的，如果和统计数据很接近，那么很难区别出来。还有一些攻击，比如反射式的邮件攻击等，这是完全合法的，但是很难分类出来。
