First Hour on a New Linux Dedicated Server: A Hardening Checklist

Answer first: the checklist

Eight steps, roughly in the order you should do them. Each one is a few minutes; the whole list fits comfortably in your first hour on the machine:

1. Create a non-root admin user with sudo; stop logging in as root.
2. Switch SSH to keys only and harden sshd_config.
3. Apply a default-deny firewall baseline — allow SSH and your services, drop the rest.
4. Enable automatic security updates.
5. Install fail2ban to ban addresses that fail authentication.
6. Verify time synchronisation is active.
7. Audit what's listening and remove or internally-bind anything that shouldn't be public.
8. Make logs persistent and skim them once.

Everything on the list defends against the actual day-one threat model of an internet-facing server: automated, indiscriminate scanning and credential stuffing. Unit 42's honeypot research found exposed services attacked within minutes of going live and 80% of honeypots compromised within 24 hours — the scanners do not care who you are, only that you answered. The details, distro-by-distro, follow.

Step 1: a non-root user with sudo

Working as root full-time means every typo runs with full privileges and every service you misconfigure defaults to maximum blast radius. Two minutes:

adduser deploy
usermod -aG sudo deploy      # Debian/Ubuntu
usermod -aG wheel deploy     # RHEL/AlmaLinux/Rocky

Copy your SSH key to the new user (ssh-copy-id [email protected], or paste into ~/.ssh/authorized_keys), confirm you can log in and sudo -i, then proceed to locking down SSH. Order matters: never disable a door until the new one demonstrably opens.

Step 2: SSH — keys only, root locked

Password authentication is the thing the scanning botnets are betting on. Kill it:

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Then validate and reload — sshd -t syntax-checks the config so a typo can't take SSH down with it:

sshd -t && systemctl reload ssh    # 'sshd' on the RHEL family

Keep your current session open and confirm a fresh connection works before you log out. That habit — test the new door with the old one still open — is the difference between hardening and locking yourself out. (If it ever goes wrong anyway, out-of-band console access saves you; more on that at the end.)

Notes worth knowing:

• Modern distros ship reasonable SSH crypto defaults — you don't need to hand-curate cipher lists anymore.
• PermitRootLogin prohibit-password (key-only root) is a defensible alternative to no if your tooling genuinely needs root logins; prefer no plus sudo when you have the choice.
• On recent Ubuntu releases sshd is socket-activated (ssh.socket), which mostly doesn't matter — until you change the port, at which point it very much does. Which brings us to:
• Changing the SSH port is noise reduction, not security. It cuts log spam from the dumbest scanners; it does not slow an attacker with a port scanner. Do it for quieter logs if you like, never instead of keys.

Step 3: the firewall baseline

Debian and Ubuntu ship with no firewall rules at all — every listener is world-reachable the moment it starts. The baseline takes five minutes: default-deny inbound, allow established traffic, allow-list SSH and your actual services, and get ICMP right (don't blanket-block it — that breaks path-MTU discovery and IPv6).

We've written the complete annotated ruleset up as its own guide — sensible default firewall rules for a Linux server — with the same policy in native nftables, ufw, and firewalld, plus the lockout-avoidance mechanics. If you only follow one link from this checklist, make it that one. (Deciding between rule syntaxes? iptables vs nftables.)

The one-line summary per family: ufw on Ubuntu, firewall-cmd on RHEL/Alma/Rocky, native nftables on Debian — enable it, allow 22 plus your service ports, deny the rest, both address families.

Step 4: automatic security updates

The majority of real-world compromises exploit vulnerabilities that had patches available. A server that patches itself closes that window without relying on you reading advisories at breakfast:

# Debian/Ubuntu — installed and on by default on Ubuntu Server; verify:
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# RHEL/AlmaLinux/Rocky — security-only automatic updates:
dnf install dnf-automatic
# set upgrade_type = security in /etc/dnf/automatic.conf, then:
systemctl enable --now dnf-automatic.timer

Scope it to security updates (both defaults above do) so unattended runs can't surprise you with major version bumps. Kernel updates still need a reboot to take effect — check in occasionally or schedule reboots; unattended-upgrades can do controlled automatic reboots if your workload tolerates them.

Step 5: fail2ban — ban on evidence

Your firewall's rate limit throttles connection attempts blindly; fail2ban reads the authentication log and bans addresses that actually fail — evidence-based blocking that complements both the firewall and key-only auth:

apt install fail2ban    # dnf install fail2ban (needs the EPEL repository on RHEL-family)

The packaged defaults enable the SSH jail, which is the one that matters. One adjustment worth making in /etc/fail2ban/jail.local: add your own management IPs to ignoreip so a fumbled key on your side can't ban you.

Is fail2ban necessary once passwords are off? Strictly, no — key-only auth doesn't fall to brute force. It still earns its slot: it cuts log noise dramatically, covers the other services you'll add later (mail, panels, databases with auth logs), and blunts the CPU cost of aggressive scanners.

Step 6: time sync

Unsexy and essential: TLS certificate validation, database replication, log correlation during an incident, and scheduled jobs all quietly depend on correct time. Every modern distro ships an NTP client — just verify it's actually synchronised:

timedatectl    # look for "System clock synchronized: yes" and "NTP service: active"

Debian/Ubuntu use systemd-timesyncd by default; the RHEL family uses chrony. Either is fine for a server — there's nothing to tune on day one beyond confirming the yes.

Step 7: audit your listeners

Now make the firewall's allow-list honest by finding out what's actually listening:

ss -tlnp    # TCP listeners; add -u for UDP

Read the output with three questions: Do I know what this is? Does it need to be reachable from the internet? Is it in my firewall allow-list deliberately? Typical findings on a fresh box are benign (sshd, systemd-resolved on 127.0.0.53) — but this is the habit that catches the database bound to 0.0.0.0 after next month's deploy. Anything internal-only should be bound to 127.0.0.1 or a private network address, not merely firewalled — two layers beat one.

If you run Docker, know that published container ports bypass ufw entirely — -p 8080:80 is internet-facing regardless of your rules. Bind to localhost (-p 127.0.0.1:8080:80) or use the DOCKER-USER chain; details in the firewall guide.

Step 8: persistent logs, one skim

On some distros the systemd journal is memory-only and vanishes at reboot — precisely when you'd want it. Make it persistent:

mkdir -p /var/log/journal && systemctl restart systemd-journald

Then spend two minutes skimming journalctl -p warning -b so you know what "normal" looks like on this machine — incident response starts from a baseline. Wire the box into whatever monitoring you already run (even a basic uptime/disk alert); the first hour just needs the logs to survive and someone to be told when the machine misbehaves.

The cheat sheet, by distro family

Which family to run in the first place is its own decision — our Linux distribution guide covers it.

What NOT to bother with in hour one

An honest hardening guide also says where the diminishing returns start:

• Port knocking and single-packet authorisation. Fun, obscure, and operationally fragile; keys + fail2ban already won this fight.
• Disabling SELinux or AppArmor to "fix" an app. The opposite of hardening. Leave SELinux enforcing / AppArmor enabled; when something breaks, fix the policy (or the app's labels), not the framework.
• Deep kernel/sysctl hardening tours. Beyond SYN cookies (already on by default) and what your firewall guide sets, day-one sysctl tuning is cargo cult. Do it later, with a benchmark and a reason.
• Antivirus and rootkit scanners. On a fresh single-purpose Linux server these mostly consume RAM and produce false positives. Compliance regimes aside, skip them today.
• CIS benchmark runs. Valuable for fleets and audits, overkill for hour one. The checklist above covers the intersection of "high impact" and "low effort"; formal benchmarks can come with maturity.

The pattern: hour-one hardening is about closing the doors bots actually try, then getting on with the work you bought the server for.

Frequently asked questions

Is changing the SSH port worth it?

As log-noise reduction, mildly; as security, no. Untargeted botnets do mostly hammer port 22, so moving sshd quiets your logs — but any attacker who cares runs a port scan and finds it in seconds, and non-standard ports complicate tooling and firewalls. If you do move it, treat it as a convenience tweak layered on top of key-only auth and fail2ban, never as a substitute for them.

Do I still need fail2ban if password authentication is disabled?

Need, no — brute force can't beat a key it can't guess. Want, probably: fail2ban keeps auth logs readable by banning the endless scanner background noise, extends the same evidence-based banning to services you'll add later, and reduces the resource cost of being scanned. It's five minutes of setup for a permanently quieter server; most operators consider that a good trade.

Should I disable root login completely?

Set PermitRootLogin no and use sudo from a named user — that's the right default, and it gives you attribution (whose key did what) plus a second hurdle for attackers. The exception is automation that genuinely requires direct root; there, PermitRootLogin prohibit-password (keys only, never passwords) is acceptable. What's never defensible on an internet-facing server is root with password login.

How is a dedicated server different from a VPS for hardening?

The checklist is identical — the differences sit at the edges. On a dedicated server you own the whole stack, so there's no provider agent inside your OS and no shared-kernel neighbours; the flip side is that recovery is your responsibility, which makes two things matter more: out-of-band console access (for when a firewall or sshd change goes wrong) and the network-edge protections in front of your port. Check your provider offers both before you need either.

Deploying on Serverside

Hardening starts before your first SSH login: on our dedicated servers, always-on DDoS mitigation and a self-service edge firewall sit upstream of your port — so non-service traffic can be dropped before it ever reaches the machine you're hardening — and included KVM-over-IP console access means a botched sshd or firewall change is a two-minute fix instead of a lockout. Provision Ubuntu, Debian, AlmaLinux/Rocky, or RHEL in under a minute on ASN 55285 and run this checklist top to bottom.

Go deeper with the companion guides: sensible default firewall rules, iptables vs nftables, and — for the day the scanners bring friends — DDoS attacks explained.