Skip to content
Back to Blog
Security10 min read

Ransomware Prevention for Servers: 7 Configs That Block Attacks

Seven OS and network hardening steps that stop ransomware before encryption starts, from file-system protections to network segmentation.

Written by Abdul AbrorTechnical Hosting Support Engineer
Ransomware Prevention for Servers: 7 Configs That Block Attacks
On this page

Ransomware gangs target servers because they hold customer data, backups, and databases. An encrypted production VPS means downtime, ransom negotiations, and reputation damage. But most attacks follow predictable patterns—lateral movement from a compromised account, scanning for open shares, and exploiting services that shouldn't be exposed.

Hardening at the OS and network layer stops those patterns before encryption starts. The seven configs below have blocked real attacks I've investigated in support tickets, and they work on any Linux distribution you're running.

1. Immutable Flags on Critical Binaries

Ransomware often replaces or overwrites system utilities to maintain persistence or evade detection. Setting the immutable attribute on core binaries prevents modification even by root until you explicitly remove the flag.

sudo chattr +i /bin/bash /usr/bin/python* /usr/bin/perl /bin/sh
sudo chattr +i /usr/sbin/sshd /sbin/init

This stops an attacker who has gained root from replacing your shell with a backdoored version or tampering with SSH. To update packages later, remove the flag with chattr -i, apply updates, then reapply.

Check which files are immutable:

lsattr /bin/* | grep '^....i'

In support tickets I handled, the usual culprit was a web application exploit leading to root. Immutable flags bought enough time for intrusion detection to fire.

2. Disable Unnecessary Network Services

Every listening port is an attack surface. Ransomware spreads by scanning for open SMB, RDP, or database ports, then brute-forcing or exploiting unpatched services.

List what's listening:

sudo ss -tulnp

You'll often find services you forgot were installed. Disable anything not required for your workload:

sudo systemctl disable --now rpcbind
sudo systemctl disable --now cups
sudo systemctl disable --now avahi-daemon

For database servers, bind only to localhost if your application is on the same host:

# /etc/mysql/my.cnf or /etc/my.cnf.d/server.cnf
[mysqld]
bind-address = 127.0.0.1

Restart the service and confirm with ss again. External scans should see nothing.

3. Filesystem Segmentation with Separate Partitions

A single root partition means ransomware can encrypt everything in one pass. Separate partitions for /home, /var, and /tmp create boundaries that limit blast radius and let you mount with restrictive options.

If you're provisioning a new server, set up dedicated partitions during install. For existing servers, move directories to new partitions during maintenance windows:

# Example: move /var to a new partition
sudo systemctl stop apache2 mysql
sudo rsync -avxHAX /var/ /mnt/new_var/
# Edit /etc/fstab, reboot, verify

Mount /tmp and /var/tmp with noexec and nosuid:

# /etc/fstab
tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev 0 0
tmpfs /var/tmp tmpfs defaults,noexec,nosuid,nodev 0 0

This blocks execution of malicious scripts dropped into temp directories, a common ransomware tactic.

4. Application Firewalls at the Host Level

Cloud provider security groups are great, but host-level firewalls (iptables, nftables, or firewalld) provide defense in depth. If an attacker pivots from another compromised instance in your VPC, the host firewall is your last line.

A basic iptables ruleset that drops everything except SSH and HTTP:

sudo iptables -F
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables-save | sudo tee /etc/iptables/rules.v4

For production, whitelist your office IP for SSH and drop the rest. Ransomware scanning your subnet won't find open management ports.

So what about outbound traffic?

Default-allow egress is common, but it lets ransomware phone home for encryption keys or exfiltrate data. Consider an egress allowlist for production servers that only need to reach your package mirrors, monitoring endpoints, and known APIs.

sudo iptables -P OUTPUT DROP
sudo iptables -A OUTPUT -o lo -j ACCEPT
sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 443 -d <your-monitoring-ip> -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 80 -d <package-mirror-ip> -j ACCEPT

This is aggressive and breaks convenience, but it stops command-and-control callbacks cold.

5. Real-Time File Integrity Monitoring

Ransomware encrypts files. Detecting mass file changes in real time gives you seconds to kill the process before it finishes.

Install AIDE (Advanced Intrusion Detection Environment) and initialize the database:

sudo apt install aide
sudo aideinit
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Run checks via cron every few minutes:

# /etc/cron.d/aide
*/5 * * * * root /usr/bin/aide --check | mail -s "AIDE Report" [email protected]

For a faster, less comprehensive option, use inotify-tools to watch critical directories:

sudo apt install inotify-tools
inotifywait -m -r -e modify,delete,create /var/www /home --format '%T %w%f %e' --timefmt '%Y-%m-%d %H:%M:%S' >> /var/log/file-changes.log &

Parse the log with a script that alerts when hundreds of files change in under a minute. That pattern is ransomware, not a legitimate deployment.

6. Restrict User Privileges and Enforce Least Privilege

Ransomware runs with the privileges of the compromised account. If your web server runs as root or your backup scripts use a root cron, an exploit gives the attacker everything.

Run services as dedicated users with minimal permissions:

# Apache example
sudo useradd -r -s /usr/sbin/nologin www-data
# Confirm in /etc/apache2/envvars or httpd.conf
User www-data
Group www-data

For file uploads, set ownership so the web user can write but not execute:

sudo chown www-data:www-data /var/www/uploads
sudo chmod 755 /var/www/uploads
sudo find /var/www/uploads -type f -exec chmod 644 {} \;

Use sudo with command whitelists instead of giving accounts full root:

# /etc/sudoers.d/backup-user
backup ALL=(ALL) NOPASSWD: /usr/bin/rsync, /bin/tar

An attacker who pops the backup script can only run rsync and tar, not install rootkits.

7. Network Segmentation and VLANs

Putting all servers on the same flat network lets ransomware spread instantly. Segment production, staging, and admin networks so a compromised dev box can't reach your database cluster.

If your host supports VLANs, create separate subnets:

  • VLAN 10: Web servers (public-facing)
  • VLAN 20: Application servers (backend APIs)
  • VLAN 30: Databases (internal only)
  • VLAN 40: Management (SSH, monitoring)

Configure your switch or hypervisor to enforce this. Use firewall rules to allow only the required flows:

# On the database server
sudo iptables -A INPUT -s 10.0.20.0/24 -p tcp --dport 3306 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 3306 -j DROP

Web servers in VLAN 10 can't talk to databases in VLAN 30 unless you explicitly allow application servers in VLAN 20 to proxy the connection. Ransomware that compromises a front-end server is contained.

What to check after hardening

Once these configs are in place, verify each one:

  1. Immutable flags: Try to modify a protected binary as root. It should fail.
  2. Disabled services: Run ss -tulnp and confirm only required ports are listening.
  3. Mount options: Check /proc/mounts for noexec on /tmp and /var/tmp.
  4. Firewall rules: Scan your server from an external host with nmap. Closed ports should be filtered, not open.
  5. Egress filtering: Try to curl an arbitrary external domain from the server. If your egress rules are strict, it should timeout.
  6. File integrity monitoring: Modify a watched file and confirm AIDE or inotify logs the change.
  7. Privilege checks: Log in as a service account and attempt privileged operations. They should be denied.

Document the baseline in your runbook. When you investigate an incident, compare current state to this baseline.

Start with the firewall and service audit

If you implement one thing today, lock down your firewall and disable unused services. Those two steps close the majority of entry points ransomware uses to gain a foothold. The other five configs build defense in depth, making it exponentially harder for an attacker to move laterally, escalate privileges, or encrypt your data.

Check your listening ports now. Then work through the rest of the list during your next maintenance window.

FAQ

Will immutable flags break package updates?

Yes, temporarily. Remove the flag before upgrading, then reapply. Automate it in your update script.

Can I use UFW instead of raw iptables?

Absolutely. UFW is a front-end for iptables and easier to manage. The same principles apply.

How do I test egress filtering without breaking production?

Apply rules during a maintenance window and monitor application logs for connection failures. Whitelist any missed destinations incrementally.

Does file integrity monitoring catch ransomware fast enough?

It depends on your check interval. Five-minute cron jobs are better than nothing; real-time inotify is better. Pair it with process monitoring that kills high-CPU processes modifying many files.

What if ransomware already has root before I harden?

These configs prevent initial compromise and lateral movement. If you already have a rootkit, you need incident response—offline backups, forensic imaging, and a clean rebuild.