Published: 08 Feb 2005
BITS & BOLTS
The overhauled encryption protocol helps harden networks.
SSH is a powerful suite of programs that enable enterprises to harness the power of encryption to protect data in transit. Some security managers shy away from encryption because it can be difficult and costly to implement. But SSHv2, a completely overhauled version of the protocol and often included free with Linux distributions, is a practical option that gives skilled practitioners a versatile tool to enhance confidentiality, integrity, authentication and nonrepudiation.
SSH was created for two fundamental purposes: as a replacement for Telnet and as an encryption tunnel for protecting other protocols. This basic functionality can be leveraged to secure your network in many of the areas in which it's most vulnerable. SSHv2 is more secure and functional than the original protocol, although SSHv1 is still in widespread use.
Applications like Telnet and FTP, which were fine for remote access and file transfers not that long ago, are now security nightmares. Authentication information, like user IDs and passwords, are transmitted in plaintext, and mobile users are connecting to public networks in hotels, airports and coffee shops--an open invitation for stolen IDs. An admin connecting via Telnet or transferring files via FTP is asking for trouble. Ssh, the main program included in the SSHv2 suite, encrypts sensitive data and is a secure replacement for Telnet. The SSH protocol suite also contains programs like scp for remote file copying and SFTP, which replaces the insecure FTP program.
SSHv2 is reasonably easy to learn; most people with a foundation in networking will quickly grasp its nuances and potential. We'll examine several ways, some of which may surprise you, that you can put SSHv2 to work to protect your networks.
While the SSHv2 contains several programs that directly replace their insecure counterparts, it can also be used to secure applications and protocols such as POP3 and SMTP. These e-mail programs also send sensitive information in the clear, but have no secure replacements. A secure version of POP3 is available, but it's not supported by many e-mail servers or clients.
The SSHv2 solution: Pipe POP3 or any insecure protocols inside a secure SSH tunnel. Obviously, secure POP3 or secure SMTP would be better; with their built--in functionality, they provide the exact service you need, but require considerable expertise to customize. While more generic, SSHv2 provides a more versatile solution that can work with a range of services.
Here's how it's done: Configure the SSHv2 server to allow the connection on the SSH default port 22; no other ports are open. Then, configure the server to allow clients to connect via port 22 to access other network services. Clients would then connect to the network on port 22 and tunnel all permitted services over SSHv2.
VPNs are enormously popular for secure remote access and site-to-site connections. But they require extensive configuration and customized client software. SSHv2 is a viable option for occasions when you need a temporary, versatile VPN.
For example, if you need to transfer several large, sensitive documents between your laptop and a corporate server, an SSH tunnel can be set up so all traffic leaving the computer or network is sent over it. By tunneling all traffic as opposed to a single protocol, SSH can create the same benefit as an IPSec or SSL VPN. Since it's only temporary, there's no need for the cumbersome administration of conventional VPNs.
Vulnerabilities are a fact of life. A vulnerable application--such as a custom transaction program with security holes--may be exploited for days, even weeks, without detection. In theory, you can pipe the application over an SSHv2 tunnel, but that's certainly not practical if it uses a general port, such as a Web server running on port 80.
Many services are limited in scope and can run on any port, yet they're no less vulnerable. For example, if an organization is running FTP on port 21 for a group of people, an attacker scanning the system will detect the open port and try to hack it. In these cases, you can tunnel the app over SSHv2, bulletproofing it without worrying about unknown vulnerabilities or rewriting code to repair those you discover.
A real-world scenario would go something like this: A company would set up a Web server to allow its sales people to access a database that contains client information. But the server, vulnerable to several remote exploits and buffer-overflow attacks, is quickly compromised. The company then sets up an SSHv2 tunnel, protecting the application and providing strong authentication. This technique is so popular that many commercial products are utilizing SSHv2, especially for remote consoles used by sysadmins.
For many Internet-facing apps, authentication is the first and only line of defense, yet many services and protocols have weak password authentication. Adding strong authentication is cumbersome and must be done for each application or protocol. And it's risky. For example, when the developers of the popular IMAP e-mail protocol rewrote the code to provide stronger authentication, they introduced several buffer-overflow vulnerabilities.
A more reliable and flexible approach is to tunnel the app or protocol over SSHv2 and use its secure authentication, which supports a variety of methods, from passwords to smart cards. This is particularly useful in environments running multiple Web applications. Smart cards would be an ideal choice for authentication, but would require enormous time, cost and effort to integrate with each application. Running the applications over SSHv2, which supports smart cards, is simpler, faster and cheaper solution.
In addition, while not directly supported, SSHv2 can be adapted to use RADIUS, TACACS+ and other centralized user credential databases.
Many enterprises run a variety of services and applications, each of which needs additional open ports on the firewall. Eventually, the brick-and-mortar firewall is turned into Swiss cheese. Instead, use SSHv2 to "mark" trusted packets, adopting a strong default-deny firewall policy and allowing only common ports, like 80 and 25, and SSH traffic. This provides strong authentication and keeps rule sets simple. Organizations implementing IPSec use the AH header in a similar way to mark trusted packets, a technique that's more appropriate on an internal networks, where encryption may not be needed.
By now you get the idea. Some of these solutions are very unconventional, but they show the power of SSHv2. With a basic understanding and some creativity, you will come up with unique ways to make this security protocol work in your enterprise environment.