Restricting Access to Web Applications in Synology DSM

Synology storage systems are a fairly common thing now. They are comfortable, quiet, compact, with lots of features. However, own cloud is good, but you need to think seriously about security. Next, we look at how to flexibly restrict access to Synology's custom web applications. We will use x509 authentication with certificates, name and password and IP address restrictions.

DSM has 2 types of web-based applications:

• system (the desktop itself, PhotoStation, VideoStation, TimeMachine, etc.)
• custom Work when the WebStation service is enabled. For example: dokuWiki, mediaWiki, RSS reader, etc.)

The simplest protection against access from the outside is to transfer the application to a non-standard port. With system applications, this is easy to do - there are corresponding settings in the control panel.

With user a little more complicated, moreover, sometimes you want to leave them on the standard 443 port, accessible via the HTTPS protocol (it makes sense to refuse to use HTTP at all).

So, I will describe some kind of "life" configuration. Given:
')
- Synology DSM 5.2-5592 Update 4
- The WebStation service is enabled, running on it:

• DokuWiki (Wiki with its internal users)
• Tiny RSS (RSS reader)
• Cops (Electronic Library Catalog)

- Access to the DSM itself is possible outside and from the internal network.

It should be noted that the level of trust in DSM system applications is quite high - system security updates are released frequently. What can not be said about user applications. In my opinion, it is their (potential) vulnerabilities that pose the main security threat to the entire system and user data of a particular application. Therefore, access to them must be limited. Again, some applications do not imply any authorization or differentiation of access rights to their data, relying on the use only in the internal network.

We will restrict access as follows:

DokuWiki - free access from the internal network. Outside access only with certificate. The apache mod_ssl module is used. Then comes the internal authorization system. As I wrote above, in DokuWiki their own users and their own system of rights to access articles.

Tiny RSS - free access from the internal network. Outside access only with certificate. The apache mod_ssl module is used. No further means of restricting access is required.

Cops - free access from the internal network. Out of access by name and password. The apache module mod_auth_digest is used. It is understood that all kinds of “e-books” can be connected from the outside and I am not sure that it is possible to upload a user certificate to them and use it in a web browser.

Thus, various modules of the Apache web server are used to restrict access.

Now implementation, we will configure authorization on certificates

The idea here is that only a user who has a certificate signed by our CA has access to a certain part of the site.

1. We need to create a self-signed CA (Certificate Authority) and use it to create a client certificate. How to do this I will not describe - there are many instructions, for example: www.opennet.ru/base/sec/ssl_cert.txt.html , and surely some already have their own CA, which can be used for our purposes. Yes, and to meet the realities, we will slightly complicate the task and add an intermediate CA, i.e. make a chain: Root CA - Intermediate CA - client:
   1. Create a self-signed RootCA.crt
   2. Create InterCA.crt, signed by RootCA.crt
   3. Create client: client.crt, signed by intermediate
   4. From the created certificates we do bundle with the command: cat RootCA.crt InterCA.crt> ca-bundle.crt
   5. Copy ca-bundle.crt and InterCA.crt on Synology to the /usr/syno/etc/ssl/ssl.crt/ folder
2. Edit the corresponding apache config (/etc/httpd/conf/extra/httpd-ssl.conf-cipher), add the lines to it:
   

   SSLCACertificatePath "/usr/syno/etc/ssl/ssl.crt" #       SSLCACertificateFile "/usr/syno/etc/ssl/ssl.crt/ca-bundle.crt" #     ,    SSLCADNRequestFile "/usr/syno/etc/ssl/ssl.crt/InterCA.crt" 

   
   
3. Customize DokuWiki. Create the /volume1/web/dokuwiki/.htaccess file or add to the existing lines:
   

    #  mod_revrite ,      . SSLVerifyClient require <IfModule mod_rewrite.c> #    SSLVerifyClient optional #  . ..   bundle   2 -    . SSLVerifyDepth 2 #  :       RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS$ #  :       192.168.1.x RewriteCond %{REMOTE_ADDR} !^192.168.1.[0-9]*$ #     -     403 RewriteRule ^ - [F] </IfModule> 

   
   
4. Restart the httpd-user service with the command: synoservicectl --restart httpd-user
5. With DokuWiki everything.
6. Similarly, we prescribe .htaccess for TynyRSS

Then we will configure authorization by password-name:

1. Create a file with users and passwords with the command: / etc / httpd / passwddg -c / etc / httpd / passwddg “Books Library” book. Thus, the user bookuser will be able to connect to the service. Please note that if you add other users to the same file, you must remove the –c key, otherwise the password file will be overwritten!
2. Customize Cops . Create the /volume1/web/cops/.htaccess file or add it to the existing lines:
   

    #       PHP .  . <FilesMatch "\.php$"> Order allow,deny #       192.168.1.x Allow from 192.168.1 #  Digest  AuthDigestProvider file # ,          AuthUserFile /etc/httpd/passwddg AuthType Digest #   ,         AuthName "Books Library" #     ,   Require valid-user #        . #    IP    , #       Satisfy Any </FilesMatch> 

   
   
3. Restart httpd-user service: synoservicectl --restart httpd-user
4. C Cops, too, everything is ready!

A few words about the authorization methods used

auth_digest: replaced auth_basic and differs from its predecessor in that the password is not transmitted in clear text, so it can be used over HTTP.
SSL: as part of the mod_ssl module. Main: everyone who will have a client certificate signed by our CA will have access to the necessary applications.

How can authorization be improved with certificates?
- It is possible to use different CA for different applications
- You can allow user access based on different certificate fields
- You can issue a client certificate for a short period - for example, a week or a month
- It is possible (even necessary) to add to the configuration the path to the CRL (list of revoked certificates) for the quick blocking of individual users
- Client certificates can be locked with a password and / or stored on USB eToken

Successful setting!