Ransomware operators go after servers because that's where the valuable data lives. A single compromised VPS or dedicated server can encrypt customer databases, application files, and every backup stored on the same disk. I've watched support tickets where an attacker pivoted from a WordPress site to the underlying server, encrypted /var/www and /home, then demanded payment in cryptocurrency. The damage isn't just downtime—it's lost trust, regulatory fines, and the question of whether to pay.
Prevention is cheaper than recovery. The seven defenses below assume your server is already running and you want to harden it against ransomware without rebuilding from scratch. Each layer addresses a different attack vector: access, lateral movement, backup integrity, and runtime detection. Stack them and you force an attacker to burn multiple zero-days to succeed.
Offline backups disconnected from the network
Ransomware can't encrypt what it can't reach. Offline backups mean storage that is physically or logically disconnected after the backup completes—an external USB drive you rotate offsite, a tape library, or an S3 bucket with API credentials removed from the server after the upload finishes.
Mount the backup destination only during the backup window, then unmount it. For example, if you back up to an NFS share at 2 AM:
mount -t nfs 10.0.1.50:/backups /mnt/backup
rsync -a /var/www/ /mnt/backup/www/
umount /mnt/backup
The NFS export itself should deny writes except from the backup user, and that user's SSH key should be passphrase-protected or stored in a hardware token. If the server is compromised during business hours, the attacker has no mount point and no credentials to reach the backup.
Tape is still relevant for air-gapped environments. Write the backup to LTO-8 or LTO-9 tape, eject it, and store it in a locked cabinet. Tape can't be encrypted over the network because it isn't on the network. The downside is slower restore times, so keep a recent online copy for quick recovery and rely on tape for worst-case scenarios.
Snapshot rotation with separate retention policies
Filesystem snapshots give you point-in-time recovery, but only if you keep enough of them and rotate them independently of the live filesystem. ZFS and Btrfs snapshots are lightweight and fast. LVM snapshots work but consume space quickly if you write heavily to the origin volume.
Create hourly snapshots for the last 24 hours, daily snapshots for the last week, and weekly snapshots for the last month. When ransomware encrypts your data, you roll back to the most recent clean snapshot—usually minutes or hours old, not days.
# ZFS example
zfs snapshot tank/www@$(date +%Y%m%d-%H%M)
zfs list -t snapshot -o name,creation -S creation | head -n 25
Store snapshots on a separate pool or send them to a remote ZFS server via zfs send over SSH. If the attacker gains root and tries to destroy snapshots, the remote server's firewall blocks inbound SSH and only accepts snapshots pushed from your origin server. The attacker can delete local snapshots but not the remote copies.
Rotate snapshots automatically with a cron job and keep the script read-only. Set immutable flags on the snapshot directory so even root needs an extra step to delete them:
chattr +i /tank/snapshots
That won't stop a determined attacker with root, but it blocks automated ransomware scripts that blindly rm -rf everything.
Immutable storage buckets for backup archives
Object storage providers offer immutability features that prevent any user—including your own API credentials—from deleting or modifying objects for a defined retention period. AWS S3 Object Lock, Backblaze B2 with retention policies, and Wasabi immutability all implement WORM (write once, read many) semantics.
Configure your backup script to upload daily archives to an S3 bucket with Object Lock in compliance mode and a 30-day retention. Even if an attacker steals your AWS access keys, they cannot delete or overwrite those archives until the retention window expires.
aws s3 cp /backups/daily.tar.gz.gpg s3://my-immutable-bucket/backups/ \
--storage-class STANDARD_IA
Set the bucket policy to deny s3:DeleteObject for everyone except a break-glass IAM role that requires MFA. Your daily backup user has s3:PutObject only. This separation means ransomware that compromises your server can write new (potentially malicious) backups but cannot erase the good ones.
Test your restores monthly. Immutable storage is useless if you discover during an incident that you encrypted the backups with a key stored on the same server the attacker just wiped.
Least-privilege access and credential hygiene
Every service and user should run with the minimum permissions needed to do its job. If your web application doesn't need to write to /etc, the application user shouldn't own /etc. If your database doesn't need to execute shell commands, remove the SYSTEM privilege in MySQL or COPY PROGRAM in PostgreSQL.
Disable root SSH login. Use sudo with per-user audit logs:
Defaults logfile=/var/log/sudo.log
Defaults log_input, log_output
Rotate SSH keys every 90 days and store private keys in a password manager or HSM, not in ~/.ssh on a jump host that ten people share. For service accounts (backup scripts, monitoring agents), use short-lived credentials or IAM roles that expire after the task completes.
Check for stale accounts monthly:
lastlog | awk '$2 == "Never" {print $1}'
Lock or delete any account that hasn't logged in for six months. Attackers love dormant accounts because nobody notices when they're abused.
Audit sudoers files and check for overly broad rules like appuser ALL=(ALL) NOPASSWD: ALL. If the application user can sudo to root without a password, a code execution vulnerability in your app becomes instant root access. Drop the NOPASSWD and scope the command whitelist:
appuser ALL=(root) /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp
Now the app can restart itself but can't install packages or modify system files.
Endpoint detection and response for Linux servers
EDR tools monitor process behavior, file access, and network connections in real time and kill or quarantine processes that match ransomware patterns. They're not signature-based antivirus; they watch for anomalies like a PHP process spawning openssl to encrypt files or a cron job suddenly writing to thousands of files per second.
Open-source options include Wazuh and OSSEC. Commercial EDR for Linux includes CrowdStrike Falcon, SentinelOne, and Microsoft Defender for Endpoint. I've seen Wazuh catch a cryptominer within seconds by flagging unexpected outbound connections to a mining pool.
Install the agent and configure it to alert on:
- File integrity changes in
/etc,/usr/bin,/var/www - Processes writing to more than 100 files per minute
- New reverse shells or unusual parent-child process trees
- Unauthorized modifications to systemd units or cron jobs
Route alerts to a separate logging server the application server cannot reach. If ransomware compromises the server, it can't silence the EDR agent's alerts because those alerts live elsewhere.
EDR response actions range from alerting a human to auto-killing the process. Start with alerts and tune the rules for a month before enabling auto-kill, or you'll block legitimate batch jobs that happen to look suspicious.
Network segmentation and firewall rules
Ransomware spreads by pivoting from one compromised host to another over SMB, SSH, RDP, or database ports. Segment your network so a compromised web server cannot reach your database server's management interface or your backup server's SSH port.
Use VLANs, security groups, or iptables to enforce segmentation. For example, your web tier should only talk to your database tier on port 3306 and should never initiate SSH to anything:
iptables -A OUTPUT -p tcp --dport 22 -j DROP
iptables -A OUTPUT -p tcp --dport 3306 -d 10.0.2.10 -j ACCEPT
iptables -A OUTPUT -p tcp -j DROP
Drop by default and allow by exception. If you run Cloudflare or another CDN, restrict inbound HTTP/HTTPS to Cloudflare IP ranges only:
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
iptables -A INPUT -p tcp --dport 443 -s $ip -j ACCEPT
done
iptables -A INPUT -p tcp --dport 443 -j DROP
Now attackers scanning your origin IP directly can't reach your web server.
Internal zones matter too. Backup servers should accept connections only from defined source IPs. Database servers should never reach the public internet. A compromised database shouldn't be able to exfiltrate data or download ransomware payloads.
Micro-segmentation is even tighter: every container or VM gets its own firewall policy, and lateral movement becomes nearly impossible. Tools like Cilium for Kubernetes or AWS security groups for EC2 automate this.
Automated patch management and vulnerability scanning
Unpatched CVEs are ransomware's favorite entry point. Operators scan for known vulnerabilities in web apps, control panels, and system libraries, then exploit them before you apply the fix.
Automate security updates for your OS packages. On Debian and Ubuntu:
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
Configure it to install security updates daily and reboot if needed. For RHEL, CentOS, or Rocky Linux, enable dnf-automatic:
dnf install dnf-automatic
systemctl enable --now dnf-automatic-install.timer
Application patches are harder because they often require downtime. Use a staging environment to test updates, then push to production weekly. For WordPress, enable auto-updates for minor releases and security patches:
define('WP_AUTO_UPDATE_CORE', 'minor');
add_filter('auto_update_plugin', '__return_true');
Run a vulnerability scanner weekly. OpenVAS and Nessus both work. They'll catch outdated PHP versions, expired SSL certificates, and exposed services that shouldn't be public. Fix high-severity findings within 48 hours.
Subscribe to security mailing lists for software you run. If you manage cPanel servers, follow the cPanel security announce list. If you run Nextcloud, watch the Nextcloud security advisories. Waiting for your distro to package the patch can take days; sometimes you need to compile from source or apply a vendor hotfix immediately.
What about detection after the fact?
Prevention is the goal, but you need tripwires. Configure your EDR or SIEM to alert on file extension changes (.php becoming .php.locked), mass file modifications, and ransom notes (README.txt created in every directory). Set up disk usage alerts so you know immediately if free space drops by 20% in an hour—a sign that ransomware is writing encrypted copies before deleting the originals.
Keep application logs and system logs on a separate log server. Attackers wipe logs to cover their tracks. If your logs live on the same server, they're gone. If they're on a remote syslog server or a cloud logging service, you can reconstruct the attack timeline and identify the entry point.
Practice restoring from backup under time pressure. Ransomware recovery is a race. You need to know which backup is clean, how long the restore takes, and whether you can bring up a parallel environment while you clean the compromised one.
How often should I test my offline backups?
Monthly at minimum. Quarterly if you're constrained by time or resources. The test should include a full restore to a temporary environment, not just verifying that the backup file exists. I've seen backup scripts run for years writing zero-byte archives because nobody checked the output.
Can ransomware encrypt ZFS snapshots?
Local snapshots can be destroyed by an attacker with root access using zfs destroy. They cannot be modified, but deletion is enough. Send snapshots to a remote ZFS pool over SSH with a one-way trust relationship—the remote server never initiates connections back—and the attacker loses access to those snapshots unless they also compromise the remote server.
Does EDR slow down my server?
Modern EDR agents have low overhead, usually under 5% CPU and a few hundred MB of RAM. The bigger cost is alert fatigue if you don't tune the rules. Start with conservative policies and tighten them over time. A false positive that blocks a legitimate workload is worse than a missed detection, so tune carefully.
Should I pay the ransom if prevention fails?
No. Payment funds future attacks and there's no guarantee the attacker will provide a working decryption key. Law enforcement and security researchers have recovered keys for some ransomware families. Restore from your offline, immutable backups instead. That's why you built them.
Stack these layers and test them
No single defense stops every ransomware variant. Offline backups protect your data. Immutable storage prevents backup deletion. Least-privilege access limits blast radius. EDR detects active encryption. Segmentation contains lateral movement. Patching closes entry points. Snapshots give you point-in-time recovery.
An attacker who defeats one layer hits the next. Defense in depth works because each layer forces the attacker to spend more time and use more sophisticated techniques, increasing the chance you detect them before they finish encrypting your server. Test each layer quarterly and update your runbooks when you find gaps. The best ransomware defense is the one you built before you needed it.