Most server breaches don't start with a Hollywood-style hack. They start with a misconfigured permission, an unpatched service, or logs that nobody checked. The three pillars that actually stop breaches at the infrastructure level are audit trails that show you what happened, encryption at rest so stolen disks are useless, and least-privilege access that limits blast radius when credentials leak.
I've cleaned up after enough incidents to know that prevention is cheaper than forensics. Let's walk through each layer.
Why audit trails matter more than you think
Audit logs are your time machine. When something goes wrong, they tell you who did what and when. Without them, you're guessing.
Linux systems ship with auditd, but most people never turn it on. Start by installing the audit daemon if it's missing:
sudo apt install auditd audispd-plugins # Debian/Ubuntu
sudo yum install audit audit-libs # RHEL/CentOS
Once installed, configure rules in /etc/audit/rules.d/audit.rules. Track file access on sensitive directories, privilege escalations, and network connections. Here's a starter set:
# Watch shadow file for password changes
-w /etc/shadow -p wa -k password_changes
# Track sudo usage
-w /var/log/sudo.log -p wa -k sudo_activity
# Monitor SSH config changes
-w /etc/ssh/sshd_config -p wa -k sshd_config
# Log all executions from temp directories
-w /tmp -p x -k tmp_execution
-w /var/tmp -p x -k tmp_execution
# Catch privilege escalation attempts
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid!=0 -k privilege_escalation
Restart the service and verify rules loaded:
sudo systemctl restart auditd
sudo auditctl -l
Audit logs pile up fast. Rotate them and ship them off-server. If an attacker gets root, the first thing they'll do is wipe logs. Store a copy somewhere they can't reach—a central syslog server, S3 bucket, or SIEM.
For cPanel servers, check /usr/local/cpanel/logs/access_log and /usr/local/cpanel/logs/error_log regularly. Failed login attempts, plugin installs, and DNS zone changes all leave traces there. Set up log forwarding in WHM under "Configure cPHulk Brute Force Protection" and "Manage Wheel Group Users" to track administrative actions.
Encryption at rest: protect data on disk
If someone walks out with your hard drive or snapshot, encryption at rest makes that theft pointless. They've got a brick, not your customer database.
Full-disk encryption with LUKS is the standard on Linux. If you're provisioning a new server, encrypt during install. For existing systems, encrypting the root partition requires downtime and a rebuild, but data partitions can be encrypted in place.
Here's how to encrypt a separate data volume:
# Install cryptsetup
sudo apt install cryptsetup
# BACKUP YOUR DATA FIRST
# This will destroy everything on the device
sudo cryptsetup luksFormat /dev/sdb1
# You'll set a passphrase here
sudo cryptsetup luksOpen /dev/sdb1 encrypted_data
sudo mkfs.ext4 /dev/mapper/encrypted_data
sudo mount /dev/mapper/encrypted_data /mnt/secure
The passphrase problem is real. You can't type it in every time the server reboots. Store the key in a file on the root volume (which should also be encrypted), or use a hardware security module if you're in a compliance environment. For automated unlocking:
# Generate a key file
sudo dd if=/dev/urandom of=/root/luks-key bs=512 count=1
sudo chmod 600 /root/luks-key
# Add the key to the LUKS volume
sudo cryptsetup luksAddKey /dev/sdb1 /root/luks-key
# Add to /etc/crypttab for automatic unlock
encrypted_data /dev/sdb1 /root/luks-key luks
Database files, backups, and any PII should live on encrypted volumes. MySQL and PostgreSQL both support table-level encryption, but filesystem encryption is simpler and catches everything—logs, temp files, core dumps.
For cloud VMs, use the provider's encryption features. AWS EBS encryption, Google Cloud persistent disk encryption, and Azure disk encryption all use AES-256 and integrate with key management services. Turn them on. There's usually no performance hit.
Least-privilege access: assume breach, limit damage
Principle of least privilege means giving each user, process, and service the minimum permissions needed to do its job. Nothing more.
Start with your user accounts. Run cat /etc/passwd and look for UIDs below 1000 that aren't system accounts. Check /etc/sudoers and /etc/sudoers.d/ for overly broad sudo rules. If you see ALL=(ALL) NOPASSWD: ALL, that's a problem.
Create role-based groups instead:
sudo groupadd webadmin
sudo groupadd dbadmin
# Give webadmin limited sudo for Apache/Nginx
echo "%webadmin ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart apache2, /usr/bin/systemctl restart nginx" | sudo tee /etc/sudoers.d/webadmin
# Give dbadmin limited sudo for MySQL
echo "%dbadmin ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart mysql" | sudo tee /etc/sudoers.d/dbadmin
Service accounts need the same treatment. Your web server doesn't need to write to /etc. Your backup script doesn't need a login shell. Check what's running as root with ps aux | grep ^root and ask why.
For SSH access, disable root login entirely. Edit /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Force key-based auth and require a regular user account with sudo. Two-factor authentication adds another gate—Google Authenticator PAM module works well:
sudo apt install libpam-google-authenticator
# As each user:
google-authenticator
# Edit /etc/pam.d/sshd, add:
auth required pam_google_authenticator.so
# Edit /etc/ssh/sshd_config:
ChallengeResponseAuthentication yes
sudo systemctl restart sshd
On cPanel servers, use "Manage Wheel Group Users" in WHM to control who gets root. Resellers and end users shouldn't be in wheel. API tokens should have scoped permissions—full WHM API access is rarely necessary. Check "Manage API Tokens" and revoke anything with broader scope than required.
File integrity monitoring catches tampering
Audit logs show actions. File integrity monitoring shows results. If an attacker modifies a binary or config file, you'll know.
AIDE (Advanced Intrusion Detection Environment) is the go-to tool. Install and initialize a baseline:
sudo apt install aide
sudo aideinit
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
Run checks daily via cron:
0 3 * * * /usr/bin/aide --check | mail -s "AIDE Report" [email protected]
Customize /etc/aide/aide.conf to ignore log directories and other high-churn paths. Focus on /bin, /sbin, /usr/bin, /etc, and web roots.
For web applications, monitor file hashes in your document root. A changed index.php or new .php file in /tmp is a red flag. Tools like inotifywait can alert in real time:
sudo apt install inotify-tools
inotifywait -m -r -e modify,create,delete /var/www/html/ | while read path action file; do
echo "$(date): $action on $path$file" >> /var/log/webroot-changes.log
done
Run that in a systemd service so it survives reboots.
Network segmentation and firewall rules
Your database server doesn't need to talk to the internet. Your web server doesn't need to SSH to your backup host. Network segmentation limits lateral movement.
Use iptables or firewalld to enforce this. Drop everything by default, then allow only what's required:
# Default deny
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT
# Allow established connections
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow SSH from specific IP
sudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 22 -j ACCEPT
# Allow HTTP/HTTPS from anywhere
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Allow MySQL only from app server
sudo iptables -A INPUT -p tcp -s 192.168.1.10 --dport 3306 -j ACCEPT
# Save rules
sudo netfilter-persistent save
If you're running containers, isolate them with separate networks and avoid --net=host. For VMs, put different tiers in different subnets and use security groups or NACLs to enforce boundaries.
Patching and vulnerability management
Unpatched software is the easiest entry point. Enable automatic security updates and monitor them.
On Debian/Ubuntu:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
On RHEL/CentOS, yum-cron does the job:
sudo yum install yum-cron
sudo systemctl enable yum-cron
sudo systemctl start yum-cron
Edit /etc/yum/yum-cron.conf and set apply_updates = yes for security patches.
Track CVEs for your stack. If you're running Nginx, Apache, PHP, or MySQL, subscribe to their security mailing lists. When a high-severity CVE drops, patch immediately. Don't wait for the monthly maintenance window.
Use vulnerability scanners like Lynis to audit your configuration:
sudo apt install lynis
sudo lynis audit system
It checks kernel settings, file permissions, installed packages, and service configs. Fix the warnings it flags.
Backup and disaster recovery
Backups are your last line of defense. If everything else fails, you can restore.
Store backups off-server and encrypt them. A backup on the same disk as your production data isn't a backup. Use rsync over SSH to a remote host, or tools like restic for encrypted cloud backups:
sudo apt install restic
restic -r sftp:backup-server:/backups/myserver init
restic -r sftp:backup-server:/backups/myserver backup /var/www /etc /home
Test restores quarterly. I've seen too many cases where backups ran for months but the retention policy deleted the good copies or the encryption key was lost.
For databases, dump and encrypt before transferring:
mysqldump --all-databases | gzip | openssl enc -aes-256-cbc -salt -out backup.sql.gz.enc -pass file:/root/backup-password.txt
Rotate the encryption password annually and store it in a password manager or HSM, not in a plaintext file on the server.
So what about third-party software and plugins?
WordPress plugins, cPanel plugins, and custom scripts are frequent breach vectors. Audit them.
For WordPress, remove unused plugins entirely. Keep the rest updated. Tools like WPScan can find known vulnerabilities:
wpscan --url https://example.com --api-token YOUR_TOKEN
For cPanel, check installed plugins under "Manage Plugins" in WHM. If you don't recognize it or didn't install it, investigate. Same goes for custom scripts in cron or systemd timers—review them periodically.
Vendor software should come from official repos, not random GitHub releases or forums. Verify GPG signatures on packages when available.
Start with one layer, then stack them
You don't need to implement everything at once. Pick one—audit trails, encryption, or least privilege—and get it right. Then add the next layer.
I usually start with audit logs because they're non-disruptive and give visibility immediately. Encryption comes next if compliance or data sensitivity demands it. Least privilege is ongoing work, but the biggest wins come from disabling root SSH and scoping sudo rules.
Breaches happen. The goal isn't perfect security. It's raising the cost and effort high enough that attackers move to an easier target, and having enough logging and backups that you can recover when they don't.