The layer most ransomware prevention guides skip
Ransomware still gets in. Phishing works, credentials leak, and zero-days surface before vendors patch them. The question is what happens next—whether the attacker can encrypt your production data or pivot laterally into backups and billing systems. Server-level controls decide that outcome.
Most ransomware playbooks focus on endpoint detection or user training. Those matter. But once malware touches a server it has root or can escalate, the game is containment and blast-radius reduction. That means file integrity monitoring, process restrictions, segmented networks, and backups the attacker cannot reach. This checklist walks through seven server hardening steps that raise the cost of a successful ransomware campaign from nuisance to failed operation.
Each step is practical, testable, and fits standard hosting environments running cPanel, Plesk, or bare Linux VPS instances. No enterprise-grade SIEM required.
1. Immutable backups stored offline or in append-only mode
Your backups are the primary ransomware target after production data. Attackers hunt for mounted NFS shares, S3 buckets with overly broad credentials, and backup scripts that run under the same compromised account.
Store at least one copy offline or in a mode the server cannot delete. Object storage with retention locks works well—AWS S3 Object Lock, Backblaze B2 with retention policies, or Wasabi immutable buckets. Configure a retention window that matches your recovery-point-objective tolerance. Seven days is typical for small sites; mission-critical systems go longer.
If you use rsync to a remote server, run the destination in append-only or snapshot mode so the source cannot purge old data. ZFS snapshots with readonly=on serve this purpose on FreeBSD and Linux. The key property is write-once: the compromised host must not hold credentials that allow deletion.
Test restoration quarterly. I have seen too many support tickets where the backup worked but the restore workflow broke because dependencies changed or the destination path no longer existed.
Script the verification
Automate a monthly restore to a test instance and run smoke tests—database connectivity, file counts, configuration checksums. If restoration takes manual intervention, document every step in a runbook and keep a printed copy off-server.
2. File integrity monitoring on critical paths
Ransomware encrypts files in place or writes encrypted copies before deleting originals. Either pattern creates detectable mass file-modification events that rarely occur during normal operation.
Use inotify on Linux or AIDE (Advanced Intrusion Detection Environment) to monitor paths like /var/www, /home, /etc, and /usr/local. Configure alerts when more than a threshold number of files change within a short window—say, fifty files in five minutes outside maintenance windows.
Here is a minimal inotifywait loop that logs bulk changes:
inotifywait -m -r -e modify,delete,create /var/www /home --format '%T %w%f %e' --timefmt '%Y-%m-%d %H:%M:%S' | \
awk '{print} (NR % 50 == 0){system("logger -t ransomware-watch ALERT: 50 file events in short window")}'>
Pipe the output to syslog and forward to a separate log aggregator the attacker does not control. Local logs alone are useless if the attacker has root.
AIDE is more thorough. Install it, initialize the database, then schedule daily checks:
aide --init
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
aide --check | mail -s "AIDE daily report" [email protected]
AIDE compares checksums, permissions, and timestamps. A ransomware run shows up as thousands of modified files in the next report.
3. Application and user process sandboxing
Limit what each daemon and user can modify. If the web server account can write to the entire document root, a compromised PHP script can encrypt every site on the box.
Set ownership so web content is owned by a non-service account and the web server user has read-only access. Use group permissions when the application must write to specific directories like wp-content/uploads. For Apache, that looks like:
chown -R siteowner:www-data /var/www/example.com
find /var/www/example.com -type d -exec chmod 755 {} \;
find /var/www/example.com -type f -exec chmod 644 {} \;
chmod -R 775 /var/www/example.com/wp-content/uploads
For cPanel environments, ensure each account runs under its own UID and enable cageFS or CloudLinux if available. These jail users into their own filesystem view and prevent cross-account traversal.
Seccomp and AppArmor profiles add another layer. AppArmor can confine the MySQL daemon so it cannot write outside /var/lib/mysql and /tmp, blocking ransomware from encrypting arbitrary files even if it exploits the database process. Prebuilt profiles ship with Ubuntu and Debian; enable them:
aa-enforce /etc/apparmor.d/usr.sbin.mysqld
Check the status with aa-status.
4. Network segmentation and lateral-movement barriers
Ransomware spreads via SMB shares, SSH key reuse, and accessible admin panels. A flat network lets one compromised host reach everything else.
Segment your network so production web servers cannot directly access backup storage, management interfaces, or database clusters from other customers. Use VLANs if you control the switch, or configure host-based firewall rules with iptables or nftables.
A minimal deny-by-default rule set for a web server looks like this:
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.5 -j ACCEPT # management IP
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
Restrict outbound as well. A compromised web app should not initiate SSH or RDP to other hosts. Whitelist only the ports and destinations the application needs—DNS, NTP, package mirrors, external APIs.
Disable or firewall SMB ports (445, 139) on Linux servers entirely unless you run Samba for a specific reason. Same for RDP (3389). These protocols are ransomware highways.
5. Disable unnecessary services and remove unused software
Every installed package is potential attack surface. Many VPS templates ship with mail servers, FTP daemons, and database engines the site never uses.
Run systemctl list-unit-files --type=service and netstat -tuln to audit what is listening. Stop and mask anything not required:
systemctl stop exim4
systemctl mask exim4
Remove packages that provide no value:
apt remove --purge exim4-base exim4-daemon-light
apt autoremove
I have handled incidents where ransomware exploited an old Exim vulnerability on a server that never sent mail. The service was simply forgotten. Minimal installs mean fewer patch cycles and less to compromise.
So what if backups are safe but the database is gone?
Data integrity is half the problem; availability is the other half. Ransomware that encrypts your database can still halt operations even when backups exist, because restoration takes time—minutes to hours depending on size and automation maturity.
Snapshot production databases frequently and store the snapshots where the database host cannot modify them. For MySQL and MariaDB, use a dedicated replication slave configured for delayed replication (a few hours behind master) and snapshot that slave. The delay gives you a recovery window before encrypted data replicates downstream.
PostgreSQL users can leverage WAL archiving with archive_command sending segments to immutable storage:
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'
Mount /mnt/wal_archive from a network share the database user can write to but not delete from. Retention policies on the storage side enforce immutability.
6. Mandatory access controls and execution policies
Prevent execution from writable directories. Most web exploits drop a payload into /tmp, /dev/shm, or an uploads folder, then execute it.
Mount writable partitions with noexec:
# /etc/fstab
tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev 0 0
tmpfs /dev/shm tmpfs defaults,noexec,nosuid,nodev 0 0
Remount immediately:
mount -o remount /tmp
mount -o remount /dev/shm
For user upload directories, set noexec on the partition or use AppArmor to deny execution. If the application requires executing scripts from uploads (rare and dangerous), isolate that path in a separate mount with tight AppArmor confinement.
Linux Security Modules like SELinux add policy-based controls. SELinux in enforcing mode blocks many privilege-escalation techniques and confines daemons even after compromise. Red Hat and CentOS ship with SELinux enabled; Debian and Ubuntu default to AppArmor. Enable whichever your distribution provides and do not disable it for convenience.
Check the current mode:
getenforce # SELinux
aa-status # AppArmor
If set to permissive or disabled, switch to enforcing after verifying your applications work under confinement.
7. Logging, alerting, and off-host log storage
Local logs disappear when attackers gain root. Forward logs to a separate system they do not control—a dedicated log server, a managed SIEM, or even a secondary VPS in a different account.
Configure rsyslog or syslog-ng to send copies over TLS:
# /etc/rsyslog.d/remote.conf
*.* @@logs.example.com:6514
The @@ prefix uses TCP; add TLS configuration separately. Alternatively, use a lightweight agent like Promtail or Fluentd to ship to Loki or Elasticsearch.
Alert on:
- Sudden spikes in file-modification events
- Failed login attempts exceeding a threshold
- New processes launched by the web server user
- Changes to /etc/passwd, /etc/shadow, or SSH authorized_keys
- Outbound connections to unusual ports or IPs
Integrate alerts with email, Slack, or PagerDuty. During an incident, minutes matter. In support tickets I handled, teams that detected ransomware in the first ten minutes usually contained it; those that noticed hours later faced full encryption.
Keep audit logs intact
Enable auditd to track privileged operations:
apt install auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
auditctl -w /etc/shadow -p wa -k shadow_changes
auditctl -w /usr/bin/sudo -p x -k sudo_exec
Audit logs capture who did what, even after the attacker deletes shell history. Forward auditd logs off-host as well.
Start with backups and monitoring
If you implement two controls today, make them immutable backups and file integrity monitoring. Backups let you recover; monitoring tells you when to start that recovery before the attacker finishes. The other five steps reduce the blast radius and buy you time.
Ransomware is not going away. Defenses that worked in 2020 are table stakes now. The groups running these campaigns are persistent, well-funded, and patient. Server hardening does not make you invincible, but it changes the math—your infrastructure becomes more expensive to compromise than the next target, and attackers move on.
Test your restore process this week. Then work through the checklist one step at a time.