Security

Einführung

opsi ist ein mächtiges Werkzeug zur zentralen Administration vieler Clients. Damit steht der 'opsi-Server' natürlich auch im besonderen Fokus der Sicherheitsbetrachtung. Wer den 'opsi-Server' kontrolliert, kontrolliert auch die Clients. Wer einen Client davon überzeugen kann, er sei der richtige 'opsi-Server', der kontrolliert den Client.

Wieviel Energie und Geld Sie in die Absicherung der opsi Infrastruktur stecken sollten hängt von Ihren Sicherheitsbedürfnis und vom Einsatzszenario ab. Ein 'opsi-Server' in der 'cloud' ist z.B. gefährdeter als einer in einem abgeschlossenen Inselnetz.

Im Folgenden haben wir die wichtigsten uns bekannten Maßnahmen und Probleme zusammengetragen.

Wir danken an dieser Stelle allen Kunden und Anwendern die uns auf Probleme hingewiesen und damit zur Sicherheit beigetragen haben. Wir bitten Sie darum Probleme die Ihnen auffallen zunächst an info@uib.de zu melden bevor das Problem öffentlich gemacht wird.

Informiert bleiben

Informationen über Security relevante opsi Updates werden veröffentlicht in:

News Bereich des opsi forums:
https://forum.opsi.org/viewforum.php?f=1

In der opsi Mailingliste:
https://lists.sourceforge.net/lists/listinfo/opsi-announce_de

Allgemeine Serversicherheit

Die opsi Software auf einem Server kann nicht sicherer als der Server selbst sein. Daher ist es wichtig, dass Sie Ihren 'opsi-Server' regelmäßig aktualisieren, d.h. die vom Distributor angebotenen Security Updates auch einspielen. Dies gilt sowohl für den 'opsi-Configserver' wie auch für die 'opsi-Depotserver'.

Sie können auf dem Server Programme installieren, welche Sie per E-Mail informieren wenn es Paketupdates gibt.

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

Darüber hinaus gibt es viele Möglichkeiten Linuxserver weiter abzusichern. Dies ist aber nicht das Thema dieses Handbuchs. Gerne beraten wir Sie hierzu im Rahmen eines Support- und Pflegevertrages.

Authentifizierung des Clients beim Server

Der Client authentifiziert sich beim Server mit seinem FQDN sowie dem opsi-host-key. Client-seitig liegt dieser Key in der Datei %programfiles%\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf und ist nur mit administrativen Rechten lesbar. Serverseitig liegen die opsi-host-keys im jeweiligen Backend (z.B. unter /etc/opsi/pckeys).

Zusätzlich zu dieser Authentifizierung kann der opsiconfd angewiesen werden, zu überprüfen ob die IP-Adresse unter der sich der Client meldet auch zu dem angegebenen Clientnamen passt. Um dieses Verhalten zu aktivieren setzen sie in der /etc/opsi/opsiconfd.conf folgenden Parameter:

verify-ip = true

und starten 'opsiconfd' neu:

systemctl restart opsiconfd.service

Verwenden Sie diese Feature nur wenn Sie eine vollständig funktionierende Namensauflösung (vorwärts wie rückwärts) für Ihre Clients haben.

Verifizierung der Server-Identität

Seit opsi 4.2 kann die Vertrauenswürdigkeit des 'opsi-Server' über TLS-Standard-Methoden sichergestellt werden.

Jeder 'opsi-Configserver' verwaltet eine Certificate Authority (CA), die 'opsi CA'. Diese CA wird vom 'opsi-Configserver' automatisch verwaltet. Jeder 'opsi-Server', auch die 'opsi-Depotserver' erhalten vom 'opsi-Configserver' ein TLS-Zertifikat, das von dieser CA signiert ist. Auch diese Zertifikate werden automatisch erstellt, verteilt und bei Bedarf aktualisiert. Jeder Client, der der 'opsi CA' vertraut, vertraut auch diesen Server-Zertifikaten.

Um das Schadenspotential einer kompromittierten 'opsi CA' zu begrenzen, gibt es die Möglichkeit, diese über sogenannte 'X.509 name constraints' einzuschränken. Zu diesem Zweck kann der opsiconfd-Konfigurationsparameter ssl-ca-permitted-domains verwendet werden, um eine Liste von Domains angegeben werden, für die die 'opsi CA' Zertifikate ausstellen darf.

Das Zertifikat der 'opsi CA' kann von jedem 'opsi-Server' unter der URL https://<server-address>:4447/ssl/opsi-ca-cert.pem abgerufen werden. Weitere Informationen zu der CA und dem Server-Zertifikat sind auf der Admin-Seite des 'opsi-Servers' einsehbar (https://<server-address>:4447/admin).

Verbindet sich ein 'opsi-client-agent' mit einem 'opsi-Configserver', ruft er die 'opsi CA' automatisch ab und legt sie unter 'c:\opsi.org\tls\opsi-ca-cert.pem' bzw. '/etc/opsi-client-agent/tls/opsi-ca-cert.pem' ab. Dies passiert jedoch nur unter der Voraussetzung, dass dort entweder noch keine 'opsi CA' abgelegt ist oder eine sichere, verifizierte Verbindung mit dem 'opsi-Configserver' besteht.

Um die Verifizierung der Server-Verbindungen zu aktivieren, wird in der opsiclientd.conf, Sektion '[global]' folgende Option gesetzt:

verify_server_cert = true

Es bietet sich an, diese Änderung nicht manuell vorzunehmen, sondern einen entsprechenden Host-Parameter auf dem Server anzulegen. Hierfür wird beispielsweise über den 'opsi-configed' der boolesche Host-Parameter 'opsiclientd.global.verify_server_cert' mit Standardwert 'false' erzeugt. Das funktioniert auch per opsi-cli:

opsi-cli jsonrpc execute config_createBool opsiclientd.global.verify_server_cert verify_server_cert false

Dieser Parameter kann dann Client-spezifisch auf true gesetzt werden oder auch global aktiviert werden. Damit ist die Verifizierung aktiviert. Wird webdav als clientconfig.depot.protocol verwendet, so wird auch der 'opsi-Depotserver' entsprechend geprüft.

Sobald die Verifizierung aktiviert ist, wird der Client Verbindungen zu Servern ohne gültiges Zertifikat verweigern. Es sollte also im Vorfeld sichergestellt werden, dass der Mechanismus wie gewünscht funktioniert.

Zusätzlich besteht die Möglichkeit die 'opsi CA' auch im Zertifikatsspeicher des Betriebssystems abzulegen. Dann vertraut sowohl das Betriebssystem als auch alle Applikationen, die diesen Zertifikatsspeicher verwenden, der 'opsi CA' und den Zertifikaten der 'opsi-Server'. Dies ist auch Voraussetzung um ein opsi-Depot per WevDAV mounten zu können.

Die Zugehörige boolesche Konfiguration ist opsiclientd.global.install_opsi_ca_into_os_store. Ist diese aktiviert, spielt der 'opsi-client-agent' die 'opsi CA' automatisch in den Zertifikatsspeicher des Betriebssystems ein.

Problemlösung

Sollte es zu der Situation kommen, dass ein Client das Server-Zertifikat des 'opsi-Configservers' wegen Problemen mit der 'opsi CA' nicht mehr akzeptiert, ist der Client nicht mehr über die normalen opsi-Mechanismen verwaltbar.

In diesem Fall gibt es mehrere Möglichkeiten das Problem zu lösen:

Löschen der 'opsi CA' auf dem Client

Die Datei 'opsi-ca-cert.pem' wird auf dem Client gelöscht. Bei der nächsten Verbindung zum 'opsi-Configserver' ruft der 'opsi-client-agent' die 'opsi CA' dann neu ab.

Ersetzen der 'opsi CA' über den Control-Server des opsi-client-agent

Die 'opsi CA' kann über die Control-Server-API des opsi-client-agent aktualisiert werden. Hierfür wird der RPC 'updateOpsiCaCert' verwendet. Über den Parameter 'ca_cert_pem' wird der Inhalt des 'opsi CA'-Zertifikats im PEM-Format als String übergeben.

Über ein temporäres Server-Zertifikat der uib GmbH

Zusätzlich zur 'opsi CA' der jeweiligen Umgebung vertraut ein 'opsi-client-agent' auch der 'uib opsi CA', wenn die entsprechende Konfiguration 'opsiclientd.global.trust_uib_opsi_ca' auf 'true' steht. Die 'uib opsi CA' wird von der 'uib GmbH' verwaltet. Die uib GmbH ist daher in der Lage ein temporär gültiges Server-Zertifikat für den 'opsi-Configserver' zu erzeugen. Dieses Zertifikat kann dann auf dem 'opsi-Configserver' der Umgebung eingespielt werden. Der 'opsi-client-agent' nimmt dann wieder eine Verbindung auf und ruft dann automatisch die 'opsi CA' der jeweiligen Umgebung ab. Wenn dieser Prozess auf allen betroffenen Clients stattgefunden hat, kann das temporäre Zertifikat wieder entfernt werden.

Betrieb der opsi CA als Intermediate-CA

Es wird empfohlen, die opsi CA als eigene Root-CA zu betreiben. Dies ist auch der vorkonfigurierte Standard.

Alternativ besteht jedoch auch die Möglichkeit die opsi-CA als Intermediate-CA zu betreiben. Hierfür sind folgende Schritte notwendig:

Erstellen Sie ein Backup des opsi-Servers, insbesondere der Konfiguration unterhalb von /etc/opsi.
Erstellen Sie eine Intermediate-CA. Hierbei sollte die folgende Konfiguration verwendet werden:
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical,CA:true,pathlen:0
keyUsage = critical,digitalSignature,cRLSign,keyCertSign
Legen Sie den Private Key der Intermediate-CA im verschlüsselten PEM-Format unter /etc/opsi/ssl/opsi-ca-key.pem auf dem opsi-Server ab.
Die Passphrase zum Private Key der Intermediate-CA muss über --ssl-ca-key-passphrase in der /etc/opsi/opsiconfd.conf oder als Environment-Variable hinterlegt werden.
Legen Sie das Zertifikat der Intermediate-CA zusammen mit dem Zertifikat der Root-CA im PEM-Format unter /etc/opsi/ssl/opsi-ca-cert.pem auf dem opsi-Server ab.
Installieren Sie das Zertifikat der Root-CA auf dem opsi-Server.
Stellen Sie sicher, dass der opsiconfd die Zertifikats-Datenbank des Betriebssystems verwendet (--ssl-trusted-certs).
Fügen Sie opsi_ca zu --skip-setup hinzu, um die Verwaltung der opsi CA durch den opsiconfd zu deaktivieren.
Starten Sie den opsiconfd neu.
Stellen Sie sicher, dass die Intermediate-CA rechtzeitig vor Ablauf erneuert und ausgetauscht wird.

Sollten der opsi-client-agent das Server-Zertifiakt bereits prüfen (verify_server_cert = true), kann eine bestehende opsi CA nicht mehr ohne weiteres durch eine Intermediate-CA ausgetauscht werden. Nach dem Austausch würden die Clients das geänderte Server-Zertifikat ablehnen. Lösungsansätze hierzu finden Sie unter Problemlösung.

Authentifizierung beim Controlserver des Client

Der 'opsiclientd' besitzt eine Webservice-Schnittstelle die es erlaubt dem opsiclientd Anweisungen von außen zu erteilen (Fernsteuerung des opsi-client-agent).

Für den Zugriff auf den Webservice wird eine Authentifizierung benötigt. Dies geschieht entweder mittels des lokalen Administrator-Accounts (ein leeres Passwort ist unzulässig) oder mittels leerem Benutzernamen und dem 'opsi-Hostschlüssels' als Passwort.

Dieser Controlserver kann so konfiguriert werden, dass nur Verbindungen von localhost akzeptiert werden. Hierfür ist der Konfigurations-Parameter opsiclientd.control_server.interface auf [::1, 127.0.0.1] zu setzen. Mittels opsi-cli kann dies wie folgt gesetzt werden:

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

Befehle können dann nur noch über den opsi-Messagebus an den Client gesendet werden.

Die Kiosk API des opsi-client-agents

Die Kiosk-API des opsiclientd erlaubt den Zugriff von localhost ohne jegliche Authentifizierung. Wird die Software-On-Demand-Funktion (opsi-client-kiosk) nicht verwendet, kann diese API komplett deaktiviert werden. Hierfür ist der Konfigurations-Parameter opsiclientd.control_server.kiosk_api_active auf false zu setzen. Mittels opsi-cli kann dies wie folgt gesetzt werden:

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

Multi-Faktor-Authentifizierung

Erzwingen Sie Multi-Faktor-Authentifizierung um die Sicherheit zu erhöhen.

Konfiguration erlaubter Netzwerke

Standardmäßig akzeptiert der opsi-Service Verbindungen von jeder beliebigen IP-Adresse. Um die Sicherheit zu erhöhen, kann man eine Liste von IP-Netzwerken angeben, die sich imit dem service verbinden dürfen. Hierfür existiert die Option networks des opsiconfd.

Eine Konfiguration wie z.B.

networks = [192.168.1.0/24, 10.1.0.0/16]

würde die Zugriffe auf die Netzwerke '192.168.1.0/24' und '10.1.0.0/16' begrenzen.

Konfiguration erlaubter Admin-Netzwerke

Die Idee eines Admin-Netzwerks ist es, administrative Zugriffe auf Server nicht aus dem allgemeinen Produktiv-Netz zu erlauben, sondern nur von einem speziellen und abgesicherten Netzbereich.

Zwar müssen alle 'opsi-clients' Zugang zum opsi-webservice haben, diese dürfen aber nur eingeschränkt Daten abrufen und ändern. Ein administrativer Zugang zum Webservice setzt die Mitgliedschaft in der Gruppe 'opsiadmin' voraus.

Über die Option admin-networks in der /etc/opsi/opsiconfd.conf kann der administrative Zugriff auf den 'opsiconfd' auf Verbindungen von bestimmten Netzwerkadressen eingeschränkt werden.
Es können mehrere Netzwerkadressen angegeben werden.
Nicht-administrative Client-Verbindungen können auch aus anderen Netzwerken erfolgen.

Der default ist:

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

und erlaubt Zugriff von allen Netzen.

Eine Konfiguration wie z.B.

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

würde administrative Zugriffe nur vom Server selbst und aus dem Netz '10.1.1.0/24' erlauben.

Konfiguration Clients aussperren und wieder freigeben

Wenn sich ein Client zu oft vergeblich versucht am Server anzumelden, wird er für eine bestimmte Zeit gesperrt. Hierfür gibt es drei Konfigurationsoptionen:

max-auth-failures legt fest nach wie vielen Fehlversuchen ein Client gesperrt wird. Der default ist:

max-auth-failures = 10

Die Option auth-failures-interval bestimmt in welchen Zeitraum die mit max-auth-failures festgelegten Fehlversuche auftreten müssen, dass ein Cleint gesperrt wird. Die Angabe ist in Sekunden.

Default:

auth-failures-interval = 120

Die dritte Option client-block-time legt fest wie lange ein Client geblockt wird, wenn er in dem Zeitraum (max-auth-failures) über die Anzahl der Versuche (auth-failures-interval) kommt. Auch diese Angabe ist in Sekunden.

Hier ist der default:

client-block-time = 120

Die Informationen über die Fehlerversuche und welche Clients geblockt werden, wird in Redis gespeichert. Hierfür gibt es zwei Redis keys:

opsiconfd:stats:client:failed_auth:<client ip> Anzahl der Fehlversuche des Clients (Redis Time Series)
opsiconfd:stats:client:blocked:<client ip>: Wird beim blocken des Clients angelegt und enthält den Wert "True" (Type: stirng)

Zum manuellen freigeben der Clients kann die Adminseite https://<opsi-server>:4447/admin verwendet werden (siehe opsi admin page).

Der Benutzer pcpatch

Der Benutzer 'pcpatch' wird für den Zugriff der opsi-Clients auf den CIFS-Depot-Share (opsi_depot) benötigt.

Ausnahme hierbei sind die Produkte:

opsi-wim-capture und opsi-local-image-capture welche als Benutzer 'pcpatch' auch den Share opsi_depot_rw mit Schreibrechten mounten.
opsi-clonezilla welches den Share opsi_images mit Schreibrechten mountet.

Das Passwort des Benutzers 'pcpatch' wird verschlüsselt abgelegt und auch nur verschlüsselt übertragen. Es existieren jedoch auch unter gewissen Umständen Möglichkeiten das Passwort in Erfahrung zu bringen. Um den Schaden der hierdurch entstehen kann zu minimieren empfehlen wir folgende Maßnahmen:

In der /etc/samba/smb.conf in allen Share-Definitionen ausser 'opsi_depot' dem Benutzer pcpatch den Zugriff verbieten über den Eintrag:

invalid users = root pcpatch

Alternativ:
In der /etc/samba/smb.conf dem Benutzer 'pcpatch' auf Leserechte beschränken durch den Eintrag in der [global] Sektion:

read list = pcpatch

Für die Produkte opsi-wim-capture und opsi-local-image-capture muß der share opsi_depot_rw für 'pcpatch' beschreibbar sein. Für das Produkt opsi-clonezilla muß der Share opsi_images beschreibbar sein.

Als weitere Maßnahme sollten das Passwort des Benutzers 'pcpatch' regelmäßig geändert werden. Da das Klartext-Passwort niemandem bekannt sein muss, kann es z.B. durch den regelmäßigen Aufruf (z.B. per Cronjob) des folgenden Skriptes auf ein zufälliges Passwort setzen.

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

Dem Benutzer 'pcpatch' sollte keine Shell zugewiesen werden, damit dieser sich nicht direkt am Server anmelden kann.

Wenn die opsi-Clients ausschließlich über WebDAV auf die Depots zugreifen (siehe Hostparameter clientconfig.depot.protocol), können sowohl der Benutzer 'pcpatch' als auch der Samba-Server komplett deaktiviert werden.

Webservice-Zugriffsbeschränkungen

In der Datei /etc/opsi/backendManager/acl.conf kann der Zugriff auf bestimmte Methoden und Attribute der zurückgegebenen Werte beschränkt werden.

Die Beschränkung greift auf die Basis-Methoden des Webservices, für welche eingeschränkt werden kann welche Benutzer oder Gruppen zugreifen dürfen sowie für welche Attribute der Zugriff erlaubt ist.

Der Zugriff sollte für eine Absicherung auf eine Freigabe der verwendeten Methoden beschränkt werden. Falls unklar ist welche Methoden verwendet werden, so kann dazu die Ausgabe des opsiconfd über die aufgerufenen Methoden herangezogen werden, welche im Falle eines Neustarts oder Stops des Dienstes in der Datei /var/log/opsi/opsiconfd/opsiconfd.log ausgegeben werden.

Weitere Informationen zu den Methoden des Webservice sind unter JSON-RPC-API zu finden.

Nicht benötigte Funktionen deaktivieren

Es ist möglich, bestimmte sicherheitsrelevante Funktionen des opsi-Dienstes zu deaktivieren, wenn sie nicht benötigt werden. Die deaktivierten Funktionen können über disabled-features in /etc/opsi/opsiconfd.conf oder die Umgebungsvariable OPSICONFD_DISABLED_FEATURES gesetzt werden. Siehe opsiconfd Konfiguration für weitere Details.

Sicherheitsrelevante Funktionen, die deaktiviert werden können, sind:

status-page: Deaktiviert die opsiconfd-Statusseite (/status), die ohne Authentifizierung verfügbar ist.
public-folder: Deaktiviert den öffentlichen Ordner /var/lib/opsi/public, der unter dem Pfad /public ohne Authentifizierung verfügbar ist.
rpc-interface: Deaktiviert das JSONRPC-Interface auf der opsiconfd-Admin-Seite (/admin/#rpc-interface).
messagebus_terminal: Deaktiviert die Möglichkeit Terminals über den opsi-Messagebus zu verwenden.
messagebus_execute_process: Deaktiviert die Prozessausführung über den opsi-Messagebus.

Root Passwort des bootimages ändern

Das root Passwort des bootimages ist per default 'linux123'. Dies sollte aus Gründen der Sicherheit geändert werden. Wie das geht ist beschrieben in: Parametrisierung vom Linux Installationsbootimage