Mitigating the Security Risks of SSH
Like this article? We recommend
Like this article? We recommend
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.
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?