Linux Server Hardening Best Practices: 7 Essential Rules

Securing a Linux server is a foundational responsibility for any systems administrator, DevOps engineer, or developer. Default operating system installations prioritize out-of-the-box accessibility over security, leaving critical vectors open to automated botnets, credential-stuffing campaigns, and unauthorized lateral movement. Adhering to structured linux server hardening best practices security frameworks significantly reduces your attack surface and fortifies your infrastructure against emerging threats.

Whether you are provisioning a cloud instance, an on-premises hypervisor, or a container host, implementing a rigorous defense-in-depth posture is non-negotiable. Below are seven essential rules focused on SSH hardening and stateful firewall configuration to secure your Linux environment.

1. Enforce Public Key Authentication and Disable Passwords

Password-based authentication remains the single largest vulnerability for remote access. Brute-force attacks target SSH ports continuously. Switching exclusively to cryptographic public-key authentication renders standard dictionary and brute-force attacks obsolete.

To enforce key-based access, modify your SSH daemon configuration file located at /etc/ssh/sshd_config:

PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

Ensure you have successfully copied your public SSH key to the remote server via ssh-copy-id before restarting the SSH service to prevent locking yourself out.

2. Disable Root Login via SSH

Allowing direct remote root logins gives attackers a guaranteed target username. Best practices dictate logging in as a standard, unprivileged user with restricted sudo privileges, then escalating privileges only when necessary.

Update your SSH configuration with the following directive:

PermitRootLogin no

This single change forces malicious actors to guess both the username and the password or private key, exponentially increasing the cryptographic complexity required to compromise the host.

3. Move SSH Away from Default Port 22

While security through obscurity is not a primary defense, changing the default SSH port dramatically reduces the volume of automated log noise generated by continuous botnet scanning.

Modify the port directive in your SSH configuration:

Port 2222

Remember to update your firewall rules to allow traffic on your new custom port before restarting the SSH daemon.

4. Implement Timeout Intervals to Drop Idle Connections

Open, unattended SSH sessions left by administrators pose a severe session-hijacking risk if a workstation is left unlocked. Configuring automated client-alive timeouts ensures stale sessions terminate automatically.

Add these parameters to /etc/ssh/sshd_config:

ClientAliveInterval 300
ClientAliveCountMax 2

This configuration instructs the server to ping the client every five minutes and drop the connection after two unanswered responses (ten minutes of total inactivity).

5. Establish a Default-Deny Firewall Policy with UFW

A stateful packet filtering firewall is your perimeter defense. Uncomplicated Firewall (UFW) provides an intuitive interface for managing underlying iptables or nftables rules. The golden rule of firewall hardening is a default-deny posture, blocking all inbound traffic while allowing outbound requests.

Initialize your baseline rules with the following commands:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp
sudo ufw enable

Always verify your SSH rule is active before enabling UFW to prevent permanent lockout on remote instances.

6. Restrict Network Services to Local Loopback

Many databases, caching layers, and internal monitoring agents bind to all network interfaces (0.0.0.0) by default. If these services only communicate with applications on the same host, they should strictly bind to the local loopback interface (127.0.0.1).

Inspect your active listening sockets using the ss utility:

sudo ss -tulpn

Review services listening on public interfaces and update their respective configuration files (such as MySQL, PostgreSQL, or Redis) to bind exclusively to localhost or internal virtual private network (VPN) interfaces.

7. Implement Fail2ban to Mitigate Brute-Force Attacks

Even with SSH hardened, automated scanners will continuously probe your ports, generating resource overhead and log pollution. Fail2ban parses system logs in real-time and dynamically updates firewall rules to ban offending IP addresses exhibiting malicious behavior, such as repeated authentication failures.

Install and configure Fail2ban to protect SSH:

sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edit /etc/fail2ban/jail.local to enable the SSH jail and define your desired ban duration and retry thresholds.

Frequently Asked Questions

What happens if I lose my SSH key after disabling password login?

If you lose your private SSH key and have disabled password authentication, you will lose direct network access to the server. To recover, you must access the server via a cloud provider’s emergency console, a serial interface, or by mounting the storage volume to a recovery instance to restore authorized keys manually.

Is changing the default SSH port an effective security measure?

Changing the default port from 22 to a custom port is not a substitute for robust authentication, but it acts as an effective noise reducer. It drastically cuts down unauthorized connection attempts and log spam generated by automated script kiddies and vulnerability scanners.

Should I use UFW or configure nftables directly?

For most standard Linux deployments, UFW provides a clean, maintainable abstraction layer that prevents human error in complex rule syntax. For advanced kernel-level packet manipulation, custom routing, or high-performance edge firewalls, writing native nftables rulesets directly is preferred.

Conclusion

Hardening a Linux server is an ongoing process rather than a one-time configuration task. By systematically enforcing cryptographic key authentication, restricting root access, locking down network services, and maintaining a strict firewall policy, you establish a resilient operational baseline. Begin applying these practices to your infrastructure today, and audit your configurations regularly to maintain long-term security hygiene.

Disclosure: BriteHacks is reader-supported. When you buy through links on our site or deploy infrastructure, we may earn an affiliate commission at no extra cost to you. As an Amazon Associate, we earn from qualifying purchases.