Demons Seeking Dæmons—A Practical Approach to Hardening Your OpenSSH Configuration

A few simple configuration tweaks could save you sleepless nights over whether or not someone might crack your SSH server.
Monitoring Those Demons and Keeping Them in Their Place

Keeping a watchful eye on the demons seeking dæmons is relatively easy and the (expected) default setup should be confirmed in the configuration file. With the SyslogFacility set to AUTH, your sshd will log (via syslog) to (paths and filenames may vary depending on distribution) /var/log/messages and /var/log/secure. It is highly recommended that a program such as Psionic's logwatch be used to monitor your system logs. Logwatch will take care of parsing the logs, and you will be able to decipher the sshd authorized logins as well as failures. There is a distinct difference between an invalid user and an authentication failure. An authentication failure is a failure that occurs on an account that is present on the machine, and an invalid user is exactly that. This can become relatively important when you are choosing account names as well as contemplating who will be on the AllowUser and DenyUser lists. For example, you may not have an actual person named amanda using your machine, but you are using the amanda open-source backup program. This said account, if not added to the DenyUser specification, will trigger an authentication failure rather than an invalid user flag. Although not necessarily required, I add the system accounts that are active to the DenyUsers list just to be on the safe side. The most recent log entries from sshd scans show that the system accounts have in fact been added to the probe list (Listings 2 and 3).

Because user names have been mentioned, it is now appropriate to discuss the possibility of the demons (the evildoers) having one of the two credentials required for a login. In the event of a Web server hosting personal accounts or from e-mail headers, it is relatively easy to determine a user name on a particular machine. With this, the demon has half of the user name/password combination, and if the scanner goes beyond simply scanning common accounts and passwords, it is easy to take the sshd scan one step further and begin brute-force attempts at those accounts that already have been determined to exist on a machine.

There is no need to re-invent the protocol, only the need to improve the current configuration. OpenSSH provides a strong end-to-end encryption method for networked machines. Updates continuously are released to the code to address any insecurities that may come about. One of the most relevant releases is the change from SSH v1 to SSH v2. Both version 1 and 2 sshd servers have their own keys. In other words, with SSH1 and SSH2, neither private nor public keys intermix. These keys are independent of each other. Just as the keys are independent of each other, so are the protocols, and it is possible through the Protocol directive in the configuration to allow either protocol 1, protocol 2 or both. SSH1 is depreciated but is still in use in many organizations and applications. It is advisable to check your sshd_config file, and if you are not dependent on SSH1, disable this and run only protocol 2 on your server. This eliminates any chances of falling victim to an insecurity associated with version 1.

Earlier, while you were perusing your password file to build your user list, you probably noticed that there is an sshd user with a home directory of /var/empty and a name listed as Privilege-separated SSH. If this user does not exist, the following is of particular importance, and you will want to look further into running sshd in privilege-separated mode. Privilege separation in sshd is a multipart process that entails the sshd process of creating a privileged monitor process, which creates an sshd process with the privileges of the user. This user-owned process in turn spawns the shell process. The privilege separation process is run via chroot and is restricted to the /var/empty directory. For those of you familiar with running processes in a chroot environment, this privilege separation is the same. It allows protection to the listening dæmon if a buffer overflow or similar compromise is discovered. The /var/empty directory should be root-owned, empty and it should not be world- or group-writable. If an sshd user does not exist, privilege separation will not work, and systems that lack mmap or anonymous memory mapping compression must be disabled.

Consider a situation where a machine has a minimal amount of users that are accessing it through SSH. Quite possibly, you own a machine that is accessed only by a couple of accounts, and then su or sudo is used for administrative purposes. Consider also the scripts that often are run to seek the machines that are running an SSH server. Although it is possible that the scripts may do a full-system port scan to expedite the scanning and identify possible victims, a specific port (22 in the sshd case) is often the only port scanned, and if found open, it is expanded upon. The logical alternative to this, especially in machines with minimal users logging in, is to run sshd on an alternate port. Specifically, in the sshd_config file, one of the very first options is the port. By changing the port from 22 to an alternate port, you can write off a good amount of the scripts that are scanning for open port 22. This is such a trivial configuration change, but it is one that will result in a drastic lessening of brute-force attempts (Listing 4).



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

ssh work

Steve Jim1's picture

The new work about ssh server is to be access very carefully to get fixed.

ssh -p <alternate port>

Keith Daniels's picture
Doing ssh -p will allow a second dæmon to run and provide you with a secondary secure connection Shouldn't that be: sshd -p ?

All the new OSs and windowing systems are oriented towards content consumption instead of content production.

--Steve Daniels 2013


Anonymous's picture

"DenyHosts is a python program that automatically blocks ssh attacks by adding entries to /etc/hosts.deny. DenyHosts will also inform Linux administrators about offending hosts, attacked users and suspicious logins." Very nifty when your machine is getting hammered with brute force attacks. You can find it here.