- SSH Servers: A Basic Risk Analysis
- Step 1 in Securing Your SSH Servers
- Creating a Solid Configuration Baseline
- Relevant Settings
- The Big Picture
Step 1 in Securing Your SSH Servers
As I mentioned in the previous article, you should get a copy of Metasploit or Nessus and scan your servers running OpenSSH. OpenSSH.org does a great job of listing known issues with their product. Make sure that you have the latest version, of course, but beyond that, make sure that you have the best-patched version of anything running on the system. The weakest defensible service is the weakest link in your SSH installation.
Review the reported SSH security issues with some objectivity. Some of these issues, reported as "SSH issues," aren’t solely a problem with SSH. Need an example? You’ll read about SSH’s issue with the X Window System (commonly referred to as X). Whether using OpenSSH and the X Window System’s tunneling (or using X and common forms of xhost security), you have the same security issue. In most cases, a compromised server, throwing sessions and displays to your X Window System software, can monitor (and inject data into) your session. Somehow a core X vulnerability gets tied to SSH when SSH is used to tunnel X?
Just remember that the attacker who controls a service gets that service. Now consider the SSH issue. The attacker who controls your SSHD gets the SSH service and basic networking connectivity into your intranet or back onto the Internet. SSH must be secured well. Give your OpenSSH environment a solid, secure foundation. Secure the server itself well.