This article can also be found in the Premium Editorial Download "Information Security magazine: 12 security lessons for CISOs they don't teach you in security school."
Download it now to read this article plus other related content.
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
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.
This was first published in February 2005