Over the past few months, I ran a test with two Synology NAS devices to see exactly what can be done to improve the overall security of them. Out of the box, Synology devices aren’t set up in a way that would be considered insecure, but as we start to configure the NAS, there are things that can be done that will either increase or decrease the overall security of the device.
Introduction to the Security Test
To highlight how some of these security features work, I set up a completely isolated network with two different DSM instances – one with the default port 5001 and one with a customized port 6751. I then exposed both NAS devices to the external internet – there wasn’t a firewall configured, and there were no actual differences in DSM other than the port.
After three months, the Synology device with the default DSM port 5001 was attacked almost every minute. This is where things started to get interesting and I think there’s a lot that we can learn here, so let’s break down some of these findings.
Method of the Ransomware Attacks
The only account that was used by the attackers was admin. So technically, if the admin account was disabled, the attackers wouldn’t actually be able to authenticate.
The other thing is that the attacks weren’t as frequent as I expected. Initially, I thought there would be multiple attacks per second to try and brute force the account and that is NOT what happened. Instead, there would be one login attempt roughly every 60 to 90 seconds.
These login attempts mostly came from different IP addresses, so there was not a single IP address that was blocked from Synology’s built-in auto-block feature, which I find to be interesting and I will explain in a little bit. The important thing here is that we can try and use this information to increase the overall security of the device.
Securing a Synology NAS Based on the Attack Information
First, and most obvious. Don’t expose the NAS to the external internet. If the NAS isn’t accessible to the external world, there wouldn’t be any login attempts and the overall security of the device would be exponentially better…but telling you to only do that wouldn’t be a very good article, especially because there are things like UPnP that exist which can port forward the DSM port to the external internet without the admin of the device even knowing about it.
If you want to test to see if it’s accessible by the external world, use a port checker with the DSM port and if it’s open, you need to close the port on your router.
Step 1: Disable the Admin Account
You must ensure the admin account is disabled. This was the only account that the attackers attempted to log in with, so disabling it means that outside of a separate security flaw with the login authentication process itself, they would never be able to log in because the account they’re attempting to log in with is disabled.
You’ll receive a warning when logging into DSM 7 that the admin account should be disabled, and this is the main reason why. So if you’re using the admin account, create a new user that will be your admin user, then disable the admin account.
Step 2: Configure Auto Block Correctly
Auto block should be enabled, but the default settings need to be modified. At least when looking at this small sample of the attacks.
The attacks came in by different IP addresses all within 60 to 90 seconds, so with the default auto-block settings, there was never an IP address that was blocked. What this tells us is that if you’re directly getting attacked, meaning someone knows your NAS is exposed and is attacking from a single location, as long as they attempt to log in based on the login attempts and minute settings that were configured, they will be blocked.
However, for bot attacks which is what I was experiencing, they’re sophisticated enough that the default auto-block settings are fairly useless. Proof being that after 4 months of being attacked basically every single minute, there wasn’t a single IP address blocked.
So how can we improve auto block? First, you have to ensure that your subnet is whitelisted. In the allow/block list, create a new entry for either your entire subnet or use an IP range. These should be local IP addresses so that you can never indirectly block yourself. Just keep in mind that you’re whitelisting indirect attacks, meaning that if a device is compromised on your network, it’ll have unlimited attempts. If you have multiple subnets that access the NAS, you must create one line for each of them.
Once that’s done, we have to talk about the auto-block settings. Using the information from the attacks, we have a few interesting conclusions that we can draw. First, there were a few examples of 2-3 login attempts within a few seconds.
The majority of them weren’t though, and ranged from 6 hours to multiple days.
So we have two ways that we can handle this, assuming you set up your allow list correctly which like I said, must be done to avoid indirectly blocking yourself.
The first option is to set the login attempts to 1. This will allow your local subnet to have unlimited login attempts since it’s in the allowed list, but everything else will be blocked immediately. With the sample of the data gathered, using this approach, every single one of the IP addresses would have been blocked on their first incorrect attempt.
Option two is to increase the minute setting. If you change this setting to 10,080 and keep the login attempts at 2, this would mean that if a single IP address attempts to log in more than once in one week, incorrectly, they will be blocked.
You can always increase these numbers to be longer as well on either the login attempts or total minutes, but from the information I gathered, almost all of the login attempts seemed to be within 7 days.
To be clear, I’m not saying you should do this, but I am saying that these bot attacks were sophisticated enough that this is the only defense you have in terms of actually making this feature work as expected. This is something that I have always suggested is enabled, but quite honestly, isn’t something that I knew had to be customized so drastically.
I thought the default values would be fine, but they’re not. so assuming you set this up right, you’ll never block anyone on your local network, but if you were getting attacked by bots this way, they’ll be blocked from this feature.
Step 3: Change the Default DSM Port
Remember, at the beginning of the article, I said that there were two instances exposed to the external internet. One with a customized DSM port of 6751 and one with the default port 5001. The device with the customized port did not receive a single login attempt in the same exact timeframe as the device with the default port. Change the DSM Port by navigating to the Control Panel > Login Portal > DSM Ports.
This small change allowed the NAS to be exposed to the external internet for over 4 months without receiving one login attempt. I know, if you’re not exposing the NAS to the internet, there’s no reason to change the port, but security through obscurity is a thing and this is proof. I suggest changing the default port.
Step 4: Configure Two-Factor Authentication.
Assuming two-factor authentication is configured for all of your devices, even if someone successfully authenticates, they’ll need a second factor to access DSM. This should be configured, at minimum, for all admin user accounts and is a best practice.
Step 5: Configure Snapshots and Backups
The data stored on NAS devices is generally important, and the only way to recover from any sort of data loss is to either restore the data through a snapshot or backup. Make sure you’re using Btrfs if you can, and enable a snapshot schedule for each shared folder.
You can even enable immutable snapshots if you’d like, but keep in mind that immutable snapshots cannot be deleted until the protection period expires.
Next, set up Hyper Backup to back up somewhere. In a perfect world, it would be backing up offsite, but something is better than nothing, so if you want to use an external hard drive, use that. Just make sure that in some way, you have backups that you can restore from. These are data integrity best practices and paired with some of the security changes we just made, should protect you.
Final Thoughts & Conclusion on Protecting your NAS
There are other things you can do to secure your NAS and I have an in-depth Synology NAS security guide that you can follow, but even though the NAS shouldn’t be exposed to the internet, these changes are harmless and in my opinion, should be considered as best practices for every setup.
