| 2.1 |  | General Router and Switch Security |
| 2.1.3 |  | Controlling access |

| In addition to protecting physical access, secure configurations are necessary to protect access to routers and switches. Anyone who can log in to a router or switch can display information that should not be made available to the general public. It is important to realize that any router or switch, by default, is an open system. A user who can log in may be able to use the device as a relay for further network attacks. Anyone who can obtain privileged access to the router or switch can reconfigure it. To prevent inappropriate access, administrators need to control logins.

Although most access is disabled by default, there are exceptions. They are sessions from directly connected, asynchronous terminals, such as the console terminal, and sessions from integrated modem lines.

Console ports
The console port of an IOS device has special privileges. In particular, if a

Break or ctrl-Break signal is sent to the console port during the first few seconds after a reboot, the password recovery procedure can easily be used to take control of the system. Attackers who can interrupt power or induce a system crash, and who have access to the console port via a hardwired terminal, a modem, a terminal server, or some other network device, can take control of the system, even if they do not have physical access to it or the ability to log in to it normally .

It follows that any modem or network device that gives access to the console port must be secured to the same degree as the router. At a bare minimum, any console modem should require the dialup user to supply a password for access, and the modem password should be carefully managed.

General access
There are more ways of connecting to routers than users may realize. Cisco IOS software, depending on the configuration and software version, may support connections through Telnet, rlogin, SSH, non-IP-based network protocols like LAT, MOP, X.29, and V.120. Connections may also be supported by way of local asynchronous connections or modem dial-ins. Additional protocols for access are always being added. Telnet access occurs not only on the standard TCP port 23, but on a variety of higher-numbered ports as well .

The best way to protect a system is to make certain that appropriate controls are applied on all lines, including vty lines and tty lines. Administrators should usually make sure that logins on all lines are controlled using some sort of authentication mechanism, even on machines that are supposed to be inaccessible from untrusted networks. This is especially important for vty lines and for lines connected to modems or other remote access devices.

Logins may be completely prevented on any line by configuring the router with the

login and no password commands. This is the default configuration for vtys, but not for ttys. There are many ways to configure passwords and other forms of user authentication for tty and vty lines.

Controlling TTYs and AUX
Local asynchronous terminals are less common than they once were, but they still exist in some installations. Even if the terminals are physically secured, the router should be configured to require users on local asynchronous terminals to log in before using the system. Most tty ports in modern routers are either connected to external modems, or are implemented by integrated modems. Securing these ports is even more important than securing local terminal ports .

To disable the reverse Telnet feature, apply the configuration command

transport input none to any asynchronous or modem line that should not be receiving connections from network users. If at all possible, do not use the same modems for both dialing-in and dialing-out, and do not allow reverse Telnet connections to the lines used for dialing-in.

Controlling VTYs
Any vty should be configured to accept connections only with the protocols actually needed. This is done with the

transport input command. For example, a vty that was expected to receive only Telnet sessions would be configured with transport input telnet, while a vty permitting both Telnet and SSH sessions would have transport input telnet ssh. If the software supports an encrypted access protocol such as SSH, it may be wise to enable only that protocol, and to disable Telnet. It is also a good idea to use the ip access-class command to restrict the IP addresses from which the vty will accept connections.

A Cisco IOS device has a limited number of vty lines, usually five. When all of the vtys are in use, no more additional remote connections can be established. This creates the opportunity for a DoS attack. If an attacker can open remote sessions to all the vtys on the system, the legitimate administrator may not be able to log in. The attacker does not have to log in to do this, the sessions can simply be left at the login prompt.

One way of reducing this exposure is to configure a more restrictive

ip access-class command on the last vty line in the system. The last vty might be restricted to accept connections only from a single, specific administrative workstation, whereas the other vtys might accept connections from any address in a corporate network .

Another useful tactic is to configure vty timeouts using the

exec-timeout command . This prevents an idle session from consuming the vty line indefinitely. Although its effectiveness against deliberate attacks is relatively limited, it also provides some protection against sessions accidentally left idle. Similarly, enabling Transmission Control Protocol (TCP) keepalives on incoming connections, using the service tcp-keepalives-in command, can help guard against both malicious attacks and orphaned sessions caused by remote system crashes.

Disabling all non-IP-based remote access protocols, and using SSH, SSL, or IP Security (IPSec) encryption for all remote connections to the router can provide complete vty protection.