Linux Security Hardening: A Practical Enterprise Guide for Linux Administrators

Linux is widely used for enterprise servers, cloud infrastructure, databases, web applications, containers, and critical workloads. But installing Linux and applying updates is only the beginning. A production Linux server should be hardened before it is exposed to users, applications, or the Internet. Linux security hardening is the process of reducing the server's attack surface, restricting unnecessary access, protecting privileged operations, securing network services, enforcing mandatory access controls, monitoring activity, and maintaining a secure configuration over time.

This article provides a practical security-hardening checklist for enterprise Linux administrators, with examples applicable to Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Ubuntu Server, and other major Linux distributions. For the underlying service behaviour discussed here, see Enterprise Linux Services.

Linux Security Hardening Architecture

A hardened Linux server should not depend on a single security mechanism. Think of security as multiple layers:

                    Internet / Corporate Network
                              |
                              v
                    +--------------------+
                    | Network Firewall   |
                    | Security Groups    |
                    | ACLs / Routing     |
                    +--------------------+
                              |
                              v
                    +--------------------+
                    | Host Firewall      |
                    | firewalld / UFW    |
                    | nftables           |
                    +--------------------+
                              |
                              v
              +----------------------------------+
              | Linux Server                     |
              |                                  |
              | SSH Hardening                    |
              | User / Group Controls            |
              | sudo / Privilege Management      |
              | SELinux / AppArmor               |
              | Filesystem Permissions           |
              | Service Hardening                 |
              | Kernel Hardening                  |
              | Patch Management                  |
              | Logging / Auditing                |
              +----------------------------------+
                              |
                              v
                    Applications / Data

The objective is defence in depth.

If one layer fails, another layer should still provide protection.

Start With an Asset and Exposure Assessment

Before changing configuration, determine what the server actually does. Start with:

hostnamectl
uname -a
cat /etc/os-release

Check the IP configuration:

ip addr
ip route

Identify listening services:

sudo ss -lntup

For example:

Netid  Local Address:Port
tcp    0.0.0.0:22
tcp    0.0.0.0:80
tcp    0.0.0.0:443
tcp    127.0.0.1:5432

This immediately tells you something important.

If PostgreSQL is listening on 127.0.0.1:5432 it is locally accessible. If it is listening on 0.0.0.0:5432 it may be accessible from the network, depending on firewall and database configuration.

Security principle

You cannot secure what you have not identified.

Create an inventory of:

• Network interfaces and IP addresses
• Open ports and running services
• Local users and privileged users
• Scheduled jobs and installed packages
• Mounted filesystems and SSH keys
• Firewall rules and security policies
• Log sources

Keep the Operating System Updated

Unpatched software is one of the most common sources of security exposure.

Check for security-related updates according to the distribution's package management and enterprise patching process.

For production environments, patching should normally be integrated with:

Vendor Security Advisories
        |
        v
Vulnerability Scanner
        |
        v
Patch Repository
        |
        v
Test / Non-Production
        |
        v
Production Deployment
        |
        v
Verification

Do not treat patching as a one-time activity. Security hardening is a continuous lifecycle.

Remove Unnecessary Software

Every installed service potentially increases the attack surface. List installed packages according to the distribution.

# RPM-based systems
rpm -qa

# Debian / Ubuntu
dpkg -l

Identify running services:

systemctl list-units --type=service --state=running

Disable services that are not required:

sudo systemctl disable --now <service>

# Example, if Telnet is not required
sudo systemctl disable --now telnet.socket

The general rule is:

Required service       -> Keep + secure
Required but exposed   -> Keep + restrict
Not required           -> Disable/remove
Unknown                -> Investigate

Secure SSH

SSH is often the primary remote administration interface, so SSH hardening deserves special attention. Configuration is typically:

/etc/ssh/sshd_config

Before making changes:

sudo cp /etc/ssh/sshd_config \
        /etc/ssh/sshd_config.backup

Validate the configuration, then reload only after validation:

sudo sshd -t
sudo systemctl reload sshd

# On Ubuntu the service may be named ssh
sudo systemctl reload ssh

Disable Direct Root Login

A common hardening configuration is:

PermitRootLogin no

Administrators should authenticate using an individual account and then use controlled privilege escalation.

Disable Password Authentication Where Appropriate

For SSH key-based administration:

PasswordAuthentication no
PubkeyAuthentication yes

However, do not blindly disable password authentication on a production server. First verify that key-based access works from a separate session, otherwise you can lock yourself out.

Restrict SSH Users

For example:

AllowGroups linux-admins

Create the group and add an administrator:

sudo groupadd linux-admins
sudo usermod -aG linux-admins brits
sudo sshd -t
sudo systemctl reload sshd

Use SSH Keys Properly

Generate a modern SSH key on the administrator's workstation:

ssh-keygen -t ed25519
ssh-copy-id user@server
ssh user@server

Protect private keys:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

The private key should never be copied to the server unnecessarily.

Control Privileged Access With sudo

Avoid giving administrators the root password for routine administration. Instead:

Administrator
      |
      v
Individual Linux Account
      |
      v
sudo
      |
      v
Privileged Operation

Check sudo configuration:

sudo visudo

A controlled configuration could look like:

%linux-admins ALL=(ALL) ALL

For application administrators, use more restrictive rules where practical:

%web-admins ALL=(root) /bin/systemctl restart nginx

This follows the principle of least privilege.

Review Linux Users

Normally, UID 0 accounts deserve immediate review. Use care with service accounts because applications may depend on them.

Enforce Strong Authentication

Enterprise environments should consider centralised authentication instead of maintaining independent local accounts on every server.

LDAP
Active Directory
Kerberos
SSSD
FreeIPA / Identity Management
MFA
SSH certificates

A typical enterprise architecture looks like:

                  Active Directory
                         |
                         v
                      Kerberos
                         |
                         v
                        SSSD
                         |
                         v
                  Linux Server
                         |
                         v
                    sudo policy

Centralised identity provides better control over:

• User lifecycle and group membership
• Authentication and access revocation
• Auditing and privileged access

Configure the Host Firewall

A Linux server should expose only the ports that are actually required. Two common administration approaches are:

RHEL / many RPM environments
        -> firewalld / nftables

Ubuntu
        -> UFW / nftables

UFW Example

sudo ufw status verbose
sudo ufw allow 22/tcp
sudo ufw allow 443/tcp
sudo ufw allow from 10.10.10.0/24 \
    to any port 22 proto tcp
sudo ufw enable

Important: on a remote server, allow your administration path before enabling the firewall.

SSH session
    |
    v
Enable firewall
    |
    v
SSH blocked
    |
    v
Administrator locked out

firewalld Example

sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-services
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

The firewall should be designed around the application's actual requirements:

Web Server
   |
   +-- TCP 443 -> Internet / users
   |
   +-- TCP 22  -> Management network only
   |
   +-- Database -> Application subnet only

Use SELinux or AppArmor

A firewall controls network access. It does not fully control what a compromised process can do after it has been allowed to run. This is where mandatory access control becomes important.

RHEL / Fedora / related
        -> SELinux

Ubuntu / Debian
        -> AppArmor

SUSE
        -> AppArmor

SELinux

getenforce
ls -Z
sudo ausearch -m AVC -ts recent

Typical states are Enforcing, Permissive, and Disabled. For production systems, Enforcing is generally the desired operating mode when SELinux policies are properly configured.

Do not solve SELinux problems by simply disabling SELinux. A better approach is:

Application
     |
     v
SELinux denial
     |
     v
Identify actual access requirement
     |
     v
Correct label / policy / configuration
     |
     v
Retest

AppArmor

sudo aa-status

AppArmor profiles restrict what applications are allowed to access, providing an additional security boundary around supported applications.

Secure File Permissions

Linux permissions are one of the fundamental security controls.

ls -l /etc/passwd
ls -l /etc/shadow

/etc/shadow should not be readable by ordinary users.

Find world-writable files and directories:

sudo find / -xdev -type f -perm -0002 -ls
sudo find / -xdev -type d -perm -0002 -ls

Be careful when interpreting these results because some applications legitimately require specific permissions.

Protect Sensitive Files

/etc/passwd
/etc/shadow
/etc/group
/etc/sudoers
/etc/ssh/sshd_config
/etc/ssh/ssh_host_*

For example:

sudo stat /etc/shadow
sudo stat /etc/sudoers
sudo stat /etc/ssh/sshd_config

Do not make configuration files writable by ordinary users.

Secure Temporary Directories

Temporary directories can sometimes become useful to attackers when applications create insecure files. Check mount configuration:

findmnt /tmp
findmnt /var/tmp

Where appropriate for the workload, administrators can consider mount options such as nodev, nosuid, and noexec.

However, do not blindly apply noexec. Some applications legitimately execute binaries or scripts from temporary locations, and hardening must be tested against the workload.

Protect the Filesystem

For enterprise systems, separate filesystems can make security and operational management easier:

/
├── /boot
├── /var
├── /var/log
├── /var/log/audit
├── /home
├── /tmp
└── /opt

This can prevent a single filesystem from consuming all available space. For example, an application that generates excessive logs should not necessarily be able to consume the entire root filesystem.

Disable Unnecessary Kernel Modules

lsmod
modinfo <module>

If a module is genuinely unnecessary, it may be possible to prevent loading it using distribution-supported configuration.

However, kernel-module hardening should be performed carefully. Removing or blocking a module without understanding dependencies can break:

• Network interfaces
• Storage
• Virtualisation
• Containers
• Hardware drivers

Harden Network Parameters

Linux exposes network-related kernel parameters through sysctl.

sysctl -a
sysctl net.ipv4.ip_forward

Common security-related settings include controls around IP forwarding, ICMP behaviour, reverse path filtering, source routing, redirect handling, and IPv6 behaviour.

Do not blindly copy a generic "secure sysctl.conf" from the Internet. A server acting as a router, Kubernetes node, VPN gateway, load balancer, or container host may legitimately require settings that would be inappropriate on a normal application server.

Secure DNS and Time Synchronisation

Check resolver configuration:

resolvectl status
cat /etc/resolv.conf

DNS security matters because compromised or manipulated DNS resolution can redirect applications to malicious infrastructure:

Linux Server
     |
     v
Corporate DNS
     |
     +-- Internal records
     |
     +-- Forwarders
     |
     v
External DNS

Accurate time is equally critical for authentication, Kerberos, TLS certificates, logs, incident investigation, and distributed systems. Modern Linux systems commonly use chrony:

chronyc tracking
chronyc sources -v

Enterprise Time Sources
          |
          v
       chronyd
          |
          v
    Linux Server

Enable Security Auditing

sudo systemctl status auditd
sudo ausearch -m USER_LOGIN
sudo ausearch -m USER_AUTH

Audit logs can help answer:

Who logged in?
When?
From where?
What privileged operation occurred?
Which file was accessed?
Which security policy generated a denial?

Centralise Logs

Local logs are useful, but they should not be your only source of evidence. A production architecture should consider forwarding logs to a central platform:

             Linux Server
                  |
       +----------+----------+
       |                     |
   journald                auditd
       |                     |
       +----------+----------+
                  |
                  v
           Log Forwarder
                  |
                  v
       Central Logging / SIEM
                  |
          +-------+-------+
          |               |
       Alerting       Investigation

Common enterprise technologies include:

rsyslog
journald
syslog-ng
Elastic Stack
Splunk
Microsoft Sentinel
Cloud-native logging platforms

Monitor Authentication Activity

Look for:

Repeated authentication failures
Unknown users
Unexpected source IPs
Successful login after multiple failures
Unexpected privileged activity

Protect Against Brute-Force Attacks

A layered approach is preferable:

Internet
   |
   v
Network Firewall / Security Group
   |
   v
Host Firewall
   |
   v
SSH
   |
   +-- Key authentication
   +-- Restricted users
   +-- MFA where supported
   +-- Rate limiting / intrusion prevention
   +-- Logging

Tools such as Fail2ban can dynamically react to repeated authentication failures. However, Fail2ban should complement, not replace:

• Strong authentication
• Firewall restrictions
• Network segmentation
• Centralised monitoring

Secure File Transfer and File Sharing

Avoid legacy plaintext FTP where it is not required. Remember:

FTP
    -> File Transfer Protocol

FTPS
    -> FTP protected by TLS

SFTP
    -> SSH File Transfer Protocol

These are different technologies. For example, SFTP normally operates through SSH:

sftp user@server

If an organisation still requires an FTP service such as vsftpd, harden it carefully and consider encrypted transport.

File-sharing services should never be exposed unnecessarily:

# NFS
cat /etc/exports

# SMB / Samba
testparm

Application subnet
       |
       v
NFS Server
       |
       +-- Restricted exports
       +-- Network ACLs
       +-- Appropriate authentication

Do not expose administrative file-sharing protocols directly to the public Internet.

Disable Legacy and Insecure Protocols

Review whether the environment still requires:

Telnet
rlogin
rsh
FTP
HTTP for sensitive applications
SMBv1
Unencrypted administrative protocols

If a legacy protocol is genuinely required, isolate it and document the exception. Security hardening is not about blindly disabling everything. It is about reducing unnecessary exposure while preserving required functionality.

Protect Secrets

Never store credentials casually in:

Shell scripts
Git repositories
Plain-text configuration files
Command history
World-readable files
Shared documentation

Instead consider:

Enterprise Secrets Manager
Vault
Cloud Secrets Manager
Kubernetes Secrets with appropriate controls
Protected configuration files
SSH keys / certificates

Check shell history when investigating accidental credential exposure:

history

Avoid commands such as:

mysql -u admin -pMyPassword

because credentials can become visible through shell history or process inspection.

Secure Cron and Systemd Timers

crontab -l
ls -la /etc/cron.*
systemctl list-timers

Unexpected scheduled tasks can indicate:

• Malware persistence
• Unauthorised administration
• Misconfigured applications
• Forgotten automation

Every scheduled task should have a known owner and purpose.

Harden Systemd Services

Systemd provides several mechanisms that can reduce the privileges and capabilities available to services:

User=
Group=
NoNewPrivileges=
PrivateTmp=
ProtectSystem=
ProtectHome=
ReadOnlyPaths=
InaccessiblePaths=
RestrictAddressFamilies=
CapabilityBoundingSet=

An application should ideally not run as root if it does not need root privileges:

Application
     |
     v
Dedicated service account
     |
     +-- Minimum filesystem permissions
     +-- Minimum network access
     +-- Minimum Linux capabilities

This significantly reduces the impact of application compromise.

Container Host Security

If the Linux server runs Docker, Podman, or Kubernetes, hardening becomes even more important. A container is not automatically a security boundary equivalent to a virtual machine.

Review:

Privileged containers
Host networking
Host filesystem mounts
Docker socket access
Linux capabilities
Seccomp
AppArmor / SELinux
Container images
Image vulnerabilities
Root containers
Secrets
Network policies

Avoid --privileged unless there is a clearly documented requirement. Also avoid unnecessary host mounts such as /, /etc, or /var/run unless required and carefully controlled.

Scan for Vulnerabilities

Security hardening should be validated continuously. Common categories of tools include:

Vulnerability scanners
Configuration scanners
CIS benchmark scanners
Container scanners
Dependency scanners
File integrity monitoring
SIEM
EDR

Examples include OpenSCAP, Lynis, Nessus, Qualys, Rapid7, OpenVAS / Greenbone, Trivy, and cloud security services.

sudo lynis audit system

The output should be treated as an assessment aid rather than an instruction to blindly apply every recommendation.

Use CIS Benchmarks Carefully

The Center for Internet Security publishes security benchmarks for many operating systems and technologies. A typical hardening workflow is:

Baseline
   |
   v
CIS / Internal Standard
   |
   v
Gap Assessment
   |
   v
Remediation
   |
   v
Testing
   |
   v
Exception Management
   |
   v
Continuous Compliance

Do not assume that 100% compliance with a benchmark automatically means that a server is secure. Business requirements and application dependencies must also be considered.

File Integrity Monitoring

For critical servers, monitor important system files:

/etc/passwd
/etc/shadow
/etc/sudoers
/etc/ssh/
/etc/systemd/
/etc/cron.*
Application configuration

Tools such as AIDE can be used for file-integrity monitoring:

Known-good baseline
        |
        v
File integrity database
        |
        v
Periodic comparison
        |
        v
Unexpected modification
        |
        v
Security alert

Secure Backups

Backups are also part of security. A backup strategy should consider confidentiality, integrity, availability, and recovery.

Production
    |
    v
Backup
    |
    +-- Separate credentials
    +-- Restricted access
    +-- Encryption
    +-- Immutable copies
    +-- Offline / isolated copy
    +-- Regular restore testing

At minimum, protect backups from the same compromise that affects the production server. A backup that has never been successfully restored is not a fully validated recovery strategy.

Protect the Boot Process

Physical and console access can bypass many logical controls if the system is poorly protected. Consider:

BIOS / UEFI password
Secure Boot
Bootloader protection
Disk encryption
Restricted physical access
Console access controls

For sensitive systems, full-disk encryption may be appropriate, although unattended server environments require careful consideration of how keys are managed and how systems recover after reboot.

Security Hardening Checklist

A practical Linux server baseline can look like this:

A Practical Hardening Workflow

For a newly provisioned enterprise Linux server, I would use the following sequence:

1.  Identify OS and workload
2.  Patch the operating system
3.  Inventory packages and services
4.  Remove unnecessary components
5.  Create individual administrator accounts
6.  Configure sudo
7.  Harden SSH
8.  Configure firewall
9.  Enable SELinux / AppArmor
10. Review filesystem permissions
11. Secure application services
12. Configure logging and auditing
13. Configure time synchronisation
14. Scan for vulnerabilities
15. Validate against security baseline
16. Document exceptions
17. Monitor continuously

The Most Important Security Principle

Linux hardening is not about running a huge collection of commands. It is about controlling who can access the server, what they can access, what services are exposed, what processes are allowed to do, and how activity is detected.

A useful mental model is:

                Linux Security

             +----------------+
             |   Identity     |
             +----------------+
                     |
             +----------------+
             |   Privileges   |
             +----------------+
                     |
             +----------------+
             |    Network     |
             +----------------+
                     |
             +----------------+
             |    Services    |
             +----------------+
                     |
             +----------------+
             | MAC: SELinux   |
             |     AppArmor   |
             +----------------+
                     |
             +----------------+
             | Filesystem     |
             +----------------+
                     |
             +----------------+
             | Audit / Logs   |
             +----------------+
                     |
             +----------------+
             | Monitoring     |
             +----------------+

Each layer addresses a different part of the threat surface.

Conclusion

A production Linux server should be treated as a security-controlled system rather than simply an operating system with applications installed on top.

The most important areas for a Linux administrator to understand are:

SSH + identity + sudo + firewall + SELinux/AppArmor + filesystem permissions + patching + auditing + logging + vulnerability management + backups.

The strongest hardening strategy is also the simplest to maintain:

Minimise what is installed, minimise what is exposed, minimise privileges, enforce security policies, monitor everything important, and continuously validate the configuration.

Linux security hardening is therefore not a single configuration task. It is an ongoing operational process that must evolve with the operating system, applications, vulnerabilities, infrastructure, and business requirements.

This can also be extended into a Part 2: Linux Security Hardening Commands Cheat Sheet, with distro-specific commands for RHEL, SLES, and Ubuntu, including SSH, UFW/firewalld, SELinux/AppArmor, auditd, permissions, sysctl, and CIS-style checks.