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.

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-admin:

opsi-admin -d method 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 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.

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. Dafür muss in der opsiclientd.conf in der Sektion '[control_server]' folgender Parameter gesetzt werden:

kiosk_api_active = false

Dies können Sie auch über das Setzten eines systemweiten configs / Hostparameters erreichen:
opsiclientd.control_server.kiosk_api_active = false

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 geblocked 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 user pcpatch

Der user 'pcpatch' dient in opsi 4 dem Mounten des depot-Shares (opsi_depot) durch den Client.

Ausnahme hier von sind die Produkte:

opsi-wim-capture und opsi-local-image-capture welche als user '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 in der Regel 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 user pcpatch den Zugriff verbieten über den Eintrag:

invalid users = root pcpatch

Alternativ
In der /etc/samba/smb.conf dem User '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 Sie das Passwort des Users 'pcpatch' öfters ändern. Da das Klartext-Passwort niemandem bekannt sein muss, kann es z.B. durch den regelmäßigigen Aufruf (z.B. per cronjob) des folgenden Scriptes auf ein zufälliges Passwort setzen.

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

Falls Sie keine Netboot-Produkte verwenden, welche eine Anmeldung am Server als Benutzer 'pcpatch' benötigen, so können Sie zusätzlich die Anmeldung des Benutzer 'pcpatch' am Server unterbinden. Dazu weisen Sie in der Datei /etc/passwd dem Benutzer 'pcpatch' die Shell /bin/false zu. Seit opsi 4.1 wird der Benutzer 'pcpatch' standardmäßig mit der Shell /bin/false angelegt. Handlungsbedarf besteht hier nur, falls das System mit einer früheren Version installiert wurde.

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 Web service / API Methoden seit opsi 4.0 zu finden.

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