Ransomware doesn't need a zero-day to wreck your server. Most attacks walk through an open door—an exposed service, a weak password, or a misconfigured backup that encrypts itself alongside your live data. I've watched support tickets pour in after an attack, and the pattern is always the same: the server was running default settings, backups were mounted read-write, and no one checked the logs until it was too late.
You can stop most ransomware before it touches your files. The key is treating your server like an adversary is already probing it, because they probably are.
Disable unnecessary services
Every running service is a potential entry point. SSH, FTP, MySQL exposed to the internet—each one gives an attacker another angle. Start by auditing what's actually listening.
sudo ss -tulpn | grep LISTEN
That command shows every open port and the process behind it. If you see MySQL on 3306 or Redis on 6379 bound to 0.0.0.0, you have a problem. Databases should never be reachable from the public internet unless you have a specific, documented reason.
For each service, ask: does this need to be running? Does it need to be reachable from outside the local network? If the answer is no to either question, stop the service or bind it to 127.0.0.1.
# MySQL example: bind to localhost only
# In /etc/mysql/mysql.conf.d/mysqld.cnf
bind-address = 127.0.0.1
FTP is another common problem. If you're still running it, switch to SFTP. FTP sends credentials in plain text, and brute-force bots love it. I've seen servers compromised in under 24 hours after enabling FTP with a weak password.
Lock down SSH access
SSH is how you manage the server, which makes it the highest-value target. Default settings allow password authentication and root login, both of which are mistakes.
Disable root login first. Edit /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Then restart SSH:
sudo systemctl restart sshd
Before you do that, make absolutely certain you have a working SSH key pair and a non-root user with sudo privileges. Test the key login in a separate session before you restart sshd, or you'll lock yourself out.
Change the default port if you want to cut down on automated scans. Moving SSH from port 22 to something like 2222 won't stop a determined attacker, but it does eliminate the constant noise from bots.
Port 2222
Use Fail2Ban to block repeated login attempts. Install it, enable the SSH jail, and set a ban time of at least an hour. That stops brute-force tools cold.
sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
The default Fail2Ban config is usually fine, but check /etc/fail2ban/jail.local to make sure the SSH jail is active and bantime is reasonable—600 seconds is a good starting point.
Segment backups from live filesystems
If ransomware can reach your backups, you don't have backups. This is the single most common failure I see. Admins mount a backup drive at /mnt/backup, give it the same permissions as the live filesystem, and then wonder why everything gets encrypted together.
Backups need to be immutable or at least append-only. That means the live system can write new backups but cannot modify or delete old ones. A few ways to achieve this:
- Off-server backups with SSH keys that only allow writes, not deletes (use
rsyncwith a restricted shell). - Object storage with versioning enabled (S3, Backblaze B2, Wasabi).
- A dedicated backup server that pulls from the live server instead of the live server pushing.
Never mount a backup destination as a normal writable filesystem on the production server. If you're using rsync, push backups over SSH to a remote server where the receiving user has restricted permissions.
Here's a simple rsync backup script that pushes to a remote server:
#!/bin/bash
rsync -avz --delete /var/www/ backup@backup-server:/backups/www/
On the backup server, restrict the backup user so they can't delete old files. Use a chroot jail or a forced command in ~/.ssh/authorized_keys.
Apply the principle of least privilege
Applications shouldn't run as root. Web servers, databases, and custom scripts should each have their own unprivileged user. If ransomware compromises the web server process, it should only be able to touch files the web server user owns.
Check what user your web server runs as:
ps aux | grep apache
ps aux | grep nginx
If you see root, that's a misconfiguration. Apache and Nginx both have config directives to set the worker user—usually www-data or apache.
For custom applications, create a dedicated user:
sudo useradd -r -s /bin/false appuser
The -r flag creates a system user, and -s /bin/false prevents interactive login. Then run your application as that user, and make sure file permissions reflect the least access needed.
So what if a process needs to write logs or upload files?
Set ownership and permissions narrowly. If the app needs to write to /var/www/uploads, that directory should be owned by the app user and have mode 755 or 750. The rest of the web root should be read-only to the web server process.
Patch the operating system and software
This one is obvious, but I still see unpatched servers running kernels from two years ago. Ransomware often uses known exploits to escalate privileges or move laterally after the initial foothold.
Enable automatic security updates:
# Debian/Ubuntu
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# CentOS/RHEL
sudo yum install yum-cron
sudo systemctl enable yum-cron
sudo systemctl start yum-cron
Automatic updates won't catch everything—you still need to manually update web apps, control panels, and language runtimes. But they keep the base system patched, which closes the most common privilege escalation paths.
Check for available updates regularly:
# Debian/Ubuntu
sudo apt update && sudo apt list --upgradable
# CentOS/RHEL
sudo yum check-update
Reboot after kernel updates. A patched kernel sitting on disk doesn't help if you're still running the old one.
Restrict file permissions across the board
World-writable files and directories are an open invitation. Ransomware that compromises a low-privilege process will look for files it can modify. Tighten permissions so only the owning user and group can write.
Find world-writable files:
find / -type f -perm -002 -ls 2>/dev/null
That lists every file where the "others" permission includes write. Review the list and fix anything that shouldn't be writable by everyone.
For directories:
find / -type d -perm -002 -ls 2>/dev/null
Common culprits are /tmp, /var/tmp, and upload directories. Those need the sticky bit set so users can only delete their own files:
sudo chmod +t /tmp
The sticky bit is already set on /tmp by default, but third-party applications sometimes create their own temp directories without it.
Enable and monitor intrusion detection
File integrity monitoring alerts you when something changes unexpectedly. AIDE (Advanced Intrusion Detection Environment) is the standard tool for this on Linux.
Install AIDE:
sudo apt install aide
Initialize the database:
sudo aideinit
That takes a snapshot of critical files and directories. Run a check regularly via cron:
0 2 * * * /usr/bin/aide --check | mail -s "AIDE Report" [email protected]
AIDE will flag any changed, added, or deleted files. If you see unexpected changes in system binaries or config files, investigate immediately.
Log monitoring is just as important. Centralize logs if you're managing multiple servers, but even on a single server, you should be checking auth logs for failed login attempts and application logs for anomalies.
sudo tail -f /var/log/auth.log | grep "Failed password"
If you see dozens of failed attempts from the same IP, Fail2Ban should be catching it. If it's not, your Fail2Ban config needs tuning.
Isolate network segments with a firewall
A firewall is your first line of defense. Only allow inbound traffic on ports you actually need, and block everything else by default. ufw (Uncomplicated Firewall) makes this straightforward on Ubuntu and Debian.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
That allows SSH, HTTP, and HTTPS, and blocks everything else. If you changed the SSH port earlier, adjust the rule accordingly.
For servers that don't need to be reached from the public internet—database servers, internal application servers—put them behind a private network and use a bastion host or VPN for access. That way, even if the web server is compromised, the attacker can't directly reach your data layer.
Check your active firewall rules:
sudo ufw status verbose
Make sure nothing unexpected is open. A misconfigured firewall rule can expose services you thought were locked down.
Test and document your recovery process
You can't know your backups work until you restore from them. Schedule regular restore tests—quarterly at minimum. Spin up a fresh server, pull the latest backup, and verify you can bring the application back online.
Time the process. If a restore takes eight hours and you don't know that until you're in the middle of an incident, you're in trouble. Document every step: where the backups live, what commands to run, what credentials you need, and in what order to bring services back up.
That documentation should be stored outside the server environment. A runbook on the server itself won't help if the server is encrypted.
Test failover scenarios too. What happens if the primary server goes down? Can you bring up a replica quickly, or are you rebuilding from scratch? Knowing your recovery time objective (RTO) before an attack happens keeps expectations realistic when you're under pressure.
How do I know if my backups are encrypted?
Try restoring a test file from your latest backup. If the restore fails or the file is corrupted, the backup may be compromised. Regularly scheduled restore tests catch this early.
Will moving SSH to a different port really help?
It cuts down on automated scanner noise, which makes your logs cleaner and reduces the load on Fail2Ban. It won't stop a targeted attacker, but most ransomware is opportunistic and scans port 22 specifically.
Can ransomware spread through NFS or SMB mounts?
Yes. If the compromised server has write access to a network share, ransomware can encrypt those files too. Treat network mounts the same way you treat local backups—use read-only mounts where possible, or restrict permissions tightly.
Do I need a separate firewall appliance or is software firewall enough?
For a single server, a properly configured software firewall like ufw or firewalld is sufficient. If you're managing multiple servers or need more advanced traffic inspection, a hardware firewall or cloud security group adds another layer.
Start with SSH and backups
If you only have time to do two things today, lock down SSH and fix your backup strategy. Those two changes block the most common initial access vector and ensure you can recover if something gets through.
The rest of the steps build defense in depth—firewalls, least privilege, patching, monitoring. Each one closes another gap. Ransomware prevention isn't about perfect security; it's about making your server a harder target than the next one.
Check your server against this list. Note what's already in place and what needs work. Then fix the gaps before someone else finds them.