Ransomware on Linux — No Longer a Rare Occurrence
After auditing security on 10+ servers, I kept seeing the same pattern repeat itself: SSH using weak passwords, cron jobs running scripts from unknown sources, no solid backup plan. When ransomware actually hit, the DevOps team had nothing to fall back on — just blank stares at each other.
A lot of people still assume Linux is less vulnerable to ransomware than Windows. True — it gets hit less often. But that doesn’t mean it’s immune. REvil, Cl0p, and LockBit all have variants that specifically target Linux servers. The question isn’t “will we get attacked?” — it’s “when we do, what has our team prepared?”
Comparing Defense Approaches
Approach 1: Reactive — Responding After the Attack
This is the most common approach I encounter. Files get encrypted, then everyone scrambles for a solution — contacting vendors, debating whether to pay the ransom. According to IBM’s Cost of a Data Breach Report, recovery from a ransomware incident takes an average of 21 days — not counting ransom payments ranging from $200K to several million dollars depending on the scale. If your team is in this camp, change course now.
Approach 2: Backup-Only — Relying Solely on Backups
Backups are necessary, but not sufficient on their own. Without detection, you have no idea when ransomware started encrypting your files. I’ve seen a case where a team mounted a NAS directly to an infected server — all 3 TB on the NAS got encrypted too, leaving nothing to restore from. And even with a clean backup, restoring without patching the entry point means getting hit again a few days later.
Approach 3: Defense-in-Depth — Multiple Layers of Protection
This combines system hardening + real-time monitoring + offline backups + a response plan. Initial setup takes a few sessions — but when an incident occurs, recovery time drops from weeks to hours. This is the approach I recommend for any server exposed to the internet.
Pros and Cons of Each Approach
- Reactive: No setup required — but downtime is measured in weeks, data may be permanently lost, and paying the ransom doesn’t guarantee you’ll get the decryption key.
- Backup-only: Simple and easy to deploy — but online-mounted backups can get encrypted alongside your data, and there’s no early warning system.
- Defense-in-depth: Early detection, reduced damage, faster recovery — requires a few sessions of initial setup. Costs the most in time upfront, cheapest in consequences.
Choosing the Right Approach for Your Situation
For a personal VPS or staging server with little critical data, a 3-2-1 backup strategy combined with basic monitoring is enough. For production servers holding customer databases, user files, or proprietary code — you need all three layers, no compromises.
Implementation priority order: offline backup first (your lifeline), then hardening, then detection. You don’t have to do everything at once — one step per week is enough to meaningfully reduce your risk.
Implementation Guide: 3 Layers of Protection
Layer 1: Hardening — Reducing the Attack Surface from the Start
Ransomware typically gets in through three vectors: SSH brute force, unpatched web vulnerabilities, and malicious scripts in cron jobs. Blocking entry points upfront is the most effective step you can take.
Disable password-based SSH, use keys only:
# Edit sshd_config
sudo nano /etc/ssh/sshd_config
# Change the following lines:
PasswordAuthentication no
PermitRootLogin no
Port 2222
sudo systemctl restart sshdInstall fail2ban to block brute force attacks:
sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# Add to jail.local:
[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 86400
findtime = 600
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshdMount /tmp and /var/tmp with noexec — prevents malware from executing out of temp directories:
# Add to /etc/fstab
tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev 0 0
tmpfs /var/tmp tmpfs defaults,noexec,nosuid,nodev 0 0
# Apply immediately without rebooting
sudo mount -o remount,noexec,nosuid /tmp
sudo mount -o remount,noexec,nosuid /var/tmpLayer 2: Detection — Catching It Early Before Damage Spreads
Ransomware actually leaves fairly obvious traces: masses of files renamed with suspicious extensions (.encrypted, .locked), sudden CPU spikes, disk I/O surging at 3 AM. Catching these signals in time lets you cut off the damage before it spreads across the entire system.
Script to detect abnormal file extensions:
#!/bin/bash
# /usr/local/bin/ransomware-detector.sh
WATCH_DIRS="/var/www /home /etc"
SUSPICIOUS_EXT="\.encrypted$|\.locked$|\.crypt$|\.enc$|\.WNCRY$"
THRESHOLD=10
ALERT_EMAIL="[email protected]"
for dir in $WATCH_DIRS; do
count=$(find "$dir" -newer /tmp/.ransomware_check -type f 2>/dev/null \
| grep -E "$SUSPICIOUS_EXT" | wc -l)
if [ "$count" -gt "$THRESHOLD" ]; then
msg="ALERT: $count encrypted files found in $dir at $(date)"
echo "$msg" | mail -s "RANSOMWARE ALERT: $(hostname)" "$ALERT_EMAIL"
logger -t ransomware-detector "$msg"
# Optional: isolate network immediately
# iptables -I INPUT -j DROP && iptables -I OUTPUT -j DROP
fi
done
touch /tmp/.ransomware_check# Run every 5 minutes
chmod +x /usr/local/bin/ransomware-detector.sh
echo "*/5 * * * * root /usr/local/bin/ransomware-detector.sh" \
| sudo tee /etc/cron.d/ransomware-monitorUse auditd to monitor changes in critical directories:
sudo apt install auditd -y
sudo systemctl enable --now auditd
# Watch web and home directories
sudo auditctl -w /var/www -p wa -k ransomware_watch
sudo auditctl -w /home -p wa -k ransomware_watch
# View logs in real time
sudo ausearch -k ransomware_watch --start recent | tail -30Layer 3: Offline Backup — Your Lifeline When Everything Else Fails
The golden rule: backups must be offline or immutable. Mounting a backup to an infected server means the backup gets encrypted too — the NAS case mentioned earlier is the textbook example. That’s a lesson you don’t want to pay for twice.
BorgBackup — encrypted, deduplicated, and the most efficient option:
sudo apt install borgbackup -y
# Initialize a repo on a separate backup server
borg init --encryption=repokey \
backup-user@backup-server:/backups/$(hostname)
# Daily backup script
borg create --stats --compression lz4 \
backup-user@backup-server:/backups/$(hostname)::backup-{now:%Y%m%d_%H%M} \
/var/www /home /etc /var/lib/mysql
# Keep 7 daily, 4 weekly, 6 monthly snapshots
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 \
backup-user@backup-server:/backups/$(hostname)
# List available backups
borg list backup-user@backup-server:/backups/$(hostname)# Restore a specific file from a snapshot
borg extract \
backup-user@backup-server:/backups/$(hostname)::backup-20250601_030000 \
var/www/html/wp-config.php# Add to crontab — runs at 3 AM every day
echo "0 3 * * * root /usr/local/bin/borg-backup.sh >> /var/log/borg-backup.log 2>&1" \
| sudo tee /etc/cron.d/borg-backupResponse Plan — When You’ve Already Been Hit
No matter how solid your defenses are, you still need an incident response playbook. The first 15 minutes determine the blast radius — handle it right and you can contain the damage to a couple of servers; handle it wrong and your entire infrastructure goes down.
- Isolate immediately: Disconnect the server from the network. Don’t shut it down yet — a RAM dump may be needed for forensics.
- Assess the scope: Which files are encrypted? When did it start? Where did the attacker get in?
- Don’t pay the ransom: There’s no guarantee you’ll receive the decryption key. The FBI advises against paying — and according to Cybereason, 80% of victims who pay get attacked again within a year.
- Restore from the cleanest snapshot: Choose a backup from before the infection occurred.
- Patch the vulnerability before bringing the server back online: Find and fix the entry point. Skip this step and you’ll be hit again within days.
# Check recently modified files
find /var/www /home -newer /tmp/.last_check -type f \
| grep -v ".log$" | head -50
# Check for suspicious running processes
ps aux --sort=-%cpu | head -20
# Check for unusual network connections
ss -tunap | grep ESTABLISHED | grep -v "127.0.0.1\|::1"Wrapping Up
I’ve watched a team spend an entire week restoring after a ransomware attack simply because they had no backup plan. Another team resolved a nearly identical incident in 4 hours because they had BorgBackup snapshots ready to go. The difference wasn’t the tools or the budget — it was setting up the process ahead of time.
Three steps you can take today: disable password-based SSH, set up BorgBackup to a separate server, and add the detection script to cron. That’s it — enough to make sure you never have to stare at a screen full of .encrypted files.
