OverviewA 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.PrerequisitesRoot or sudo access to the server (or WHM Administrator access for cPanel environments)SSH client — PuTTY on Windows, Terminal on macOS/LinuxBasic 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 auditBackups confirmed working before you make any changesStep-by-Step Security Audit Checklist1. Confirm All Software Is Up to DateUnpatched 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:Copied to clipboarddnf update -y dnf upgrade -yOn Ubuntu 24.04:Copied to clipboardapt update apt upgrade -y apt autoremove -yIn WHM, navigate toHome cPanel Upgrade to Latest Versionand also runHome Server Configuration Update Preferencesto 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 ConfigurationSSH 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:Copied to clipboardnano /etc/ssh/sshd_configCheck or set these values:Copied to clipboardPort 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 usersAfter saving, restart SSH — but keep your current session open and test in a second terminal window before closing anything:Copied to clipboardsystemctl 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 RulesFor cPanel/WHM servers, CSF (ConfigServer Security Firewall) is the standard. If it’s not installed, install it:Copied to clipboardcd /usr/src wget https://download.configserver.com/csf.tgz tar -xzf csf.tgz cd csf sh install.shCheck your current open ports:Copied to clipboardcsf -l | grep ACCEPTOr on a non-cPanel server using nftables (the default in AlmaLinux 9 and Ubuntu 22.04):Copied to clipboardnft list rulesetThe 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’sTESTINGmode in/etc/csf/csf.confshould be set to0on 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 AccountsList all accounts with login shells:Copied to clipboardgrep -v /sbin/nologin|/bin/false /etc/passwdAny account you don’t recognise needs to be investigated immediately. Also check for accounts with empty passwords:Copied to clipboardawk -F: ($2 ) {print $1} /etc/shadowFor cPanel servers, audit hosting accounts in WHM underHome Account Information List Accounts. Remove any accounts that are no longer needed.5. Audit File Permissions and SUID BinariesWorld-writable files are a common vector for privilege escalation. Find them with:Copied to clipboardfind / -xdev -type f -perm -0002 -not -path /proc/* 2/dev/nullFind SUID binaries (files that run with elevated privileges):Copied to clipboardfind / -xdev -perm /4000 -type f 2/dev/nullCompare 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 ServicesSee everything listening on a network port:Copied to clipboardss -tlnpReview 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:Copied to clipboardps aux | grep root7. Check Logs for Suspicious ActivityFailed SSH login attempts accumulate fast. See the worst offenders:Copied to clipboardgrep Failed password /var/log/secure | awk {print $11} | sort | uniq -c | sort -nr | head -20On Ubuntu, the log is at/var/log/auth.loginstead of/var/log/secure.For web server logs, scan for common attack patterns like../traversal attempts orwp-login.phphammering. 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_logor/var/log/apache2/access.log.8. Verify SSL/TLS CertificatesExpired certificates cause trust warnings that users see as security issues even when the server itself is fine. Check expiry dates with:Copied to clipboardecho | openssl s_client -connect yourdomain.com:443 2/dev/null | openssl x509 -noout -datesIn cPanel, go toHome SSL/TLS Manage SSL Hoststo see all installed certificates and their expiry dates in one view.9. Test Your Backup and Recovery ProcessA 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 ScanOn Linux servers,maldet(Linux Malware Detect) combined with ClamAV gives solid coverage:Copied to clipboardmaldet --scan-all /home clamscan -r /home --infected --removeno --log/var/log/clamscan.logUse--removenoon your first scan to review what it finds before deleting anything. False positives happen, particularly in WordPress plugin directories.Common Issues and TroubleshootingSSH Login Succeeds But Immediately DisconnectsUsually caused by incorrect permissions on~/.ssh/authorized_keysor the~/.sshdirectory itself. The SSH daemon is strict about this. Fix it with:Copied to clipboardchmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chown -R youruser:youruser ~/.sshCSF Blocking Legitimate TrafficIf CSF has blocked an IP that shouldn’t be blocked, the logs are at/var/log/lfd.log. To temporarily unblock an IP:Copied to clipboardcsf -dr 203.0.113.45To permanently whitelist it, add the IP to/etc/csf/csf.allowand restart CSF withcsf -r.Maldet Reports Thousands of Infected Files After a WordPress HackThis 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 RebootOn AlmaLinux 9, rules written directly withnftcommands don’t persist by default. Save them to the config file:Copied to clipboardnft list ruleset /etc/nftables.conf systemctl enable nftablesfind Command Takes Forever or Hangs During Permission AuditWithout the-xdevflag,findwill cross into mounted filesystems including/procand/sys, which can hang indefinitely. Always include-xdevin recursivefindcommands on live servers.FAQFrequently Asked QuestionsHow often should I run a server security audit?At minimum, quarterly. After any security incident, major software update, or staff change, run it again immediately. Monthly is better if you’re handling sensitive customer data or running eCommerce. Audits that don’t happen on a schedule just don’t happen.Do I need root access to run a server security audit?For a full audit, yes — many of the checks require root or sudo. If you’re on shared hosting, your ability to audit is limited to your own files and account settings. VPS and dedicated server customers have full root access and can run every step in this checklist.Is ClamAV good enough for server malware scanning?ClamAV alone misses a lot of PHP webshells and fileless threats. Pair it with Linux Malware Detect (maldet), which is specifically tuned for shared hosting and web server environments. Running both together gives you much better coverage than either tool alone.Can I run this checklist on a cPanel shared hosting account?Partially. Steps like SSH hardening, firewall rule changes, and process auditing require server-level access you won’t have on shared hosting. You can still check file permissions, review your account’s error logs, and verify SSL certificates. For full control over server hardening, you’ll need a VPS or dedicated server.Whats the difference between a security audit and a penetration test?A security audit reviews your configuration, settings, and software against known best practices — it’s largely checklist-driven. A penetration test involves actively attempting to exploit vulnerabilities, often done by a specialist. Audits are something you can run internally on a regular basis; pen tests are typically scheduled annually or after major infrastructure changes.Related ArticlesHow to Secure Your Linux Server: A Practical Hardening Guide