Recently I bought the network attached storage (NAS) DS1513+ from Synology and integrated it into my home network in order to have a central place to store and access my data. This NAS has several server functions, making it convenient to access data remotely, but also making it vulnerable to unauthorized intrusion. So the question arises, how to mitigate this risk without restricting the remote functionality of the NAS. There is a lot of information available in the web; yet for me it took some time to identify and understand the most important modifications and to implement them:
- VPN Virtual Private Network – to remotely access the local area home network
- SSH Secure Shell – for secure login as root user or admin to fully access the (embedded) operating system
- SSL/TLS – to secure traffic between website and browser (HTTPS)
- Enable 2-Step Verification for DSM web access
- Store all critical data (certificates and private keys) on an encrypted memory card
1. VPN Virtual Private Network
Whenever possible, use VPN to access your NAS. I decided for the openVPN protocol, as it will work under Windows and iOS and allows for a flexible configuration of ports, protocol and authentications. The standard port for openVPN is 1193 UDP. I changed it to 8080 TCP in order to have the possibility to tunnel through firewalls.
Necessary steps and modifications
- Install Synology VPN server and use openVPN to remotely access your disk station and local network.
- Generate your own set of certificates using EasyRSA or OpenSSL.
- Change the VPN server configuration to make authentication with client certificates mandatory
- Ensure verification of server certificate and server name on the client side.
For openVPN I use self-signed certificates. All server and client certificates can be generated using EasyRSA and OpenSSL.
You need to generate a
- Root certificate ( self signed, will replace ca.crt), a
- Server certificate (to replace server.crt) with the
- Server key (server.key), and a
- Client certificate (user.crt) with the private
- Client key (user.key).
Root and server certificates, as well as the server key, are found in the directory /var/packages/VPNCenter/target/etc/openvpn/keys/. Login to the Synology NAS as root user, using a terminal program, change to this directory and place your own certificates and server key there. Rename the original files ca.crt, server.cer and server.key before copying, to keep them as backup.
On the client system under Windows, the client certificate can be imported with the command (“run”) certificate manager certmgr.msc, or it can be part of the openVPN client configuration file using <cert> </cert> and <key> </key> (necessary for iOS).
OpenVPN Server configuration (DSM 5.2)
Then change the authentication procedure for openVPN and make the use of a client certificate and password mandatory. The openVPN server configuration file can be found under /usr/syno/etc/packages/VPNCenter/openvpn. Use vi editor in the BusyBox build-in shell to modify the openvpn.conf file.
Replace the lines starting with ca, cert and key with
Then comment out (#) the line client-cert-not-required:
OpenVPN Client configuration
On the client side use the following lines in your openVPN client configuration file:
#Root certificate (self signed)
<ca> Copy and paste your ca root certificate here </ca>
#verify type of certificate to be server authentication:
#verify correct server name:
verify-x509-name ‘xxx.com’ name
#either get client certificate in pkcs12 format from an encrypted memory card:
pkcs12 Y:/pki/private/[user name].p12
#or get client certificate using Microsoft crypto api for windows PCs:
cryptoapicert “THUMB:XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX”
#or for iOS devices copy/paste public and private part of the client certificate:
<cert> copy/paste client certificate here </cert>
<key> copy paste your client key here </key>
#login with user name – password
2. SSH – Secure Shell
With SSH root login you have full access to the embedded OS and can modify any configuration of the NAS. Therefore, if you really need to allow SSH access remotely, you should always be extremely careful and verify the correct connection. In addition the login should be changed from user name/password authentication to RSA key authentication. SSH works under windows with Pageant/Putty, on iOS devices I use iTerminal Pro.
Necessary steps and modifications
- Always verify server fingerprint of your SSH host
- Change SSH standard TCP port 22 to a high port number
- Replace user- password log in with RSA key authorization
The ssh server (host) keys can be found in the directory /etc/ssh. By default there are key pairs for DSA, ECDSA and RSA. The public key files have the extension .pub. Note down the fingerprint of the host keys using the command ssh-keygen -l -f [public key file name], for example ssh_host_rsa_key.pub
When you call the SSH terminal program and the server key is not cashed, you will be prompted with the fingerprint of the server key to trust the server. To delete a cashed fingerprint under Windows using PuTTY
- Open the registry (regedit)
- Go to HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys
Delete the cashed key.
First generate an RSA key pair (public and private) with the program puttygen. I use an SSH2-RSA key with 2048 bits. By default the public key of the root user is expected to be found in the directory /root/.ssh/ under the file name authorized_keys.
So you need to create the directory .ssh and put the public key, generated with puttygen, into this directory under the name authorized_keys.
In order to disable password login for the root user, you then need to modify the file sshd_config in the directory /etc/ssh. Change the line
#PasswordAuthentication yes to
3. SSL Secure Sockets Layer – to secure traffic between website and browser (HTTPS)
Though SSL does not protect from unauthorized access, it helps to avoid eavesdropping of your data when using the web interface. Most critical is the web access to the disk station manager with admin rights. The standard access ports are 5000 (HTTP) and 5001 (HTTPS).
Steps and modifications
- Disable standard admin user account
- Allow access via HTTPS only
- Use a really strong password with 15 characters or more
For administration via web interface disable the standard admin account and use a different user name first. Then allow DSM login under https (default port 5001) only, in addition you could use port forwarding in your router to change to a high port number). The most important measure is to use a really strong password. The password should be at least 15 characters long and consist of a mixture of small/capital letters, numbers and special chars.
4. Enable 2-Step Verification for DSM web access
DSM allow to introduce a second layer of authentication. You can enable 2-step verification for the admin user. A good step-by-step description can be found 2-step-authentication.
5. Storage of critical Data
All measure shown above will be useless, if the private keys are not kept secret. Your passwords, key pairs and certificates should never be made accessible to any unauthorized users. Here I use a mountable encrypted memory card. When leaving the computer I can unmount the card or take it with me.
6. Useful links
How to connect to Synology’s VPN Server using a Windows PC or Mac https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Application/How_to_connect_to_Synology_s_VPN_Server_using_a_Windows_PC_or_Mac
13 thoughts on “How to make your Synology Disk station (NAS) more secure?”
___123___How to make your Synology Disk station (NAS) more secure? – BPMSG___123___
What’s Hapoening i’m new to this, I stumbled սpon tһis
Ӏ’ve found It aƄsolutely helpfl ɑnd it һas aided me
᧐ut loads. Ӏ am hoping tο contribute & aid ᧐ther uѕers lijke its
aided mе. Gｒeat job.
hello!,I like your writing so much! proportion we communicate extra approximately your post on AOL?
I need an expert in this space to resolve my problem. Maybe
that’s you! Having a look forward to see you.
can you please post openvpn.conf for the server and client?
;http-proxy yourproxi 80 stdin basic
# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# All traffic through VPN
# dhcp-option DNS: To set primary domain name server address.
dhcp-option DNS 192.168.1.254
#Root certificate (your root sertificate - self signed)
#type of certificate has to be server
#verify correct server
verify-x509-name 'yourserver.com' name
#client certificate (when using pkcs12 format from memory card)
#client certificat (in config directory)
#client certificate (using Microsoft crypto api: thumbprint of certificate)
cryptoapicert "THUMB:xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx"
#login with user name - password
push "route 192.168.1.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
management 127.0.0.1 1195
server 10.8.0.0 255.255.255.0
keepalive 10 60
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
status /tmp/ovpn_status_2_result 30
For DSM 6 I had to add the server certificate under Control Panel -> Security -> Certificate and configure VPNServer-OpenVPN to use it.
Thanks, with some work and all your tips I was able to make it work.
How do you force client to surf via the server IP address and not directly from the client local IP address?
use “redirect-gateway” in the config file.
Nice and concise write up on a topic I’d love to know better! Thanks.
I focused on the OpenVPN setup trying to avoid password-only auths.
I stumbled with creating the keys/certs since so many options exist. Would be very helpful if you showed the openssh commands to create/request/sign keys/certs that will work synology. For instance, I created keys with passwords, which I think broke it for me. Is the process for server cert different than user certs? And what about the subj/CN? Does it need to match anything on synology or across all the ca/server/user keys&certs being created?
Oh, a quick note of how the client user key/cert gets accepted would be nice. I see the user key/cert are only on client, and maybe being signed by the ca.crt lets the entered username/password login through? I kind of assumed that like ssh, that the user key/cert would be on server somewhere.
About the syno keys, you’d mentioned “Rename the original files”, but it looks like you renamed the new files in your example “your_ca.crt”. I favored the approach of leaving the original files in place, and creating a subdirectory for the new files, so the file names could all remain generic. Ex: ca /var/packages/VPNCenter/target/etc/openvpn/keys/your/ca.crt
I found that the ca.crt and server.crt files exist in several locations across the diskstation. I found them in /usr/syno/etc/ssl/ssl.crt/, /usr/syno/etc/packages/VPNCenter/openvpn/keys/, /volume1/@appstore/VPNCenter/etc/openvpn/keys/. That’s another reason why I wanted to leave the original files in place with original names. Oh, and while some symlinks existed in the openvpn packages path, all of these seemed to be duplicate files. In my experiments I tried to leave the other key/cert files alone, though I suspected that it might be best to replace them all with the new files.
I found importing a new server.crt/server.key with DSM/ControlPanel/Security/Certificates seemed to mess things up a bit (my new keys/certs seemed to be less trusted). Rather than pursue that, I reverted by importing the original server.crt/server.key files that came with the device. I also then went to each directory above to make sure all the server.crt/server.key files were back to the originals.
I tried to modify the openvpn.zip file so that DSM would give me a pre-configured file. Ends up this file is created each time you click “Export configuration” in the OpenVPN app. I gave up on that since I didn’t want to modify too many original files on the synology. If I replaced all the certs/keys, and the original openvpn.ovpn file in place, the openvpn.zip file would have taken my changes.
As I was doing a rebuild, I was able to determine that the ca.crt, ca.key, server.crt, server.key files that originally install on the synology box are unique with each install. I ended up grabbing those files and just generated new user keys/certs. In the end I didn’t need to change any of the keys/certs on the synology, just tweak the server openvpn.conf and install the user keys/certs in the client side openvpn.ovpn file. I’m exhausted now, but if I wanted higher grade or differently created keys, I assume I could generate the new keys/certs with more bits and actually do the file replacements.
Also, for everyone to note… MAKE SURE YOU HAVE BACKUPS of all the files you change. In each directory I work in, I usually “mkdir orig” and copy files in there before modifying them.
I’m thinking of buying a Synology NAS but when I read that you can reset the NAS and the admin password with a simple press of a button (https://www.synology.com/en-us/knowledgebase/faq/410) that didn’t feel too secure. Or have I misundertod something? What do you think? The steps above might as well protect from this but the point it out for me so I understand…
you can reset, but only on the hardware. That means you need physical access to the disk station. What I describe above is for remote access.
I have modified the post for DSM version 5.2 On my NAS (DS1513+) openvpn on port 443 was no longer working. I had to move to another port (recommendation: use port 8080, as it is open on most firewalls). Your own certificates can no longer be placed in a user directory, but need to be under the directory /var/packages/VPNCenter/target/etc/openvpn/keys/.