Server Security Audit Checklist 2026: Harden Your Hosting Environment

Overview

A proper security audit is how you catch problems before attackers do. Whether you’re on a shared plan, a VPS, or a Dedicated Server, the same core principles apply: reduce your attack surface, monitor what’s changing, and keep software current.

This checklist is structured for 2026 environments running cPanel/WHM, Plesk, or a plain Linux stack (Ubuntu 24.04 LTS or AlmaLinux 9.x are the most common at this point). Not every item will apply to your setup — use your judgment and skip sections that genuinely don’t fit.

I’d recommend running through this fully at least once a quarter, and after any major incident, software upgrade, or new staff member getting server access. Smaller shops often skip the audit entirely until something breaks — don’t be that shop.

Prerequisites

• Root or sudo access to the server (or WHM Administrator access for cPanel environments)
• SSH client — PuTTY on Windows, Terminal on macOS/Linux
• Basic familiarity with the Linux command line (you don’t need to be an expert, but you need to be comfortable running commands)
• A record of what software is supposed to be installed — if you don’t have this, build one during this audit
• Backups confirmed working before you make any changes

Step-by-Step Security Audit Checklist

1. Confirm All Software Is Up to Date

Unpatched software is the single most common root cause of successful server compromises. Run updates first so the rest of your audit reflects the actual current state of the system.

On AlmaLinux / CentOS Stream 9:

dnf update -y && dnf upgrade -y

On Ubuntu 24.04:

apt update && apt upgrade -y && apt autoremove -y

In WHM, navigate to Home > cPanel > Upgrade to Latest Version and also run Home > Server Configuration > Update Preferences to confirm automatic updates are enabled for security releases.

📝 Note: On production servers, I’d recommend testing updates on a staging instance first, particularly for major cPanel version jumps. Minor and security updates are generally safe to apply immediately.

2. Audit SSH Configuration

SSH is the front door. Most brute-force attempts target port 22 with default settings, so locking this down is non-negotiable.

Open the SSH daemon config:

nano /etc/ssh/sshd_config

Check or set these values:

Port 2222                        # Change from default 22 — pick any unused port above 1024
PermitRootLogin no               # Never allow direct root SSH login
PasswordAuthentication no        # Enforce SSH key auth only
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowUsers youruser              # Whitelist specific users

After saving, restart SSH — but keep your current session open and test in a second terminal window before closing anything:

systemctl restart sshd

⚠ Warning: If you disable password auth before confirming your SSH key works, you can lock yourself out completely. Always test in a separate terminal first.

3. Review Firewall Rules

For cPanel/WHM servers, CSF (ConfigServer Security & Firewall) is the standard. If it’s not installed, install it:

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

Check your current open ports:

csf -l | grep ACCEPT

Or on a non-cPanel server using nftables (the default in AlmaLinux 9 and Ubuntu 22.04+):

nft list ruleset

The goal here is simple: if a port doesn’t need to be open, close it. Common ports that get left open unnecessarily include 3306 (MySQL, should only be accessible locally unless you’re running a remote DB connection), 6379 (Redis), and 8080 (dev ports).

📝 Note: CSF’s TESTING mode in /etc/csf/csf.conf should be set to 0 on live servers. I’ve seen environments running in testing mode for months because nobody checked — in that mode, CSF won’t actually block anything permanently.

4. Check for Unauthorized User Accounts

List all accounts with login shells:

grep -v '/sbin/nologin|/bin/false' /etc/passwd

Any account you don’t recognise needs to be investigated immediately. Also check for accounts with empty passwords:

awk -F: '($2 == "") {print $1}' /etc/shadow

For cPanel servers, audit hosting accounts in WHM under Home > Account Information > List Accounts. Remove any accounts that are no longer needed.

5. Audit File Permissions and SUID Binaries

World-writable files are a common vector for privilege escalation. Find them with:

find / -xdev -type f -perm -0002 -not -path "/proc/*" 2>/dev/null

Find SUID binaries (files that run with elevated privileges):

find / -xdev -perm /4000 -type f 2>/dev/null

Compare the SUID list against a known-good baseline. Common legitimate SUID binaries include /usr/bin/passwd, /usr/bin/sudo, and /usr/bin/pkexec. Anything unexpected deserves a close look.

⚠ Warning: Don’t blindly remove SUID bits from binaries you don’t recognise — some are legitimately required by the OS. Google the binary first.

6. Review Running Processes and Listening Services

See everything listening on a network port:

ss -tlnp

Review every line. If something is listening that you didn’t expect — especially on a public interface (0.0.0.0 or ::) — find out what it is before continuing.

Check for processes running as root that shouldn’t be:

ps aux | grep root

7. Check Logs for Suspicious Activity

Failed SSH login attempts accumulate fast. See the worst offenders:

grep 'Failed password' /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -nr | head -20

On Ubuntu, the log is at /var/log/auth.log instead of /var/log/secure.

For web server logs, scan for common attack patterns like ../ traversal attempts or wp-login.php hammering. On managed WordPress hosting, this is something Host & Tech handles at the infrastructure level, but if you’re self-managing, check Apache logs at /var/log/httpd/access_log or /var/log/apache2/access.log.

8. Verify SSL/TLS Certificates

Expired certificates cause trust warnings that users see as security issues even when the server itself is fine. Check expiry dates with:

echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

In cPanel, go to Home > SSL/TLS > Manage SSL Hosts to see all installed certificates and their expiry dates in one view.

9. Test Your Backup and Recovery Process

A backup you’ve never tested is just data you haven’t verified is corrupt yet. Restore a single file or database to a test location and confirm the content is intact. This step gets skipped constantly and it’s the one that matters most when something goes wrong.

10. Run a Malware Scan

On Linux servers, maldet (Linux Malware Detect) combined with ClamAV gives solid coverage:

maldet --scan-all /home
clamscan -r /home --infected --remove=no --log=/var/log/clamscan.log

Use --remove=no on your first scan to review what it finds before deleting anything. False positives happen, particularly in WordPress plugin directories.

Common Issues and Troubleshooting

SSH Login Succeeds But Immediately Disconnects

Usually caused by incorrect permissions on ~/.ssh/authorized_keys or the ~/.ssh directory itself. The SSH daemon is strict about this. Fix it with:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R youruser:youruser ~/.ssh

CSF Blocking Legitimate Traffic

If CSF has blocked an IP that shouldn’t be blocked, the logs are at /var/log/lfd.log. To temporarily unblock an IP:

csf -dr 203.0.113.45

To permanently whitelist it, add the IP to /etc/csf/csf.allow and restart CSF with csf -r.

Maldet Reports Thousands of Infected Files After a WordPress Hack

This is annoyingly common, and the official maldet docs aren’t great on recovery. Don’t just delete everything maldet flags — some of it may be false positives in cached or minified JS files. Instead, isolate the account, restore from a known-good backup if you have one, and then rerun the scan to confirm clean. Patching over an active infection rarely works.

nft or iptables Rules Not Persisting After Reboot

On AlmaLinux 9, rules written directly with nft commands don’t persist by default. Save them to the config file:

nft list ruleset > /etc/nftables.conf
systemctl enable nftables

find Command Takes Forever or Hangs During Permission Audit

Without the -xdev flag, find will cross into mounted filesystems including /proc and /sys, which can hang indefinitely. Always include -xdev in recursive find commands on live servers.

FAQ