Hardening a fresh cloud server in thirty minutes

Automated scanning of the public internet is continuous and comprehensive. A newly provisioned server with a public address begins receiving connection attempts within minutes, and credential-stuffing attempts on SSH shortly after.

None of this is targeted. It is background noise, and it is why “I will secure it later” is a genuinely dangerous plan. The steps below take about half an hour and remove the overwhelming majority of the risk.

Do them in order, before the machine serves anything.

1. Use SSH keys, and only SSH keys

Add your public key when creating the machine. If the provider offers a password instead, do not take it.

Then create a normal user with sudo rights, copy the key to it, and disable both root login and password authentication in the SSH server configuration.

Test the new login from a second terminal before closing your existing session. This is the one step where a mistake locks you out, and keeping the original session open turns a lockout into an inconvenience.

Password authentication is the single largest attack surface on a default server. Removing it eliminates brute-force attempts entirely, because there is nothing to brute force.

2. Configure a firewall, preferably outside the machine

Default deny inbound, allow only what is needed: SSH, and the ports your service actually uses.

Prefer the provider’s cloud firewall over one running on the machine. A cloud firewall sits outside the instance, so a compromised process cannot disable it, and a misconfiguration is fixable from the console rather than requiring access to a machine you have just locked yourself out of.

The rule people break is exposing a database port “temporarily” during setup. Database ports on public addresses are found and attacked within hours. Use an SSH tunnel or a private network instead. There is no version of this that is safe for an afternoon.

3. Enable automatic security updates

Every major distribution has a mechanism for applying security patches without intervention. Enable it.

The argument against, that an update might break something, is real but far outweighed. Unpatched known vulnerabilities are exploited by automation at scale; a package update breaking your application is rare and recoverable.

Configure it for security updates specifically, not all updates, and set it to reboot automatically only if you are comfortable with that. If not, arrange to be told when a reboot is pending, and actually do it.

4. Reduce what is listening

Check which services are bound to a public interface and stop the ones that do not need to be there. Default installations frequently start things you will never use.

Anything that must run but only serves the machine itself should bind to localhost rather than to all interfaces. This is a configuration line in almost every service, and it converts a potentially exposed service into an unreachable one.

5. Add rate limiting on authentication

Even with key-only SSH, an intrusion prevention tool that bans addresses after repeated failures reduces log noise substantially and adds a layer in front of any other authenticating service you expose later.

It is a package install and a default configuration. Fifteen minutes at most.

6. Separate concerns with users

Run your application as a dedicated unprivileged user, not as root and not as your login user. If the application is compromised, the attacker gets that user’s permissions rather than the machine.

Give it access only to the directories it needs. This is not sophisticated containment, but it converts many compromises from total to partial, which is a meaningful difference.

7. Set up logging and know where it goes

Ensure authentication attempts, service logs and system messages are being written and rotated. Log rotation matters practically as well as forensically, because unrotated logs fill disks, and a full disk takes servers down more often than attackers do.

Consider shipping logs off the machine. Logs on a compromised server can be edited by whoever compromised it.

8. Back up, off the machine, and restore one

A backup stored on the server it protects survives nothing. Store it elsewhere, automate it, and restore it once into a throwaway machine to confirm it works.

An untested backup is a hypothesis. The restore test converts it into a fact, and it takes twenty minutes.

What this does not cover

This is baseline hygiene, not a security programme. It does not address application-level vulnerabilities, dependency supply chain risk, secrets management, or anything specific to your compliance obligations.

What it does is remove the automated, opportunistic attacks that account for the overwhelming majority of compromises on small servers. That is a large return for half an hour.

The one-line version

Keys not passwords, deny by default, patch automatically, listen on as little as possible, run as an unprivileged user, and keep a backup somewhere else that you have actually restored.

For a view of how the providers differ on the points above, the cloud account catalogue lays out their respective strengths and configurations.

For the vendor’s own reference on the services involved here, see the DigitalOcean documentation.

None of this takes long to try once you have somewhere to run it. Our DigitalOcean accounts come in six configurations from $20, and the cloud account catalogue shows the nine other providers we carry.

Questions people ask