Curing remote-access security ailments ssh, the secure shell, can create a moderately secure network connection

January  1996

Many people still think the problem of network security is one that exists at the boundary between the "out there" Internet and their internal networks. In reality problems exists in any distributed computing environment. If you trust your internal network, and all of the players on it, you may feel this month's topic is irrelevant. However, before jumping to the next URL peruse the list of potential internal crises that begins this month's column. Should you change your mind about your exposure and responsibility, continue reading as we talk about the secure shell (ssh), a relatively new, freely available encryption tool that reduces the risks of some of these problems. (2,800 words)

Mail this article to a friend

The Internet's ascension to media darling has raised awareness of network security across the board. Unfortunately, many people still think of the problem as one that exists at the boundary between the "out there" Internet and their internal networks, while in reality problems exist in any distributed computing environment. If you trust your internal network and all of the players on it, you may feel this month's topic is irrelevant. Before chasing the next URL, though, peruse the list of potential internal crises that follows. Should you change your mind about your exposure and responsibility, continue reading as we talk about the secure shell (ssh), a relatively new, freely available encryption tool that reduces the risks of some of these problems. We'll wrap up by matching ssh functionality against each of the attack mechanisms, highlighting what ssh does and does not do to increase your comfort level.

Everybody seems to have their own security-oriented acronym starting with S. To add to the fracas of STP, SSL, SHTTP, and SEPP, here's our first SSQ (Security Sensitivity Quiz). Think about the three scenarios below and their variations that can be played out on your network.

• You notice some new accounts added to your password file, and two new mail aliases created on the mail hub. The users appear to be legitimate, and the aliases don't appear too inviting to the outside world even though they do forward mail to a processing script. But then you find out you have a request to add those same users to your work queue, and that somebody beat you to the punch. On closer inspection, you find a large hole in one of the alias-handling scripts. How'd you lose control of the NIS password file and alias maps? Think back to the time of the last changes you applied -- you did an rlogin to the NIS master, executed su, and typed the root password. Someone with a watchful network eye grabbed the root password in clear text right off of the Ethernet. A quick look at syslog shows you who became root at the time the changes were made, so you're quick to admonish the over-anxious user.

• Corporate press relations calls you in a panic because someone has leaked news of a product announcement to the trade press. One of the handful of people who knew the details was the vice president who works in your office, but her mail is delivered on a private subnet, directly off the backbone, and also firewalled from the rest of the internal world. What you find out later is your executive was reading mail using a command-line interface from another site, on a machine connected to an exposed network. Sensitive e-mail contents spilled in the clear onto that network, where they were picked up by a traffic analyzer running on one of the hosts. Good news travels a bit too fast. (You can substitute for this example one of the bulk mail delivery systems, such as POP, on an untrusted network and get the same scary effect.)

• Your manager logs in from another machine in the office and prepares to set up a remote mailtool by executing xhost on the remote machine. He starts up mailtool on his home machine, and X authority information is exchanged with the remote system to allow the X client connection. One of the e-mails asks him to approve an expense report, which he does by xhosting the X-based approval application from his home machine. Some days later, your manager notices that a rash of small expense reports are being approved -- without any effort on his part! The source of your white collar crime: someone captured the X authority information as it crossed the network. Armed with a valid authorization key, the attacker was able to connect an arbitrary client to the server. A current favorite is a little floating net-ditty known as xkey that dumps out every keystroke handled by the remote X server. From that stream, it's trivial to assemble the necessary logins and approval passwords.

Indecent exposure

Each of these meltdowns started with the exposure of data over an insecure network. There are a variety of other, more subtle problems that arise out of lower-level attacks on DNS and IP. For example, let's say you have subscribed to a Web-based information service for which you shell out $15 per month. Prying eyes in your office notice the http traffic requests leaving your machine for www.goodies.com, so they forge a DNS entry pointing to a machine on the local network. Populating it with the HTML forms from your favorite site, your registration and password access information are easy pickings. More information about IP address spoofing and similar attacks can be found on-line in the Information Warehouse! publications list. The bottom line is that unless you blindly trust the network and everyone who may be connected to it, you have to worry about data exposure and user authentication.

Distributed systems often come under fire for being less secure than host-based (mainframe) or centralized computing environments. While most of the criticism centers around the maturity of the Unix operating system (or lack thereof), in reality problems stem from two primary areas: exposure of sensitive data (such as passwords transmitted over a network connection), and the ability to access systems via a network without actually being physically present at the system. It's not Unix per se that's the problem, but the distributed systems Unix engender that create the headaches.

Put another way, it's difficult to steal a password from someone logging into a 3270 terminal without cutting the coaxial cable and splicing into the SNA network, while it's fairly easy to copy a password transmitted unprotected over a TCP/IP network. Using any Unix workstation on which they have root access, a PC, or low-cost network analysis equipment plugged into an unused twisted pair port an attacker can snoop anything sent over the network in the clear. When you can no longer control or even enumerate all of the potential access points and you can't restrict access to all of the paths over which data travels, you need to start designing security measures into your system to replace the physical comforts offered by a centralized data center.

Twisty little passages, all different

What can a responsible system manager do? Your primary goal is to protect the channels through which sensitive information flows, either by authenticating the users and servers connected to the channel or by encrypting the data so that it's not useful to anyone except the corresponding parties. As authentication is typically accomplished using an encryption mechanism to verify credential information, we'll lump the two problems together as we survey potential solutions.

As you evaluate data-security implementations, examine the impact on users. Asking the users to encrypt each file they send over the network is not entirely practical; they may not know what files are local and which are remote and they are not likely to pause before each file access or mail message delivery. The higher you go in the network protocol stack, generally, the less transparent encryption becomes. At a superficial level, you can protect data by encrypting files with PGP (two FAQs are available that answer many PGP questions: the main FAQ and a FAQ devoted to PGP download sites) or the Unix crypt utility. Users then send the encrypted files over the network, where they are converted back to clear text by the recipient. It's far from transparent, but this approach often suffices in a pinch where you need to send selected files or e-mail messages over untrusted networks.

The drawback to crypt is that it uses a private key mechanism -- anyone wishing to decrypt the file needs the password used to encrypt it. You need to exchange passwords "out of band" -- via Federal Express, snail mail, or telephone calls to maintain some sense of password integrity. PGP uses public key encryption, so you can decipher a file with the sender's public key that can be e-mailed to you or picked up via ftp. Of course, concerns about IP address spoofing and DNS attacks may make you question where the public keys came from and if they were also spoofed, so PGP allows you to build "key rings" that require multiple verifications of a key from trusted parties. (We'll talk about PGP and its applications in more detail next month.)

The encrypted-file solution layers encryption on top of the application, leaving the application's protocols and implementation unchanged. If you have access to source code, it's possible to build integrity into the application, having it perform authentication and packet- or request-level encryption. Good examples are the secure ftp and telnet systems developed at Texas A&M University, and available from the Purdue COAST archives. Encryption-enabled applications are more transparent than user-driven file encryption, but they require care and feeding from the system administration side.

You'll need to double-check the level of data privacy and protection offered by the modified application. If encryption is used to verify credentials and authenticate users, but not to encrypt data, it won't help you with data-exposure problems. A good example of this half-way solution is Sun's Secure NFS. It protects you from users who become root on their own machines, su to another user and then NFS-mount those users' filesystems, because it requires a secret key (password) to generate a verifier for the user's NFS credentials. However, Secure NFS only performs credential verification and it doesn't help with the file-exposure problems highlighted in the opening section.

The most transparent, and often highest performance solution, is to invest in network- or link-level encryption. Devices like Sun's Solstice SunScreen SPF100 encrypt incoming IP traffic and deliver it over insecure channels to a peer device that converts it back to plain text. With SunScreen, for example, you don't need to modify applications or user behavior to derive encryption benefits. On the other hand, this isn't a cheap proposition and it requires an all-or-none approach for all of the sites that you want included in the extended, secure network. You pay a price for a high degree of transparency with a fixed maintenance investment.

Double secret probation

Until recently, there hasn't been a middle ground between an end-to-end encryption solution at the link or network level and a growing suite of modified applications. Several months ago, Tatu Ylonen, a researcher at the Helsinki University of Technology, released the Secure Shell (ssh) as a compromise between modified applications and hardened networks. The premise behind ssh is that the network can't be trusted, so secure data exchange requires building secure channels on top of untrusted ones. Secure Shell replaces the Berkeley remote login (rlogin) application and the rcp remote copy tool with versions that perform end to end encryption at the application layer. By working at the remote login level, ssh builds a "tunnel" between systems that can be used to carry other kinds of traffic as well, including X Window System sessions and arbitrary TCP socket connections.

In a nutshell, ssh uses a mechanism similar to the /etc/hosts.equiv and .rhosts access-control files that manage remote login transparency. Users continue to use these files, which are augmented by access controls and key-management files in the user's home directory and maintained by a daemon on the remote host. When you install ssh, you run some scripts to generate keys for users and hosts, and to collect keys from known hosts on your network. Ideally, users can alias rlogin to ssh or slogin and never notice the encryption mechanism at work.

When creating a login connection, ssh authenticates the client and server using public key encryption, eliminating spoofing attacks. The handshaking can use a variety of authentication mechanisms, with or without additional passwords. Once the two sides have verified their identities, a channel is created using one of several encryption methods, including DES, triple DES, IDEA (considered stronger than DES), and the RC4 streaming cipher. To eliminate attacks stemming from key transmission over the network, ssh uses something of a double-secret double-check. Client and server systems compute something called an encrypted message digest 5 format (MD5) checksum on a value generated on the server side. The checksum is exchanged, with the belief that only the correct key combinations could generate the correct MD5 checksums. While this isn't completely secure, it does eliminate problems stemming from key exchange over an unencrypted channel. You can find complete details of the session-key generation and key exchange in the RFC included in the ssh distribution and also available from your favorite RFC depot as draft-ylonen-ssh-protocol-00.txt

While you can visit the general distribution site for ssh, you may have better results with one of the mirrors, including one at Ohio State University. There is a wealth of information available for exploration, starting with the ssh home page. A FAQ document was recently created, and will be posted to comp.security.misc and comp.security.unix. The FAQ includes URLs for all of the ftp mirror sites. A mailing list for ssh users, ssh@clinet.fi, has been created; join by sending the message "subscribe ssh" to majordomo@client.fi. Archives of the mailing list are online as well.

Twisty little passages, all the same

Let's see how ssh addresses some of the scenarios outlined above. The simple case of password exposure over the network is handled by the encryption used by ssh; when you're typing through the encrypted tunnel your passwords aren't flying over the Ethernet in the clear. Of course, this requires that you have ssh available where you're initiating the login; if you plan on using this method to secure yourself while doing system administration from offsite, make sure you are tying into an ssh session directly without any intervening insecure network. Another solution to the remote login problem is to use a one-time password system, such as a digital token card or the Bellcore S/Key system.

The remote mail access problem is also fixed by ssh, since it encrypts the mail contents going over the login session. You can use ssh under a POP session, forwarding the TCP endpoint through an encrypted tunnel to the remote end if you don't go the command-line-interface route. Similarly, problems with IP and DNS spoofing are addressed by host authentication. If you have a known key for the remote host, you may be detoured by bogus routing, IP, or name information but won't actually complete an ssh connection to the other side.

The X session protection is handled through features built into ssh to transparently erect X-aware tunnels. Instead of forwarding X authority information over the network, the ssh client creates dummy authorization information that is forwarded to the server. The server creates a fake X11 server that is used to intercept X requests (see the sidebar on Xscope in "A TCP/IP primer," November 1995 SunWorld Online SysAdmin). The server side forwards the X traffic back to the client, where the dummy authorization information is checked. If it matches, the client forwards the request on to the real, local X server. The local authorization information is never sent over the network, reducing the possibility of opening a window of attack from another host that would use a non-encrypted channel to the local X server.

As with all encryption tools, ssh is not a perfect or complete solution. If you can't trust the contents of your home directory, you'll have trouble putting absolute faith in the key management system used by ssh. NFS traffic in general isn't protected by ssh, so you need to worry about mail spools exported via NFS across untrusted networks. You must be consistent about implementing data integrity policies -- if you are worried about executives reading mail over insecure channels, you should also focus on how the mail is delivered. There's no point in using an encrypting shell for forwarding POP connections if the incoming SMTP traffic waltzes across your network to the common mail spool without any protection at all. The first order of defense is to perform a careful analysis of all of the paths over which your traffic travels, determine which of them are likely to produce inappropriate access to your bits, and then act to protect your data while it's exposed.

Resources

• List of IP spoofing and other attacks at Information Warehouse!
  http://www.iwi.com/iw-pubs.html
• Main PGP FAQ
  ftp://ftp.prairienet.org/pub/providers/pgp/pgpfaq.txt
• FAQ devoted to PGP download sites
  ftp://ftp.csn.net/mpj/getpgp.asc
• Purdue COAST archives
  ftp://coast.cs.purdue.edu/pub/toolsunix/TAMU
• Solstice SunScreen SPF100
  http://www.incog.com/spf.100.html
• The general distribution site for ssh
  ftp://ftp.cs.hut.fi/pub/ssh
• ssh mirror site at Ohio State University
  ftp://ftp.net.ohio-state.edu/pub/security/ssh
• The ssh home page
  http://www.cs.hut.fi/ssh
• ssh FAQ document
  http://www.uni-karlsruhe.de/~ig25/ssh-faq
• Archives of the ssh mailing list
  http://www.cs.hut.fi/ssh/ssh-archive
• Sidebar on Xscope
  /sunworldonline/swol-11-1995/swol-11-sysadmin.html#sidebar2
• A list of Hal Stern's other Sysadmin
  /sunworldonline/common/swol-backissues-columns.html#sysadmin

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-01-1996/swol-01-sysadmin.html
Last modified: