A new server on a public IP address is probed within minutes. The first day is when you set the baseline that keeps it boring afterwards. Work through the list in order, and keep a second SSH session open while you change login settings so a mistake does not lock you out.
The checklist
- Update everything. Refresh the package index and install all security updates, then reboot if the kernel changed.
- Create a non-root user with sudo and set up an SSH key for it.
- Harden SSH. Disable password login and direct root login in
sshd_config, test withsshd -t, reload and confirm a new session works before closing the old one. - Turn on a firewall with default deny and allow only the ports you serve, such as 22, 80 and 443.
- Stop unused services. List listening ports with
ss -tlnpand remove anything you did not install on purpose. - Enable automatic security updates for the operating system.
- Add brute-force protection such as rate limits or a ban tool for repeated SSH failures.
- Check time sync so logs and certificates agree.
- Secure remote management. Restrict access to the management interface and change default credentials.
- Back up and test. Configure an off-server backup and restore one file as proof.
- Record what you did in a short document: IP, users, ports, backup target, who owns patching.
What to monitor from day one
| Signal | Why |
|---|---|
| Disk usage | A full disk stops databases and mail |
| Memory and load | Early sign of an undersized machine |
| RAID or disk health | A degraded array is a risk until rebuilt |
| Failed logins | Shows scanning and weak points |
| Certificate expiry | An expired certificate shows visitors a warning |
The decision on who handles this long term is in managed vs unmanaged dedicated server. For the data-protection side of security, read GDPR data security. Options start at the dedicated server page.
Frequently asked questions
Should I change the SSH port?
It reduces log noise but is not a security control. Keys and a firewall do the work.
Is a firewall enough?
No. It limits exposure. Updates, keys and backups are still needed.
What if I lock myself out?
Keep a second session open while you test, and know how to reach the remote management console.
How often should I patch afterwards?
Apply security updates automatically and review the rest on a fixed calendar, for example weekly.
