A freshly provisioned server is found by automated scanners within minutes of its IP going live. Not hours — minutes. Every routable address on the internet is swept continuously for open SSH, exposed databases and default credentials, and your new box is indistinguishable from any other target until you make it otherwise.
None of what follows is clever. It is the boring set of things that, done in the first hour, removes the overwhelming majority of the ways a server gets taken over. Work through this new server security checklist in order; it takes about forty minutes on a fresh install and it is much harder to retrofit after something is already running in production.
Before you log in, read what you were sent
The provisioning email tells you the IP, the root credentials and the OS image. Three things to do with it:
- Note the OS version. A "CentOS 7" image in 2026 is a machine that stopped receiving updates on 30 June 2024. If you were given a choice, take a release still in support.
- Log in once from a trusted network, not from a café.
- Change the root password immediately if one was mailed to you in plain text. It has been sitting in at least two mailboxes.
1. Keys, not passwords
Password authentication on SSH is the single largest attack surface on a default install, because it is the one an attacker can brute-force from anywhere at no cost.
Generate a key pair on your own machine, install the public key on the server, verify you can log in with it, and only then disable password authentication in sshd_config. Verify first — locking out password login before confirming the key works is the classic way to need a rescue console.
Setting up SSH keys and passwordless SSH login cover the steps on any distribution.
A note on moving SSH off port 22: it cuts your log volume dramatically because most scanners only probe 22. It is not security — a port scan finds the new port in seconds. Do it for quieter logs, not for safety, and do not let it substitute for key authentication. Changing the SSH port if you want the quiet.
2. A user that is not root
Create an ordinary account, add it to the sudo group, confirm it can escalate, then disable direct root login over SSH.
The reason is not that root is dangerous in itself. It is accountability and blast radius: a named account produces an audit trail, and a compromised session that has to run sudo gives you one more place to notice and one more place to log.
Distribution-specific guides: create a sudo user on Ubuntu and add a user to sudoers on Debian.
Resist configuring passwordless sudo on a production box because it is convenient. It is convenient for whoever else gets in, too.
3. Close everything you are not using
Default installs listen on more than you expect. Find out what is actually exposed before you decide what to block: check for listening ports shows you what is bound, and to which interface.
The distinction that matters is bind address. A database listening on 127.0.0.1 is not reachable from the internet; the same database on 0.0.0.0 is, firewall or no firewall. Fix the bind address first, then add the firewall as a second layer.
Default-deny inbound, allow SSH and your application ports, and nothing else. iptables or UFW will do it. For blocking large address ranges, ipset is far more efficient than thousands of individual rules.
4. Patch now, and keep patching
Apply every available update before the server does anything useful. Then decide how the next ones arrive, because "when I remember" is not a plan: automatic updates with yum-cron on the RHEL family, unattended-upgrades on Debian and Ubuntu.
Enable unattended security updates at minimum. The risk of an unattended update breaking something is real but much smaller than the risk of running a known-exploitable package for six weeks.
5. Backups you have actually restored
A backup you have never restored is a hypothesis, not a backup.
Set up backups before the server is in production, and then restore one — to a different machine — to prove the process works end to end. Do it now, while nothing depends on the answer.
Keep at least one copy off the server itself. A copy on the same box protects you against a deleted file and against nothing else: not disk failure, not ransomware, not a mistaken reinstall. Sizing and costing that copy is covered in offsite backup storage for servers, and NexonHost backup storage runs over isolated SFTP-over-SSH accounts from €5 per TB a month as of September 2026.
6. Monitoring you will actually look at
Two categories, both cheap to set up on day one and expensive to add during an incident.
Hardware. Install smartctl and check disk health on a schedule. Disks warn before they fail, but only if something is reading the warning.
Traffic. Establish what normal looks like now, so that abnormal is recognisable later — monitoring network bandwidth and traffic. A baseline captured on a quiet week is worth more than a dashboard installed in a panic.
The checklist
| # | Task | Time | Skipping it means |
|---|---|---|---|
| 1 | SSH keys, password auth disabled | 10 min | Brute force is viable |
| 2 | Non-root sudo user, root SSH disabled | 5 min | No audit trail |
| 3 | Bind addresses checked, default-deny firewall | 10 min | Services exposed you forgot about |
| 4 | Full update, unattended security updates on | 5 min | Known exploits stay open |
| 5 | Off-server backup, one restore tested | 15 min | You have a hypothesis |
| 6 | Disk and traffic monitoring, baseline captured | 10 min | You find out from customers |
What this checklist does not protect you from
Being honest about the boundary is the most useful part of any hardening guide.
It does nothing about application-layer vulnerabilities. An out-of-date CMS plugin is exploited through port 443, which you deliberately left open. Patch the application on the same schedule as the OS.
It does nothing about volumetric DDoS. Attack traffic arrives at your port whether or not you accept it, and a firewall on the host drops packets that have already consumed the bandwidth you are paying for. Filtering has to happen upstream — network-edge mitigation is included on every NexonHost dedicated server, and remote DDoS protection adds application-layer filtering for services that need it.
It does nothing about credentials leaked elsewhere, or a compromised developer laptop, or a supply-chain compromise in a dependency you pulled at build time.
And it is a starting state, not a steady one. A server hardened in September and untouched since is a server hardened in September. If nobody on the team owns that ongoing work, infrastructure management exists to own it — the trade-offs are set out in managed vs unmanaged server hosting.
Sources
- OpenSSH manual pages, OpenBSD. Authentication directives referenced in step 1. Retrieved 21 September 2026.
- CentOS Linux 7 end of life, 30 June 2024, Red Hat. Retrieved 21 September 2026.
- NexonHost backup storage pricing and access method. Retrieved 21 September 2026.
- NexonHost dedicated servers — included network-edge DDoS mitigation. Retrieved 21 September 2026.
