How to make your Synology Disk station (NAS) more secure?


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:

  1. VPN Virtual Private Network – to remotely access the local area home network
  2. SSH Secure Shell – for secure login as root user or admin to fully access the (embedded) operating system
  3. SSL/TLS – to secure traffic between website and browser (HTTPS)
  4. Enable 2-Step Verification for DSM web access
  5. 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

  1. Root certificate ( self signed, will replace ca.crt), a
  2. Server certificate (to replace server.crt) with the
  3. Server key (server.key), and a
  4. Client certificate (user.crt) with the private
  5. 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 cacert and key with

ca /var/packages/VPNCenter/target/etc/openvpn/keys/your_ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/your_server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/your_server.key

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:
remote-cert-tls server
#verify correct server name:
verify-x509-name ‘’ 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:

#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>
auth SHA1

#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

SSH Host

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

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

  1. Open the registry (regedit)
  2. Go to HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys

Delete the cashed key.

SSH Client

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.

#AuthorizedKeysFile .ssh/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
PasswordAuthentication no

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

Rate this post

13 thoughts on “How to make your Synology Disk station (NAS) more secure?”

  1. 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е. Great job.

  2. 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.

    1. Client:

      dev tun
      verb 2
      # Proxy
      ;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

      port 8080
      proto tcp-client

      script-security 2

      #Root certificate (your root sertificate - self signed)
      ca ca.crt
      #type of certificate has to be server
      remote-cert-tls server
      #verify correct server
      verify-x509-name '' name

      #client certificate (when using pkcs12 format from memory card)
      ;pkcs12 F:/pki/private/user.p12
      #client certificat (in config directory)
      ;cert user.crt
      ;key user.key
      #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"
      auth SHA1
      #login with user name - password
      auth-user-pass F:/pki/private/credentials.txt

      reneg-sec 0

    2. Server:

      push "route"
      push "route"
      dev tun

      management 1195

      dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
      ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
      cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
      key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key

      max-clients 5


      verb 3
      #log-append /var/log/openvpn.log

      keepalive 10 60
      reneg-sec 0

      plugin /var/packages/VPNCenter/target/lib/ /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf

      status /tmp/ovpn_status_2_result 30
      status-version 2
      proto tcp6-server
      port 8080

    3. For DSM 6 I had to add the server certificate under Control Panel -> Security -> Certificate and configure VPNServer-OpenVPN to use it.

      1. 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?

  3. 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 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 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.

  4. Hi!
    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 ( 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…

    1. Hi Lasse,
      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.

  5. 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/.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.