Hardening of Digital Access component appliance

During the installation, Digital Access component installs the OpenSSH server for communication from outside. A Postgres database is installed and only used for local communication. Connections from outside are disabled by default.

During the installation, the default firewall of Ubuntu is applied. Only features that comes by default with the corresponding Ubuntu base image (currently 20.04) are available within the Digital Access component appliance, including:

• Simple Network Management Protocol (SNMP)
  SNMP is configured to send information related to its services and system health. However, by default it does not send information to any location as it does not know who the recipient would be. For this, the customer needs to un-comment the trapsess command in the file /etc/snmp/snmpd.conf and point it to their SNMP manager to start sending information.

• Systemd-Timesyncd Service
  Systemd-Timesyncd is installed and set to 0.ubuntu.pool.ntp.org as default. You can change the value over the VM wizard.

If Digital Access component is configured to use an external database for users, reporting and OATH, the internal Postgres database service can be turned off without any hassle.

Important

To improve the hardening index of Digital Access component, an SSH configuration parameter (MaxAuthTries) was introduced with Digital Access component version 5.13.0. This configuration parameter limits the maximal authentication attempts to the amount of two. This change can affect the SSH authentication, if the client has more than one private key configured that is not configured for the corresponding user in Digital Access component. In this case, an authentication with username and password will fail. If this setting affects you, you can increase the amount of authentication attempts.

To increase the amount of authentication attempts:

1. Change the parameter
   MaxAuthTries within the file /etc/ssh/sshd_config to a suitable number.

In case of Digital Access component upgrades, this change has to be done after the appliance has been upgraded successfully.

All services in Digital Access component inside the Docker containers are run by a separate user named pwuser. Authentication from outside is not allowed with that user. For authentication from outside, the user agadmin is created during installation.

Writing permissions to Digital Access component-related files are restricted to power users, such as pwuser and root.

Because of security reasons, the passwords of pwuser and root can be changed after installation. To do this, use sudo access of agadmin or root. The pwuser could still not be used to authenticate from outside after this change. All passwords are saved as part of the default location of passwords. 

Change root password

1. To change the root password:

   1. Type the following command to become root user and issue passwd
      sudo -i passwd

   2. or set a password for root user in a single command
      sudo passwd root

With every release of Digital Access component, all binaries are updated to the latest versions to prevent security vulnerabilities as much as possible. Therefore, vulnerabilities like Spectre and Meltdown are taken care off as soon as updates are available. A steady release cycle ensures prompt security updates. 

Once Digital Access component is deployed as virtual appliance, the customers have to make sure that security updates get applied on a regular basis. 

The communication between Digital Access component nodes is secured with a Nexus proprietary protocol called LCP. The protocol is based on length, type and value. LCP uses a shared secret which is initialized during the system setup. Once the secret is shared among all the registered nodes the secret is never shared again. Although, it is possible to update the secret time-to-time for security purpose. To update the secret, use one of the two following methods:

• Setting the secret manually into each node.

OR

• Distribution via Digital Access Admin for particular nodes. The secret will be sent to the nodes using LCP protocol, protected with the previous secret.

The following types of data are encrypted over LCP:

• Shared key hash in Server/Client Hello

• SSO credentials

• Authentication credentials

• Encryption key used when importing a PSKC file

On a regular basis, Nexus instructs specialized, external companies to perform penetration tests on the latest versions of Digital Access component, to ensure that it maintains it high security status.

Critical vulnerabilities found by PEN testing will be fixed as soon as possible and released with the next version (or an interim version if required).