Blog / The Linux Server Security Checklist Every Business Should Run

The Linux Server Security Checklist Every Business Should Run

Published July 7, 2026 in Security & hardening

Attackers aren't targeting you specifically

Most server compromises aren't the result of a targeted attack. They're automated scans finding a default SSH port with password auth enabled, an unpatched package with a known CVE, or a firewall rule that's wide open because it was easier during initial setup and nobody closed it afterward. Closing the common gaps stops the overwhelming majority of opportunistic attacks, which is most of what any server actually faces.

The checklist

In rough order of impact for the effort involved:

  • Disable password authentication over SSH entirely, key-only access, no exceptions
  • Move SSH off port 22 if you're not already using fail2ban or an equivalent (reduces log noise more than it stops a determined attacker, but it helps)
  • Configure a firewall (ufw, iptables, or your cloud provider's security groups) with a default-deny policy and only the ports you actually need open
  • Install and configure fail2ban to block repeated failed login attempts
  • Set up unattended security updates for the OS and critical packages, with a tracked cadence for anything that needs a human decision
  • Disable root login over SSH; use sudo with a non-root user instead
  • Review who has SSH access on a schedule, not just when someone leaves
  • Set up centralized log review so unusual activity gets noticed instead of sitting in a log file nobody reads

What this checklist doesn't cover

This list handles the baseline that stops opportunistic, automated attacks. It doesn't cover application-layer security (input validation, dependency vulnerabilities in your codebase), which is a separate and equally important concern, or defending against a targeted, resourced attacker, which is a different threat model entirely for most businesses. For the vast majority of servers, though, the baseline above is the gap that actually gets exploited.

Doing this once isn't enough

Hardening a server once and never revisiting it is common, and it's why periodic audits matter as much as the initial setup. New services get added, firewall rules accumulate, and access lists grow stale. A periodic review with a written report catches drift before it becomes a gap.

RELATED SERVICE
Security & hardening

Firewalls, SSH lockdown, patch cadence and audits that keep business systems out of the news.

View this service

Have a system that needs this kind of attention?

Get a Quote