- The True Issues
- Mitigating Organizational Risk
- Mitigating Agent-Forwarding Risk
- Mitigating Port-Forwarding Risk
- Final Ideas
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Mitigating Organizational Risk
Why would anyone propose running SSH on most major platforms? For more than a decade, architectures have settled on standard utilities and protocols. For example, Telnet and FTP are commonly used on all kinds of servers, including some established long before TCP/IP, UNIX, the C programming language, etc. But while Telnet and FTP are common denominators, they’re lowest common denominators when you consider their security issues. In response, organizations look to SSH to take the place of these insecure protocols. SSH is very scriptable and makes automation easy by allowing common code to run on several platforms; for example, by using Perl. Instead of working the script through two separate utilities, you can stay "in session" with SSH. File size seem too small? Kick off another transfer via SSH seamless processing power that allows both file transfer and command execution. It even allows for authentication to work without pesky passwords and authentication processes. It encrypts all traffic, so the security people feel warm and fuzzy. It’s an easy sell.
Now, how do you make sure that all those administrators and platform security architectures are on the same page? You must create a cross-platform SSH implementation team that will take ownership of the issues. This group can ensure that security is consistent across platforms, by identifying implementation weaknesses on some of those platforms.
For example, you must control access to the private-key file used with authentication. Imagine that the desktop Windows administrator has no clue how important PCs are to server security. He or she has implemented the FAT file system, making any sort of file access security very difficult. To make remote administration easy, the same person has opened the administrative shares and Remote Desktop access to Everyone. With this kind of design, a hacker can collect private keys like flowers for the plucking. With these private keys (used with multiplatform scripts), the hacker can take on any identity s/he wants—the time needed varying only in relationship to the private key’s passphrase complexity.
Don’t want me to pick on Windows administrators? Perhaps you’re serving out home directories with NFS instead. Have you studied NFS security? Got poor home directory permissions on top of poor NFS permissions?
This is just one example of how one platform’s foolishness endangers all others. Once I heard an administrator strongly recommend that we all use the same host key on our servers. This approach would remove the pesky warning that users get regarding host identity. How likely is phishing in a big intranet? Here again, one person’s ideas remove a vital security component from SSH. The best way to have a consistent, complete security model is to have a group of experts assemble the plan, document it, and weave it into server and client implementation and maintenance processes.
This group must be empowered to choose the best settings, despite complaints from administrators and developers alike. The group must be responsible for security openings found during an intrusion study performed by a credible external group. You must confirm the security plan, right? The group should find a monitoring system, either purchased or self-written, that checks production settings. You might even create a process that periodically overwrites existing files with a baseline file containing documented security settings. (It’s amazing what vendors, customers, etc. with root access can do to your settings files!)
Let me warn you: SSH security begins with use of the server-side security features. There must be agreement on which server settings are optional and which are mandatory, with which specific settings enabled. Is SSH protocol 1 good enough? One version of SSH has a configuration file with security features commented out. It’s assumed that you—and the hacker 0wning your server—have compiled SSH with security embedded. Is that good enough, and did anyone on your team catch that fail-open security design from the factory?
There will be some tough, very detailed questions to answer. If reading books and articles isn’t enough, management should work with a consultant whose costs are shared across all platform owners.