Linux Server Security Hardening Checklist: SSH, Firewall, Fail2Ban and Patching

The Checklist at a Glance

Ten controls, each explained below. Tick them off per server and keep the list with your documentation.

• Inventory listening ports, accounts and enabled services
• Disable root login and password login over SSH
• Restrict SSH to named users and trusted addresses
• Set a default-deny firewall that exposes only what is needed
• Ban repeated failed logins automatically
• Apply security updates on a schedule
• Remove unused packages and services
• Give users and services the least privilege they need
• Send logs to a central place and watch for changes
• Review everything on a regular cycle

Start With an Inventory

You cannot protect what you have not listed. Before changing anything, record what is listening, who can log in and what starts at boot.

ss -tulpn                                   # listening ports and the process behind each
getent passwd                               # every account on the system
systemctl list-unit-files --state=enabled   # services that start at boot

Anything you cannot justify should be stopped, disabled or removed. A service that is not running cannot be attacked, and it needs no patching.

Lock Down SSH

SSH is the front door of most Linux servers, so it gets the most attention. Confirm that your own key-based login works, then set the following in /etc/ssh/sshd_config.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers deploy admin

• PermitRootLogin noAttackers have to guess a username as well as a credential, and sudo leaves a record of who did what.
• PasswordAuthentication noOnly keys are accepted, which removes password guessing as an attack.
• MaxAuthTries 3Limits the number of attempts per connection.
• AllowUsersOnly the listed accounts can log in over SSH. Replace the example names with your own.

Moving SSH to a different port reduces log noise from automated scans, but it is not a security control on its own.

Set a Default-Deny Firewall

A firewall should drop everything that is not explicitly allowed. Use ufw on Debian and Ubuntu, firewalld on Red Hat family systems, or nftables directly. Hosting servers often also have a firewall built into the control panel.

Open only the ports the server must expose, usually 80 and 443 for a web server. Restrict administration ports such as SSH and database ports to known IP addresses or a VPN. A database port open to the whole internet is a frequent finding in security reviews.

If your cloud provider offers a network firewall such as security groups, use it as well. The provider firewall filters traffic before it reaches the server, and the host firewall protects you if that outer layer is misconfigured.

Block Repeated Failed Logins

Fail2Ban reads service logs and temporarily bans addresses that fail authentication repeatedly. With key-only SSH those guesses cannot succeed, but banning them still cuts log noise and wasted load. Fail2Ban can also protect other services, such as mail and web logins, once the matching log filters are enabled.

Start with the SSH defaults, add your own addresses to the ignoreip setting so you cannot ban yourself, and test that a ban actually triggers.

Patch on a Schedule

Unpatched software is a standing invitation. Enable automatic security updates where you can: unattended-upgrades on Debian and Ubuntu, dnf-automatic on Red Hat family systems.

Kernel updates need a reboot, so agree a maintenance window, or use live kernel patching where your distribution supports it. Track end-of-life dates as well, because a distribution that no longer receives security fixes cannot be hardened. Production systems with strict change control can stage updates on a test server first, but the delay should be days, not months.

Limit Privileges and Keep Watch

Give each person their own account, use sudo with specific rules instead of shared root access, and run services under dedicated low-privilege users. Turn on auditd where you need a record of sensitive actions, and send logs to a central place so an attacker who reaches one server cannot erase the evidence there.

Lynis is a free auditing tool that checks a server against common hardening practices, and the CIS Benchmarks publish detailed configuration guidance for each major distribution. Both are useful for checking your own work.

Keep It Hardened Over Time

Hardening decays. New packages open new ports, staff leave and configurations drift. Review the checklist every quarter, remove accounts when people change roles, and run a vulnerability scanner such as Nessus or Qualys against the server on a schedule.

Security controls use resources too. If a hardened server starts to feel slow, this guide to finding CPU, memory and disk bottlenecks shows how to trace the cause.

The Bobcares engineering team includes security hardening and regular patching in its server management work, for teams that would rather not carry it alone.

Conclusion

A hardened Linux server is the result of a few dull habits: knowing what runs, locking down SSH, filtering traffic by default, patching on time and watching the logs. None of them is difficult, and together they close most of the doors that automated attacks rely on.

If keeping up with them is a struggle, server management services can take on the routine, and server monitoring services can alert you when something changes.

Frequently Asked Questions