Eigrp恶意插入路由和致瘫攻击测试（五）

Eigrp恶意插入路由和致瘫攻击测试（五）

 

六、修改拓扑验证能否触发和攻击脚本一样的现象

拓扑修改如下：

我们插入R3的目的是分别在R3的f0/0上启用248、249地址，测试在接口打开和关闭时对R0的影响，通过分析现象确认是否和攻击脚本一致。

 

1、192.168.1.248进网。模拟一个正常的邻居下线时的状态。

启动R3的f0/0接口，这个就不比说了，只是多了个邻居的协商，并通告新的网络和路由，不会触发goodbye，这里就不演示了。

 

关闭R3的f0/0接口。

R3#clear ip eigrp 1 neighbors

抓包看看：

R3发出的是一个标准的K值全部是255的goodbye包。

观察另外两个路由器的现象：

R0

Feb  1 08:56:22.286: IP: s=192.168.1.248 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
Feb  1 08:56:22.294: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.248
Feb  1 08:56:22.298:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Feb  1 08:56:22.298:        Inteface goodbye received
Feb  1 08:56:22.298: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.248 (FastEthernet0/0) is down: Interface Goodbye received
Feb  1 08:56:22.298: DUAL: linkdown: start - 192.168.1.248 via FastEthernet0/0
Feb  1 08:56:22.298: DUAL: Destination 192.168.0.0/16
Feb  1 08:56:22.302: DUAL: Destination 172.16.0.0/16
Feb  1 08:56:22.306: DUAL: linkdown: finish

 

R1

Feb  1 08:56:22.233: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.248
Feb  1 08:56:22.237:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Feb  1 08:56:22.241:        Inteface goodbye received
Feb  1 08:56:22.241: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.248 (FastEthernet0/0) is down: Interface Goodbye received
Feb  1 08:56:22.245: DUAL: linkdown: start - 192.168.1.248 via FastEthernet0/0
Feb  1 08:56:22.253: DUAL: Destination 192.168.0.0/16
Feb  1 08:56:22.257: DUAL: Destination 172.16.0.0/16
Feb  1 08:56:22.261: DUAL: Destination 172.16.0.0/24
Feb  1 08:56:22.265: DUAL: linkdown: finish

可以看到，两个路由器几乎在同时收到了248的goodbye，因此做了终止路由选择动作。以上过程非常符合我们对eigrp的认识。

 

2、192.168.1.249进网。模拟攻击方法一中网内出现不同mac地址的249时，会不会触发goodbye。

我们在R3的f0/0接口上直接修改地址：

ip add 192.168.1.249 255.255.0.0

（1）R3接口地址改变，eigrp重新计算，发送goodbye信息：

R3

.Feb  2 00:18:02.474: IP: s=192.168.1.249 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast
.Feb  2 00:18:02.478: EIGRP: Sending HELLO . FastEthernet0/0
.Feb  2 00:18:02.482:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0

（指令生效，R3已经把249当成自己的local，向外组播）

其实根据mac地址确定，这个包时R3已经向外发送goodbye信息。

 

（2）R0本来向R1路由的172.16失去目标（由于被假的249顶替），发出查询数据：

R3收到查询信息，并再次发出goodbye信息：

R3

.Feb  2 00:18:02.510: DUAL: rcvupdate: 192.168.0.0/16 via Connected metric 4294967295/4294967295
.Feb  2 00:18:02.514: DUAL: Find FS for dest 192.168.0.0/16. FD is 281600, RD is 281600
.Feb  2 00:18:02.518: DUAL:     0.0.0.0 metric 4294967295/4294967295 not found Dmin is 4294967295
.Feb  2 00:18:02.518: DUAL: Peer total 2 stub 0 template 0
.Feb  2 00:18:02.522: DUAL: Dest 192.168.0.0/16 (No peers) not entering active state.
.Feb  2 00:18:02.526: DUAL: Removing dest 192.168.0.0/16, nexthop 0.0.0.0, infosource 0.0.0.0
.Feb  2 00:18:02.530: DUAL: No routes.  Flushing dest 192.168.0.0/16
.Feb  2 00:18:02.534: IP: s=192.168.1.249 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast
.Feb  2 00:18:02.538: EIGRP: Sending HELLO . FastEthernet0/0

 

（3）R0终于明白过来，也开始进入down程序：

R0

Feb  2 00:18:02.534: IP: s=192.168.1.249 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
Feb  2 00:18:02.542: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.249
Feb  2 00:18:02.546:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Feb  2 00:18:02.550:        Inteface goodbye received
Feb  2 00:18:02.550: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.249 (FastEthernet0/0) is down: Interface Goodbye received
Feb  2 00:18:02.554: DUAL: linkdown: start - 192.168.1.249 via FastEthernet0/0
Feb  2 00:18:02.562: DUAL: Destination 192.168.0.0/16
Feb  2 00:18:02.566: DUAL: Destination 172.16.0.0/16
Feb  2 00:18:02.570: DUAL: Find FS for dest 172.16.0.0/16. FD is 307200, RD is 307200
Feb  2 00:18:02.574: DUAL:      192.168.1.249 metric 4294967295/4294967295 not found Dmin is 4294967295
Feb  2 00:18:02.574: DUAL: Peer total 1 stub 0 template 1
Feb  2 00:18:02.578: DUAL: Dest 172.16.0.0/16 entering active state.
Feb  2 00:18:02.582: DUAL: Set reply-status table. Count is 1.
Feb  2 00:18:02.582: DUAL: Not doing split horizon
Feb  2 00:18:02.586: DUAL: linkdown: finish

 

（4）与此同时，R1也收到了假249的包和R0的查询包，一直做忽略和更新通告处理：

R1

Feb  2 00:18:02.595: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.249
Feb  2 00:18:02.599:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
Feb  2 00:18:02.599: EIGRP: Packet from ourselves ignored
Feb  2 00:18:02.667: IP: s=192.168.1.251 (FastEthernet0/0), d=224.0.0.10, len 67, rcvd 2
Feb  2 00:18:02.671: EIGRP: Received QUERY . FastEthernet0/0 nbr 192.168.1.251
Feb  2 00:18:02.671:   AS 1, Flags 0x0, Seq 111/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
Feb  2 00:18:02.671: EIGRP: Enqueueing ACK . FastEthernet0/0 nbr 192.168.1.251
Feb  2 00:18:02.671:   Ack seq 111 iidbQ un/rely 0/0 peerQ un/rely 1/0
Feb  2 00:18:02.671: IP-EIGRP(Default-IP-Routing-Table:1): Processing incoming QUERY packet
Feb  2 00:18:02.671: IP-EIGRP(Default-IP-Routing-Table:1): Int 172.16.0.0/16 M 4294967295 - 256000 4294967295 SM 4294967295 - 256000 4294967295
Feb  2 00:18:02.675: DUAL: dest(172.16.0.0/16) not active
Feb  2 00:18:02.675: DUAL: rcvquery: 172.16.0.0/16 via 192.168.1.251 metric 4294967295/4294967295, RD is 281600
Feb  2 00:18:02.679: DUAL: send REPLY(r1/n1) about 172.16.0.0/16 to 192.168.1.251
Feb  2 00:18:02.683: IP: s=192.168.1.249 (local), d=192.168.1.251 (FastEthernet0/0), len 40, sending
Feb  2 00:18:02.687: EIGRP: Sending ACK . FastEthernet0/0 nbr 192.168.1.251
Feb  2 00:18:02.691:   AS 1, Flags 0x0, Seq 0/111 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
Feb  2 00:18:02.695: EIGRP: Enqueueing REPLY . FastEthernet0/0 nbr 192.168.1.251 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 7-7
Feb  2 00:18:02.699: EIGRP: Requeued unicast . FastEthernet0/0
Feb  2 00:18:02.703: EIGRP: Forcing multicast xmit . FastEthernet0/0
Feb  2 00:18:02.703: IP-EIGRP(Default-IP-Routing-Table:1): 172.16.0.0/16 - do advertise out FastEthernet0/0
Feb  2 00:18:02.707: IP-EIGRP(Default-IP-Routing-Table:1): Int 172.16.0.0/16 metric 281600 - 256000 25600
Feb  2 00:18:02.707: IP: s=192.168.1.249 (local), d=192.168.1.251 (FastEthernet0/0), len 67, sending
Feb  2 00:18:02.707: EIGRP: Sending REPLY . FastEthernet0/0 nbr 192.168.1.251
Feb  2 00:18:02.707:   AS 1, Flags 0x0, Seq 65/111 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 7-7
Feb  2 00:18:02.711: IP: s=192.168.1.249 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
Feb  2 00:18:02.719: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.249
Feb  2 00:18:02.723:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
Feb  2 00:18:02.727: EIGRP: Packet from ourselves ignored
Feb  2 00:18:02.767: IP: s=192.168.1.249 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
Feb  2 00:18:02.775: EIGRP: Received HELLO . FastEthernet0/0 nbr 192.168.1.249
Feb  2 00:18:02.779:   AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
Feb  2 00:18:02.779: EIGRP: Packet from ourselves ignored

 

（5）随后三者的状态：

R0

Feb  2 00:55:37.910: IP: s=192.168.1.249 (FastEthernet0/0), d=192.168.1.251 (FastEthernet0/0), len 40, rcvd 3
Feb  2 00:55:37.918: EIGRP: Received UPDATE . FastEthernet0/0 nbr 192.168.1.249
Feb  2 00:55:37.922:   AS 1, Flags 0x1, Seq 72/136 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0, last received seq 72, out of sequence, this seq 72

R0不断的收到起死回生后的R3的更新，但是由于真假249的交错数据，R0发现序列号不对，不断丢弃更新，从而始终在反复重启eigrp状态。

R1和R3则不断的发送hello更新，企图争先和R0建立邻居关系。

这样，网内的路由不断翻滚，并伴随路由器报出IP地址重叠的消息。

 

归根结底，通过修改路由拓扑的方法并不能重现攻击时的状态，这次R0明显的报告出了数据包序列号不同步等方面的问题，而非地址动态等毛病。

 

七、总结

这次的实验中我们设计了几个环节：

1、eigrp恶意路由的插入；这个没有悬念，非常顺利。

2、eigrp的hellodos攻击，这个我们认识到了不是真正的dos，而是在eigrp收到一个构造的包，包的源是已经形成邻接关系的邻居，目的不是224.0.0.10而是自身eigrp进程接口地址时，会触发本机发出goodbye，同时报告地址动态/静态变化。

3、eigrp的ipgoodbye攻击，这个我们也发现了并非全255的值，但是后面跟上了一段攻击脚本自身的数据，同样引发了被攻击设备识别为goodbye的现象。

4、最后我们自己修改环境，模拟网内插入一个同样地址的设备，发现现象又和上述情况不同，新插入的设备和被攻击路由器交互，被攻击路由器收到两个相同设备的数据而困扰，处于丢弃状态，而另外真假两个路由器则不断的试图联系和更新对端。

 

认识：

1、此攻击脚本有很多忽悠的成分，说是dos其实根本不是，说ipgoodbye其实组包格式不对；其他参数由于和攻击无关还未一一测试。

2、eigrp在算法上有很多值得深入研究的，目前认识还比较浅薄，尤其在什么情况下触发goodbye在本次实验中并未达成共识。

3、本次实验的几种现象都是攻击者较为容易模拟的现象，证明eigrp在某些情况下存在容易引发路由翻滚的弊端。

 

建议：

1、严格匹配邻居关系，锁定IP地址，合理规划网内eigrp布局。

2、打开认证，不要怕麻烦，安全在于意识。尤其在局域网速率飞速上涨的今天，一点加解密算法不会对网络和设备荷载造成很大的影响。

3、加强管理，随时关注网内数据。

     本文转自 beansprouts 51CTO博客，原文链接：http://blog.51cto.com/netwalk/128214 ，如需转载请自行联系原作者