Your First Virtual Server: A Practical Checklist

A freshly created cloud server is reachable from the entire internet within
seconds of existing, and automated scanning will find it quickly. The following
sequence is not advanced administration. It is the minimum that should happen
before anything of value goes anywhere near the machine.

Before you create it

Two decisions are much easier to make now than to change later.

Choose the region deliberately, based on where your users
are and any legal requirement about where data sits. Moving a server between
regions later means rebuilding it.

Add your SSH public key during creation, if the provider
offers it. This avoids the machine ever having password authentication enabled,
which is a better starting position than turning it off afterwards.

The checklist

1. Connect using key authentication and confirm it works
   before you change anything else. Keep that session open while you make changes,
   so that a mistake in the SSH configuration does not lock you out of a machine
   you cannot get back into.
2. Apply all pending updates. Provider images are built
   periodically and are rarely current. This is the single highest-value command
   you will run on the machine.
3. Create a non-root user with administrative rights and use
   that from now on. Working as root full time means every mistake is maximally
   destructive and nothing is attributable.
4. Disable password authentication and root login over SSH,
   then reload the SSH service and open a second session to verify before closing
   the first.
5. Configure a firewall that denies by default. Allow SSH, and
   allow HTTP and HTTPS only if the machine is serving them. Use the provider’s
   network-level firewall as well as the host firewall where one is offered: the
   provider firewall keeps traffic off the machine entirely, which is the stronger
   position.
6. Set the hostname and time zone, and confirm time synchronisation is
   running. Clock drift produces authentication failures and log
   timestamps that cannot be correlated, and both are miserable to diagnose.
7. Install and enable automatic security updates if the
   distribution supports them, or put a recurring reminder in a calendar if it does
   not.
8. Set up a backup and then restore from it. A provider
   snapshot schedule is a good start. An untested backup is not a backup, and the
   moment to discover that is now rather than during an incident.
9. Install basic monitoring. At minimum, something that tells
   you about disk space. A full disk is the most common cause of a small server
   failing, and it is entirely preventable with a warning.
10. Record what you did. A short text file listing the region,
    the size, what is installed and why, and where the backups go. In four months
    this file will answer questions you cannot otherwise answer.

What not to do on day one

Do not install a control panel unless you have a specific reason. They open
additional network services and expand what you need to keep patched.

Do not expose a database to the internet. If something else needs to reach
it, bind it to a private address and restrict access by firewall.

Do not pick an instance size based on what feels safe. Start small. Resizing
up takes minutes, and oversizing from the start is the most common reason a
first bill is higher than expected, as covered in
why your first cloud bill is
higher.

Once it is running

Point a domain at it rather than using the raw IP address, so that rebuilding
the server later does not mean changing everything that refers to it. Get a TLS
certificate, which is free and automated on every modern stack. And note the
renewal mechanism, because an expired certificate is an outage that arrives on a
schedule you were told about in advance.