Ransomware gangs don't just hit desktops anymore. They pivot through networks, encrypt database servers, and wipe backups stored on the same LUN. A single compromised WordPress plugin or exposed SSH port can hand them the keys to your entire stack.
No single tool stops every attack. What works is layered defense: making each stage of the kill chain harder until the economics tip against the attacker. Here are five layers that actually matter when you're running production infrastructure.
Layer 1: Immutable and Air-Gapped Backups
Your backups are the attacker's second target. They know recovery is your escape hatch.
Immutable storage means files cannot be altered or deleted for a retention period you set—often called object lock or compliance mode in S3-compatible systems. Even if an attacker steals your backup credentials, they can't touch data already written. Combine this with the 3-2-1 rule: three copies, two different media types, one off-site.
Air-gapped backups take it further by physically or logically disconnecting the backup system after each snapshot. Tape libraries with robotic arms that eject and store cartridges offline are the classic example. Cloud alternatives include write-once buckets that accept data over a unidirectional sync and never grant delete permissions to the source server.
What this looks like in practice
A production server pushes nightly snapshots to an S3 bucket with object lock enabled for 90 days. The IAM role attached to the server has s3:PutObject but no s3:DeleteObject or s3:DeleteObjectVersion. A separate recovery account holds the delete keys, protected by hardware MFA. Attackers who compromise the server can't poison old backups.
For physical systems I've seen a USB rotation scheme work: two drives, one plugged in for the Monday-Wednesday-Friday job, the other locked in a fireproof safe. The drive in the safe is always at least 48 hours behind, which gives you a clean restore point if ransomware spends a day spreading before triggering encryption.
Test your restores monthly. Immutability is worthless if the data is corrupt or the process is broken.
Layer 2: Network Segmentation and Least Privilege
Ransomware spreads laterally. Flat networks are feast tables.
Segment your infrastructure so a breach in the web tier doesn't grant access to the database tier. VLANs, security groups, and firewall rules enforce boundaries. The web server talks to the application server on port 8080; the application server talks to the database on port 5432. Nothing else is allowed.
Least privilege applies to service accounts too. Your WordPress cron job doesn't need sudo. Your backup script doesn't need write access to /var/www. Limit what each process can touch, and you limit the blast radius when something goes wrong.
Real-world example
A hosting client ran a multi-tenant cPanel box. Every account had shell access, and all sites lived under /home. An attacker uploaded a reverse shell through a vulnerable Joomla installation, then used a kernel exploit to escalate to root. From there they encrypted every account on the server.
The fix wasn't just patching the kernel. We rebuilt with CloudLinux to cage each tenant, disabled shell access for all but two admin accounts, and moved database servers to a separate VLAN with strict firewall rules. When the next compromise happened six months later, the attacker was trapped inside one account with no route to the others.
Check your own network map. If you drew a line from your most exposed service to your most critical database, how many hops does it take?
Layer 3: Aggressive Patch Management
Exploits age like milk. The window between disclosure and mass scanning is measured in hours, not days.
Automate security updates for the OS and critical packages. On Debian and Ubuntu, unattended-upgrades handles this. RHEL-based systems have dnf-automatic. Configure them to install security patches nightly and reboot if necessary—your uptime matters less than your data.
For application dependencies, the math is harder. Composer, npm, pip, and gem all ship vulnerabilities. Set up automated scanning with tools like npm audit, pip-audit, or Dependabot. Not every CVE is exploitable in your context, but you need to know what's in the stack.
The human part
Patching is straightforward until it isn't. A kernel update breaks a proprietary driver. A PHP version bump kills a legacy app. That's why you need staging environments and a rollback plan.
In support tickets I handled, the usual excuse for skipping patches was "the application vendor doesn't support the new version yet." Fine—then isolate that server, restrict its network access, and monitor it like a hawk. Don't let one legacy app become the breach point for your entire fleet.
The faster you patch, the smaller the exposure window. Aim for seven days on critical issues, 30 on everything else.
Layer 4: Runtime Monitoring and Anomaly Detection
Signature-based antivirus catches known malware. Ransomware authors repack their binaries every few hours to evade signatures.
Behavioral detection looks for suspicious patterns instead: a web server process suddenly writing to hundreds of files per second, a user account initiating SMB connections to 50 hosts in five minutes, or a backup directory accumulating .locked files. These are all red flags.
Tools like Wazuh, OSSEC, or Falco watch system calls and file operations in real time. Configure alerts for unusual file renames, unexpected privilege escalations, and mass file modifications. Auditd on Linux logs every execve, open, and unlink call if you tell it to—the volume is high, but correlation rules can surface the needles.
What actually triggers
A file integrity monitor like AIDE or Tripwire alerts when binaries in /usr/bin or configs in /etc change unexpectedly. An attacker replacing ps or netstat with trojanized versions will trip the alarm.
Process monitoring catches ransomware packing itself into memory and forking encryption workers. A sudden spike in CPU and disk I/O from a web application process is abnormal. Most CMSs read far more than they write; a WordPress instance churning through gigabytes of writes per hour is wrong.
Set baseline metrics during normal operation, then alert on deviations. This requires tuning, but the upfront work pays off when you catch an attack in the first five minutes instead of the first five hours.
Layer 5: Principle of Least Persistence
The longer an attacker stays undetected, the more damage they do. Kill their persistence mechanisms.
Ransomware loves cron jobs, systemd timers, and init scripts. After encryption, many variants leave a backdoor for follow-up extortion. Regular audits of scheduled tasks, startup scripts, and user login sessions cut off their fallback options.
On Linux, check crontab -l for all users, inspect /etc/cron.*, and review systemd units with systemctl list-units --type=service --all. Look for recently modified files in /etc/init.d, /etc/rc.local, and user .bashrc or .profile files.
SSH keys are another favorite. An attacker drops a public key into ~/.ssh/authorized_keys and walks back in whenever they want. Audit authorized keys monthly and rotate host keys after any suspected breach.
Ephemeral infrastructure helps
Immutable infrastructure limits persistence by design. If your application servers are rebuilt from a known-good image every deployment, an attacker's cron job vanishes with the next release.
Containers and orchestration platforms like Kubernetes take this further. Pods are disposable; persistent state lives in databases and object storage, not on the container filesystem. Ransomware that encrypts a container's ephemeral disk achieves nothing—you just terminate the pod and spin up a fresh one.
This doesn't eliminate the need for monitoring, but it shrinks the attack surface. The fewer places an attacker can hide, the fewer places you have to look.
How these layers overlap
None of these techniques work in isolation. Immutable backups don't help if network segmentation is missing and the attacker pivots to the backup server. Patching is useless if runtime monitoring never alerts you to the exploit attempt.
The point is to raise costs at every stage. Reconnaissance gets harder when your SSH port isn't default and your services don't advertise versions. Initial access gets harder when endpoints are patched and credentials aren't reused. Lateral movement gets harder when the network is segmented. Encryption gets harder when anomaly detection kills the process mid-run. Recovery gets easier when your backups are immutable and tested.
Think of each layer as a time tax. If you add 15 minutes of friction per layer, five layers buy you over an hour to detect and respond. Most automated ransomware gives up and moves to an easier target.
What to prioritize first
Start with backups. Everything else buys time; backups guarantee recovery.
Get immutability working this week—object lock on S3, compliance mode on Wasabi, or a write-once NAS. Test a restore. Then tackle network segmentation: put your databases behind a firewall and close the ports you aren't using.
Patching and monitoring can scale in parallel. Automate security updates, then layer in behavioral detection as your observability matures. Least persistence is ongoing hygiene—schedule a quarterly audit and stick to it.
Ransomware protection isn't a product you buy. It's a system you build one layer at a time.