4.6 Limit Access to Routers

Protecting routers from being corrupted by remote attacks is important, but a more basic control overlooked by many network administrators is restricting who can access their routers. Many networks have fewer than five routers in place. In smaller networks a full-blown authentication system, like TACACS and RADIUS (covered in Chapter 6), is probably overblown. However, even in smaller networks, access to the router should be limited, both in terms of securing it against external unauthorized access and restricting personnel within your organization who have access.

An attacker who gains access to the network and is able to sniff, or guess, the router password can easily take the network offline, and may be able to damage an ISP's backbone. The same is true of an unknowledgeable or malicious employee who is given access to the networking equipment, or uses another employee's password. Because the potential for damage is greatest at the network level, this is where the most precautions should be taken.

4.6.1 Telnet, SSH, and HTML

Telnet should be disabled on routers, and SSH should be used to access them remotely. On Cisco routers SSH was introduced into IOS with Version 12.0.5. Other manufacturers, such as Juniper, have had SSH enabled from the start. Remember that enabling SSH on an interface is not enough; you also have to make sure you explicitly disable telnet. This will prevent anyone from accidentally logging in using telnet.

There are several steps involved in enabling SSH on a Cisco router.

 gw1(config)#ip domain-name example.com  gw1#crypto key generate rsa  gw1#config t  Enter configuration commands, one per line. End with CNTL/Z.  gw1(config)#ip ssh  gw1(config)#ip ssh timeout 60  gw1(config)#ip ssh authentication-retries 3 

Similarly on a Juniper router:

 services {       ssh {            root-login (allow  deny  deny-password);            protocol-version [v1 v2];            <connection-limit limit> ;                 <rate-limit limit>;                    }   } 

The first step is to set a domain name for the router. Only set the top-level domain, as the host name is already set ( gw1 in the example). The next step is to generate an Rivest-Shamir-Adelman (RSA) encrypted key in the exec mode. Finally, enter back into the configuration mode and enable SSH. Set the authentication time-out and the number of failed attempts.

Now that SSH has been enabled on the router, it is a good idea to disable telnet. Of course, make sure to test that SSH has been properly enabled before disabling telnet.

 gw1(config)#transport input ssh 

Secure remote login is now enabled for the router, and telnet is disabled. It is also a good idea to check with the router vendor to find out what version of the SSH protocol is enabled on its routers. SSH Version 1.0 has several security holes, including a root exploit. These will be discussed in detail in Chapter 11, but it is a serious enough problem to note that you should check with your vendor.

Many network devices include an HTML interface. The HTML interface is convenient because it gives users a graphical tool which can be used to manage the network device. This can be nice for users not familiar with the command line, but the truth is, because of limited processing power on the router, HTML interfaces tend to be slow and cumbersome, and cannot perform all of the tasks that can be done through the command line.

HTML interfaces also present a serious security risk. Like telnet, information transmitted during an HTML session is sent unencrypted. Again, anyone with a sniffer on the network will be able to gather username, password, and configuration information for the router. To further exacerbate this problem, many router vendors have separate default usernames and passwords for the HTML interface, which means that unless you specifically disable the HTML interface it can be a security hole, even if it is not used. On a Cisco router, the command is:

 gw1(config)#no ip http server 

If, for some reason, a web interface is required for configuration, consider asking your vendor for an SSL option, or try using a remote configuration tool that sends encrypted information between your workstation and the router.

Now that we have restricted the protocols people can use to access your router, the next step is to restrict the interfaces they can use to access it.

4.6.2 Restricting Interfaces

Whenever possible, remote access should be disabled for all public interfaces. If remote access to a router is needed, you should do it using the internal interface, or an out-of-band interface designated for remote administration. If you are using the out-of- band method, make sure the IP address is not advertised anywhere , and disable ICMP access to it, so it is not discovered by someone using a scanner.

If an out-of-band interface is out of the question, and you need to allow access to the public interface to make troubleshooting easier, it is a good idea to apply a strict access list to the virtual terminal on the public interface.

Different router vendors have different ways of restricting remote access to virtual terminals. Many vendors allow administrators to apply a standard ACL, as described earlier in the chapter, like you would to an interface, while others have special ACLS designated for virtual terminals only.

Cisco refers to an ACL for a virtual terminal as an access-class. Access-classes can be defined for incoming or outgoing traffic. This allows administrators to limit not only who can telnet into the system, but also where they can go once they have gained access.

An ACL for a virtual terminal is configured in the same manner as a standard access list, except administrators have to define which of the virtual terminal(s) it should be applied to (in Cisco-speak, which line(s) it should be applied to):

 access-list 50 permit 192.168.105.0 0.0.0.255 line 1  access-class 50 in 

This will only allow IP addresses in the 192.168.105.0 “255 netblock to open a virtual terminal on the router. As with interface-based ACLS, there is an implicit deny at the end of this ACL.

Of course, there can be problems with creating this type of ACL. If your home ISP assigns a dynamic IP address every time a connection is made, you may not be able to create a single rule like the one in the example. If you begin adding every netblock you may get assigned into your virtual terminal ACL, you will effectively render it useless.

One way to avoid this is to use dynamic access lists. Dynamic access lists, also called lock and key security, allow a user to make a connection to the router, and authenticate. If the authentication is successful, then a temporary access list is created allowing the user to access the router and the network beyond the router. When the user has finished the connection, the dynamic access list is automatically deleted, after a time-out period.

A dynamic ACL allows administrators to keep router configuration cleaner by not having to add additional ACL entries that may become security holes. Of course, you are opening the public interface on your router to anyone from your remote IP address with a password, so it is still important to send encrypted data to your router. Also, using a dynamic ACL means that good password security is even more important. Anyone who can successfully authenticate will now be able to access the router. Enable them only if absolutely necessary.

NOTE

Another way to increase router security is to limit router access to a single machine located in the firewall demilitarized zone (DMZ). The machine can be secured using whatever server firewall software necessary, and access to the routers can be restricted to SSH. This provides a very secure solution.