Linux Server Hardening: 10 Ubuntu and RHEL Best Practices

You are currently viewing Linux Server Hardening: 10 Ubuntu and RHEL Best Practices

Linux Server Hardening: 10 Ubuntu and RHEL Best Practices

Image by: panumas nikhomkhai

In an era where ransomware attacks occur every 11 seconds, a single misconfigured port can be the difference between a stable production environment and a catastrophic data breach. For systems administrators managing securing production enterprise servers, the stakes have never been higher. Whether you are deploying Ubuntu in a cloud environment or running Red Hat Enterprise Linux (RHEL) on bare metal, the attack surface is constantly evolving. This guide provides a deep dive into the professional-grade security protocols required to defend your infrastructure against modern cyber threats, moving far beyond basic firewall rules into the realm of proactive hardening and mandatory access controls.

Securing the gateway: SSH hardening for Linux servers

The Secure Shell (SSH) protocol is the lifeline of remote administration, but it is also the primary target for automated brute-force bots. If your server is connected to the public internet, it is being probed by malicious scripts within minutes of going live. Standard configurations are rarely sufficient for enterprise-level protection.

Disabling password authentication

The single most effective step you can take is to disable password-based logins entirely. Passwords, no matter how complex, are vulnerable to sophisticated credential stuffing and brute-force attacks. By enforcing SSH key-based authentication, you move from a knowledge-based security model to a possession-based one. Use Ed25519 keys for the best balance of security and performance.

“The strength of your SSH configuration is the first line of defense against 90% of automated botnet attacks.”

Implementing advanced SSH protections

Beyond keys, you should modify the /etc/ssh/sshd_config file to restrict access further. Consider the following best practices:

  • Change the default port: While “security through obscurity” isn’s a complete strategy, moving SSH from port 22 to a non-standard port significantly reduces the noise in your logs from low-level script kiddies.
  • Limit users: Use the AllowUsers or AllowGroups directives to ensure only specific, audited accounts can even attempt to authenticate.
  • Disable Root Login: Never allow direct root login. Force users to log in as a standard user and use sudo for privileged tasks. This creates an audit trail linking actions to specific individuals.
  • Set Idle Timeouts: Use ClientAliveInterval and ClientAliveCountMax to automatically drop connections that have been left unattended, preventing session hijacking.

For more information on secure communication protocols, visit the Wikipedia page on Secure Shell. For organizations looking to scale these security policies across thousands of nodes, integrating these settings into enterprise infrastructure solutions is essential.

Network perimeter defense: UFW versus Firewalld

Once the entry points are hardened, the next layer of defense is the host-based firewall. An enterprise server should operate on a principle of “default deny,” where all incoming traffic is blocked unless explicitly permitted. The tool you use depends heavily on your distribution choice.

Ubuntu and the Uncomplicated Firewall (UFW)

Ubuntu users typically rely on UFW, a user-friendly wrapper for iptables/nftables. While it is simplified, it is highly effective for managing rules. In a production environment, you should strictly define the protocols and source IPs allowed to reach your service ports. For example, instead of opening port 80 to the world, you might restrict it if your architecture uses a controlled load balancer.

RHEL and Firewalld

Red Hat-based systems utilize firewalld, which operates on the concept of “zones.” This is a more sophisticated approach that allows you to apply different security levels to different network interfaces. An internal management interface might reside in a “trusted” zone, while the public-facing interface remains in a “public” zone with minimal permissions.

Feature UFW (Ubuntu/Deb_ian) Firewalld (RHEL/CentOS)
Configuration Style Command-based / Simple Zone-based / Dynamic
Complexity Level Low Medium to High
Cloud instances, single-purpose nodes Complex enterprise networks
Interface CLI centric Automated patch management: Never skip an update

The most common entry point for attackers is not a zero-day exploit, but a well-known vulnerability for which a patch has existed for months. In a production environment, the tension between “uptime” and “security” is constant. However, neglecting updates is a gamble that most enterprises will eventually lose.

Unattended Upgrades on Ubuntu

Ubuntu offers the unattended-upgrades package, which can be configured to automatically install security updates. This is critical for mitigating the window of vulnerability between a CVE (Common Vulnerability and Exposure) announcement and your manual maintenance window. You should configure it to only install security-related packages to minimize the risk of service disruption caused by major version-up-grade changes.

DNF-Automatic on RHEL systems

For RHEL and its derivatives, dnf-automatic provides a similar functionality. It allows you even more granular control, such as downloading updates without installing them, or sending email notifications when updates are available. For enterprise environments, we recommend setting apply_updates = no and using a central management tool like Red Hat Satellite or Ansible to orchestrate updates across the fleet.

When implementing automated updates, follow these rules of thumb:

  1. Test first: Always deploy updates to a staging environment that mirrors production-level-load.
  2. Monitor logs: Watch /var/log/dpkg.log or dnf_history to ensure no package failures occurred.
  3. Reboot strategy: Many kernel patches require a reboot. Use tools like kpatch or Livepatch if your SLA does not allow for downtime, but plan for periodic maintenance windows.

To learn more about the latest vulnerability trends, consult the MITRE CVE database.

Mandatory access control: SELinux and AppArmor

Standard Linux security relies on Discretionary Access Control (DAC), where owners of a file decide who can access it. However, if a service running as root is compromised, the attacker gains full control. This is where Mandatory Access Control (MAC) becomes indispensable. MAC systems like SELinux and AppArmor provide an extra layer of defense by defining what a process is allowed to do, regardless of the user running it.

AppArmor: The Ubuntu standard

App actually works on profiles attached to specific executables. It is relatively easy to configure and much less “aggressive” than SELinux. It restricts programs (like web servers or browsers) to specific files, capabilities, and network sockets. If a vulnerability is found in Apache, AppArmor can prevent the compromised process from accessing the /etc/shadow file, even if the process has high privileges.

You can check the status of AppArmor using aa-status. For enterprise-grade security, you should move your critical services from “complain” mode into “enforce” mode.

SELinux: The RHEL heavyweight

Security-Enhanced Linux (SESELinux) is much more complex and granular. It uses labels (contexts) for every file, process, and network port. While it has a steeper learning curve, it offers much deeper protection. A common mistake among administrators is to disable SELinux when a service fails to start. Never do this. Instead, use audit2allow to create custom policies that permit the necessary actions without disabling the entire security subsystem.

For those managing complex-cloud deployments, integrating these-MAC-policies with robust cloud security frameworks is vital for maintaining compliance (such as PCI-DSS or HIPAA).

Auditing and continuous monitoring

Security is not a state; it is a process. Even with hardened SSH and strict firewall rules, you must have visibility into what is happening on your servers. If an attacker manages to bypass your perimeter, your ability to detect them quickly is what prevents a minor incident from becoming a headline-grabbing breach.

Log management and centralisation

Local logs are easily manipulated by an attacker who gains root access. To maintain integrity, you must stream your logs to a remote, hardened logging server. Use rsyslog or an ELK (Elasticsearch, Logstash, Kib Kibana) stack to aggregate logs from all production nodes. Focus on:

  • Failed SSH login attempts (potential brute force).
  • Sudo execution logs (who changed what?).
  • File integrity changes in /etc and /bin.
  • Network connections to unknown external IP addresses.

The power of Auditd

The Linux Audit Framework (auditd) is an underutilized tool in many enterprise environments. It allows you to track system-level-events, such as file access, system calls, and modifications to sensitive configuration files. By configuring rules in /etc/audit/audit.rules, you can create an immutable record of administrative actions, which is essential for forensic analysis after an incident.

For real-time threat detection, consider integrating tools like Fail2Ban, which automatically updates firewall rules to ban IPs exhibiting suspicious behavior, and Lynis quite, an auditing tool that scans your system for security weaknesses and provides actionable hardening advice.

Frequently asked questions

Should I disable root login via SSH entirely?

Yes. In a production environment, you should always disable direct root login. Instead, log in as a standard user with limited privileges and use sudo for administrative tasks. This provides an audit trail and prevents attackers from targeting the most powerful account on the system.

What is the difference between UFW and Firewalld?

UFW (Uncomplicated Firewall) is designed for simplicity and is the default for Ubuntu/Debian. Firewalld is more feature-rich and uses a zone-based approach, making it better suited for complex enterprise environments running RHEL, CentOS, or Fedora.

Is SELinux better than AppArmor?

Neither is “better” in a vacuum; they serve different philosophies. SELinux is more granular and powerful but much more complex to manage. AppArmor is easier to use and easier to learn, but slightly less comprehensive. The choice often depends on the Linux distribution you are using.

How often should I run security audits?

Security audits should be continuous. While deep-dive-audits may happen quarterly, automated vulnerability scanning and log monitoring should happen in real-time or at least daily to catch emerging threats.

Conclusion

Securing production enterprise servers is not a “set and forget” task. It is a continuous lifecycle of hardening, patching, and auditing. By implementing SSH key authentication, configuring robust firewall zones, automating your patch management, and leveraging Mandatory Access Control systems like SELinux or AppArmor, you significantly increase the cost and effort required for an attacker to succeed. Remember that security is about depth; one layer of defense will eventually fail, but a multi-layered approach ensures that a single failure does not lead to total system compromise. Start by auditing your current configurations today and move toward a zero-trust architecture for your infrastructure.