利用现有的网络环境，包括图1中的GSR、OSR、6509、4507R和2950，在本次测试中，Guard和Detector只与图1的一台6509和4507R相连，在GSR上做了少量路由的改动，保证来往于被保护对象的数据流总是从我们指定的6509经过，避免由于2台6509的Load Balance造成测试误差。

　　由于Guard和Detector上均有2个GE接口，因此，我们可以配置Guard和Detector同时与两台6509相连(此时Guard不采用串联在4507R和6509之间的方式，而是单臂连接到6509上，进入到Guard的数据流从同一个接口返回)，这样，对整个IDC的保护将更加完整(图4)。

图4

　　客户端测试手段:FTP客户端软件(leapftp)、Ping;

　　服务器端测试手段: FTP服务器端软件(3CServer)、Ping、Windows任务管理器;

　　攻击工具:DDoS攻击工具箱(基于Linux)。

　　1. 发起网络攻击时

　　1)Client端:丢包率为0，时延<10ms，表现正常。下载速率>=2Mbps，工作正常。

　　2)Server端:CPU使用率约等于0%，网卡带宽利用率约等于0%。

　　2. 攻击开始，未进行保护

　　1)Client端:所有的Ping均time out,说明网络严重拥塞。FTP客户端无法与服务器建立连接，原因在于服务器资源耗尽(CPU和内存)。

　　2) Server端:Ping时延巨大(2509ms，相对于正常的<10ms，大部分Ping被time out,显示网络严重拥塞，以及自身资源耗尽，如图5中显示no resource)。CPU利用率非常高，达到96%，甚至100%，网卡带宽利用率高(50%以上，相对于正常的约0%)，如图6所示。

图5

图6

　　3. 攻击进行中，进行保护

　　1)Guard:在图7中可以看到定义为Server的Zone(221.5.248.37)处于被保护状态，从图表可以看到目标为Server的数据流为50Mbps，非法的数据流约为50Mbps，并且都已经被过滤。相应的效果可以从Server和Client看到。

图7

　　通过从Client发起到Server的Trace，我们可以在图8中看到，数据流确实流经Guard(10.0.2.1)。

图8

　　2)Detector:从图9中可以看到，定义为Server的Zone被检测到处于被攻击状态。并发起到Guard的SSH连接，激活Guard对于Server Zone的保护动作。

图9

　　3)Client端:Ping工作正常，时延很低，丢包率为0。FTP下载工作正常，与Server正常建立连接，下载的速率在2Mbps左右。

　　4)Server端:Ping工作正常，时延低，丢包率为0。CPU利用率维持在一个比较低的水平(32%，此处不是0，是由于进行FTP下载)，网卡带宽较低(相对于未被保护的50%)。

　　本次测试中采用了DDoS攻击工具箱的多种其它攻击方式分别进行测试(包括Spoofed/Non-Spoofed的TCP、UDP、ICMP组合攻击，总共有14攻击方式，基本包含了目前已有的所有DDoS攻击方式)，测试的现象与结果与上述基本相同，不再一一描述。

　　四、测试结论

　　由思科的Guard和Detector组成的DDoS攻击防御方案可以非常有效地减轻或消除目前流行的各种DDoS网络攻击，提高IXC的安全性和可靠性。

　　本次测试没有开启Guard和Detector的学习功能来进行精确的流量模型建立和策略设定，而是采用了系统缺省自带的策略参数，已经取得了很好的防御效果，如果时间允许利用两天时间专门用于流量模型建立和策略参数设定，效果将会更好。

　　通过对信息流进行比较，找出正常流量模式、行为与协议执行情况，发现并阻止恶意流量而不影响合法的交互过程。防护器作为一个资源共享的设备，它可以根据需要动态地对网络中的网络设备资源和服务器进行保护，谁被攻击，就去保护谁，既可保护客户的服务器，又可保护客户的连接带宽。