What to Do First on a New Server: A Basic Server Hardening Checklist

A freshly bought server is like a house with no locks: the default user has a simple password, every port is wide open, and root can log in remotely — each is an entry point for someone to "move everything out". Many attacks are automated; within hours of boot, scanners will find your IP. The good news is that most intrusions can be kept out by a basic hardening routine. This guide lays out the routine in six steps that a beginner can follow, ending with a checkable checklist.

1. Why "Start the Website First" Is the Wrong Order

Many people follow this flow: buy a server → install the environment → launch the website → done. Fixing security only after something goes wrong is often too late. The correct order is: buy the server → harden it first → then run your business. Once the business is live, the server has real traffic and real data, and hardening actions like reboots, port changes, and firewall edits can disrupt availability; an empty server costs nothing to fiddle with. So "the first thing" is not installing Nginx — it is securing the front door.

2. Six Hardening Steps, Each with Concrete Actions

Step 1: Update the System and Patch Known Vulnerabilities

Right after logging in, update packages. On Ubuntu/Debian run sudo apt update && sudo apt upgrade -y; on CentOS/RHEL-family run sudo yum update -y. The software in a stock image is often out of date and may carry publicly known vulnerabilities. Reboot afterward to confirm the new kernel is active. Enabling automatic security updates (like Ubuntu's unattended-upgrades) saves you from manual patching. For the reasoning and more baselines behind this layer, see Server Initial Security and CIS Benchmark Hardening.

Step 2: Harden SSH to Close the Biggest Entry

SSH is your operations lifeline and the most common target for brute force. At minimum:

  1. Disable root login directly: set PermitRootLogin to no; work with a normal user plus sudo.
  2. Switch to key-based login: generate a key pair, place the public key in ~/.ssh/authorized_keys, then set PasswordAuthentication to no.
  3. Change the default port: change Port 22 to a high port like 2222 to dodge much default-port scanning (allow the new port through the firewall before restarting sshd).
  4. Restrict which users can log in: use AllowUsers youruser to define an explicit allow list.

Full steps are in SSH Hardening Guide. For another layer, enable Two-Factor Authentication to stack a rotating code on top of your key.

Step 3: Configure the Firewall with a Default-Deny Policy

The firewall's default policy should be "default deny, allow on demand". Open only what you truly need: ports 80/443 for web, your changed SSH port, and database ports restricted to internal networks. Common tools:

  • UFW (Ubuntu): sudo ufw default deny incoming, sudo ufw allow 80/tcp, sudo ufw allow 2222/tcp, sudo ufw enable.
  • firewalld (CentOS): sudo firewall-cmd --add-service=http --permanent and similar.
  • Cloud provider security groups: on cloud servers, the security group is the "first door" and the system firewall is the "second door" — configure both layers.

Rule syntax and common pitfalls are in Linux Firewall Configuration.

Step 4: Least Privilege — Give Every Account "Just Enough"

  • Create a normal user and do daily work with that user plus sudo; do not live as root.
  • Run each service under its own low-privilege user (e.g., Nginx under the nginx user) instead of sharing one privileged account.
  • Tighten permissions on databases, config files, and keys: directories 700/750, files 600/640.
  • When using sudo, grant only the commands needed rather than everything (use the command whitelist in /etc/sudoers).

Step 5: Turn on Logging and Auditing So You Can Investigate Later

Logs are the crime scene. At minimum ensure:

  • System logs (/var/log/syslog or /var/log/messages) are recording;
  • SSH login logging is on (/var/log/auth.log) to spot brute force;
  • sudo auditing is on (records who ran which privileged command);
  • Logs rotate and archive regularly, with important logs stored off-host.

If you do not know where to start, learn the "three checks": failed logins, disk usage, and unusual processes. An intro to auditing and log analysis is in Security Log Auditing Basics.

Step 6: Set Up Backups — Plan for "What If Something Goes Wrong"

Hardening prevents "getting in"; backups cover "even if someone got in / deleted everything / the disk died, you can still recover". A minimal workable plan:

  • Back up critical data (databases, configs, upload directories) automatically every day;
  • Store backups on another machine or object storage, not on the same disk or domain as the server (ransomware encrypts backups too);
  • Practice restore regularly; do not discover a broken backup only after an incident.

Backup strategies and drill templates are in Backup & Restore Runbook and Website Backup Strategy.

3. Checkable Checklist

Tick each item as you complete it; all ticked = basic hardening done.

  • System packages updated to the latest
  • Automatic security updates enabled
  • Remote root login disabled
  • SSH switched to key login with password auth off
  • SSH port changed (optional but recommended)
  • Firewall default-deny with only necessary ports open
  • Both cloud security group and system firewall configured
  • Daily work uses a normal user + sudo, not root
  • Each service runs under its own low-privilege account
  • Sensitive file permissions tightened (600/700)
  • System, SSH, and sudo audit logging enabled
  • Critical data backed up off-site daily
  • One backup restore drill completed

4. Frequently Asked Questions

Q1: Will hardening slow down my website?
Firewall and SSH configuration have almost no performance impact; patching is strictly positive. What affects the business is "changing ports, restarting services" — so do those before launch.

Q2: I only bought a server for a personal blog — do I need all of this?
At minimum do five things: update the system, disable root login, switch to key login, enable the firewall, and back up off-site. Personal sites are scanned by automation too; do not gamble.

Q3: After hardening, am I safe?
Hardening is the starting point, not the finish line. You still need to patch regularly, review logs, and check open ports. Security is an ongoing process, not a one-time action.

Q4: Where can I find more content related to "security hardening"?
The Security Hardening category on this site covers system hardening, WAF, security headers, and more for deeper reading.