Security

Introduction

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.

Stay tuned

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

General server security

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-configserver', but also for all the 'opsi-depotserver'.

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

Debian, Ubuntu: apticron
RHEL, CentOS: yum-updatesd

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.

Client authentication at the server

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:

verify ip = true

and restart 'opsiconfd':

systemctl restart opsiconfd.service

Do not use this feature if you are not really sure, that your name resolution works properly in both directions for all clients.

Verification of the server identity

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

Each 'opsi-configserver' maintains a Certificate Authority (CA), the 'opsi CA'. This CA is automatically managed by the 'opsi-configserver'. Each 'opsi-server', also the 'opsi-depotserver' receive a TLS certificate from the 'opsi-configserver', 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-configserver', 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-configserver' is established.

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

verify_server_cert = true

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:

opsi-admin -d method config_createBool opsiclientd.global.verify_server_cert verify_server_cert false

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.

Once verification is enabled, the client will refuse connections to servers without a valid certificate. So it should be ensured in advance that the mechanism works as desired.

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.

Problem solving

If it comes to the situation that a client does not accept the server certificate of the 'opsi-configservers' anymore because of problems with the 'opsi CA', the client is no longer manageable by the normal opsi mechanisms.

In this case there are several ways to solve the problem:

Delete the 'opsi CA' on the client.

The file 'opsi-ca-cert.pem' is deleted on the client. The next time the client connects to the 'opsi-configserver', the 'opsi-client-agent' will retrieve the 'opsi CA' again.

Replacing the 'opsi CA' via the opsi-client-agent’s control server.

The 'opsi CA' can be updated via the control server API of the opsi-client-agent. The RPC 'updateOpsiCaCert' is used for this purpose. Via the parameter 'ca_cert_pem' the content of the 'opsi CA' certificate is passed in PEM format as a string.

Via a temporary server certificate of uib GmbH.

In addition to the 'opsi CA' of the respective environment, a 'opsi-client-agent' also trusts the 'uib opsi CA' if the corresponding configuration 'opsiclientd.global.trust_uib_opsi_ca' is set to 'true'. The 'uib opsi CA' is managed by 'uib GmbH'. The uib GmbH is therefore able to generate a temporary valid server certificate for the 'opsi-configserver'. This certificate can then be installed on the 'opsi-configserver' of the environment. The 'opsi-client-agent' then reconnects and automatically retrieves the 'opsi CA' of that environment. When this process has taken place on all affected clients, the temporary certificate can be removed again.

Operation of the opsi CA as Intermediate-CA

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:

Create a backup of the opsi server, especially of the configuration below /etc/opsi.
Create an intermediate CA. Here the following configuration should be used:
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical,CA:true,pathlen:0
keyUsage = critical,digitalSignature,cRLSign,keyCertSign
Place the private key of the Intermediate CA in encrypted PEM format under /etc/opsi/ssl/opsi-ca-key.pem on the opsi server.
The passphrase to the private key of the Intermediate-CA must be stored via --ssl-ca-key-passphrase in /etc/opsi/opsiconfd.conf or as an environment variable.
Place the certificate of the intermediate CA in PEM format under /etc/opsi/ssl/opsi-ca-cert.pem on the opsi server.
Install the certificate of the root CA on the opsi server.
Make sure that the opsiconfd uses the certificate database of the operating system (--ssl-trusted-certs).
Add opsi_ca to --skip-setup to disable the opsi CA management by opsiconfd.
Restart the opsiconfd.
Ensure that the intermediate CA is renewed and replaced in time before expiration.

If the opsi-client-agent already verifies the server certificate (verify_server_cert = true), an existing opsi CA cannot be easily replaced with an intermediate CA. After the exchange, the clients would reject the modified server certificate. Possible solutions for this can be found in Problem solving.

Authentication at the control server of the client

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 user name and the 'opsi-host-Schlüssel' as password.

The opsi-client-agent kiosk api

The opsiclientd kiosk API allows access from localhost without any authentication. If the software-on-demand function (opsi-client-kiosk) is not in use, this API can be disabled completely. To do this, the following parameter must be set in the opsiclientd.conf in the section '[control_server]':

kiosk_api_active = false

This can be done by creating a system config / host parameter:
opsiclientd.control_server.kiosk_api_active = false

Configuration of allowed networks

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.

networks = [192.168.1.0/24, 10.1.0.0/16]

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

Configuration of allowed admin networks

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:

admin-networks = [0.0.0.0/0, ::/0]

and allows administrative access from all networks.

A configuration like e.g.

admin-networks = [127.0.0.1/32, 10.1.1.0/24]

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

Configuration Lock out clients and unlock them again.

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:

max-auth-failures = 10

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:

auth-failures-interval = 120

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:

client-block-time = 120

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

opsiconfd:stats:client:failed_auth:<client ip> Number of failed attempts of the client (Redis Time Series)
opsiconfd:stats:client:blocked:<client ip>: Will be created when the client is blocked and contains the value "True" (Type: stirng)

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

The user pcpatch

With opsi 4 the user 'pcpatch' is used just by the 'opsi-client-agent' to mount the 'depot share' (opsi_depot).

Excepions are the products:

opsi-wim-capture and opsi-local-image-capture which use 'pcpatch' to mount the share opsi_depot_rw
opsi-clonezilla wich use 'pcpatch' to mount the share opsi_images

The password of the user 'pcpatch' is usually stored and transmitted encrypted. Under special circumstances it might be possible to catch the clear password. To reduce risks arising from that, you should do the following:

Deny for the user pcpatch the access to all other shares than the 'opsi_depot' share. You should do this by adding the following entry to all share definitions (besides the 'opsi_depot') at the /etc/samba/smb.conf:

invalid users = root pcpatch

Alternative
At the /etc/samba/smb.conf restrict privileges for the user 'pcpatch' to global read only by setting in the [global] section:

read list = pcpatch

For the products opsi-wim-capture and opsi-local-image-capture the share opsi_depot_rw must have write permission for 'pcpatch'. For the product opsi-clonezilla the share opsi_images must have write permission for 'pcpatch'

As an additional task you should frequently change the password of the user 'pcpatch'. You may set the password to a random string which no one knows (besides opsi). You may do this by calling the following command e.g by a cronjob:

opsi-admin -d task setPcpatchPassword $(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c16)

If you are not using netboot products that require the possibility to login as user 'pcpatch' you can disable the login for that user. To do so please change the shell of the user 'pcpatch' to /bin/false in the file /etc/passwd. Since opsi 4.1 the default shell for the user 'pcpatch' is /bin/false. You only need to take action if the system was set up using an earlier version.

Webservice access limitations

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 object oriented methods.

Change the bootimage root password

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