--- title: "NAS Security for a Public Website: The 5 Layers We Run on Synology" description: "NAS security is usually described as a list of switches inside DSM. For a NAS that only holds family photos, that list is enough. Ours does something riskier: SynoPower Club, a store that takes payments in 16 languages, is served…" url: "https://synopower.club/zh/%e6%96%87%e4%bb%b6/synology-nas-security-public-website/" updated: "2026-10-11" category: NAS Hosting 101 --- # NAS Security for a Public Website: The 5 Layers We Run on Synology NAS security is usually described as a list of switches inside DSM. For a NAS that only holds family photos, that list is enough. Ours does something riskier: SynoPower Club, a store that takes payments in 16 languages, is served from a Synology NAS in our own rack, so every scanner and botnet on the internet can knock on the door. One setting was never going to be enough NAS security for that. This NAS Hosting 101 article walks through the five layers a request crosses before it reaches WordPress, what each layer caught in real incidents during 2026, and the times a layer hurt us instead of the attacker. > **SynoPower Club Point:** I worked on the support side of Synology for years, and the compromised machines I saw were almost never beaten by something clever. They had the default admin account still enabled, a management port forwarded to the internet, and no second factor. Good NAS security is mostly boring work done in the right order. What surprised me after we started hosting our own store is how much of the job moves outside the NAS. Most of the traffic we refuse today is turned away before it ever touches our line. ## What NAS Security Means Once the NAS Hosts a Website A private NAS has one job in a security sense: keep strangers out of the login page. A NAS that hosts a public website has the opposite problem. Strangers are the customers, and thousands of them must get in every day without an account. The question changes from who may connect to what a connection is allowed to ask for. That is why we stopped thinking about NAS security as a product feature and started drawing it as a path. A request for our shop passes five points, and each one can refuse it: - **The edge.** Cloudflare receives every request first and answers most of them from its own cache. - **The router.** A Synology router inspects what Cloudflare passes on and forwards only the ports we need. - **The front NAS.** A DSM machine terminates TLS and acts as reverse proxy and mail server. - **The Virtual DSM.** WordPress runs in a container inside its own Virtual DSM instance, apart from everything else. - **The application.** WordPress itself decides what a visitor may do on a form or a login page. No single layer is trusted to be right. Each one is there for the day the layer in front of it is wrong, misconfigured, or simply bypassed. ## Layer 1: Cloudflare Refuses Most Attacks Before They Reach Us Good NAS security starts somewhere that is not the NAS. The cheapest request to defend against is the one that never arrives. In the 24 hours before we wrote this, Cloudflare handled 78,690 requests for our domain. It answered 57,620 of them from its cache, stopped 5,590 as unwanted, and sent only 15,470 on to our origin. Four out of five requests never used a single CPU cycle on the NAS. ![Cloudflare security analytics for a Synology-hosted store, the first NAS security layer, showing requests mitigated, served from cache and served by origin](https://synopower.club/wp-content/uploads/2026/10/cloudflare-security-analytics-mitigated-requests-scaled.webp) One ordinary day in October 2026. The yellow line is traffic answered from the Cloudflare cache, the blue line is what reached our NAS, and the pink line is what Cloudflare refused. We are on the Pro plan and run 15 custom firewall rules plus two rate limits. Every one of them exists because of a specific bad day. Three examples show the pattern: - **Webshell hunters, 20 July.** In 17 hours we logged 950 probes for 535 different PHP file names from 14 addresses. Blocking addresses could not keep up, so we turned the logic around: only the handful of PHP entry points WordPress really uses are allowed, and every other one is refused at the edge. - **Credential scanners, 29 August.** A wave from cloud hosting networks asked for configuration and secret files more than 1,400 times. None existed, but each miss made WordPress build a full error page, the load average reached 46 and the container had to be restarted. Those paths are now blocked outright, and unverified traffic from the large cloud networks gets a browser challenge. - **An add-to-cart botnet, 31 August.** Within an hour, 258 add-to-cart requests arrived from almost as many different addresses, about one request each, so there was nothing to block by address. A managed challenge on that one action stopped it, and real browsers pass it without noticing. Cloudflare Turnstile covers the forms the firewall cannot judge: registration, password reset, comments and the contact form. The account that controls all of this, and the one at our domain registrar, both require a second factor. An attacker who can change your DNS does not need to break your NAS. ## Layer 2: Threat Prevention on the Synology Router Whatever Cloudflare lets through arrives at a Synology router running SRM, the second NAS security layer. This is the layer that was in the original note for this article: *Threat Prevention blocks another wave*. It is an intrusion prevention system that compares packets with known attack signatures, and ours is set to drop high-severity matches automatically instead of merely logging them. On 2 August 2026 one address fired 116 attempts at a PHP flaw that only affects Windows servers. It could never have worked against us, and that is the point of the story: Threat Prevention dropped every attempt, and when we searched the web server logs afterwards the address was not there at all. The attack ended at the router. ![Synology router Threat Prevention map showing the sources of high, medium and low severity events over seven days, the second NAS security layer](https://synopower.club/wp-content/uploads/2026/10/synology-router-threat-prevention-map.webp) Seven days of Threat Prevention events on our router in October 2026, plotted by source. Red marks are high severity, and those packets are dropped automatically. Three plainer settings on the same box do as much for NAS security as the inspection engine does: - **Only the necessary ports are forwarded.** Web and mail ports go to the front NAS. The DSM management ports and SSH are not forwarded anywhere. - **Country rules in the firewall.** A short list of regions we do not sell to is refused before any application sees the packet. - **Safe Access.** DNS and web filtering stop machines inside the network from talking to known malicious domains, which matters on the day something inside is already infected. ## Layer 3: NAS Security Inside DSM, From 2FA to Auto Block The front NAS is the first Synology system an outside packet can reach, so this is where classic NAS security advice applies in full. Our settings are deliberately unoriginal: - **The default accounts are disabled.** Both `admin` and `guest` are switched off. Every automated login attack starts with those two names. - **Administrators cannot sign in with a password alone.** Two-factor authentication is enforced for the whole administrators group, and Adaptive MFA asks for extra proof when a sign-in looks unusual. - **Auto Block is on.** Ten failed logins within five minutes block the source address, and the block does not expire by itself. - **The DSM firewall is enabled** on top of the router rules, so a mistake on one device is not a hole in both. - **Security updates install themselves** on this machine. On the Virtual DSM that runs the shop we are only notified, and we update by hand after taking a snapshot. ![DSM Control Panel Security Account tab with 2-factor authentication enforced for the administrators group and Adaptive MFA enabled](https://synopower.club/wp-content/uploads/2026/10/dsm-enforce-2fa-administrators-adaptive-mfa.webp) Control Panel, Security, Account on the front NAS. Enforcing the second factor for the group means a new administrator cannot forget to enable it, which is NAS security that survives staff changes. Two habits matter to NAS security as much as the switches. We reach DSM from outside through QuickConnect or not at all, which is why no management port needs to be open. And temporary helpers get temporary accounts: when a contractor or an AI agent needs administrator access, we create a named account, let the work finish, and disable it the same day. ## Layer 4: A Virtual DSM That Contains the Damage WordPress does not run on the front NAS. It runs in a container inside a Virtual DSM, a complete second copy of DSM hosted by Virtual Machine Manager. Mail, the reverse proxy and the shop therefore live in separate systems with separate accounts and separate storage. Isolation is the part of NAS security that does not try to prevent a break-in. It limits what a break-in is worth. If a WordPress plugin is ever compromised, the attacker lands in a container with a memory limit, inside a virtual machine that holds no mailboxes and no backups. And because the whole machine is a single file to Virtual Machine Manager, a snapshot before every risky change takes seconds and rolling back takes a few minutes. Virtual Machine Manager includes one Virtual DSM instance free of charge on supported models, which is enough to try this layout. Further instances need a license each. [Get a Virtual DSM license](https://synopower.club/virtual-dsm-vdsm-license-pack/) ## Layer 5: What WordPress Still Has to Do Itself The outer NAS security layers judge packets and requests. Only the application knows what a request means, so a few defences have to live in WordPress: - **A second factor for every administrator login**, the same rule as in DSM. - **Quiet limits on password resets.** Repeated reset requests for one account are dropped without an error message, because a helpful error tells an attacker the account exists. - **No user list for strangers.** The standard ways of listing WordPress user names are closed. - **Tor is refused on forms.** In September somebody used our contact form to flood other people with confirmation emails, every submission arriving through Tor. Reading the site over Tor still works. Submitting a form does not. - **A cheap error page.** A request for something that does not exist gets a one-kilobyte answer instead of a full themed page of 148 kilobytes. The Tor incident has its own write-up: [Email bombing through a contact form](/docs/email-bombing-contact-form-synology-nas/). ## Adding NAS Security in 4 Steps, Outside In If you are starting from a NAS with default settings, the order of your NAS security work matters more than the tools. Work from the outside in, and test the site after each step. ### Put a proxy in front of the site Move the DNS of your domain to Cloudflare and switch the records for the website to proxied. Turn on Always Use HTTPS, add Turnstile to your login and contact forms, and block the paths your site never uses. From this moment most attacks are answered by Cloudflare and not by your NAS. ### Turn on Threat Prevention and forward only what you need On a Synology router install Threat Prevention and let it drop high severity events automatically. Then open the port forwarding list and delete everything except the web ports and, if you run mail, the mail ports. Never forward the DSM management ports or SSH. ### Lock down the DSM administrator accounts In Control Panel disable the admin and guest accounts and create a named administrator. Under Security, Account enforce 2-factor authentication for the administrators group. Under Security, Protection enable Auto Block. Enable the DSM firewall as well. ### Schedule updates, a scan and an offsite backup Let DSM install security updates automatically, or set a reminder if you prefer to update by hand after a snapshot. Run Security Advisor and clear its findings. Finally make sure one copy of the whole system leaves the building on a schedule. A fifth step belongs to anyone who finishes the first four: restrict the web ports at the router to the address ranges Cloudflare publishes. It is the piece of NAS security most often left for later. Until that is done, a proxy is a suggestion. Anyone who learns the real address of the line can walk around it and meet only the inner layers. ## When a NAS Security Rule Hurts You Instead Every rule that stops an attacker can stop a customer, and the failure is silent. These are the three times our own NAS security setup cost us something. In July a rule aimed at crawlers also blocked the checker Google uses to review shopping listings, and 39 product listings were disapproved before we connected the two events. Since then every bot rule makes an explicit exception for verified search crawlers. In September a business customer in the United States tried to pay four times over two days and failed each time without an error on either side. His company routes all web traffic through a cloud security gateway, so to our firewall he looked like the scanners from the August wave and got a challenge in the middle of checkout. Corporate buyers often arrive from the same cloud networks that attackers rent. We narrowed the rule so that people who are already shopping are left alone. And the Threat Prevention engine that performed so well on 2 August stopped passing outbound traffic for our mail server after that same burst. Mail queued until the router was restarted. An inspection engine in the path is one more thing that can fail, and when ours failed, it failed closed. The lesson for NAS security is not to remove layers. It is to write down why each rule exists, look at what it blocked in its first week, and prefer a challenge to a block whenever a real person might be on the other end. ## Backups Are the Layer That Works After the Others Fail No amount of NAS security makes recovery optional. Hardware fails, updates go wrong, and an administrator at one in the morning is more dangerous than most botnets. We keep three kinds of copy: snapshots on the NAS for quick rollback, a scheduled export of the complete virtual machine that is synchronised to cloud storage, and a separate offsite backup of the data. The virtual machine export is described step by step in [VMM backup to Google Drive](/docs/vmm-backup-google-drive-cloud-sync/), and the cluster that hosts all of it in [our 3-node VMM Pro setup](/docs/synology-virtual-machine-cluster-vmm-pro/). ## Limits of This NAS Security Setup This is one small company describing what it runs, not a standard. A few honest limits: Our NAS security depends on Cloudflare. If their network has a bad day, so do we, and the paid plan is part of the monthly cost of the site. It was built by reacting. Most of our rules were written the day after an incident. A larger team would have done threat modelling first, and would have found some of these holes before an attacker did. NAS security needs maintenance. Rules that list specific paths or networks go stale, and a rule nobody remembers is a future outage. We review the list whenever the site structure changes. And it protects a shop, not a bank. If you store health records or card numbers on a NAS, you need more than this article, starting with a professional review. ## Frequently Asked Questions ### Is it safe to host a public website on a Synology NAS? It can be, if the NAS is not the only line of defence. Good NAS security puts the work in layers. Put a proxy such as Cloudflare in front, forward only the web ports, keep management access off the internet and run the site in a container or a Virtual DSM so that a compromised site cannot reach your other data. ### What is the most important NAS security setting in DSM? Disable the default admin account and enforce 2-factor authentication for every administrator. Most successful attacks on a NAS are logins with a guessed or leaked password, and a second factor defeats those even when the password is known. ### What does Threat Prevention on a Synology router do? It inspects traffic passing through the router and compares it with signatures of known attacks. Events are graded by severity, and the router can drop high severity packets automatically. It runs on Synology routers with SRM. ### Do I still need NAS security settings if I use Cloudflare? Yes. Cloudflare only sees traffic that is sent through it. Anything that reaches your line directly, and anything that starts inside your network, never meets those rules. The router and DSM settings are what cover those cases. ### Should I forward port 5000 or 5001 to reach DSM remotely? No. Leave the DSM management ports closed to the internet. Use QuickConnect or a VPN when you need to reach DSM from outside. An open management port is found by scanners within hours and attacked continuously. ### How does Auto Block work in DSM? Auto Block counts failed sign-in attempts per source address. When the count passes the limit you set within the time window you set, DSM refuses further connections from that address. We use ten attempts in five minutes with no expiry. ### Can a NAS security rule block real customers? Yes, and it does so silently. Rules based on network or country can catch buyers behind corporate security gateways or travellers abroad. Prefer a challenge to a hard block for anything a person might trigger, and review what a new rule stopped during its first week. ### Does NAS security replace backups? No. Security lowers the chance of an incident and backups decide what an incident costs. Keep snapshots for quick rollback and at least one copy outside the building, and test a restore before you need one. ## References and Video Walkthroughs - [Synology: how to add extra NAS security](https://kb.synology.com/en-global/DSM/tutorial/How_to_add_extra_security_to_your_Synology_NAS), the official checklist for accounts, firewall and updates. - [Synology SRM Threat Prevention help](https://kb.synology.com/en-global/SRM/help/ThreatPrevention/threatprevention_desc), describing severity levels and the automatic drop policy. - [Synology DSM 2-factor authentication help](https://kb.synology.com/en-global/DSM/help/DSM/SecureSignIn/2factor_authentication), including how to enforce it for a group. - [Cloudflare WAF custom rules](https://developers.cloudflare.com/waf/custom-rules/), the rule language behind the edge layer. - [Cloudflare IP ranges](https://www.cloudflare.com/ips/), the list to allow at your router when you lock the origin. These Synology videos cover the DSM side of NAS security, from the general checklist to the second factor and user permissions. [How to Secure Your Synology NAS | Synology SPOT](https://www.youtube.com/embed/bATSGcrQ_m4?feature=oembed) How to Secure Your Synology NAS [How to enable 2-Factor Authentication in DSM? | Synology](https://www.youtube.com/embed/oLbVhRR0hfI?feature=oembed) How to enable 2-Factor Authentication in DSM [How to Manage User Permissions on Your Synology NAS | Synology](https://www.youtube.com/embed/LihsU5hHm3k?feature=oembed) How to Manage User Permissions on Your Synology NAS More from this series on hosting a business on a NAS: [fixing rejected mail with an SMTP relay](/docs/synology-mailplus-smtp-relay-resend/). Want to separate your own services the way we do? Start with [a Virtual DSM license](https://synopower.club/virtual-dsm-vdsm-license-pack/), or browse all licenses on [SynoPower Club](https://synopower.club/).