Securing a New Cloud Server: The First Hour Checklist

The clock starts when the server gets an IP

A freshly created virtual machine is scanned within minutes. Automated crawlers sweep the address ranges that cloud providers publish, knock on port 22, try a handful of common usernames and move on. None of that is personal. It is simply the background weather of the public internet.

Almost all of it is stopped by a short sequence of decisions taken in the first hour, before the machine holds anything worth stealing. None of the steps below are exotic. They are the defaults that experienced operators apply without thinking, written out so that they are easy to follow the first time.

Work through the phases in order. Each one assumes the previous one is done, and the whole run takes well under an hour on a standard Linux image.

Phase one: decisions made before the machine exists

Two choices in the creation form matter more than anything you can fix afterwards. The first is authentication. Select a public key during creation instead of accepting a password. Providers that offer both will happily email you a root password, and that password is the weakest thing on the server.

The second is network exposure. Most platforms let you attach a firewall at creation time, which means the machine boots with only the ports you named reachable. Opening nothing but SSH at first, then adding web ports once a service is ready, is far safer than booting wide open and tidying up later.

If the provider supports a startup script, this is also the moment to script the hardening rather than typing it. Our guide to cloud-init for server provisioning shows how to bake user creation, key installation and package updates into the first boot so that the risky window never opens.

Phase two: lock down how people get in

Log in and create an unprivileged user for yourself with sudo rights, copying your public key into its authorized keys file. Verify that you can log in as that user in a second terminal before you change anything else. Keeping the original session open is what saves you if a config edit goes wrong.

Now edit the SSH daemon configuration. Set password authentication off so that only keys work. Disable direct root login. If the machine faces the internet, consider moving the daemon off the default port, which removes a great deal of log noise even though it is not a security control on its own.

Reload the service and test again from the spare session. Then add a brute force mitigation such as fail2ban, which watches the authentication log and temporarily blocks addresses that fail repeatedly. Key rotation and multi key setups are covered in detail in SSH keys for cloud servers.

Phase three: shrink what is listening

Run a listening socket check and read the output honestly. A default image often ships with services you did not ask for, and a database that binds to every interface rather than to localhost is one of the most common accidental exposures on the internet.

Bind internal services to the loopback address or to a private network interface. Where a database really must be reachable from another machine, put both machines on a private network and restrict the firewall rule to that range rather than to the world.

Then apply the firewall in two places. The provider level firewall is the outer gate and it filters before packets reach your instance. A host firewall such as ufw or nftables is the inner gate and it survives a move to a different platform. Both layers are explained in cloud firewalls and security groups.

Phase four: keep it current without remembering to

Update every package immediately after first boot. Images are built at a point in time and will be missing fixes released since. After that, the question is how patching continues when nobody is thinking about it.

On Debian and Ubuntu, enable unattended upgrades limited to the security pocket. On enterprise Linux distributions the equivalent automatic update timer does the same job. Configure a reboot window for kernel updates, or adopt live patching if the distribution offers it and a restart is genuinely difficult.

Automatic patching does introduce a small chance of an unexpected change. That risk is much smaller than the risk of running a months old library, particularly for anything reachable from the internet. If uptime is critical, run the same update policy on a staging machine first, as described in building staging environments that mirror production.

Phase five: make the machine tell you things

A server you cannot observe is a server you will learn about from a customer. Before the first real workload lands, ship logs somewhere off the box. If the instance is compromised or simply deleted by accident, logs that lived only on its disk are gone.

Set a small number of alerts that mean something: sustained high load, a disk approaching full, a failed backup, and a successful SSH login by an unexpected account. Alerts that fire constantly get muted, so start narrow and add more later.

Finally, take a snapshot once the hardened state is reached. That image becomes your clean baseline, and rebuilding from it is usually faster and safer than trying to clean a machine you no longer trust. The broader tooling picture is in monitoring cloud servers.

Providers document their own instance security guidance too. DigitalOcean covers the platform side in its Droplets documentation, and the OWASP community maintains an accessible list of the application layer risks that sit above the operating system in the OWASP Top Ten.

The first hour, condensed

• Create the instance with a public key attached and a firewall that allows only SSH.
• Create a sudo user, install your key, and confirm login before locking anything.
• Turn off password authentication and direct root login, then reload the SSH daemon.
• Install a brute force mitigation tool and let it watch the authentication log.
• List listening sockets and bind anything internal to loopback or a private interface.
• Enable a host firewall in addition to the provider firewall, with a default deny inbound.
• Apply all pending updates, then enable automatic security updates and a reboot window.
• Forward logs off the machine and set a handful of meaningful alerts.
• Snapshot the clean state so you can rebuild rather than repair.

The same routine applies whichever platform you use, which makes it a useful habit to build early. If you are provisioning your first instance on a European developer cloud, the Hetzner account listings describe what the account gives you, and the DigitalOcean versus Hetzner comparison looks at how the two platforms differ in firewall and image tooling.