← Back to Blog

Linux Server Hardening 101

Published: March 2026 | Category: Security & Infrastructure

In the world of cloud infrastructure, the server is the primary attack surface. Whether you are running a bare-metal rack or a containerized instance in the cloud, an unhardened Linux system is essentially an invitation for automated scanning bots. Hardening is not a one-time "set and forget" configuration; it is a layered, proactive defense strategy aimed at minimizing your attack surface.

1. The Identity Perimeter: SSH Security

The SSH daemon is the most exposed service on any Linux server. If you leave it at default settings, you are vulnerable to brute-force attacks within seconds of assigning a public IP address.

Key SSH Hardening Rules:

Disable Root Login: Never allow direct root access. Require users to log in as a standard user and escalate privileges via sudo.
Disable Password Authentication: Only allow SSH keys (Ed25519 is currently recommended over RSA).
Change Default Port: While this is "security through obscurity," it significantly reduces log spam from automated scanners.

# /etc/ssh/sshd_config
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

2. Network Perimeter: Firewall & Least Privilege

A server should only communicate over the ports absolutely required for its function. If your server is a database, only the application server’s internal IP should be allowed on the database port. Everything else should be blocked by default.

Using UFW (Uncomplicated Firewall) or iptables is essential. Implement a Default Deny policy:

# Set default policies
ufw default deny incoming
ufw default allow outgoing

# Allow specific SSH port
ufw allow 2222/tcp

# Enable firewall
ufw enable

3. System Minimization: Reducing the Attack Surface

Every unnecessary package is a potential vulnerability. If a library has a zero-day exploit, and that library is installed but unused, your server remains vulnerable. Adopt a "minimalist" mindset:

Remove unused daemons: Run systemctl list-unit-files --state=enabled to identify unnecessary services like avahi-daemon, cups, or nfs-server if they aren't required.
Filesystem Security: Mount /tmp, /var/tmp, and /dev/shm with noexec, nosuid, and nodev options. This prevents users from executing malicious binaries within temporary directories.

4. Kernel Hardening with sysctl

The Linux kernel itself can be tuned to resist common network attacks. Modifying /etc/sysctl.conf allows you to ignore spoofed packets or protect against SYN flood attacks.

# Disable IP forwarding (unless server is a router)
net.ipv4.ip_forward = 0

# Protect against SYN flood attacks
net.ipv4.tcp_syncookies = 1

# Ignore ICMP echo requests (prevents being discovered by simple pings)
net.ipv4.icmp_echo_ignore_all = 1

5. Intrusion Detection & Auditing

Hardening stops attackers, but auditing tells you who tried to get in. You should implement two critical layers:

Fail2Ban: Automatically bans IP addresses that show malicious signs—such as too many failed password attempts or searching for exploits on your web server.
Auditd: The Linux Audit Framework provides a detailed log of every file access, process execution, and system call. This is vital for forensic analysis if a breach occurs.

Monitoring the /var/log/auth.log or journalctl is crucial. I recommend piping these logs to a centralized stack (like the ELK Stack discussed in my previous post) so that you can create alerts for unauthorized sudo attempts or repeated failed SSH connections.

Conclusion

Hardening Linux is a continuous process of reducing risk. By implementing the layers discussed—securing SSH, enforcing strict firewall rules, minimizing the OS, and enabling auditing—you make it significantly harder for an attacker to achieve their goals. Remember, security is not about being unhackable; it is about being an unattractive target. Make your server a fortress, not a target of opportunity.

References

CIS Linux Benchmarks (Center for Internet Security)
NIST SP 800-123: Guide to General Server Security
Linux Auditd Documentation

Author: Agu Chiedozie | Cloud Systems Architect