NAS Hardening Checklist — 12 Steps That Stop Real Ransomware Campaigns

Every mass NAS ransomware campaign — Qlocker (2021), DeadBolt (2022), C3RB3R (2026) — used the same two ingredients: an internet-exposed admin interface and an unpatched flaw. Break either ingredient and you're invisible to the next wave. This checklist is assembled from Synology's, Qihoo 360's, Singapore CSA's and Macau PJ's published guidance during real campaigns.

The 12 steps, in priority order

1. Update the OS today, enable auto-updates. Check the build number yourself (Synology: Control Panel → Info Center) — don't trust the "fully updated" badge on EOL branches. C3RB3R victims were on builds patched weeks or years earlier.
2. Kill exposed admin ports. No port-forward to 5000/5001 (Synology), 8080/443 (QNAP), 8000/8001 (Asustor), 8181 (TerraMaster). If you need remote access, use the vendor relay (QuickConnect, myQNAPcloud Link) or — better — a VPN into your network.
3. Disable the default admin account. Every campaign's scanner logs in as admin/admin or harvests weak admin passwords. Create a non-obvious admin name, disable the default.
4. Strong unique password + 2FA on every account, especially admin. Enable auto-block after failed attempts (Synology: Control Panel → Security → Protection).
5. Update packages too. The PHP2Shell wave (Oct 2026) lived entirely in packages like Web Station, WordPress, Mail Station. Package Center → update all. Uninstall PHP web apps you don't use.
6. Turn on the firewall. Allow your LAN subnet; deny everything else on management ports. On Synology, also set "Deny" as the default rule and whitelist your LAN + VPN ranges.
7. Enable snapshots (Btrfs/ZFS models) and check they're actually running — several C3RB3R victims survived only because of snapshots. Turn on snapshot anti-tampering where offered.
8. One backup must leave the box. Ransomware with root encrypts every share on the NAS — your backup target must be somewhere it can't reach: external USB rotated offline, cloud sync with versioning, or another machine pulling (not pushing). This is the core of 3-2-1.
9. Clean the attack surface. Remove unused packages, dead shared links, Telnet/SSH/SFTP when not needed, unused users. Singapore CSA's DeadBolt advice for Asustor owners: disable EZ Connect if unused.
10. Segment guest/IoT access. Guest shares and surveillance cams don't need to see admin interfaces.
11. Alerting. Enable email/push alerts for abnormal logins and mass file changes — one Reddit victim caught C3RB3R mid-run because Plex died and he checked.
12. EOL model? Isolate it. A NAS stuck on DSM 6.x / old QTS can't receive current fixes. Behind a firewall with zero WAN exposure — or retired. Harsh but true.

Vendor quick-links for the same advice

Every vendor's page on this site carries its own incident history and specifics: Synology · QNAP · Asustor · TerraMaster · UGREEN · UniFi · fnOS · Zspace · TieNiu.

Is QuickConnect / myQNAPcloud safe?

Vendor relays are considerably safer than exposed ports: your DSM login page isn't directly reachable by scanners. Mass campaigns historically enumerated directly-exposed admin interfaces. Use the relay, still keep 2FA on, and still update — relays don't patch flaws.

What ports should never face the internet?

The admin UI ports: Synology 5000/5001, QNAP 8080/443/8081, Asustor 8000/8001, TerraMaster 8181 — plus SSH 22 and SMB 445. None of these belong on port forwards. Remote access belongs behind VPN or the vendor relay.

Do snapshots protect against ransomware?

Largely yes — several 2026 victims restored fully from snapshots. But ransomware with root can delete them, so snapshots are tier-2 defense: pair them with one off-NAS (ideally offline) backup, per 3-2-1.

My NAS model is end-of-life. What can I do?

Isolation: remove all WAN exposure (firewall deny, no forwards, no relay if the firmware is ancient), keep LAN-only use, keep an offline backup, and plan replacement. EOL firmware stops receiving the patches that stop these campaigns.