How To Secure SSH In A Few Simple Steps

Adrian was describing the Anti-Sec claim for discovering a critical hole in OpenSSH a few days ago.  Nothing was released, and this all seems to be no more than FUD designed to cause chaos and disruption in the IT industry It's still a valuable lesson, and we all should take a look at our machines. Having SSH access (or any other access to the system itself) properly secured from cracking attempts may help to prevent huge data and money loss for everyone's business, especially when it is not a big hassle to secure. Here are a few suggestions on how to make your data center more secure and less vulnerable to cracking:

1. Increase logging verbosity.
   Having more information is always better than lacking it. By setting 'LogLevel INFO' variable in OpenSSH config you are giving yourself a chance to spot malicious activity on your servers while it is actually happening. You can even install a log analysis tool of your choice to raise alarm as soon as something interesting arises.
2. Increase process privilege security and checking.
   Make sure you have variables 'UsePrivilegeSeparation yes' and 'StrictModes yes' set up and uncommented in the config file. The SSH daemon requires high system privileges for running and therefore can be exploited to gain root privileges upon a connection attempt. First of these settings makes sure that the each connection attempt will be processed in a separately chrooted, empty environment from which the attacker will unlikely escape, even upon successful privilege escalation. The second option is responsible for checking if the user's directory and key file permissions settings are secure, just before landing the user in her home directory.
3. Disable password authentication in favor of public key authentication.
   Most people use passwords to access their systems, which can make their systems vulnerable to bruteforce attacks. By using password protected public and private key pairs placed on the systems and the client machine and configuring the OpenSSH daemon you can greatly enhance the system security, because a password is no longer used to authenticate on server. Follow this guide on how to configure OpenSSH and create key pairs.
4. Limit users and groups allowed to log in.
   While logging to the system directly as a root user can certainly be comfortable, it is very insecure and should not be practiced. This should be disabled by using 'PermitRootLogin no' directive in OpenSSH config file, and additional authentication mechanism like su or sudo should be used to gain root privileges instead. Additionally, you should narrow the users and groups that are allowed to log in, by usage of 'AllowUsers' and 'AllowGroups' (or 'DenyUsers' and 'DenyGroups' accordingly) directives depending on your environment requirements.  If root login is required, use the 'PermitRootLogin without-password' option to force root logins to use the SSH keypairs only.
5. Configure your firewall.
   In most cases you are connecting to your systems from known locations, such as your company's office, your datacenter, your house, or your vpn network. Therefore, there is no need to keep access to your SSH port open for the whole world. Use an external firewall or firewall software such as iptables, pf, or ipfw on the system itselft to restrict traffic to the SSH port from anything that is not your trusted location. What is a trusted location? Your office would be, and your datacenter also, but a computer in internet cafe, or laptop using public WiFi network isn't. What about your house? If you take care to secure your home computer and access to your home network then it also might be considered as secure location. Everything else must not be able to reach the SSH port.
6. Be proactive.
   It might sound boring, but it needs to be repeated - be proactive. Prevent the damage instead of recovering from the disaster. Stay up to date with your machines. Update the kernel and software as soon as security patches are released. Watch out for know holes in daemons you use to provide services. Have backups, and test them regularly. There isn't anything worse than realizing your backups are empty or broken on the day when you need them. Scan your network regularly for open ports or new services - your users or employees might be doing things, even not intentionally, that you wouldn't like, such as disabling firewalls or launching daemons that should not be launched. You need to know these things before something happens, and the only way to stay aware is to be proactive.

These steps aren't complicated, and they can increase the security of any environment, ultimately resulting in less downtime or financial loss. However, in a large server farm this can be time-consuming to implement, especially when companies are reducing the number of employees just to survive the economic crisis. It's very easy for a system to fall as a result of a strike from script kiddies or and automated botnet, especially when this is just a single brick in security wall.

This why we are here. To help you grow and protect your business.