Image by: panumas nikhomkhai

Every day, thousands of automated bots scan the internet for vulnerable entry points, specifically targeting open SSH ports on Linux servers. For sysadmins and DevOps engineers, the question is no longer if your server will be targeted, but when. A single weak password or an unpatched vulnerability can lead to a total system compromise, data exfiltration, or the deployment of ransomware. In this comprehensive guide, we provide a step-by-step guide to securing Ubuntu/CentOS servers against modern threats. You will learn how to move beyond basic configurations to implement a defense-in-depth strategy involving SSH hardening, firewall optimization, kernel tuning, and proactive auditing to ensure your infrastructure remains resilient against sophisticated attackers.

Hardening SSH access and automated intrusion prevention

The Secure Shell (SSH) protocol is the gateway to your server. If this gate is left unlocked, an attacker has a direct path to your root directory. The most common attack vector is the brute-force dictionary attack, where bots attempt thousands of password combinations per minute. To defend against this, your first line of defense should be the total elimination of password-based authentication.

Implementing SSH key-based authentication

Passwords, no matter how complex, are susceptible to social engineering and brute-force tools. SSH keys, utilizing RSA (at least 4096 bits) or Ed25519 algorithms, provide a mathematically superior method of identity verification. To secure your server, follow these steps:

• Generate a high-entropy key pair on your local machine: ssh-keygen -t ed25519 -a 100.
• Transfer the public key to your server using ssh-copy-id.
• Modify the /etc/ssh/sshd_config file to set PasswordAuthentication no and PermitRootLogin no.

By disabling root login, you force an attacker to first guess a valid non-root username before they can even begin attempting to crack a key, adding a critical layer of obscurity.

Deploying Fail2Ban for automated blocking

Even with keys enabled, attackers will still hammer your SSH port. Fail2Ban is an essential tool that monitors system logs (like /var/log/auth.log on Ubuntu or /var/log/secure on CentOS) for repeated failed login attempts. Once a threshold is met, Fail2Ban dynamically updates your firewall rules to ban the offending IP address for a specified duration.

“Automated intrusion prevention is not a luxury in modern DevOps; it is a fundamental requirement for any server exposed to the public internet.”

For a production environment, we recommend configuring a “bantime” of at least 24 hours and a “maxretry” limit of no more than five attempts. This prevents persistent bots from slowly testing credentials over long periods.

Optimizing network defenses with UFW and Firewalld

A server’s firewall is its perimeter shield. While many administrators leave all ports open by default, a “deny-all” ingress policy is the gold standard. Depending on your distribution, you will likely use either UFW (Uncomplicated Firewall) for Ubuntu/Debian or Firewalld for CentOS/RHEL/Fedora. Both are front-ends for nftables or iptables, but their management philosophies differ.

Configuring UFW on Ubuntu

UFW is designed for simplicity. To secure an Ubuntu instance, you should start by denying all incoming traffic and allowing only essential services. Use the following workflow:

1. sudo ufw default deny incoming
2. sudo ufw default allow outgoing
3. sudo ufw allow ssh (or your custom SSH port)
4. sudo ufw allow http and sudo ufw allow https
5. sudo ufw enable

Managing Firewalld on CentOS

CentOS uses a zone-based approach. Instead of just opening ports, you assign network interfaces to “zones” with specific trust levels. The public zone is the default for internet-facing interfaces. To allow a service in CentOS, use:

firewall-cmd --permanent --add-service=http && firewall-cmd --reload

It is vital to understand the differences in how these tools handle stateful inspection. Below is a comparative look at the primary firewall utilities used in Linux administration.

Kernel parameter tuning for enhanced system resilience

While firewalls manage traffic, the Linux kernel manages how the system processes that traffic. By default, many kernel parameters are tuned for compatibility rather than security. Through sysctl, you can harden the networking stack against common attacks like IP spoofing, Man-in-the-Middle (MitM), and Denial of Service (DoS).

Hardening the TCP/IP Stack

Attackers often use forged packets to redirect traffic or overwhelm a system. By editing /etc/sysctl.conf, you can implement several critical protections:

• Disable IP Forwarding: Unless your server is a router, ensure net.ipv4.ip_forward = 0 to prevent it from being used as a pivot point in a network attack.
• Prevent ICMP Redirects: Attackers use ICMP redirects to alter your routing table. Set net.ipv4.conf.all.accept_redirects = 0.
• Enable Reverse Path Filtering: This prevents IP spoofing by ensuring that packets arrive on the interface they are supposed to. Set net.ipv4.conf.all.rp_filter = 1.
• Protect against SYN Flood attacks: Increase the TCP SYN cookie protection by setting net.ipv4.tcp_syncookies = 1. This helps the server handle a high volume of connection requests without exhausting resources.

After making these changes, always run sudo sysctl -p to apply the new settings immediately without a reboot. For those managing complex cloud architectures, learning these low-level tunables is essential for maintaining kernel stability.

Implementing auditd for continuous security monitoring

Security is not a “set and forget” task. You need visibility into what is happening on your system in real-time. The Linux Audit Framework (auditd) provides a powerful mechanism for tracking system calls, file access, and user activities. While standard logs tell you what happened, auditd tells you who did it and how.

Setting up meaningful audit rules

The challenge with auditd is the sheer volume of data it can produce. If you log everything, you will drown in noise. A professional approach involves targeting high-value assets. You should configure rules to monitor:

• System Configuration Files: Monitor any changes to /etc/passwd, /etc/shadow, and /etc/sudoers.
• Binary Execution: Track whenever sensitive binaries like /bin/chmod or /bin/chown are executed.
• Unauthorized Access Attempts: Log all failed attempts to use the sudo command.

A sample rule to monitor changes to the shadow file would look like: -w /etc/shadow -p wa -k user_modification. The -k flag attaches a “key” to the event, making it significantly easier to filter through logs later using the ausearch tool. Integrating these logs into a centralized SIEM (Security Information and Event Management) system is a best practice for any scaling DevOps workflow.

Best practices for patching and privilege management

The final pillar of server security is human and process management. Even the most hardened kernel cannot protect a system if a user accidentally downloads a malicious script or if an administrator uses a shared account. Effective security requires a strict adherence to the Principle of Least Privilege (PoLP).

Automated Patch Management

Vulnerabilities like Heartbleed or Log4j show that software flaws are discovered constantly. Manual patching is prone to human error and delay. On Ubuntu, utilize unattended-upgrades to ensure security patches are applied automatically. On CentOS, ensure your yum or dnf processes are integrated into a regular maintenance window. For enterprise environments, consider using tools like Ansible to orchestrate patches across a fleet of hundreds of servers simultaneously.

Privilege Management and User Access

Never allow users to log in directly as root. Instead, every administrator should have their own unique user account. Use sudo for administrative tasks, which provides an audit trail of who executed which command. Furthermore, implement periodic access reviews to remove accounts for former employees or temporary contractors. Regular audits of the /etc/sudoers file are crucial to ensure that no unauthorized users have gained elevated permissions.

For more advanced security hardening, explore the CIS Benchmarks, which provide industry-standard configuration guidelines for nearly every major operating system. Implementing these standards alongside your cloud security protocols will significantly reduce your attack surface.

Conclusion

Securing a Linux environment is an ongoing process of refinement and vigilance. By following this step-by-step guide to securing Ubuntu/CentOS servers against modern threats, you have moved from a vulnerable, default configuration to a hardened, professional-grade setup. Remember the core pillars: replace passwords with SSH keys, restrict network access via optimized firewalls, harden the kernel against network-level exploits, and maintain total visibility through auditd. Most importantly, never stop patching and never grant more privilege than is absolutely necessary. A secure server is not just a destination, but a continuous practice of maintaining defenses in an ever-evolving threat landscape. Start by auditing your current SSH configurations today!