wiki:ProtectionOfUnsecuredWebAdminInterface

Context Navigation

Content

General Remark
Affected Releases
Mechnisms to protect the unsecured dCache Web Interface
How to configure the Apache server to relay requests to the …
How to run the httpdDomain as non root user
1. dCache release 1.9.5
2. dCache 1.9.7 and higher

Mechanisms to protect the unsecured dCache web admin interface from misuse

General Remark

In case of questions or remarks concerning the procedure described below, please contact security at dcache dot org only and not any other mailing list or support channel.

Affected Releases

A special protection of the dCache web admin interface is no NOT necessary, when running one of the patch levels listed in the table below. dCache system administrators must upgrade to one of those patch releases. Otherwise your dCache web admin interface must be protected by mechanisms described later in this document.

dCache system administrators must upgrade to one of following patched releases to mitigate the risk.

Secured releases :

Series Secured Web Admin Interface
1.9.5 1.9.5-25 and above
1.9.10 1.9.10-7 and above
1.9.11 1.9.11-4 and above
gLite Not yet applied
EMI - 1 yes (1.9.12 and above)

An interim solution to mitigate the risk is described in following section “Mechanism to protect the unsecured dCache Web Interface”. Please note, the only long term solution to mitigate the risk is to upgrade to one of the patched release.

Remark : Starting with 1.9.10-7, 1.9.11-4 and 1.9.12 (Golden Release) the self written dCache http daemon is replaced by Jetty, a professional http engine. This reduces the risk of a vulnerability in the future.

Mechnisms to protect the unsecured dCache Web Interface

Using your local firewall or the ip-tables system to restrict access to the web interface

The most secure way to protect your dCache Wed Admin interface is to restict access to the dCache http service port (default=2288) to hosts, which are entirely under your control and can't be accessed by the public. This can either be achieved by configuring your site network-firewall or by setting up ip-tables on the httpdDomain host. Please consult your local network operation center or make yourself familar with the ip-table module.

Running an front end Apache deamon.

In case the mechnism above it too restrictive, you can run a dedicated Apache service, relaying requests from public hosts to the httpdDomain. The Apache deamon can either be run on the httpdDomain host itself or on a dedicated machine not allowing public user login. With ip-tables you must only allow access to the httpdDomain service port by that dedicated Apache host. (which might be localhost). Please find some more hints on how to use the Apache redirection mechanism below.

Running the httpdDomain as non-root.

If the httpDomain is running under a non-root user, only those files (on the local file system) can be accessed which permit world read access. This protects all confidential data of the file system but still allows access to files on the httpdDomain computer. Please find instructions on how to run the httpdDomain as non-root user below. Please notice that configuring this feature differs between 1.9.5 and 1.9.7(higher). Both are described below.

Please note that the only real protection of files on the local file system is to upgrade you httpdDomain host to one of the dCache version listed above.

Although each of the mechanisms above give a certain level of protection, the EGI Software Vulnerability Group strongly urges system administrators to apply all of them. Namely :

Step1: Running the httpdDomain as non-root
Step2: Using your local firewall or the ip-tables system to restrict access to the web interface
Step3: Running an front end Apache daemon with access control enabled

Best Practice after the Upgrade to the secured Web Interface

The Software Vulnerability Group recommends sites to restrict access to the web admin interface with firewall even AFTER the upgrade. Off site access to such admin interface by system administrators can be made through either VPN or SSH tunnel.

Details

How to configure the Apache server to relay requests to the httpdDomain

The following Apache configuration has been contributed by Gerd Behrmann, NDGF.

This is the content of a file in /etc/apache2/sites-enabled/. Please replace names in capital letters with some reasonable content.

NameVirtualHost *:2288
<VirtualHost *:2288>
       ServerAdmin YOURNAME@YOURDOMAIN
       ServerName THISHOST.THISDOMAIN

       SSLEngine On
       SSLCertificateFile /etc/grid-security/hostcert.pem
       SSLCertificateKeyFile /etc/grid-security/hostkey.pem
       SSLCACertificatePath /etc/grid-security/certificates/
       SSLCARevocationPath /etc/grid-security/certificates/
       SSLUserName SSL_CLIENT_S_DN
       SSLVerifyDepth 5
       SSLVerifyClient require

       DocumentRoot /var/www
       <Directory />
               Options FollowSymLinks
               AllowOverride None
               SSLRequireSSL
       </Directory>

       ErrorLog /var/log/apache2/error.log

       # Possible values include: debug, info, notice, warn, error, crit,
       # alert, emerg.
       LogLevel warn

       CustomLog /var/log/apache2/access.log combined
       ServerSignature On

       ProxyRequests off

       <Proxy *>
               Order allow,deny
               Allow from all
       </Proxy>

       <Location /srmwatch>
               ProxyPass http://localhost:8180/srmwatch/
               ProxyPassReverse http://localhost:8180/srmwatch/
       </Location>

       ProxyPass / http://DCACHE_WEB_HOST:2288/
       ProxyPassReverse / http://DCACHE_WEB_HOST:2288/
</VirtualHost>

How to run the httpdDomain as non root user

dCache release 1.9.5

The steps are

Create the 'dcache' user under which the httpdDomain will run. Make sure 'dcache' doesn't have any particular permission except reading 'world readable' file.
Shutdown the httpd Domain
Break the link between the httpdSetup file and the dCacheSetup
Edit the httpdSetup file, setting the 'user' property to 'dcache'.
Change the ownership of the 'billing' directory structure to 'dcache'.
Restart the httpd service.

The details :

#
# create the 'dcache' user.
#
useradd dcache
#
#
# These examples assume that you have installed dCache 
# in /opt/d-cache. Please adjust the command accordingly 
# if this is not the case.
#
# prepare for 'dcache' commands.
#
PATH=/opt/d-cache/bin:$PATH
#
# check if the httpdDomain is actually running on this host.
$
[root@httpdhost bin]# dcache status
Domain                   Service          Status

httpdDomain              httpd            running

  and more

#
# Stop the httpd domain
#
[root@httpdhost bin]# dcache stop httpd
Stopping httpdDomain (pid=15195) 0 1 Done
#
# unlink the httpdSetup file
#
rm -rf /opt/d-cache/config/httpdSetup
#
cp /opt/d-cache/config/dCacheSetup /opt/d-cache/config/httpdSetup
#
# Edit the httpdSetup file. (This is now a file and no longer a link)
# Edit the line 
#     '#user=' and replace this line with 'user=dcache'
#
#
# Find your 'billing' directory.
#
grep '^billingDb=' httpdSetup
#
#   e.g. :
#
billingDb=${ourHomeDir}/billing
#
# Recursively change permission of the billing directory tree.
# ! assuming ourHomeDir is '/opt/d-cache'.
#
chown -R dcache /opt/d-cache/billing
#
# Restart the service
#
[root@httpdhost bin]# dcache start httpd
#

dCache 1.9.7 and higher