Ransomware gangs don't target you because you're special. They target you because you're accessible. Every server exposed to the internet gets scanned, probed, and tested for weak spots dozens of times per day. The question isn't whether an attacker will try—it's whether your defenses hold when they do.
I've worked tickets where a single compromised WordPress admin account led to complete server encryption within hours. The company had backups, but they were mounted on the same filesystem. Both the live data and the backups got locked. Three days of downtime and a ransom payment that solved nothing.
Ransomware attack prevention isn't about one silver bullet. It's about layered defenses that make your servers expensive and annoying to attack. Miss one layer and you might survive. Miss three and you're paying Bitcoin to strangers.
1. Offline backups with tested restore procedures
Your backup strategy matters more than any firewall rule. Backups must live somewhere the attacker can't reach—offline storage, air-gapped systems, or immutable cloud buckets with strict retention policies. If ransomware can see your backups, it will encrypt them.
Schedule daily snapshots and keep at least 30 days of history. Rotate older backups to cold storage weekly. The 3-2-1 rule still holds: three copies of your data, two different media types, one copy offsite.
Test your restores monthly. Not a quick file check—do a full server rebuild from backup on a staging environment. Time it. Document every command. I've seen backup systems that ran for years but failed on the first real restore because a dependency changed or credentials expired.
# Example backup script with offsite rsync
#!/bin/bash
DATE=$(date +%Y%m%d)
BACKUP_DIR="/mnt/backup/$DATE"
REMOTE_USER="[email protected]"
mkdir -p "$BACKUP_DIR"
tar -czf "$BACKUP_DIR/server-data.tar.gz" /var/www /etc /home
rsync -avz --delete "$BACKUP_DIR" "$REMOTE_USER:/backups/"
# Keep only last 30 days locally
find /mnt/backup -type d -mtime +30 -exec rm -rf {} +
Store database dumps separately from filesystem backups. Encrypt everything before it leaves your network. Use a password manager to store the encryption keys—not a text file on the same server.
2. Network segmentation and firewall rules
Flat networks are a ransomware operator's dream. Once they compromise one system, lateral movement becomes trivial. Segment your infrastructure so a breach in the web tier can't immediately reach your database servers or backup storage.
Create VLANs or use cloud VPC subnets to isolate different service tiers. Web servers talk to application servers on specific ports only. Application servers talk to databases. Nothing else does. Drop everything by default and allow only what you need.
# Basic iptables rules for a web server
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Allow SSH from management subnet only
iptables -A INPUT -p tcp --dport 22 -s 10.0.1.0/24 -j ACCEPT
# Allow HTTP/HTTPS from anywhere
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Save rules
iptables-save > /etc/iptables/rules.v4
Use a jump host or VPN for administrative access. Never expose SSH, RDP, or cPanel directly to the internet. Even with strong passwords and key auth, you're creating unnecessary attack surface. Fail2ban helps but it's not enough on its own.
Monitor east-west traffic between segments. Unusual database queries from a web server or SMB traffic from an application server should trigger alerts. Most ransomware spreads by exploiting trust relationships within your network.
3. Patch management and vulnerability scanning
Unpatched systems are the easiest entry point. Attackers scan for known CVEs and exploit them within hours of disclosure. Your window to patch critical vulnerabilities is measured in days, not weeks.
Automate security updates for the OS and all installed packages. On Debian-based systems, enable unattended-upgrades. On RHEL or CentOS, configure yum-cron or dnf-automatic. Check that updates actually run—I've found servers with auto-update configured but disabled by a previous admin.
# Enable automatic security updates on Ubuntu/Debian
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
# Verify it's running
systemctl status unattended-upgrades
cat /etc/apt/apt.conf.d/50unattended-upgrades
Web applications need separate attention. WordPress, Joomla, Drupal—all ship security updates regularly. Set up automatic minor updates and monitor for major releases that need manual intervention. Remove unused plugins and themes entirely. Every extra package is potential attack surface.
Run vulnerability scans weekly. Tools like Lynis for Linux hardening checks or OpenVAS for network scanning catch misconfigurations and outdated software. Schedule scans during low-traffic periods and review reports the same day.
4. Email filtering and user awareness
Phishing emails remain the most common ransomware delivery method. An employee clicks a malicious attachment or link, and the infection starts. Technical controls on the server side won't help if the threat arrives through an authenticated user session.
Implement SPF, DKIM, and DMARC on all domains you own. Reject or quarantine messages that fail authentication checks. Use a mail gateway that scans attachments and sandboxes suspicious files before delivery. Block executable attachment types entirely—no one needs to receive a .exe or .scr file by email.
# Example DMARC record in DNS
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; fo=1"
Train your users quarterly. Run simulated phishing campaigns and track who clicks. Don't shame people who fail—use it as a teaching moment. The goal is building a culture where reporting suspicious emails is normal and quick.
Disable macros in Office documents by default. Configure email clients to display plain text instead of HTML when possible. These small friction points make life harder for attackers without significantly impacting legitimate work.
5. Endpoint detection and log monitoring
You need visibility into what's happening on your servers in real time. Ransomware doesn't announce itself politely. It encrypts files as fast as the disk can write, often starting in user directories and working outward.
Deploy endpoint detection and response tools or at minimum host-based intrusion detection like OSSEC or Wazuh. Configure alerts for suspicious behavior: mass file modifications, new scheduled tasks, unauthorized privilege escalation, or connections to known malicious IPs.
# Monitor for rapid file changes (possible ransomware)
inotifywait -m -r -e modify,create /var/www /home | while read path action file; do
echo "$(date): $action $path$file" >> /var/log/file-changes.log
done
Centralize logs to a separate system attackers can't easily reach. Use a SIEM or simple syslog forwarding to a hardened log server. If your main server gets compromised and logs wiped, you still have forensic data.
Set up alerting thresholds that matter. Disk space dropping fast. Login failures spiking. Outbound traffic to strange ports. A hundred small signals often precede the actual encryption phase. The earlier you catch it, the less damage you'll face.
6. Incident response plan and regular drills
When ransomware hits, you don't have time to figure out your response. You need a documented plan everyone understands and practices.
Write down the escalation chain. Who gets called first? Who has authority to take servers offline? Where are the backup credentials stored? What's the process for isolating infected systems without cutting off your ability to investigate?
Run tabletop exercises quarterly. Present a realistic scenario—web server shows signs of encryption, backups are intact but 12 hours old—and walk through each step. Time how long it takes to isolate the system, verify backup integrity, and start recovery. Find the gaps before they matter.
## Incident Response Checklist
- [ ] Identify affected systems and isolate from network
- [ ] Preserve logs and take forensic snapshots if possible
- [ ] Notify security team and management
- [ ] Verify backup integrity and offsite status
- [ ] Assess scope: data encrypted, systems compromised, backups affected?
- [ ] Begin recovery from clean backups
- [ ] Change all credentials and keys
- [ ] Review entry point and patch vulnerability
- [ ] Document timeline and lessons learned
Keep printed copies of your runbook. If systems are down, you can't rely on accessing documentation from the same infrastructure. Store emergency contact lists, network diagrams, and critical credentials in a physical safe or with a trusted third party.
Test your backup restores under pressure. Can you rebuild your environment in four hours? Eight? Knowing that number helps you make rational decisions when an attacker is demanding payment.
What happens when prevention fails?
Even with all six layers in place, determined attackers sometimes get through. Your response speed determines whether you face hours of downtime or weeks.
Isolate infected systems immediately. Pull network cables if you have physical access, or use firewall rules to black-hole their traffic. Don't wait to be sure—better to take down a clean system briefly than let ransomware spread.
Check your backups before starting recovery. Attackers increasingly target backup systems first, encrypting or deleting them before touching production data. If backups are compromised, you need to know immediately.
Don't pay the ransom unless you have no alternative and data loss means business failure. Payment doesn't guarantee decryption, funds criminal operations, and marks you as a paying target for future attacks. Law enforcement and security companies sometimes have decryption keys for older ransomware variants—check before paying.
Document everything. Logs, timelines, decisions made, systems affected. You'll need this for insurance claims, compliance reporting, and improving your defenses afterward. The worst time to realize you're missing critical forensic data is when investigators ask for it.
Frequently asked questions
How often should I test backups?
Monthly full restore tests catch most problems. Weekly spot checks of individual files add confidence without the same time investment. Never assume backups work until you've proven it.
Can antivirus stop ransomware?
Signature-based antivirus catches known variants but misses new ones. Behavior-based detection helps but isn't perfect. Consider it one layer, not your primary defense.
Should I enable automatic updates on production servers?
For security patches, yes. Schedule updates during maintenance windows and monitor for issues afterward. The risk of running unpatched systems exceeds the risk of update-related problems.
What's the minimum backup retention period?
Thirty days covers most scenarios where ransomware sits dormant before activating. Longer retention helps if you discover the infection weeks after initial compromise.
Do I need a security team to implement this?
No, but you need someone who understands the systems and has time to maintain them. Small teams can handle this with good automation and monitoring.
Start with backups and work outward
You don't need to implement everything at once. Start with offline backups and tested restores—that's your safety net. Add network segmentation next, then patch management. Each layer makes the next more effective.
Ransomware attack prevention is ongoing work, not a one-time project. Threat actors adapt. New vulnerabilities emerge. Your infrastructure changes. Schedule quarterly reviews of your defenses and keep improving them.
The goal isn't perfect security. It's making your servers harder to compromise than the next target. Attackers optimize for return on effort. When you raise your defenses, most move on to easier victims.