A newly created cloud server is reachable from the entire internet the moment it boots. Automated scanners find it quickly — not because anyone is targeting you, but because the whole address space is scanned continuously. The good news is that the defaults that make this dangerous are all changeable in about ten minutes.
1. Use SSH keys and turn off passwords
Password authentication is the single largest exposure on a default server, because it can be attacked by guessing. Key authentication cannot, because the private key never leaves your machine.
Add your public key to the server, confirm you can log in with it in a second terminal while the first is still open, and only then disable password login in /etc/ssh/sshd_config with PasswordAuthentication no. Reload the SSH service.
Testing in a second session is not superstition. Locking yourself out of a server whose console you have not yet used is a genuinely common way to lose an hour.
2. Stop logging in as root
Create a normal user, give it sudo rights, and set PermitRootLogin no. Attackers know the root account exists on every Linux system; they do not know your username.
This also gives you an audit trail. Commands run through sudo are attributable to a person, which matters the moment more than one person has access.
3. Close every port you are not using
A firewall that allows only what you need converts every future misconfiguration into a non-event. If a service accidentally binds to all interfaces, the firewall is what stops it being reachable.
For a typical web server the entire policy is: allow 22 for SSH, 80 and 443 for the site, deny everything else inbound. A cloud firewall applied outside the virtual machine is stronger than one configured inside it, because it keeps working even if the server itself is compromised or misconfigured.
4. Do not expose your database
Databases should not listen on a public address. The default configuration of most database servers binds to localhost, and it should stay that way unless something genuinely needs remote access.
When an application server and a database live on separate machines, connect them over a private network rather than the public internet. The database then has no public route at all, which is a stronger guarantee than any password.
5. Turn on automatic security updates
Most compromises exploit vulnerabilities that were patched weeks earlier. On Debian and Ubuntu, unattended-upgrades applies security patches automatically and is a two-command install.
Automating security updates specifically — rather than all updates — gives you the patches that matter without unexpected major-version changes.
6. Set up backups before you need them
Backups are a security control, not just an operations one. Ransomware and a fat-fingered rm -rf produce the same outcome, and a restore is the only remedy for either.
Two details separate backups that work from backups that feel reassuring. They must be stored somewhere the server cannot reach — a backup an attacker with root can delete is not a backup. And you must have restored one at least once, because an untested backup is a hypothesis.
What this does not cover
This is the baseline that removes the automated, opportunistic threat, which is the overwhelming majority of what a small server actually faces. It does not cover application security. If your site runs a CMS with plugins, that is the layer most likely to be exploited, and keeping it updated matters more than anything on this list.