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.