Remote Administrative Access with Telnet and SSH


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.

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