Mitigating the Security Risks of SSH

John Tränkenschuh describes ways to create a solid security plan to lessen the unknown factors of SSH security. To mitigate SSH risks, we don't begin by considering the server or client technical settings; instead, we begin by considering the implementation challenges to organizations.

Like this article? We recommend

This article is a follow-up to my earlier article on
SSH security considerations,
in which I discussed some very real risks with SSH—risks created by how
SSH is rolled out in many organizations. Large organizations with many
production platforms are especially at risk. Slashdot featured some excellent
discussion
about that article, along with other responses that convinced me of the need for
a follow-up. In this article, we’ll consider mitigations (security
controls) that you can apply to the SSH rollout at your organization.

NOTE

The suggestions in this article are just a first step toward better SSH
security.
Safari has
some excellent online books available that cover the VPN aspects in much more
depth than I can address in this space, as well as supplemental articles and
other resources that can help you to better understand how SSH works and how to
create the ultimate SSH technical security plan.

This article will help the UNIX administrator—maybe one who’s new
to SSH—to see the need for a better security plan. It will also help the
administrator who’s rolling out SSH on a non-UNIX platform. (No one can
expect UNIX administrators to own the SSH security plan, even if some consider
SSH to be a UNIX utility.)

The True Issues

SSH is a wonderful tool with many excellent abilities. It has versions for
OpenVMS, Windows, z/OS, iSeries, UNIX and Linux, etc. Thanks to the work of the
commercial and open source SSH vendors, this tool is getting a lot of
recognition. Because more and more applications must fan across data
repositories living on multiple platforms, people want to use SSH as a more
secure replacement for Telnet, FTP, and rlogin/rsh.

Many UNIX administrators will read each SSH man page thoroughly. They
appreciate the risks of a tool that moves files, allows remote execution, and
can encrypt and tunnel network traffic into any TCP portstream. But what about
administrators using SSH on other platforms? Will they just plop in this tool as
a simple FTP replacement, get it to work in that limited role, and then declare
success?

The biggest issues with SSH lie at Layer 8 of the OSI model—politics
and personnel:

One vulnerability issue underlies all SSH implementations: Most
administrators know nothing about SSH’s port-forwarding abilities (or
choose to ignore them). They may very well regard the security problems as
"a UNIX issue." So the first risk is proliferation of a naïve SSH
security design across multiple platforms, with little ownership of the big
issues.

A second risk is the "convenience at all costs" approach to agent
forwarding. Anyone who has read an SSH man page knows that agent forwarding has
known risks when used in untrusted environments. Do the same vulnerabilities
exist with other operating systems? For that matter, do all client and server
SSH implementations carry the same warnings? We can’t answer all of these
questions, but we can make a strong recommendation and review a suggested
Slashdot poster’s mitigation.

A third major issue is the port-forwarding risk that allows an innocent
outbound connection (to a remote SSH server) to become a malicious inbound
connection into your company’s intranet. This connection is encrypted and
will be very difficult to monitor, thus adding to the danger.

Security mitigations must do more than suggest technical settings for one SSH
version. (And the technical settings vary by version, anyway, so don’t
expect this article to be a primer on SSH server and client security. There are
too many features to discuss, and we must address greater issues than just
technical settings.)

So what can your organization do to help secure multiple versions of SSH
running on multiple operating systems?