Securing Remote Administrative Access To Routers


Securing Administrative Access to Routers
Network administrators can connect to a router or switch locally or remotely. Local access through the console port is the preferred way for an administrator to connect to a device to manage it because it is secure. As companies get bigger and the number of routers and switches in the network grows, the administrator workload to connect to all the devices locally can become overwhelming.

Remote administrative access is more convenient than local access for administrators that have many devices to manage. However, if it is not implemented securely, an attacker could collect valuable confidential information. For example, implementing remote administrative access using Telnet can be very insecure because Telnet forwards all network traffic in clear text. An attacker could capture network traffic while an administrator is logged in remotely to a router and sniff the administrator passwords or router configuration information. Therefore, remote administrative access must be configured with additional security precautions.
To secure administrative access to routers and switches, first you will secure the administrative lines (VTY, AUX), then you will configure the network device to encrypt traffic in an SSH tunnel.

Remote Administrative Access with Telnet and SSH
Having remote access to network devices is critical for effectively managing a network. Remote access typically involves allowing Telnet, Secure Shell (SSH), HTTP, HTTP Secure (HTTPS), or SNMP connections to the router from a computer on the same internetwork as the router.
If remote access is required, your options are as follows:
Establish a dedicated management network. The management network should include only identified administration hosts and connections to infrastructure devices. This could be accomplished using a management VLAN or by using an additional physical network to connect the devices to.
Encrypt all traffic between the administrator computer and the router. In either case, a packet filter can be configured to only allow the identified administration hosts and protocol to access the router. For example, only permit the administration host IP address to initiate an SSH connection to the routers in the network.
Remote access not only applies to the VTY line of the router, it also applies to the TTY lines and the auxiliary (AUX) port. TTY lines provide asynchronous access to a router using a modem. Although less common than they once were, they still exist in some installations. Securing these ports is even more important than securing local terminal ports.
The best way to protect a system is to ensure that appropriate controls are applied on all lines, including VTY, TTY, and AUX lines.
Administrators should make sure that logins on all lines are controlled using an 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 and the AUX port. Therefore, if these lines are not required, ensure that they are configured with the login and no password command combination.
Controlling VTYs
By default, all VTY lines are configured to accept any type of remote connection. For security reasons, VTY lines 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, and a VTY permitting both Telnet and SSH sessions would have transport input telnet ssh configured.
The first configuration example displays how to configure the VTY to only accept Telnet and SSH connections, while the second example displays how to configure the VTY to only accept SSH connections. If the Cisco IOS image on a router supports SSH, it is strongly advisable to enable only that protocol.

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 the last VTY line to accept connections only from a single, specific administrative workstation, whereas the other VTYs can accept connections from any address in a corporate network. This ensures that at least one VTY line is available to the administrator. To implement this, ACLs, along with the ip access-class command on the last VTY line, must be configured. This implementation is discussed in Chapter 5.

Another useful tactic is to configure VTY timeouts using the exec-timeout command. This prevents an idle session from consuming the VTY indefinitely. Although its effectiveness against deliberate attacks is relatively limited, it provides some protection against sessions accidentally left idle. Similarly, enabling TCP keepalives on incoming connections by using the service tcp-keepalives-in command can help guard against both malicious attacks and orphaned sessions caused by remote system crashes.
The configuration displays how to set the executive timeout to 3 minutes and enable TCP keepalives.

Implementing SSH to Secure Remote Administrative Access
Traditionally, remote administrative access on routers was configured using Telnet on TCP port 23. However, Telnet was developed in the days when security was not an issue. For this reason, all Telnet traffic is forwarded in plain text.
SSH has replaced Telnet as the best practice for providing remote router administration with connections that support strong privacy and session integrity. SSH uses port TCP 22. It provides functionality that is similar to that of an outbound Telnet connection, except that the connection is encrypted. With authentication and encryption, SSH allows for secure communications over an insecure network.
Not all Cisco IOS images support SSH. Only cryptographic images can. Typically, these images have image IDs of k8 or k9 in their image names. Image names are discussed in Section 5.
The SSH terminal-line access feature enables administrators to configure routers with secure access and perform the following tasks:
Connect to a router that has multiple terminal lines connected to consoles or serial ports of other routers, switches, and devices.
Simplify connectivity to a router from anywhere by securely connecting to the terminal server on a specific line.
Allow modems attached to routers to be used for dial-out securely.
Require authentication to each of the lines through a locally defined username and password, or a security server such as a TACACS+ or RADIUS server.
Cisco routers are capable of acting as the SSH client and server. By default, both of these functions are enabled on the router when SSH is enabled. As a client, a router can SSH to another router. As a server, a router can accept SSH client connections.

Configuring SSH Security
To enable SSH on the router, the following parameters must be configured:
Hostname
Domain name
Asymmetrical keys
Local authentication
Optional configuration parameters include:
Timeouts
Retries
The following steps configure SSH on a router.
Step 1: Set router parameters
Configure the router hostname with the hostnamehostname command from configuration mode.
Step 2: Set the domain name
A domain name must exist to enable SSH. In this example, enter the ip domain-name cisco.com command from global configuration mode.
Step 3: Generate asymmetric keys
You need to create a key that the router uses to encrypt its SSH management traffic with the crypto keygenerate rsa command from configuration mode. The router responds with a message showing the naming convention for the keys. Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. As a best practice, Cisco recommends using a minimum modulus length of 1024. You should be aware that a longer modulus takes longer to generate and to use, but it offers stronger security.
Step 4: Configure local authentication and vty
Then configure the local authentication and vty.
Step 5: Configure SSH timeouts (optional)
Timeouts provide additional security for the connection by terminating lingering, inactive connections. Use the command ip ssh time-outsecondsauthentication-retriesinteger to enable timeouts and authentication retries. Set the SSH timeout to 15 seconds and the amount of retries to 2:
To connect to a router configured with SSH, you have to use an SSH client application such as PuTTY or TeraTerm. You must be sure to choose the SSH option and that it uses TCP port 22.
Using TeraTerm to connect securely to the R2 router with SSH, once the connection is initiated, the R2 displays a username prompt, followed by a password prompt. Assuming that the correct credentials are provided, TeraTerm displays the router R2 user EXEC prompt.

0 comments:

Post a Comment

 

NBA Live Streaming. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com | Distributed by Blogger Templates Blog