Ransomware doesn't care if your uptime is 99.99%. It only cares if it can write to your disk. In support tickets, the pattern is consistent: a single unpatched plugin, an open SSH port, or a misconfigured backup directory gives the attacker the foothold they need. Once in, the payload encrypts everything it can touch. You lose data, you lose time, and you lose customer trust. This guide breaks down how those attacks happen and gives you seven concrete fixes to close the gaps.
How Ransomware Gets In
Most server compromises don't start with a zero-day exploit. They start with a known vulnerability that was left open too long. The attacker scans for an exposed service, exploits it to get a shell, and then moves laterally. The ransomware payload is often the last step, not the first. By the time you see encrypted files, the attacker has likely been on the box for hours or days.
The most common entry points I see are:
- Unpatched WordPress plugins or themes. These are the #1 target because there are millions of sites using them.
- Exposed SSH ports. If port 22 is open to the world and you allow password authentication, bots will try to brute-force your way in within minutes.
- cPanel/WHM vulnerabilities. Outdated cPanel versions often have known CVEs that allow remote code execution.
- Misconfigured file permissions. If the
wwwuser can write to configuration files, an attacker can drop a backdoor easily. - Stale backup directories. If your backups are on the same server and accessible via the web, ransomware will encrypt your backups too.
Fix 1: Lock Down SSH Access
SSH is your lifeline, but it's also the front door. If you're allowing password authentication from 0.0.0.0/0, you're inviting trouble. Bots scan for open SSH ports constantly. If they find one with weak credentials, they get in.
First, disable password authentication. Use SSH keys only.
Edit /etc/ssh/sshd_config and ensure these lines are set:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
```n
Then, restrict access by IP. If you only need SSH from your office or a specific VPS, use `iptables` or `nftables` to allow only those IPs on port 22. For example:
```bash
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.10 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP
If you must allow SSH from multiple locations, consider using a VPN like WireGuard or OpenVPN instead of exposing the port. This adds a layer of encryption and authentication before the SSH handshake even starts.
Fix 2: Patch Your Web Stack Weekly
Outdated software is the biggest ransomware vulnerability on the web. WordPress, cPanel, Apache, Nginx, PHP—all of these have known vulnerabilities. The moment a CVE is published, bots start scanning for it. You have hours, not days, to patch.
Set up automatic updates for your OS and web server. For Debian/Ubuntu, enable unattended-upgrades:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
For WordPress, enable automatic minor updates in wp-config.php:
define( 'AUTOMATIC_UPDATES_ENABLED', true );
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
But don't rely on automatic updates alone. Subscribe to security bulletins for your specific stack. When a critical CVE drops for a popular plugin, patch it immediately. If you can't patch right away, consider disabling the plugin or putting the site in maintenance mode. Speed matters here.
Fix 3: Isolate Your Backups
If your backups are on the same server, they're not backups. They're just another set of files that ransomware can encrypt. Attackers know this. They often target /home/username/backup or /var/backups early in the attack.
Store backups off-server. Use a separate VPS, an object storage service like S3, or a dedicated backup server. The key is that the backup system must not be accessible from the production server's web interface.
For cPanel, use the WHM backup configuration to push backups to an external FTP/SFTP server. For WordPress, use a plugin that pushes backups to a remote S3 bucket. Test your restores regularly. A backup you can't restore is worse than no backup at all.
Fix 4: Harden File Permissions
Loose file permissions are a silent ransomware vulnerability. If the web server user (www-data or apache) can write to configuration files, an attacker can modify .htaccess or wp-config.php to drop a backdoor. This backdoor can then be used to deploy ransomware later.
Check your permissions. Web root files should be readable but not writable by the web server user. Config files should be owned by root or the main user, not www-data.
# Check permissions on a typical WordPress install
ls -la /home/username/public_html
If you see www-data as the owner of wp-config.php, change it:
chown username:username /home/username/public_html/wp-config.php
chmod 640 /home/username/public_html/wp-config.php
Run a permissions audit script regularly. Tools like lynis can help identify misconfigurations:
lynis audit system
Fix 5: Enable Intrusion Detection
You won't catch every attack, but you can catch some. An intrusion detection system (IDS) like Fail2Ban can block IPs that show suspicious behavior, such as multiple failed SSH logins or repeated 404 errors on admin pages.
Install Fail2Ban and configure it to monitor your SSH and web server logs:
sudo apt install fail2ban
sudo systemctl enable fail2ban
Create a custom jail for WordPress to block IPs that hit wp-login.php too many times:
[wp-login]
enable = true
filter = wp-login
logpath = /var/log/apache2/access.log
maxretry = 3
bantime = 3600
This won't stop a targeted attack, but it will stop the brute-force bots that make up the majority of initial access attempts.
Fix 6: Monitor File Integrity
Ransomware often modifies existing files before encrypting them. If you can detect unauthorized changes to critical files, you might catch the attack early. Use a file integrity monitoring (FIM) tool like aide or tripwire.
Initialize a baseline of your critical files:
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
Then, run regular checks:
aide --check
If a file has been modified without your knowledge, you'll see an alert. This is especially useful for detecting backdoors dropped in web root directories. Set up cron jobs to run these checks daily and email you the results.
Fix 7: Restrict Web Shell Access
Web shells are a common ransomware delivery mechanism. Attackers upload a PHP script to your web root that gives them a command-line interface. Once they have a web shell, they can run any command, including the ransomware payload.
Block common web shell file extensions in your web server configuration. For Apache, add this to your .htaccess file:
<FilesMatch "\.(phtml|php5|php4|php3|php2|php)$">
Allow from all
</FilesMatch>
<FilesMatch "\.(jsp|asp|aspx)$">
Require all denied
</FilesMatch>
But this is not enough. You need to monitor for new PHP files being created in your web root. Set up a file creation watcher that alerts you when a new .php file appears in directories where you don't expect them. Tools like inotifywait can help with this.
What to Check First
If you're short on time, start here. These five checks will catch the most common ransomware vulnerabilities:
- Is SSH password authentication disabled? Check
/etc/ssh/sshd_config. - Are your backups off-server? Verify that your backup destination is not accessible from the production web server.
- Are your plugins and core software up to date? Check your WordPress admin panel and cPanel update status.
- Are file permissions strict? Ensure
www-datacannot write to config files. - Do you have an IDS in place? Confirm Fail2Ban or a similar tool is running and blocking suspicious IPs.
If you pass all five, you're in good shape. If you fail any, fix them immediately. Ransomware doesn't wait for you to be ready.
FAQ
Can ransomware encrypt my backups if they're on the same server? Yes. If the backup directory is accessible by the web server user or the root user, ransomware can encrypt it. Always store backups off-server or in a location that is not mounted on the production filesystem.
How often should I patch my server? Critical patches should be applied within 24-48 hours of release. Minor patches can be applied weekly. Set up a regular patching schedule and stick to it.
Do I need a dedicated security tool like WAF? A Web Application Firewall can help block common attacks, but it's not a substitute for patching and hardening. Use a WAF as an additional layer, not a primary defense.
What if I've already been hit with ransomware? Isolate the server immediately. Do not pay the ransom. Restore from clean backups. Investigate how the attacker got in and close the vulnerability. Change all credentials that were stored on the server.
Is it worth paying the ransom? No. Paying does not guarantee you'll get your data back. It also funds further criminal activity. Always rely on backups and incident response.