How to Secure your Server

A few key practices that can secure your server

The advent of the Internet Age has had a profound effect on how business is conducted. Maintaining an online presence is no longer optional for most companies if they want to stay relevant and competitive. Existing and potential customers use the Internet to make purchases, manage their accounts, research products, and much more. The benefits of this are immeasurable, but it doesn’t come without a dark side — hackers. With so much riding on your website and online reputation, it is absolutely vital to keep your servers secure. 

Security professionals devote their entire careers to keeping up with the ever-evolving nature of online threats and global corporations have whole teams with substantial resources dedicated to keeping their online properties secure. Taking on the chore of securing your server may seem like a daunting task, but we’re here to help! We have identified a few key practices that can secure your server enough to defend against the vast majority of attacks and dissuade all but the most elite hackers. It doesn’t take a large amount of system administration ability to secure your server using these methods, but look into our management plans and SecureServer+ services if you’d rather leave it in our capable hands. 

Get Behind a Firewall

The first line of defense for any secure environment is a firewall. There are several firewalls to choose from, but they all typically have the same basic features. A firewall is either an application or a physical device that resides between the internet and any network-facing services on a server. It acts as a gatekeeper for network traffic, using a set of rules to filter both inbound and outbound connections. However, a firewall is only as good as the rules it is given to work with. A well-configured firewall can filter out the vast majority of malicious connections, while a poorly-configured one will be far less effective.

The first decision is hardware or software. Most modern operating systems come with a built-in software firewall application, which is usually sufficient. A dedicated appliance, also known as a hardware firewall, is often used in front of multi-server environments to provide a single point for firewall administration.

No matter what type of firewall you end up using, your next step is defining a good set of rules. Rule number 1 when configuring a firewall, especially remotely, is to be very careful to not lock yourself out by blocking the connection you are using to access the firewall. It is always good practice to have a fallback access method to change firewall rules should you accidentally block your own connection – typically a physical console or an out-of-band console solution like IPMI, ILO, or DRAC.

Start by considering what services your server provides. Network services utilize specific ports to help differentiate between types of connections. Think of them as lanes on a VERY wide highway with dividers to prevent one from changing lanes. A webserver, for example, will typically use port 80 for standard connections and port 443 for connections secured using an SSL certificate. These services can be configured to use non-standard ports so be sure to verify which ports your services are using.

Next, determine how you will remotely administer your server. On Windows, this is typically done via RDP (Remote Desktop Protocol) and on Linux, you will likely be using SSH (Secure Shell). Ideally, you will want to block access to the ports used for administration to all but a handful of IPs or to a small subnet in order to limit the access to these protocols from anyone not within your organization. For example, if you are the sole administrator of a Linux server, open the SSH port (typically 22) to connections from only your computer’s static IP address. If you don’t have a static IP address, you can often determine a subnet from which you will be assigned an IP. While whitelisting a range of IPs isn’t ideal, it’s far better than opening up that port to the whole Internet. 

To generate a solid set of rules, block all ports from all IPs then create specific rules to open those ports needed for your services and administration – remembering not to lock yourself out. The ports opened for your services should generally be open from all IPs, but limit administration ports as discussed above.

While a firewall shouldn’t be your only line of defense, creating a reasonable set of firewall rules is a great starting point for enhancing your server’s security. In truth, no server should be without at least a basic firewall configuration.

Authentication & Passwords

One of the simplest ways to enhance your server’s security is simply by enforcing a strong authentication policy. Your server is only as secure as the account with the weakest password. Follow good password guidelines for any password used on a server, such as making sure that your password is of adequate length, not a dictionary word, and not used on other services that could themselves become compromised and leak your password. While you can limit remote access to your server via a good firewall configuration, there are still exploits that can be used to send commands to a system through compromised or unpatched services running on open network ports.

In many cases, it’s possible (and more convenient) to go passwordless altogether! If your main method for accessing a server is via SSH, you can disable password authentication in your server’s SSH config file and instead use a pair of public and private keys to authorize your connection.

Keep in mind that this method may not be as convenient if you need to be able to login to your server from anywhere at a moment’s notice, since you will need to add your private key to any new system you are connecting from. Also, while this approach makes remote connections an order of magnitude more secure, don’t neglect to never-the-less set a strong password on your account. Hackers are sometimes able to access a system in other ways, and you wouldn’t want to have an account with elevated access secured by a password like, “1234.”

These days, two-factor authentication (2FA) is becoming very popular. When using 2FA, not only does a user need to authenticate with their password, they also need to provide a one-time-use code sent to a previously registered email address or mobile device to further verify their identity. Implementing something like this on your server could be done through a third party service, or by using a 2FA-enabled account (like Google or Microsoft). cPanel\WHM now supports two-factor authentication, so this may be an option for you if you use this control panel as your main means of server administration.

Brute Force Protection

A common attack vector on servers is a brute force attack. These are remote login attempts using guessed usernames and passwords, repeated over and over, as fast as the servers and network will allow. Unprotected, this can be several hundred thousand attempts per day — enough to crack any 8-character password in a month. For this reason, it is prudent to install some form of brute force protection on your server.

Most approaches to brute force protection take one of two forms. The first method introduces a timeout between login attempts. Even if this timeout is as short as a single second, this can cause an attack to take many times longer to crack the password. You’d likely want a longer timeout to provide better security, while not overly-interfering with legitimate login attempts by users making typos. Some systems take a clever approach to this method by increasing the timeout with every failed attempt, often exponentially. Fail once, wait 1 second. Fail again, wait 5 seconds. Fail a third time, wait 30 seconds… By the fourth attempt, you’re going to be very careful entering your password.

Alternatively, a variation of this method puts a hard cap on the number of attempts allowed within a set period of time. Failing to login too many times will get the account locked out – either temporarily, or in more extreme cases, until unlocked by a server administrator. This method effectively puts a stop to any brute force attacks, but it can be more annoying for valid users who aren’t very careful about entering their passwords.

The second method is to introduce a Captcha to the login request. This forces the user to perform a feat that is trivial for a human, but difficult for a computer. Often, this involves some sort of image recognition, such as identifying all the pictures in a grid that contain a street light, or deciphering some text written in a blurry font. While computers are usually able to solve these requests eventually, it takes them much longer than a typical human and greatly slows down the attack. Captchas are also often used to protect public comment sections from spam posts and sign-up forms from fake account creation.

Brute force protection can be found in many firewalls, or in the operating systems themselves — but don’t forget about other accounts, such as WordPress, cPanel/WHM, etc. Make sure any exposed login has some form of brute force protection enabled.

Software Updates & Security Patches

Software and operating system updates and security patches are also important to maintaining a secure server. All of your other efforts can mean nothing and go entirely to waste if you are running an outdated version of an operating system vulnerable to known exploits.

Most software and operating system vendors dedicate significant resources into keeping their products patched against the most recently discovered exploits, so much so that many minor releases contain more security fixes than feature updates. Maintaining this level of vigilance on older versions of their products can be costly, so software and operating systems are frequently classified as End of Life (EOL) after a number of years. Among other things, this means that the product will no longer receive updates for exploits that may be discovered after EOL has been reached.

A commonly seen case of this type relates to PHP, a scripting language commonly used on the web. At the time of this posting, all PHP versions older than 7.2 are EOL. Despite this, PHP versions as old as 5.3 are still common out in the wild. There are significant differences between 7.2 and 5.3, making upgrading to a supported version impossible without significant reworking of the code. 

Fortunately, with this specific example of PHP versions, CloudLinux has you covered on a cPanel server. CloudLinux offers hardened versions of old PHP versions, as well as security updates, well past the EOL date. However this issue could happen with any software, and most don’t have a solution as simple as CloudLinux. 

It is not good practice to run outdated operating systems either. For example, CentOS 5 has been EOL for some time, yet it is not a terribly rare sight. If you happen to be running something like this, you should be planning your upgrade path as soon as possible. When the operating system you are running on goes EOL, it’s common that even supported software on your server will also stop receiving updates, since vendors won’t qualify new versions on EOL OS versions. This can have a cascading negative effect on the security of your server.

Code & Custom Applications

Unfortunately, even the most hardened server can still be vulnerable to attacks through insecure code or applications running on a website.

If you are running a customizable web application, such as WordPress, Joomla, or Magento, it is critically important for you to keep not just the core application up to date, but any plugins or themes as well. This also applies to the code of the project themselves – if you suspect that your theme or plugin is “dead” and no longer being updated, it is prudent to look for alternatives. New exploits are constantly being discovered, and an application or plugin is only as secure as it’s last update.

When dealing with custom code created for you by a developer, it is wise to maintain a continued relationship with your developer so that you can continue to receive updates. Otherwise, you may end up in a situation as described above, where you find that you can no longer update your PHP or other important software because the website is not compatible with the new version.

This attack vector can be the hardest to defend against, because your datacenter or hosting provider generally can not support the custom software and code that is running on your server. Unless you are running entirely off-the-shelf software, make sure you have a plan to keep your code updated and patched.

As you can see, securing a server goes far beyond the initial setup. While this is important, equally vital is keeping it up-to-date in order to combat the ever growing list of known hacks and exploits. The damage caused by a compromised system, both financially and to your reputation, can be massive. As the old adage goes, an ounce of prevention is worth a pound of cure.