Security

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.

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

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.

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.

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 Backend.

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:

und starten 'opsiconfd' neu:

Stellen Sie sicher, dass alle opsi-Komponenten die Server-Identität prüfen. Details dazu finden Sie unter SSL/TLS & Zertifikate.

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:

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

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

Nutzen Sie die Single Sign-On (SSO) um die Sicherheit und gleichzeitig den Komfort zu erhöhen.

Über den Konfigurations-Parameter disabled-auth-methods in der /etc/opsi/opsiconfd.conf können bestimmte Authentifizierungs-Methoden deaktiviert werden. Wenn Sie beispielweise SSO verwenden und nur WebDAV als Depot-Protokoll verwenden, können Sie alle anderen Authentifizierungs-Methoden deaktivieren:

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.

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

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:

und erlaubt Zugriff von allen Netzen.

Eine Konfiguration wie z.B.

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

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:

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:

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:

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

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

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:

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:

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

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.

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.

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:

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