Ransomware operators follow a predictable playbook: compromise credentials, move laterally, escalate privileges, disable backups, then encrypt. The window between initial access and encryption is where you win or lose. Most defenses fail because they focus on detection instead of making the attacker's job impossible.
I've restored dozens of encrypted servers. The ones that survived had layered controls that forced attackers to give up or make enough noise to get caught. Here are nine configuration changes that actually stop ransomware.
1. Immutable backup snapshots
Ransomware hunts for backups first. If your backup system allows delete or overwrite operations from the production server, you're already compromised the moment an attacker gains access.
Switch to append-only or immutable backup storage. Most modern backup tools support retention locks that prevent deletion for a fixed period. On Linux systems with rsync-based backups, store snapshots on a separate machine with SSH keys that only allow write operations:
# On backup server: create restricted SSH key
command="rsync --server --daemon ." ssh-rsa AAAAB3... backup@prod
Configure your rsyncd to reject delete operations entirely. Better yet, use a cloud storage bucket with object lock enabled or a dedicated backup appliance that rejects API calls to delete recent snapshots.
Test your backups monthly. An untested backup is just a guess.
2. SSH key authentication only
Password authentication is how most server compromises start. Brute force attacks run 24/7 against every exposed SSH port. A twelve-character password falls in hours with a decent GPU cluster.
Disable password auth completely:
# /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
Restart SSH and verify you can still log in with your key before closing the session. If you lock yourself out, most hosting providers offer console access through their control panel.
For teams, deploy a bastion host with centralized key management instead of scattering keys across every server. One compromised laptop shouldn't mean rotating fifty keys.
3. Principle of least privilege for service accounts
Web applications don't need root. Database users don't need file system access. Mail services don't need write access to your website directory.
Audit every service account:
# List users with login shells
grep -v '/nologin\|/false' /etc/passwd
# Check what groups each service runs under
ps aux | grep -E 'apache|nginx|mysql|postfix'
Create dedicated users for each service with minimal permissions. Your web server user should own nothing except cache and upload directories. Application code should be owned by a separate deployment user.
I've seen ransomware encrypt entire web hosting platforms because the PHP process ran as root. Don't do that.
4. Network segmentation with firewall rules
Your web server doesn't need to talk to your backup server. Your database server doesn't need outbound internet access. Flat networks let ransomware spread instantly.
Block everything by default, then whitelist specific flows:
# iptables example: web server can only reach DB on port 3306
iptables -A OUTPUT -p tcp -d 10.0.2.10 --dport 3306 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -j DROP
For multi-server setups, use VLANs or VPC subnets to isolate tiers. Your DMZ web servers should never directly access internal databases—proxy through an application server in a middle tier.
Monitor for unusual connection patterns. A web server suddenly connecting to SMB ports is a red flag.
5. File integrity monitoring on critical paths
Ransomware has to modify files to encrypt them. Catch it before it spreads.
Deploy a file integrity monitor like AIDE or Tripwire on directories that should never change:
# Initialize AIDE database
aide --init
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
# Daily check via cron
0 2 * * * /usr/bin/aide --check | mail -s "AIDE Report" [email protected]
Watch system binaries, kernel modules, SSH config, cron jobs, and application code directories. Ignore log files and cache directories—they'll trigger false positives constantly.
When AIDE alerts you to unexpected changes, investigate immediately. It's either a legitimate update you forgot to record or an intrusion.
6. Read-only root filesystem for static servers
If the server's job doesn't require writing to disk, make the whole filesystem read-only. Ransomware can't encrypt what it can't write.
Mount the root partition with the ro flag:
# /etc/fstab
/dev/sda1 / ext4 ro,errors=remount-ro 0 1
Move logs and temporary files to a separate writable partition or tmpfs. Containerized applications make this easier—run your app container with a read-only root filesystem and mount only specific volumes as writable.
Obviously this doesn't work for databases or file upload services, but static web servers and reverse proxies can run read-only without issue.
7. Automated permission audits
World-writable files and directories are ransomware highways. So are SUID binaries you didn't know existed.
Scan weekly:
# Find world-writable files (excluding /tmp, /proc, /sys)
find / -path /tmp -prune -o -path /proc -prune -o -path /sys -prune -o -type f -perm -002 -ls
# Find SUID/SGID binaries
find / -type f \( -perm -4000 -o -perm -2000 \) -ls
Document the legitimate results, then alert on any additions. A newly appeared SUID binary is either a package update or a privilege escalation tool.
Check web directories specifically. A writable uploads folder is expected. A writable configuration directory is a vulnerability.
8. Outbound connection filtering
Ransomware needs to phone home—either to download the encryption payload or to transmit the decryption key. Cut that communication and you break the attack chain.
Block outbound connections except to required destinations:
# Allow only package repos and specific APIs
iptables -A OUTPUT -d apt.repository.com -j ACCEPT
iptables -A OUTPUT -d api.yourservice.com -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j DROP
iptables -A OUTPUT -p tcp --dport 443 -j DROP
For servers that need broad internet access, run an HTTP proxy and inspect traffic. Unusual domains or direct IP connections in TLS are suspicious.
Many hosting providers offer managed firewall rules at the hypervisor level. Use them—they're harder to disable from a compromised guest.
9. Snapshot automation with off-server retention
Even with immutable backups, you need point-in-time recovery that happens faster than ransomware spreads. Filesystem snapshots give you that.
On Linux with LVM, take snapshots every few hours:
# Create snapshot (requires free space in VG)
lvcreate -L 5G -s -n snap_$(date +%Y%m%d_%H%M) /dev/vg0/root
# List snapshots
lvs | grep snap_
ZFS snapshots are even better—they're nearly instant and copy-on-write:
zfs snapshot tank/data@$(date +%Y%m%d_%H%M)
zfs list -t snapshot
Store at least one snapshot off-server daily. Replicate to a second machine or cloud storage that the production server can't delete from. Ransomware that encrypts the live filesystem can't touch yesterday's snapshot sitting on a different host.
Automate this. Manual snapshots don't happen during an incident.
So what ties these defenses together?
Each control blocks a specific stage of the attack. SSH keys stop initial access. Network segmentation stops lateral movement. Permission limits stop privilege escalation. Immutable backups stop the final leverage.
Ransomware operators need all stages to succeed. You only need to block one.
The servers I've seen walk away unscathed had at least five of these nine in place. The ones that paid ransoms had maybe two. Layer your defenses and test them quarterly—run a tabletop exercise where you assume one control failed and see if the others hold.
Monitor your logs, but don't rely on detection alone. Configuration beats vigilance every time.
FAQ
How often should I test backup restores?
Monthly for critical systems, quarterly minimum for everything else. A five-minute restore test now saves you hours during an actual incident.
Can ransomware spread through snapshots?
Only if the snapshot is writable from the compromised system. Use read-only mounts or off-server replication to protect snapshot storage itself.
Do I need all nine defenses?
No, but each one you skip is a stage the attacker doesn't have to work for. Start with SSH keys, immutable backups, and network segmentation—those three cover the most common attack paths.
What about endpoint protection and antivirus?
Useful as an additional layer but not sufficient alone. Modern ransomware evades signature detection easily. These configuration controls make the server hostile to encryption attempts regardless of detection.
Start with access and backups
If you implement two defenses this week, make them SSH key authentication and immutable backups. Those two stop the most common entry and exit points.
Then add network segmentation to contain any breach that does occur. After that, permission audits and file integrity monitoring catch the attacker while they're still preparing to encrypt.
The rest of the controls reinforce those core defenses. Pick the ones that fit your infrastructure and build from there. A partially hardened server is infinitely better than one that trusts everything.