- Created by Karolin Hemmingsson (Unlicensed), last modified by Ann Base on Dec 22, 2021
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 9
Smart ID Digital Access component is shipped as a virtual appliance that uses an Ubuntu base image. If Digital Access component is deployed on a customer Docker host (not as virtual appliance), hardening has to be under control of the customer itself.
With every release of Digital Access component this base image is hardened in different areas:
- Only installing required software and services
- Restricted user management
- Continuous security updates
Once the appliance is deployed in the customer environment, upgrade of Digital Access component will only happen to the Docker containers inside. That means that after deployment, the customer is responsible for maintaining the virtual appliance and the operating system inside.
Read more about how to deploy here: Deploy Digital Access component.
The following topics only apply for appliances that get's created with each new Digital Access component release. Already deployed appliances are not changed afterwards.
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 thetrapsess
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:
- 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
- To change the root password:
- Type the following command to become root user and issue passwd
sudo -i passwd
- or set a password for root user in a single command
sudo passwd root
- Type the following command to become root user and issue passwd
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).
This article is valid from Digital Access 6.0.0 till 6.0.3
Related information
- No labels