Security

opsi is a powerful tool for the administration of many clients.

According to that fact, the 'opsi-Server' has to be in the focus of security considerations.

If you control the 'opsi-Server', you are in control of all the clients, that are connecting to that 'opsi-Server'.

How much time and money you should spend for hardening your 'opsi-Server', depends on your needs regarding security and the operational environment for using opsi. So for example an 'opsi-Server' in the 'cloud' is more endangered than an 'opsi-Server' in a secured network.

In the following chapter we have collected the most important issues and problems.

At this point we say 'thank you' to all customers and users which informed us about security problems and helped us to improve the security of the opsi system. If you find any security problem, please inform us (info@uib.de) before disclosing the security vulnerability in public.

Information about security relevant updates and tasks are published at
the news area at the opsi forum:
https://forum.opsi.org/viewforum.php?f=10

The opsi software cannot be more secure than the underlying operating system. So please make sure to update your server with the security updates of your Linux distribution. This has to be done not only for the opsi config server, but also for all the opsi depot server.

It may help you to install programs which inform you by email if there are new updates available.

There are a lot of possibilities to enhance the security of your Linux server. But this is not the task of this manual.

We would be happy to help you with this task as part of a support contract.

The client authenticates itself using the FQDN as username and the 'opsi-host-key' as password.

The 'opsi-host-key' is stored at the client in the file:
%programfiles%\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf
which is readable with administrative privileges only.
The 'opsi-host-key' is stored at the server in the used backend (e.g at /etc/opsi/pckeys).

In addition to this authentication, you may tell the 'opsiconfd' to check if the client ip address matches the given FQDN. To activate this check, set in /etc/opsi/opsiconfd.conf:

and restart 'opsiconfd':

Since opsi 4.2, the trustworthiness of the 'opsi-Server' can be ensured using standard TLS methods.

Each opsi config server maintains a Certificate Authority (CA), the 'opsi CA'. This CA is automatically managed by the opsi config server. Each opsi server, also the opsi depot server receive a TLS certificate from the opsi config server, which is signed by this CA. These certificates are also automatically created, distributed and updated as needed. Any client that trusts the 'opsi CA' also trusts these server certificates.

The certificate of the 'opsi CA' can be retrieved from any 'opsi-Server' at the URL https://<server-address>:4447/ssl/opsi-ca-cert.pem. More information about the CA and the server certificate is available on the 'opsi-Servers' admin page (https://<server-address>:4447/admin).

If a 'opsi-client-agent' connects to a opsi config server, it automatically retrieves the 'opsi CA' and stores it at 'c:\opsi.org\tls\opsi-ca-cert.pem' or '/etc/opsi-client-agent/tls/opsi-ca-cert.pem'. However, this only happens under the condition that either no 'opsi CA' is stored there yet or a secure, verified connection to the opsi config server is established.

To enable verification of server connections, the following option is set in opsiclientd.conf, section '[global]':

It is advisable not to make this change manually, but to create a corresponding host parameter on the server. For example, the boolean host parameter 'opsiclientd.global.verify_server_cert' with default value 'false' is created via 'opsi-configed'. This also works via opsi-admin:

This parameter can then be set to true on a client-specific basis, or it can be enabled globally. This will enable server verification. If webdav is used as clientconfig.depot.protocol, the 'opsi-Depotserver' will also be verified accordingly.

Additionally it is possible to store the 'opsi CA' in the certificate store of the operating system. Then the operating system as well as all applications which use this certificate store trust the 'opsi CA' and the certificates of the 'opsi-Server'. This is also a prerequisite to mount an opsi repository via WevDAV.

The associated boolean configuration is opsiclientd.global.install_opsi_ca_into_os_store. If this is enabled, the 'opsi-client-agent' automatically injects the 'opsi CA' into the certificate store of the operating system.

It is recommended to operate the opsi CA as its own root CA. This is also the preconfigured default.

Alternatively it is also possible to operate the opsi CA as an intermediate CA. For this the following steps are necessary:

The 'opsiclientd' provides a web service interface, which allows remote control of the 'opsiclientd' and thus remote control of the client.

(opsi-client-agent remote control).

In order to access this interface authentication is required. You may authenticate as a local administrator with a not empty password, or with an empty username and the 'opsi-host-key' as password.

This control server can be configured so that only connections from localhost are accepted. To do this, the configuration parameter opsiclientd.control_server.interface must be set to [::1, 127.0.0.1]. This can be set as follows using opsi-cli:

Commands can then only be sent to the client via the opsi messagebus.

Enforce multi-factor authentication to enhance security.

By default, the opsi service accepts connection from any ip addresses. To improve security, you may configure a list of ip networks which are allowed to connect. For this purpose there is the opsiconfd option networks.

A configuration like e.g.

would limit access to the networks '192.168.1.0/24' and '10.1.0.0/16'.

The idea of an 'admin network' is to ban any administrative access from the standard production network and allow these accesses only from a special 'admin network'.

With opsi all 'opsi-clients' need restricted access to the 'opsi web service', which allows them to read and change their own data. Administrative access with further privileges is granted to members of the unix group 'opsiadmin' only.

If you configure an 'admin-networks' parameter, all administrative accesses are restricted to these network(s).

Setting the option admin-networks at the /etc/opsi/opsiconfd.conf will restrict the administrative access to the 'opsiconfd' to connections coming from the specified network address(es).
You may define multiple addresses.
Non administrative access may also come from other networks.

The default is:

and allows administrative access from all networks.

A configuration like e.g.

restricts administrative access to the server itself and to the network '10.1.1.0/24'.

If a client tries to log in to the server too often without success, it will be locked out for a certain time. There are three configuration options for this:

max-auth-failures specifies after how many failed attempts a client will be locked out. The default is:

The option auth-failures-interval determines in which time period the failures specified with max-auth-failures must occur, that a cleint is blocked. The specification is in seconds.

Default:

The third option client-block-time specifies how long a client will be blocked if it gets above the number of attempts (auth-failures-interval) in the time period (max-auth-failures). This specification is also in seconds.

Here is the default:

The information about the error attempts and which clients are blocked is stored in Redis. There are two Redis keys for this:

To release the clients manually you can use the admin page https://<opsi-server>:4447/admin (see Admininterface).

The user 'pcpatch' is required for the opsi clients to access the CIFS depot share (opsi_depot).

Exceptions to this are the products:

The password of the user 'pcpatch' is stored in encrypted form and is also only transmitted in encrypted form. However, under certain circumstances it is possible to find out the password. To minimize the damage this can cause, we recommend the following measures:

In /etc/samba/smb.conf in all share definitions except 'opsi_depot', prohibit the user pcpatch access via the entry:

Alternative:
In /etc/samba/smb.conf, restrict the user 'pcpatch' to read rights by making an entry in the [global] section:

As a further measure, the password of the user 'pcpatch' should be changed regularly. Since the plain text password does not have to be known to anyone, it can be set to a random password by regularly calling (e.g. via cronjob) the following script:

The file /etc/opsi/backendManager/acl.conf can be used to limit the access to specified methods and attributes of the returned values.

The limitation affects the base methods of the webservice. For those a restriction of users or groups and allowed attributes can be established.

The access should be limited to the used methods. If it is not clear what methods are being used one can refer to the output of opsiconfd about the accessed methods. This is logged to /var/log/opsi/opsiconfd/opsiconfd.log in case of a stop or restart.

More information about the webservice can be found at JSON-RPC-API.

It is possible to deactivate certain security-relevant features of the opsi service if they are not required. The deactivated features can be set via disabled-features in /etc/opsi/opsiconfd.conf or the environment variable OPSICONFD_DISABLED_FEATURES. See opsiconfd configuration for details.

Security-relevant features that can be deactivated are:

The root password of the opsi linux boot image is 'linux123' by default. You may like to change this for security reasons. How to do this is desribed here: Parameters for the opsi linux boot image