UNICORE Hardening Guide

If a site does not accept publicly available certificates, site administrators can be sure who is accessing their resources. Accepting the publicly available demo certificates only authenticates these certificates, but no individual user.

A similar thing holds for clients, that cannot be certain about the identity of a server, if they accept demo certificates.

As a general rule it is always good to deactivate unused services. So if you don’t intend to monitor or manage your server using JMX, then deactivate it. JMX usually listens for connections at two levels: locally on a socket, and on the network. Listening on the network can easily be disabled by commenting the respective lines in the server startup script bin/start.sh.

Current UNICORE installations (>=6.4.x)disable JMX via network, if the port is unset.

which is later on used to enable or disable JMX

Older installation (⇐6.3x) have a slightly different setup.

The most relevant setting here is -Dcom.sun.management.jmxremote. This must not occur in the Java command line.

If you need to avoid local JMX connections, then the following unsupported setting may help (Source: http://stackoverflow.com/questions/1255049/disabling-local-jmx-connections-on-jvm). It needs to be added to the Java command line, i.e. the OPTS variable.

If you want to leave JMX activated, we strongly suggest the following settings to secure the service.

JMX service passwords are usually configured in the jmxremote.password file in the conf directory of the respective component. If you are using packaged installations provided for some Linux distributions, these files are located in /etc/unicore/<component>/jmxremote.password.

Two roles are defined in this file: monitorRole and controlRole. Each of these has a password associated with it. Change them to be unique, even a randomized string is better than the default passwords.

At the moment, it is only possible to secure the Registry against unauthorized entries by untrusted clients or services. In the uas.config file of the registry, set the following property to true.

This setting requires the server to be registered in an attribute source for the registry. A variety of attribute sources can be configured in UNICORE. As the registry usually comes with no attribute sources configured, the easiest way may be to use a plain file for this. This is described in the following. These changes are required in the uas.config file:

The uas.security.attributes.FILE.file property references /etc/unicore/registry/simpleuudb, which should contain an entry for each of the service containers that should be allowed to add or update entries in the registry. The role for each of these entries must be server.

The DN needs to be put in RFC2253 notation, which can be retrieved using openssl on the certificate file (PEM):

Put multiple entry elements for multiple servers.

If you are already using an XUUDB or UVOS service as an attribute source, you can configure this analogous to the UNICORE/X configuration of attribute sources. Don’t forget to add the required certificates or DNs to the XUUDB or UVOS and give them the server role (set attribute role to server).

Allowing only registered services to add entries in the registry avoids this problem of arbitrary services being advertised to the user or malicious users removing valid entries from the registry.

This counter measure is only really effective in conjunction with [gw_connection].

The UNICORE/X can be configured to request signed consignor assertions, checking the signatures with the Gateway’s public key. Thus, even if the service container can be reached via the network, it will be impossible to send "fake" consignor assertions without knowing private information of the Gateway.

The respective setting in the uas.config file is:

The Gateway needs to be configured to sign consignor assertions in its gateway.properties file:

The Gateway certificate for verification is established at server startup when the UNICORE/X connects to the Gateway for the first time.

If you want to configure the precise Gateway certificate that will be accepted, then you can place it in a the truststore file and set the alias with the following setting in uas.config:

If you are really paranoid, you could additionally secure the services against connections from entities other than the gateway by restricting access to the ports at the network level, e.g. only allow connections on the respective port from the gateway machine.

This Linux IPTables line may serve as an example:

Beware that the exclamation mark (!) needs to be escaped in some shells.

Only allow UNICORE admins to use particular parameters when acting as root. This can be achieved by restricting the set of parameters allowed to be passed to specific TSI scripts in the /etc/sudoers file.

This would disallow the tsi-admin user to pass any arguments to the kill_tsi script, thus only allowing to kill the TSI installation residing in /opt/unicore/tsi. Similarly, in case multiple TSIs are running on the same machine, one could restrict the user to kill only particular ones.

In this case, tsi-admin2 can kill two TSIs, while tsi-admin1 can only kill one of them. Of course, similar entries would have to be made for starting TSIs.

Create a configuration file for CRL checking and reference it at application startup as a system property. The full documentation is available in the Gateway documentation. Any component using UNICORE security libraries is capable of supporting CRL checking.

Clients can benefit from checking CRLs as they can recognize whether server certificates have been revoked.

Update Java to the latest version, at lest JRE 6 update 24 to the best of our knowledge.

JRE 6 update 24 and subsequent versions do not contain the vulnerability.