A fresh server on the internet is probed within minutes of coming online. Automated scanners test common passwords, look for open services, and try known vulnerabilities around the clock. None of this means you are being personally targeted; it means the internet is a noisy place, and an unhardened server is an easy target. Twelve steps, done before you go live, close nearly all of the easy openings.

Start with access. Disable password login for SSH and use key-based authentication only, so password-guessing attacks cannot succeed no matter how many attempts they make. Disable login as root over SSH, create a regular user with sudo access, and change the default SSH port only as a minor extra, not as your main defence. Install a tool that blocks repeated failed logins automatically, and keep exactly one way in, guarded well, rather than several ways in guarded loosely.

Next, close what you do not need. A firewall should allow only the ports your services actually use, typically web traffic and SSH, and deny everything else by default. List listening services on the server and remove or stop anything you do not recognise or need. Every open service is an invitation, and the services you forgot you installed are the ones attackers find first.

Then set up the habits that protect you over time. Enable automatic security updates so known vulnerabilities get patched without you remembering. Configure regular backups and test restoring one, because a backup you have never restored is a hope, not a plan. Add basic monitoring and log watching, so unusual activity, like a sudden spike in traffic or a new user account, reaches you while it is still small.

Finally, cover the application layer. Serve everything over HTTPS with a valid certificate, keep your application and its dependencies updated, and store secrets in environment variables or a secret manager, never in code or public files. Give each application its own system user and its own database credentials, so a problem in one app cannot walk into the others. If your app has an admin panel, protect it with an additional login or restrict it to your own IP address.

Work through this checklist in order, and do it before launch rather than after your first incident. Security hardening is not a one-time project; it is a starting position plus the habits of updating, backing up, and watching. Done properly, it takes an afternoon, and it turns your server from the easiest target on the block into a target that most automated attacks simply move past.

Hardening decays. A new application opens a port, a teammate adds a user, a debugging session leaves a service running, and months later the server no longer matches the checklist you followed at launch. Schedule a quarterly review: list users, list open ports, list installed services, and compare them against what should be there. Remove anything unexplained. This review takes under an hour and it catches the slow drift that turns a hardened server into an exposed one.

Also keep a simple record of what you changed and why. A short document noting the firewall rules, the backup schedule, and the monitoring setup means the next person, or future you, can understand the server without guessing. Security is often lost not in dramatic attacks but in small, forgotten changes, and a written record plus a regular review is the cheapest defence against both. Treat hardening as a living checklist, not a launch-day chore, and your server stays a hard target year after year.