Problem solve Get help with specific problems with your technologies, process and projects.

Using passive-interface to prevent DoS

How to use the passive-interface command to prevent Denial of Service attacks.

When configuring routing protocols such as EIGRP or OSPF, you will probably have many 'stub' interfaces. These are subnets in your network with only a single router on them, but typically lots of hosts. Which means, the only way out is through the router. If there's only a single router, then obviously, that router does not need to broadcast its 'hellos' or spend CPU and bandwidth trying to find neighbors that don't exist… or rather, shouldn't exist. Nevertheless, you still must configure a 'network' statement in your router configuration so that the stub subnets are advertised throughout your network.

To do this, use the "passive-interface" command in your router configuration. This way, the 'network' statement includes the interface in the routing protocol's algorithm, but the interface becomes passive. The really important advantage of this, is that most administrators don't bother to configure authentication for neighbors and if they do, they don't use anything stronger than clear text passwords which are easily sniffed. This makes it easy for an attacker to put a router on your network and advertise a default route to you, effectively creating a black hole. This can also easily happen when novice administrators start playing with the routing protocols on their Windows and Linux servers. Simply put, if a router interface isn't sending hellos, it won't form an adjacency, which means you'll avoid this easy denial of service.

A much better way to do this is to use the command "passive-interface all", which makes ALL interfaces on a router passive, and then use the "no passive-interface" command to enable specific interfaces. This is a good idea because many routers today are really layer 3 switches, with an uplink or two and lots of VLANs. It's easier and safer to disable them all, and then specifically enable your uplink or trunk, than to remember to explicitly disable every unnecessary interface.

Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex.

This was last published in May 2004

Dig Deeper on Network Security Monitoring and Analysis