Why Linux Server Security Cannot Be Optional in 2026

Linux powers over 90% of the world's web servers, which makes it the primary target for automated bots, brute-force scripts, and sophisticated attackers. Many hosting clients make the mistake of assuming that because Linux is "secure by default" they don't need to take further action. That assumption leads to compromised servers, data breaches, and blacklisted IP addresses every single day.

This guide walks you through every essential hardening step — from the moment your server is provisioned to the ongoing monitoring practices that keep it clean long-term. Whether you manage a shared cPanel server, a VPS, or a dedicated machine, these steps apply directly to your environment.

Step 1: SSH Configuration Hardening

SSH is the most common entry point for attackers. The default configuration leaves several dangerous doors open.

Open /etc/ssh/sshd_config and make these changes:

# Disable direct root login
PermitRootLogin no

# Change default port (pick anything between 1024-65535)
Port 2222

# Disable password authentication — use keys only
PasswordAuthentication no
PubkeyAuthentication yes

# Limit login attempts
MaxAuthTries 3
LoginGraceTime 30

# Disable empty passwords
PermitEmptyPasswords no

# Disable X11 forwarding if not needed
X11Forwarding no

After saving, restart SSH: systemctl restart sshd

Before closing your current session, open a second terminal and verify you can still connect using the new port. Locking yourself out of a server is a common and painful mistake.

Step 2: Generate and Use SSH Key Pairs

Password-based SSH is inherently weak. Key-based authentication is the industry standard because it requires possession of a private file that never travels over the network.

# On your LOCAL machine, generate a key pair
ssh-keygen -t ed25519 -C "your-server-label"

# Copy your public key to the server
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 username@your-server-ip

Once confirmed working, disable PasswordAuthentication in sshd_config and restart SSH. From this point on, only someone with your private key file can log in.

Step 3: Configure a Firewall (CSF or firewalld)

A firewall is your first line of network defence. ConfigServer Security & Firewall (CSF) is the most widely used option for cPanel/WHM environments; firewalld is preferred on minimal/non-panel setups.

Install CSF on CentOS/AlmaLinux:

cd /usr/src
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf && sh install.sh

Key CSF settings to configure in /etc/csf/csf.conf:

  • Set TESTING = "0" after verifying rules work (default "1" disables blocking)
  • Define TCP_IN and TCP_OUT to only the ports your server needs
  • Enable LF_SSHD to block IPs after repeated SSH failures
  • Set CT_LIMIT to block connection floods per IP
  • Enable SYNFLOOD protection

Step 4: Install and Configure Fail2Ban

Fail2Ban reads your auth logs and automatically bans IPs that repeatedly fail authentication. It works with SSH, cPanel, Exim, pure-ftpd, and dozens of other services.

yum install fail2ban -y
systemctl enable fail2ban --now

Create a local override file at /etc/fail2ban/jail.local:

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true
port    = 2222
logpath = /var/log/secure

Restart Fail2Ban: systemctl restart fail2ban. Check active bans at any time with fail2ban-client status sshd.

Step 5: Keep the OS and Packages Updated

Unpatched software is the root cause of most server compromises. Critical CVEs are actively exploited within hours of public disclosure.

# Manual update
yum update -y

# Enable automatic security updates
yum install yum-cron -y
# Edit /etc/yum/yum-cron.conf and set:
# update_cmd = security
# apply_updates = yes
systemctl enable yum-cron --now

For AlmaLinux 8/9 use dnf instead of yum. Check for outstanding updates weekly with yum check-update.

Step 6: Disable Unused Services and Daemons

Every running service is a potential attack surface. Audit what is running and disable what you don't use:

# List all enabled services
systemctl list-unit-files --state=enabled

# Disable common unnecessary services
systemctl disable bluetooth.service
systemctl disable cups.service
systemctl disable avahi-daemon.service
systemctl disable rpcbind.service

For a web hosting server you typically only need: sshd, httpd/nginx, mysqld/mariadb, named (if DNS), exim/postfix (if mail), and crond.

Step 7: SELinux — Keep It Enforcing

SELinux provides mandatory access controls that limit what processes can do even if they are compromised. Many administrators disable it for convenience — this is a serious security mistake.

# Check current status
getenforce

# Ensure it is enforcing in /etc/selinux/config
SELINUX=enforcing

If a service breaks after enabling SELinux enforcing mode, use audit2allow to create a targeted policy rather than disabling SELinux entirely.

Step 8: File System Permissions and Integrity

Incorrect file permissions allow local privilege escalation and cross-account compromises on shared hosting servers.

  • Web files should be owned by the cPanel/site user, not root
  • Directories: 755, PHP/HTML files: 644, config files with credentials: 600
  • Never use chmod 777 on production — it grants write access to every user on the server
  • Install AIDE (Advanced Intrusion Detection Environment) to monitor file system changes
yum install aide -y
aide --init
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
# Run weekly checks with:
aide --check

Step 9: Implement Two-Factor Authentication (2FA) for WHM/cPanel

If your server runs cPanel/WHM, enable 2FA for the WHM root login immediately. Under WHM > Security Centre > Two-Factor Authentication, enable it and configure TOTP (Google Authenticator or Authy).

Step 10: Regular Offsite Backups

Backups are not a security measure — they are your recovery mechanism when security fails. Follow the 3-2-1 rule: 3 copies of data, on 2 different media types, with 1 stored offsite (external backup server or cloud storage).

Configure WHM's Backup Configuration to keep daily snapshots for 7 days and weekly snapshots for 4 weeks, stored on a remote FTP/SFTP/S3 destination.

Step 11: Monitor Logs and Set Up Alerts

Security events you don't know about cannot be responded to. Configure log monitoring with one of these approaches:

  • cPHulk (built into WHM) — monitors and blocks brute-force login attempts
  • Logwatch — daily email summaries of server activity
  • Maldet / ClamAV — scan uploaded files for malware
  • Rootkit Hunter (rkhunter) — detects rootkits and suspicious system changes
yum install rkhunter maldet -y
rkhunter --update && rkhunter --check

Quick Security Checklist

  • ☑ SSH root login disabled, port changed, key-based auth only
  • ☑ CSF or firewalld configured, unnecessary ports blocked
  • ☑ Fail2Ban running and protecting SSH, FTP, mail
  • ☑ Automatic security updates enabled
  • ☑ Unused services and daemons disabled
  • ☑ SELinux set to enforcing
  • ☑ File permissions audited (no 777 directories)
  • ☑ 2FA enabled on WHM/cPanel admin panel
  • ☑ Daily offsite backups verified
  • ☑ Log monitoring and malware scanning scheduled
Security is a process, not a product. Schedule a monthly audit of this checklist. Server environments change — new software gets installed, new users get added — and each change is a potential new attack surface.

If you need help securing your WebsNP hosted server or want a professional security audit, contact our support team. We offer server hardening as part of our managed hosting plans.