The last two articles focussed on IPsec. IPsec can be used between routers to secure and encrypt communications across the Internet. It can also be used to secure access by your users across the Internet. The articles can be found at:
Secure Shell or SSH is another way to encrypt and protect passwords being
sent across the Internet. SSH for PC clients often can tunnel other protocols
inside its encrypted telnet-like session. This is one way to secure POP,
SMTP and FTP across the Internet, perhaps at lower cost than with IPsec,
since there are free or inexpensive SSH clients readily available. We'll
talk about another use for SSH below.
| Soapbox: Network Security I'm seeing increased press attention to Enterprise Security, and the reluctance of management to fund adequate security efforts. Meanwhile, network managers have enough to do, with Security being a big, messy, highly political area. As in, "the nasty green alligators are bad enough, who wants to go mess around with the really big ugly red ones over there?" Nonetheless, with increasing enterprise involvement and exposure through e-commerce, it may be time to start thinking about and pushing for tighter security again. Personal prediction is, we're going to see some security flaps in the press. We may also be going to see some CYA effort to stave off negligence suits: certification for network security staff is apparently one mini-trend. Adequately staffing security with personnel is a first step. Training such staff is a second step (conflict of interest alert: I work for a training company, but these are my own words). Senior staff are really needed, since the position is not just technical, but if done properly cuts across boundaries. The mix of network security needs, application security needs, and the interaction with profit/loss and business practices can be touchy ground, indeed. Yet are there experienced people available? |
So we'll focus on doing what we can to tighten up security. This month's article is about several tools that can help with secure management of routers. The article consists of the following short topics:
There is an alternative: out-of-band management of devices (routers and switches). The SAFE architecture document (see link below) at Cisco discusses this. Creating and using a separate VLAN for management traffic and isolating management traffic from user traffic is a good idea. Even with such measures, if your management traffic needs to go through a router and across a public subnet to get to the management stations, you might think about encrypting the traffic.
SAFE Architecture link: http://www.cisco.com/warp/public/cc/so/cuso/epso/sqfr/safe_wp.htm
If you're running TFTP, storing configuration files in the TFTP directory is insecure. Transferring the files by TFTP isn't too secure either, since the text crosses the network unencrypted. Including passwords. Running read-write SNMP without encryption is just asking for trouble. Using IPsec protects all such traffic.
Support for Secure Shell (version 1) was added to Cisco IOS Release 12.1(1) T, for the 1700, 2600, 3600, 7200, 7500, and ubr920 series routers. Secure Shell (SSH) allows administrators secure encrypted access to remote routers. The SSH connection is very similar to inbound telnet, and commercial or freeware clients are readily available for PC's and workstations. This is a nice alternative to the much more costly one-time password products, for those whose security needs are not as stringent. It also encrypts the session traffic, so that an observer cannot learn passwords from watching configuration commands or watching your session as you do a "show run" command. And SSH is inherently much more secure than rsh, which some use for scripted router configuration and remote execution of show commands.
The SSH implementation currently uses only user/password authentication, which can be done via TACACS+ or RADIUS. It supports DES and 3DES encryption.
hostname AtlantaWAN1
ip domain-name somecorp.com
The next step is generating an RSA key pair for the router. This is done in EXEC mode with the command
crypto key generate rsa
Use the command "crypto key zeroize rsa" if you wish to delete the key. However, this will disable the SSH server. If you do zeroize the key, you may need to re-enable SSH on the vty ports:
line vty 0 4
transport input ssh
Once we have an RSA key pair, we can then enable SSH server with
ip ssh
Options include
ip ssh timeout seconds
ip ssh authentication-retries number-of-retries
The timeout default is 120 seconds, and only applies to the SSH negotiation phase. Once the EXEC session is started, the standard vty idle timeout (default 10 minutes) applies. The authentication-retries default is 3, and can be set as high as 5. Each SSH session uses a vty, which normally number 0-4, therefore there is a maximum of 5 simultaneous SSH sessions.
To check that SSH has been enabled, and to show existing SSH sessions, use the command
show ip ssh
To terminate an existing SSH session, use the command
disconnect ssh session-number
with the session number from the show ip ssh command. The clear line vty number command can also be used.
Debug support: debug ip ssh.
For documentation and details, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/sshv1.htm
For SSH client to be available, SSH server (see above) has to be enabled. An encryption image supporting IPsec is also required (so the router contains DES/3DES support).
Using the SSH client requires no configuration. The client is initiated in EXEC mode with the following command syntax:
ssh [-l userid] [-c {des | 3des}] [-o numberofpasswdprompts n] [-p portnum] {ipaddr | hostname} [command ]
The userid parameter is the user login to use on the remote computer, if different than present userid. The -c option selects the encryption technique (56i or k2 DES or 3DES image required). The portnum is the destination port (default 22). The -l numberofpasswdprompts n number is how many password prompts before session termination, and is optional. The ipaddr or hostname argument is what computer or router to connect to. The (optional) command is a command to be issued to the remote computer.
For documentation and details, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/sshv1c.htm
Even assuming you have network management software that does SNMPv3, well, you can manage an SNMP security infrastructure, or you can do IPsec instead. I'm not necessarily recommending that, but I suspect that's what most sites will be doing. Yes, you'll probably want to secure SNMP and start using SNMPv3 informs and notifications, eventually. And it really shouldn't be all that hard. The views in SNMPv3 are also nice for controlling who has access to what data (even on a read-only basis). But I'm guessing that's not anywhere near the top of your To Do list.
By the way, Windows 2000 Active Directory contains Kerberos support (some would argue, with the inevitable Microsoft twist). In general, Kerberos uses a secure central server to authenticate users and grant them a ticket or credential with a limited lifetime, providing them with access to network resources. The server, known as a Key Distribution Center (KDC), also authenticates services. The Cisco implementation of Kerberos is based on Cybersafe code, which is derived from MIT code, and testing has confirmed interoperability with both.
Since Cisco IOS Release 11.2, the Cisco software has supported Kerberos 5. In the Cisco implementation, telnet, rlogin, rsh, and rcp are supported by the Cisco IOS Kerberos authentication capabilities. Outbound Kerberized telnet sessions from a router can be encrypted via DES. I believe if you find a Kerberized telnet for your PC or workstation, you can also do encrypted Kerberized sessions to a router -- the documentation doesn't say.
We're not going to go into the details of this here. While there are a few details to how Kerberos works (nicely summarized in the Configuration Guide), there isn't that much to configure.
For more information about Kerberos, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt2/scdkerb.htm
Plain text authentication sends a plain text key with each message. This is vulnerable to snooping. MD5 authentication performs an MD5 hash using a shared secret key, which is less vulnerable to snooping. Key chains allow a rotating series of keys to be used, to decrease the likelihood of compromise. Since the lifetime of each key is time-sensitive, NTP protocol generally needs to be enabled before using key chains. For more on key chains, see:
The following table contains links to key parts of the Cisco documentation,
in case you wish to look further into this.
Your comments, preferences and ideas and suggestions for topics are always more than welcome! I enjoy hearing from you!
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .