- SSH Servers: A Basic Risk Analysis
- Step 1 in Securing Your SSH Servers
- Creating a Solid Configuration Baseline
- Relevant Settings
- The Big Picture
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Creating a Solid Configuration Baseline
You need a solid foundation for your server implementation. With clear baselines established, you can distinguish a hacked configuration file quickly. Define your absolute must-haves: no protocol version 1 support, no blank passwords, etc. Monitoring absolutes is easy because they’re very distinct and clear, providing expected values on all devices.
Of course, let’s not forget that SSH can source configuration information from the "official" configuration file, from command-line parameters, or from a configuration file called out on the command line during a HUP. Your monitoring system cannot just check the standard files placed in standard locations and assume that these defaults were used to start the daemon.
And let’s really get ugly: Check the provided configuration file. None of the security features are configured by default in the official configuration file. Let’s let the OpenSSH crew explain their approach:
Lines starting with ´#’ and empty lines are interpreted as comments. # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 #Protocol 2,1
What’s the impact of this design? The sshd provided by OpenSSH has many security defaults compiled in. But what’s the impact if a hacker moves a new copy of sshd onto your system? If the new copy of sshd has no security settings compiled into it, the configuration file won’t call for them. This means that assumed security configurations are totally undone, and you have no easy way to determine just what your actual settings are. Let’s be honest, however. Too many administrators load a piece of software onto a system, hope the default settings are secure, and then run it as production. The problem isn’t OpenSSH’s approach; rather, it’s those people who assume security without confirming it.
You must understand each OpenSSH security setting. You must set consistent baselines for each setting. I would even suggest that you spell out each required setting in the configuration file. A hacked daemon may ignore it, but you will have provided fellow support staff with a clear statement of expected settings. Under these conditions, a daemon that doesn’t log, for example, gives a clear error condition.
So how will you monitor your running daemons? Sure, you can monitor your configuration files for unauthorized changes, once you have baselines; but what if the attacker uses command-line options to call out an alternate configuration file or settings? UNIX systems may sometimes reveal command-line parameters when a process list is generated (´ps –ef´), but that can have problems.
I can only suggest that you will restart your daemons from time to time with set values. Maybe you’ll check logs for daemon restarts outside of your normal service windows, which helps to show a possible insertion of new configurations.
But what about the hacked copy of sshd? Maybe you’ll try to use a single version of sshd—one that’s fully patched? Maybe you’ll at least have an MD5 sum calculated (or read the sum documented in your rpm package) and check the local copy of sshd against the known MD5 value.
These approaches to configuration, patching, and file-versioning management will go a long way toward lessening your risks. And now that you know the difficulties you’ll face in controlling SSH security, we can consider the settings that seem to have the most relevance to your final security settings.