Security Implications

In addition to those benefits already discussed, tunneling over encrypted Secure Shell protects against IP spoofing (attackers masquerading as legitimate hosts by using a known IP address), DNS spoofing (forged DNS records that trick clients into connecting to an attacker's own server), and IP source routing (a method used by hackers to pretend that arriving packets originate from elsewhere).

No security measure - including Secure Shell tunneling protects against every possible attack. As these examples illustrate, end-to-end security involves not just protecting data in transit, but system security at the tunnel endpoints (SecureCRT® and VShell®), firewalls, and on any trusted server receiving forwarded cleartext. For this reason, locking down the Secure Shell server platform is essential. If a hacker penetrates a misconfigured firewall, then exploits a weak administrator password to log onto the Secure Shell server, secure tunneling cannot prevent application data from falling into the wrong hands.

When outfitting travelers, teleworkers, or partners with Secure Shell clients, document "best practices" that must be used. For example, most Secure Shell clients let the user accept and save the server's host public key on first access. This may be convenient, but doing so blindly is wrong. SecureCRT displays the host key "fingerprint." Users should be instructed to visually verify this string before accepting any unknown host key. Alternatively, supply users with host keys in advance, instructing them never to accept an unknown host key.

Permitting encrypted Secure Shell tunnels through the corporate firewall means that the firewall can no longer inspect the forwarded application data. Each company must assess the benefits and risks of Secure Shell tunneling. As discussed previously, the firewall is delegating responsibility to the Secure Shell server. If implemented correctly, this has its advantages. Content inspection products - especially e-mail and web anti-virus scanners - can be deployed on the Secure Shell server, application server, and/or client. If content inspection at the firewall is mandated by company security policy, the Secure Shell server can also be placed on a firewall DMZ or sandwiched between two firewalls.