Ransomware isn’t just a desktop problem. Attackers routinely encrypt servers (Windows file and RDP servers, Linux hosts and, increasingly, entire virtual machines) and wipe or encrypt the backups they can reach, then demand payment. “Database ransom” attacks against exposed MongoDB, Elasticsearch and Redis delete data and leave a ransom note. Good protection is mostly good basics, plus backups that attackers can’t touch.
How attackers get in
| Entry point | Typical on |
|---|---|
| Exposed RDP with weak or reused passwords | Windows servers |
| Exposed databases without authentication (MongoDB, Elasticsearch, Redis) | Linux servers |
| Unpatched internet-facing software (VPN appliances, CMS plugins, file-sharing apps) | Both |
| Stolen credentials (phishing, password reuse, infostealer malware on admin PCs) | Both |
| SSH with passwords | Linux |
| Compromised remote management tools | Both |
Many attacks are opportunistic: automated scanning finds an exposed service, exploits it, and encrypts whatever is reachable.
1. Shrink the attack surface
- Never expose RDP to the whole internet. Restrict it to your IPs, or use a VPN. Enable NLA and account lockout. See RDP brute-force protection and change the RDP port.
- Never expose databases publicly. Bind them to localhost or a private network, and require authentication. See check open ports.
- Key-only SSH on Linux. See key-only SSH.
- Only the ports you need in the firewall. See UFW and Windows Firewall with PowerShell.
2. Patch quickly
Exploited vulnerabilities in internet-facing software are a top ransomware entry point. Automate security updates, and prioritise known exploited CVEs. See patch management and Windows Update with PowerShell.
3. Protect credentials and limit privileges
- MFA everywhere it’s possible: the hosting panel, email, VPN, RDP gateway and admin panels.
- Unique, strong passwords in a password manager. See team password managers.
- Separate admin accounts. Daily work without admin rights.
- Least privilege: services and users can only write where they must. A compromised web app shouldn’t be able to encrypt the whole disk. See least privilege.
- Keep admin workstations clean. Infostealer malware on an admin’s laptop hands over SSH keys, browser sessions and saved passwords.
4. Backups ransomware can’t reach
This is the decisive layer. When everything else fails, you restore.
- Off-site: at a different provider or account. See the 3-2-1 backup rule.
- Immutable or append-only: object lock, append-only Borg or restic repositories, or pull-based backups where production servers have no credentials to delete backups.
- Offline or air-gapped copy: periodically disconnected storage, for the most critical data.
- Not joined to the same domain or login system as production (Windows: backup servers outside the Active Directory domain, with separate credentials).
- Versioned and long enough: attackers often wait days or weeks before encrypting. Keep months of history.
- Tested restores: know how long a full recovery takes.
5. Segment and monitor
- Separate roles: the database server isn’t reachable from the internet, only from the app server.
- Monitor for the early stages: new admin users, disabled security tools, unusual logins, mass file changes, large outbound transfers (data theft usually precedes encryption). See server security monitoring.
- File integrity monitoring on important paths. See AIDE.
6. Have a recovery plan
Write it down before you need it:
- Isolate affected servers: firewall them, disconnect networks, and use the provider console. Don’t just shut everything down if you need evidence.
- Assess: what’s encrypted, how they got in, and whether data was stolen.
- Rebuild clean: reinstall the OS (don’t decrypt and keep running a compromised system), patch, and close the entry point.
- Restore data from backups taken before the compromise, and verify integrity.
- Rotate all credentials: passwords, SSH keys, API keys, database passwords.
- Notify customers and authorities where required by law (data protection rules).
Paying a ransom doesn’t guarantee recovery, and it funds further attacks. Good backups make it unnecessary.
Quick checklist
| Area | Done? |
|---|---|
| RDP / SSH not open to the world, MFA or keys | ☐ |
| Databases not publicly reachable | ☐ |
| Automatic security updates | ☐ |
| Least-privilege service accounts | ☐ |
| Off-site, immutable backups with long retention | ☐ |
| Restore tested in the last 3 months | ☐ |
| Alerts on logins, admin changes and mass file changes | ☐ |
| Written incident and recovery plan | ☐ |
Related: detect a compromised server and Windows VPS.