Securing Server Access

August 15th, 2016

With the wide availability of access to servers for startups, it can be easy to skip some very important steps in planning for and implementing server security.

In an earlier post, I talked about password strength. However, even with the strongest password there is always the chance that it could be guessed on the first attempt. Therefore, it is imperative that admin access to servers be secured more thoroughly. Usually, this is done through the use of Multi-factor authentication (MFA). Wikipedia, defines Multi-factor authentication as:
Multi-factor authentication (MFA) is a method of computer access control in which a user is granted access only after successfully presenting several separate pieces of evidence to an authentication mechanism – typically at least two of the following categories: knowledge (something they know), possession (something they have), and inherence (something they are).

For Cloud computing, MFA usually boils down to something you know and something you have.

Many Cloud providers include the use of public key SSH authentication as part of the server setup. This involves using a public and private key. However, using this basic method is only as secure as the device on which the private key is stored. Therefore to implement MFA you need to generate the SSH keys with a strong passphrase. In this case, you can only access the server with something you have (the private key usually stored on a device) and something you know – a strong passphrase). The key here is to always generate the SSH keys with a passphrase.

Another method gaining acceptance is to use something similar to Google Authenticator (Note: I will use Google Authenticator as a generic term for an application that uses a Time-based One-time Password (TOTP)). Google Authenticator makes available a 6- to 8- digit password that is essentially a shared secret between the user and the server that changes every 30 seconds or so.

The user logs in using a strong password and is then asked for the Google Authenticator shared secret. The user can only access the server with something they have (the Authenticator generated shared secret) and something they know – the strong password. Again, since the device on which Google Authenticator runs (usually a smart phone) can be lost, it is essential that a strong password is also used.

Finally, as an added security measure for admin server access in the cloud it is a very good idea to restrict SSH access (port 22) to just the ip range of your administrators.

The bottom line is that you need to secure server access with more than just a strong password. MFA and ip restricted access go a long way in achieving that.