It’s all very well installing fancy IDS systems, keeping your anti-virus signatures up to date and making sure your firewalls are doing what they should, but if you don’t protect your routers, and safeguard the routing protocols that they run, you may be wasting your time.

Since your routers will determine how traffic flows round your network, you need to be sure that they have the correct information as nothing will destroy your network faster than someone pretending to have the best route to part of your network and hijacking all your data. The following sections detail some configuration steps you can take to reduce the risks.

For a start, make sure that you are receiving and sending out only routing advertisements that make sense. You do not want your routers to be accepting routes from the outside world to any RFC1918 addresses (10.x.x.x, 172.16.x.x to 172.31.x.x or 192.168.x.x), regardless of who they come from. These should not be appearing out on the Internet and your ISP should be filtering them out. But better you explicitly deny them too than be complacent.

Similarly anyone trying to send you a default route (all zeros) should be ignored, and you may have your own reasons to block routes to other, albeit valid, networks. If you don’t want your users accessing a part of the network, then stopping their local router from seeing it is a start, although this should be used in conjunction with other security measures, typically a firewall.

You should also think about the routes you send out. You are likely to be using NAT to protect your internal addresses, and only advertising a subset of all the networks you have but even then, you may want to filter out certain networks -don’t by default just advertise everything you have out onto the Internet for anyone to pick up.

Black Holing
Normally ‘black holes’ are a bad thing that you make sure you design out of your network topology. However they can be useful as a filtering mechanism as a less CPU-intensive alternative to extensive access lists. All you need to do is configure routes that you do not want traffic forwarded to, and point them at a null interface. This uses less processor cycles because the traffic is routed to that interface, which doesn’t exist, and then immediately discarded, rather than being routed and then run through an access list. For this reason, service providers often use it as one of the tools to mitigate against DoS attacks.

Unicast RPF
Another way to ensure that traffic coming into your network has at least a reasonable chance of being valid, and therefore less likely to cause harm, is to do a Unicast RPF check. RPF, or Reverse Path Forwarding, is the mechanism by which a router looks at a packet’s source IP address, takes account of the interface that packet appeared on and compares these with the known routed path to that source’s subnet. If the router does not have a path back to that network over the interface from which the packet appeared, then the packet will be dropped. This prevents a hacker from using spoofed addresses to try to access your network. The unicast reference is because RPF is used extensively in multicast networks as the means by which the routers build up the paths from receivers to sources.

The only thing you need to be aware of when configuring URPF is your network topology, and ensure that there is no valid way that a router might receive traffic asymmetrically over a link that is not the best path back.

Broadcast control
Broadcasts are by themselves a potential security problem. At best they are a waste of bandwidth and CPU resources on all the hosts that don’t need to see the data. At worst they can bring your network down.

Routers, of course, do not pass broadcasts by default. However, since we need some broadcasts to be allowed to traverse the network, for DHCP requests for example, or for Wake-On-LAN use, we tend to configure ways of relaying broadcast traffic - UDP Broadcast Forwarding, or IP Helper Addresses for instance - depending on your router vendor of choice. Be aware that when you do this, some implementations by default enable broadcast relay for a set of protocols. You have to manually disable the ones you do not want forwarded, otherwise you may be passing data that you do not wish to pass.

You may also want to disable the capability of sending directed broadcasts. These are local broadcasts - i.e. to all local hosts on a subnet - sent out of the appropriate router interface. Disabling this will limit the potential for LAN-based packet flooding, and might seem an obvious configuration choice. However, there are some applications (e.g. Wake-On-LAN again) that have been written to rely on this mechanism, so you might not be able to disable it.

Before you apply any of these security mechanisms you must understand your network topology and applications, to ensure that what you configure does not impact the correct working of your network services. However, they will add another level of protection from malicious attacks and careless users.