Absicherung externer Clients und Depot (Ist OPSI sicher?)

[AlexB]

Hallo zusammen,

auf Grund der aktuellen Pandemie-Situation sind wir am überlegen zu unserem internen OPSI-Server ein externes Depot aufzustellen. Dies soll dann so funktionieren, dass User sich ohne VPN Verbindung die Config vom OPSI-Server ziehen können (Ports des Servers werden natürlich geöffnet) und dieser sie dann an das externe Depot weiterleitet um die Daten zu ziehen.
Grund für die Umstellung ist, dass wir einmal die Last von größeren Installationen von unserer Hauptleitung herunter haben wollen und das sich MA im Home-Office und externe MA sich direkt beim Start ihres Rechners die Installationen saugen können. Das hat den Vorteil das nicht extra ein Support Ticket aufgemacht werden muss für ein externes Update einer Software.

Setup:
OPSI-Server 4.1.1.86
opsiclientd 4.1.0.0-40

Nun stellt sich die Frage der Sicherheit der Verbindungen.
1. Verbindung Client und Config-Server (mit verify_server_cert=true)
2. Verbindung Client und Depot

Bei 1. wird ja über TLS die Verbindung gesichert. Dies geschieht über das selfsigned Cert auf dem Server. Wird hier nur die Verbindung verschlüsselt oder auch der Server verifiziert?
Wenn nur die Verbindung verschlüsselt wird, ist das natürlich recht ungenügend. (Möglichkeit eines Kauf einer von UIB zertifizierten Cert ist bekannt)

BUG:
Aktuell akzeptiert der opsiclientd auch einfach alle Certs vom Server. Wenn das Cert vom Server auf dem Client beim Connect nocht nicht vorhanden ist, wird es anscheinend einfach ohne Überprüfung übernommen?! Ich meine, dass das damals anders war und die Verbindung abgebrochen wurde wenn das Cert nicht verifiziert werden konnte.

Bei 2. wird das Depot per SMB verbunden. Ich bin jetzt nicht fit im Bereich Samba, aber sieht das dort mit der Sicherheit aus?

Generell:
Gibt es noch andere sicherheitsrelevante Probleme die ich übersehen habe bei der gewünschten Konfiguration?

VG
Alex

[Jan.Schmidt]

Salve,

hast du schon mehrere depots?

Wenn ja, verschiebe mal einen Client in ein Depot oder nimm gleich einen, der an einem Depot dran hängt.
Boote den Rechner neu, oder starte den Software Kiosk.

Frage: Mit welchem Server verbindet sich der Client?
Mit dem Depot oder dem Config Server?
Wenn du das herausgefunden hast, dann weißt du - was du deinem Chef vorschlagen solltest.

Erwerben der WAN Erweiterung.

Gruß

[AlexB]

Salve,

hast du schon mehrere depots?

Frage: Mit welchem Server verbindet sich der Client?
Mit dem Depot oder dem Config Server?
Wenn du das herausgefunden hast, dann weißt du - was du deinem Chef vorschlagen solltest.

Moin Jan,

Als Test ist schon ein weiteres reines Depot im Netzwerk. Natürlich wird zuerst der Config-Server angesprochen. Das soll auch so bleiben.
Der Config-Server soll ja auch von "draußen" verfügbar sein. Deshalb meine Frage, ob das Grundsystem überhaupt sicher genug ist.
Aber aktuell sehe ich mit dem oben beschrieben Bug 0 Sicherheit bei der Verwendung von OPSI wenn der Server nicht verifiziert werden kann.

Die WAN-Erweiterung steht erstmal nicht zur Debatte, da das auch nicht mit unseren externen MA funktioniert.

VG
Alex

[SirTux]

Als Test ist schon ein weiteres reines Depot im Netzwerk. Natürlich wird zuerst der Config-Server angesprochen. Das soll auch so bleiben.
Der Config-Server soll ja auch von "draußen" verfügbar sein. Deshalb meine Frage, ob das Grundsystem überhaupt sicher genug ist.
Aber aktuell sehe ich mit dem oben beschrieben Bug 0 Sicherheit bei der Verwendung von OPSI wenn der Server nicht verifiziert werden kann.

Also ich würde stark davon absehen den Config-Server direkt im Internet zu betreiben. Sonst fungiert der womöglich bald als C&C-Server eines Botnetzes.

[AlexB]

Also ich würde stark davon absehen den Config-Server direkt im Internet zu betreiben. Sonst fungiert der womöglich bald als C&C-Server eines Botnetzes.

Wie ich schon schrieb, der Config-Server bleibt bei uns und es werden lediglich die benötigen Ports die für den Mindestbetrieb nötig sind geöffnet. Das sollte afaik ja nur 4447 sein. Sehe da kein Problem.

[SirTux]

Ich gehe lieber prinzipiell davon aus, daß es Sicherheitslücken gibt. Speziell dann, wenn kein Security-Code-Audit durchgeführt wurde.

Aber falls es unbedingt sein muß (würde ich mir sehr gut überlegen!): Wird bzw. wurde ein Admin-Netz am opsiconfd konfiguriert? Das wäre dann wenigstens noch eine Sicherheitsstufe.

[AlexB]

Ich gehe lieber prinzipiell davon aus, daß es Sicherheitslücken gibt. Speziell dann, wenn kein Security-Code-Audit durchgeführt wurde.

Ja aktuell muss man das wohl
Ansich nun für uns erstmal kein Problem wenn der Rest erstmal sicher ist. Danach kann man immer noch schauen. Aber darum gehts mir aktuell ja erstmal nicht

Wird bzw. wurde ein Admin-Netz am opsiconfd konfiguriert? Das wäre dann wenigstens noch eine Sicherheitsstufe.

Jup, das sind ja so Basics, die sollte man aktiveren

[ueluekmen]

Hi,

verify_server_cert ist kaputt und wurde noch nicht gefixed. Wir haben für opsi 4.2 den Webservice neu implementiert. Wir werden das Problem nach dem neuen Release noch mal neu angehen. Aber auch verify_server_cert war nur ein "Zäunchen". Wir bieten ebenfalls opsi-CA Zertifikate an. Mit denen kann man seine Clients vor Fake-Servern schützen. Wir (uib gmbh) sind in diesem Fall die CA für opsi.

Allgemein wäre ich vorsichtig mit so einem Titel, es erweckt den Anschein, dass opsi ein allgemeines Security-Problem hat. Das sehen wir natürlich anders. Zu dem Thema will ich auch gar nicht viel sagen, nur so viel, dass opsi mehrmals in den letzten Jahren auch von Pentestern geprüft wurde und zum Teil haben die auch was gefunden, was wir dann zeitnah gefixed haben. Das letzte mal haben die eine Lücke in unsere API-ACL gefunden. War nicht lustig .

Allgemein findet neben dem HTTPS natürlich auch noch ein Hostkey-Verfahren statt. Dieser wird sowohl als auth intern aber auch zum Teil zum Verschlüsseln genutzt (Das Sharepasswort zum Beispiel wird auch durch HTTPS nicht in Klartext geschickt).

Natürlich könnten wir auch eine echte Zertifikatsprüfung machen, aber nicht jeder der opsi einsetzt nutzt auch echte Zertifikate. Das heißt wir können das nicht voraussetzen. Es steht aber jedem Frei mit Geld zu winken, dann bauen wir auch so was noch ein.

Und zum Schluss noch mal eine Info: Sollte jemand tatsächlich eine Lücke in opsi finden (wir kochen ja auch nur mit Wasser), sind wir natürlich offen für Feedback. Ebenso wenn jemand wirklich mal ein Audit durchläuft und opsi angemeckert wird, würden wir das natürlich auch gerne Wissen und kümmern uns dann auch gerne darum, dass die "Löcher" auch zeitnah gestopft werden. Bis jetzt war jeder Audit bei unseren Kunden kein Problem für opsi. Aber auch das muss natürlich nichts heißen.

[AlexB]

Hey,

verify_server_cert ist kaputt und wurde noch nicht gefixed. Wir haben für opsi 4.2 den Webservice neu implementiert. Wir werden das Problem nach dem neuen Release noch mal neu angehen. Aber auch verify_server_cert war nur ein "Zäunchen". Wir bieten ebenfalls opsi-CA Zertifikate an. Mit denen kann man seine Clients vor Fake-Servern schützen. Wir (uib gmbh) sind in diesem Fall die CA für opsi.

Ah, dachte ich mir schon, da ich in der Vergangenheit damit schon mal Probleme hatte und es deaktivieren musste. Gibts eine ETA für das 4.2er Release bzw. die Beta dazu?
Jup, die CA hatte ich schon auf dem Schirm. Wenn der 4.2er Release noch in weiter Ferne ist, wäre das dann wohl der nächste Schritt für uns.

Zu dem Thema will ich auch gar nicht viel sagen, nur so viel, dass opsi mehrmals in den letzten Jahren auch von Pentestern geprüft wurde und zum Teil haben die auch was gefunden, was wir dann zeitnah gefixed haben.

Das hört sich ja schon mal gut an. Das sollte definitiv auch in der Doku vermerkt werden.

Natürlich könnten wir auch eine echte Zertifikatsprüfung machen, aber nicht jeder der opsi einsetzt nutzt auch echte Zertifikate.

Würde ja schon reichen, wenn der Client keine Zertifikate von anderen Servern, als dem aktuellen, annimmt (ein- und ausschaltbar per Property). Mal abgesehen von dem aktuellen Bug.

Danke für die Rückmeldung!

VG
Alex

[gen_log]

Hallo AlexB + UIB + alle Anderen,

ich greife das Thema hier auch noch einmal auf, da wir die gleiche Diskussion bei uns innerhalb der IT hatten.

Wir sind zu dem Schluss gekommen den OPSI Server so nicht "einfach" im Internet erreichbar zu machen. Denn falls der wirklich mal übernommen wird, ist unser komplettes Netzwerk tot. Man kann sich dann ja ganz einfach ein OPSI Paket machen: "Verschlüssel meinen lokalen Client und schreib eine Meldung auf dem Bildschirm wo er sich melden und das Geld hin schicken kann und setze den auf "setup" + "reboot" !"

D.h. wir gehen davon aus, dass OPSI sehr unsicher ist. Nicht weil es das potenziell wirklich so ist, sondern nur weil der Schutzfaktor hier so hoch ist und eine Übernahme des Hauptdepots + Config Server extreme Auswirkungen auf die Sicherheit unseres Netzes hat.

Da der "Hauptdepot" + "Config" Server dann ja extern stehen, haben wir uns dazu entschlossen den nur per OVPN erreichbar zu machen.
Dafür haben wir (oder sind noch dabei) entschlossen einen Windows Dienst zu programmieren, der beim Starten eine OVPN Verbindung zum OPSI Server aufbaut, sich dann connected, seine Aufgaben ausführt und danach wieder beendet.
Das Ganze ist nicht so trivial wie es sich anhört (Dienst muss vor dem OPSI Client die Verbindung aufgebaut haben oder der Dienst muss den OPSI Client erneut "anstupsen"). Wir sind noch am programmieren, haben dann aber eine höhere Schutzklasse (denken wir) als wenn der OPSI Dienst so am Netz hängt.

Das war so meine Meinung dazu ...