Server Security


This article explores some high-level concepts around securing SpinUp Cloud Servers. We highly recommend performing these actions on any resource deployed in the cloud, if applicable.

Basic Cloud Server security

This article describes how to set up some basic security for your Linux and Windows® Cloud Servers.

Overview

Securing your Cloud Server is one of the most important steps that you should take after creating it. This article provides steps to set up basic security for your Cloud Server, but this is not necessarily the most secure configuration. Be sure to write secure application code as well as securing your Cloud Server.

Prerequisites

To you use the following recommendations, you must have root or Administrator login permissions on your Cloud Server.

Be sure that Secure Shell (SSH), sudo, and iptables are configured correctly on your Cloud Server. If not, you might be locked out of your system when you make changes to these configurations. If you are locked out, log in to the Control Panel and use the console or rescue mode to change the configuration settings.

Use the recommended actions in the following tabs to set up basic security for your Cloud Server.

Secure your Cloud Server

Update your Linux repositories and packages

Your Cloud Server does not necessarily have automatic updates enabled–this varies by the specific Linux distribution you’re using. When you start a new SpinUp Cloud Server, ensure that you update to the latest repository information, and then update your installed packages to their latest versions to avoid potential vulnerabilities resulting from outdated software.

If you are developing custom code that runs on your Cloud Servers, such as websites coded in php, then updating your installed packages might have unintended effects on your code. However, you should not create static environments and neglect to apply critical updates for the sake of code stability, because this introduces a huge security risk that only increases the longer your packages are left unattended and out-of-date. Instead, be sure to create a thorough testing environment where you can update packages first and check the stability of your custom code, and then schedule periodic package updates to be performed once testing and error correction is done.

Disable root SSH access

Most server administrators require SSH access to their Cloud Servers. Even if you do not typically interact with your individual devices manually and use automation, you should have an available login to the shell in case automation is broken (plus some services will use SSH to log into servers). The ability to directly SSH into a server as the root user, however, introduces the risk that an intruder can gain full access and control of that device.

There are many bots that attempt to gain access to cloud servers all across the internet, including yours, over SSH by attempting to log in as root repeatedly with any number of popular passwords and random combinations of characters. You should disable the root user from logging in via SSH, and create a new username that you will use to access your Cloud Server. By giving this user sudo privileges, you can then perform all the same actions as root once you are logged in.

Block ports

Blocking all ports except for HTTP (port 80), HTTPS (port 443), and SSH (port 22) reduces the ways that someone could use to access your Cloud Server. You can block all other ports from receiving traffic by configuring rules in the firewall package installed by default on your Cloud Server. Ubuntu and Debian Linux servers typically use UFW, CentOS and Fedora use firewalld. Check the documentation for your specific firewall to find out more about how to configure these rules, and remember that some firewall systems require you to explicitly save your changes to make them permanent, otherwise they do not persist through a server reboot.

Prevent brute force attacks with fail2ban

Brute force attacks attempt to discover your password by systematically trying every possible combination of letters, numbers, and symbols, usually starting with popularly used passwords first. This is how bots and other bad actors try to gain access to your Cloud Servers, especially over SSH, though bots also attempt to break into other popular and often vulnerable services running on other ports, such as MySQL.

Fail2ban blocks repeated, failed attempts at access by adding firewall rules to ignore requests from repeat offenders. You can fine-tune the rules to be temporary or permanent, and set the number of failed tries before a ban is applied. You can also create whitelists to allow certain IPs through without the possibility of getting banned. If you accidentally lock yourself out of your Cloud Server, you can always use the Console button to log in directly, without relying on SSH or any other remote services that can get blocked by the firewall, and correct your Fail2ban settings.

For more information, see the Fail2ban documentation.

Enable automatic security updates

Some Linux distributions have automatic security updates enabled by default, however because this will vary between distributions, it’s important that you know where to check the settings for automatic updates and how to enable them yourself. The following the commonly used services manage automatic security updates.

OS Method Enabled by Default?
Ubuntu unattended-upgrades yes
Debian unattended-upgrades no
CentOS yum-cron no
Fedora dnf-automatic no

Use SSH keys

An SSH key is an alternative method to passwords that can be used to authenticate when logging into SSH. When you generate a pair of keys, one private and one public, the public key can then be distributed to your Cloud Servers and used to authenticate you when connecting via SSH. Unlike passwords, modern SSH keys are extremely long and encrypted in such way that it is very close to impossible for any attacker to reverse engineer or guess the private key contents.

SpinUp provides you with the ability to create and store a project-wide collection of public keys, and add any one of these to a Cloud Server when it is being built. You can add a public key to a Cloud Server at any time, by copying it to the correct directory for stored keys for your Linux distribution.

Warning

SSH key security only works so long as the contents of your private keys are kept secure. Do not upload your private keys into your SpinUp account, any public or insecure shared spaces, or distribute it to other users in your own environment. Unless you are thoroughly familiar with security best practices and moving private keys into a secured management platform, private keys should never leave the machine on which the keypair was created.

What’s next?

Check out the SpinUp Community for detailed, step-by-step walkthroughs of these security recommendations for your specific Linux OS, plus help and expert tips on many other topics.

Enable Windows Automatic Updates

SpinUp strongly recommends that you enable Windows Automatic Updates to make sure critical patches are applied to your Windows Cloud Servers. You can set a schedule for updates that best fits your needs, and because there can be a brief downtime for patches that require a reboot, we recommended that you stagger the day of the week assigned to different production Cloud Servers in a load balanced solution, so that some nodes are always up while the others nodes potentially have patches applied. For example, in each load balanced group, half the nodes could be set to receive automatic updates on Mondays, while the other half is patched on Wednesdays.

Configure local firewall rules

By default, Cloud Servers do not have a dedicated firewall device in front of them to manage traffic. This means that the Windows firewall is the only layer of defense between your server and anybody with access to an Internet connection. You should disable all rules on the firewall that you do not need. Disabling rules means that fewer ports are open and accessible over the public interface, which helps to limit the server’s exposure to the Public Network. One of the most common ways Windows servers are compromised is through brute force attacks on the Remote Desktop port (3389)–you should restrict access to this port via the firewall so that only trusted IP addresses can connect to it.

Enact a strong password policy

At a minimum, passwords should consist of at least 8 to 10 characters that include uppercase and lowercase letters, numbers, and special characters (such as !, #, $, and %). Using simple passwords can be extremely dangerous for servers exposed to the public net. You can also set an expiration date for each user’s password. While it might be inconvenient for user to set and remember a new password periodically, this practice helps you to manage security on your server.

Next steps

Check the security logs for your server regularly, and be sure to promptly disable or delete any user accounts on the server that are no longer in use. You can stay informed about the latest potential security vulnerabilities and how to address them by checking out the Microsoft Security Response Center blog regularly.

Check out the SpinUp Community for detailed, step-by-step walkthroughs of our recommended security settings for your Windows Cloud Server, plus help and expert tips on many other topics.

Conclusion

Securing your server is one of the first things that you should do after creating it. The steps in this article help you set up some basic security, and provide tips to help users operate securely as well. SpinUp recommends the preceding steps as minimum guidelines. You should determine if your infrastructure requires more security and set that up if needed. To this end, SpinUp recommends following the documentation for your selected operating systems and installed software.


Related Content