Security

Introduction

opsi is a powerful tool for managing many clients. As such, the security of the 'opsi-Server' is critical. If you control the 'opsi-Server', you control all connected clients.

The level of security hardening required depends on your environment and needs. For example, an 'opsi-Server' in the cloud is exposed to more risks than one in a secured internal network.

This chapter summarizes key security considerations and recommendations.

We thank all customers and users who have reported security issues and helped improve opsi security. If you discover a security problem, please contact us at info@uib.de before making it public.

Stay informed

Security-related updates and information can be found in the news section of the opsi forum as well as on the opsi website.

For automated processing, a JSON format is available at https://changelog.opsi.org/Releases/releases.json.

Subscribe to the opsi-Announce newsletter to receive current security update notifications directly.

General server security

The security of opsi largely depends on securing the underlying operating system. Ensure that your server regularly receives all security-relevant updates from your Linux distribution—this applies to both the opsi config server and all depot servers.

You can also keep these systems up to date automatically, for example using opsi.

Further measures for hardening your Linux server are beyond the scope of this manual. If needed, we are happy to support you as part of a support contract.

Client authentication at the server

Clients authenticate to the server using their opsi-host-key. This key is a 32-character secret hexadecimal value that is uniquely assigned to each client. It is stored on the client in the opsiclientd.conf file and is only readable with administrative privileges.

Verification of the server identity

To ensure secure communication, all opsi components should verify the server’s identity using SSL/TLS certificates. You can further enhance security by restricting the opsi CA to issue certificates only for specific domains using X.509 Name Constraints. Refer to SSL/TLS & certificates for configuration instructions.

Authentication at the client control server

The opsiclientd provides a web service interface for remote control of the client (see opsi-client-agent remote control).

Authentication is required to access this interface. You can authenticate as a local administrator with a non-empty password, or with an empty username and the 'opsi-host-key' as password.

You can restrict the control server to accept only localhost connections by setting opsiclientd.control_server.interface to [::1, 127.0.0.1]. Set this using opsi-cli:

opsi-cli jsonrpc execute config_createUnicode opsiclientd.control_server.interface "opsiclientd control server interface" "[]" "[\"::1\", \"127.0.0.1\"]"

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

The opsi-client-agent kiosk API

The opsiclientd kiosk API allows unauthenticated access from localhost. If you do not use the software-on-demand feature (opsi-client-kiosk), you can disable this API by setting opsiclientd.control_server.kiosk_api_active to false:

opsi-cli jsonrpc execute config_createBool opsiclientd.control_server.kiosk_api_active "opsiclientd control server kiosk API active" false

Multi-factor authentication

Enable multi-factor authentication to enhance security.

SAML - Single Sign On (SSO)

Use Single Sign-On (SSO) for improved security and convenience.

Disable authentication methods

The disabled-auth-methods parameter in /etc/opsi/opsiconfd.conf can disable specific authentication methods. For example, if you use SSO and only WebDAV as the depot protocol, you can disable other methods:

disabled-auth-methods = [pam, ldap, opsi_passwd]

Configuration of allowed networks

By default, opsi accepts connections from any IP address. To improve security, restrict access to specific networks using the networks option:

networks = [192.168.1.0/24, 10.1.0.0/16]

This limits access to the specified networks.

Configuration of allowed admin networks

To restrict administrative access, configure the admin-networks parameter in /etc/opsi/opsiconfd.conf. Only connections from these networks can perform administrative actions. Multiple addresses can be specified.

Default:

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

This allows admin access from all networks. For example, to restrict access:

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

Locking out clients after failed authentication

Clients are locked out for a period after too many failed login attempts. Three options control this:

max-auth-failures: Number of failed attempts before lockout (default: 10)
auth-failures-interval: Time window in seconds for counting failures (default: 120)
client-block-time: Lockout duration in seconds (default: 120)

Example:

max-auth-failures = 10
auth-failures-interval = 120
client-block-time = 120

Failed attempts and blocked clients are tracked in Redis:

opsiconfd:stats:client:failed_auth:<client ip>: Number of failed attempts
opsiconfd:stats:client:blocked:<client ip>: Indicates if the client is blocked

You can manually unblock clients via the admin page: https://<opsi-server>:4447/admin (see Admininterface).

The user pcpatch

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

Exceptions:

opsi-wim-capture and opsi-local-image-capture also mount opsi_depot_rw as 'pcpatch' with write access.
opsi-clonezilla mounts opsi_images with write permissions.

The 'pcpatch' password is stored and transmitted in encrypted form, but may be discoverable under certain circumstances. To minimize risk:

In /etc/samba/smb.conf, deny 'pcpatch' access to all shares except 'opsi_depot':

invalid users = root pcpatch

Alternatively, restrict 'pcpatch' to read-only in the [global] section:

read list = pcpatch

For opsi-wim-capture, opsi-local-image-capture, and opsi-clonezilla, 'pcpatch' needs write access to the respective shares.

Change the 'pcpatch' password regularly. Since no one needs to know the plain text password, set it to a random value, for example via cronjob:

opsiconfd setup --set-depot-user-password $(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c16)

Do not assign a shell to 'pcpatch' to prevent direct logins.

If clients use only WebDAV for depot access (clientconfig.depot.protocol), you can disable both 'pcpatch' and the Samba server.

Webservice access limitations

Limit access to webservice methods and attributes using /etc/opsi/backendManager/acl.conf. Restrictions can be set for users or groups and for allowed attributes.

Restrict access to only the necessary methods. To identify used methods, check the opsiconfd log at /var/log/opsi/opsiconfd/opsiconfd.log after a stop or restart.

See JSON-RPC-API for more information.

Deactivate unnecessary features

You can disable certain features in opsi for security reasons using disabled-features in /etc/opsi/opsiconfd.conf or the OPSICONFD_DISABLED_FEATURES environment variable. See opsiconfd configuration for details.

Features that can be disabled:

status-page: Disables the unauthenticated status page (/status).
public-folder: Disables the public folder /var/lib/opsi/public (/public).
rpc-interface: Disables the JSONRPC interface on the admin page (/admin/#rpc-interface).
messagebus_terminal: Disables terminal usage via opsi-messagebus.
messagebus_execute_process: Disables process execution via opsi-messagebus.

Change the Boot Image root password

The default root password for the opsi Linux boot image is 'linux123'. Change this for security reasons as described in Parameters for the opsi linux boot image.