Aus aktuellem Anlass: bwLehrpool und kritische Sicherheitslücken

Im Zuge der immer wiederkehrenden Diskussion um kritische Sicherheitslücken (aktuell u.a. Intel1, RDP , …) kommt regelmäßig die berechtigte Frage auf, welche Auswirkungen dies auf die mit bwLehrpool betriebenen PC-Pools hat. Aus diesem Grund möchten wir unsere Einschätzung basierend auf unseren bisherigen Erfahrungen dazu kurz vorstellen.

Sicherheitslücken, wie z.B. die oben genannten, können generell auf zwei Ebenen ein Problem darstellen: Zum einen auf der Ebene des Hostsystems, in dem der Hypervisor läuft, zum anderen auf der Ebene der genutzten virtuellen Lehr- und Arbeitsumgebung. Da beide Systeme grundsätzlich stateless (zustandslos) bereitgestellt werden, ist sowohl auf der Host-Plattform (Linux) als auch für die bereitgestellten virtuellen Maschinen das Problem relativ gering. Diese werden nach dem Ausschalten (Host) bzw. Logout/Abschalten der VM wieder ihren ursprünglichen Zustand2 einnehmen, und eine mögliche Kompromittierung der Maschine wäre damit wieder zurückgesetzt. Hierin liegt ein wesentlicher Vorteil des Konzepts. Aus diesem Grund sind uns keine relevanten Vorfälle aus den letzten Jahren3 bekannt (beispielsweise durch Meldungen angegriffener Systeme). Das bedeutet jedoch nicht, dass sie nicht vorgekommen sein könnten.

Die Aktualisierung der Systeme ist trotzdem immer eine gute Idee! Für das Hostsystem erfolgt dies durch das bwLehrpool-Team. Die Aufgabe, die jeweiligen VMs aktuell zu halten, unterliegt bis auf die Standard-Images und Vorlagen den jeweiligen Lehrenden. Das wird unterschiedlich intensiv wahrgenommen. Die gängigsten Standardangriffsvektoren lassen sich aber bereits durch zwei Maßnahmen erheblich reduzieren:

  • Pool-Räume bzw. Pool-Clients sollten in einem internen Netz, also nicht mit einer aus dem Internet öffentlich erreichbaren IP laufen,
  • alle VMs in bwLehrpool laufen standardmäßig hinter einer NAT, sind also auch aus dem internen-Netz nicht direkt erreichbar.

Das Basissystem (Linux) wird zentral gewartet und kann sehr schnell Updates einfahren, die sofort nach einem Neustart eines Clients aktiv sind. Zudem lässt sich die clientseitige Firewall zentral konfigurieren, so dass auch auf diesem Wege schon diverse Probleme abgewehrt werden konnten.

Potenzielle Bedrohungsszenarien

Einbruch in die lokale Maschine

Potenziell wäre es möglich, aus dem lokalen Hypervisor auszubrechen. Ebenso könnten Nutzer versuchen, auf dem Grundsystem eine Rechteeskalation zu erreichen. Um Nutzer in ihren VMs nicht zu gefährden, sind die Maschinen im Prinzip als Single-User-Systeme ausgelegt, da ein entfernter SSH-Login auf bwLehrpool-Clients nur einem kleinen Admin-Kreis vorbehalten ist. Eine lokale Rechte-Eskalation beschränkt sich daher typischerweise auf die einzelne Maschine, und eine Replikation auf weitere ist recht aufwändig. Durch den zustandslosen Charakter und das komplette Löschen der eingebundenen lokalen Festplatte (ID44) sind persistente Einbrüche stark erschwert.

Verteilung von Schadsoftware durch bwLehrpool-Clients

Im Prinzip könnten bwLehrpool-Rechner bzw. Images, die u.U. nicht regelmäßig aktualisiert werden, während des Betriebs, also so lange sie eingeschaltet sind, gekapert werden. Dann könnte versucht werden, Schadsoftware im internen-Netz zu verteilen.

Durch die Konstruktion des Gesamtsystems sind die Einfallsvektoren insgesamt jedoch deutlich eingeengt (USB-Stick, Side-Load im Browser, via Home eines Users). Ein weiterer Faktor ist die relativ kurze Laufzeit der einzelnen virtuellen Maschine. Anders als im klassischen Betrieb, in dem ein Rechner durchaus länger durchläuft und sich mehrere Nutzer an- und abmelden, ist in bwLehrpool bei jedem Login die ausgewählte VM wieder auf einen sauberen Anfangszustand zurückgesetzt. Nach erfolgtem Logout läuft keine VM mehr weiter. Das lässt das Zeitfenster für die Verbreitung von Schädlingen erheblich schrumpfen. Dadurch, dass virtuelle Maschinen sich nicht gegenseitig “sehen” (NAT), ist eine Ausbreitung auf klassischem Weg über das Netz außerdem erheblich erschwert, auch wenn natürlich DoS-Attacken möglich sind. Bisher konnten wir jedoch keine Probleme beobachten, die auf solche Fälle zurückzuführen wären.

Mittelfristig können zusätzliche Netzsegmentierungen helfen, um auch hier auf der sicheren Seite zu sein. So kann man in weiteren Schritten dafür sorgen, dass potenziell auftretende Probleme sich nicht weiter ausbreiten. Hier muss dann ggf. geprüft werden, welche Dienste und Services am Campus genutzt und das Firewalling entspreched konfiguriert werden, damit diese aus den Pools weiterhin funktionieren. Nur sollte in der Regel z.B. niemand aus den Pools direkt auf Admin-Netze von Cloud, HPC oder ähnliche Dienste zugreifen müssen.

Krypto-Trojaner und Homeverzeichnisse

bwLehrpool-Clients und die darauf laufenden virtuellen Maschinen binden je nach Konfiguration das Homelaufwerk eines Nutzers oder weitere Netzlaufwerke ein. Damit könnte im Falle eines Befalls eine entsprechende Schadsoftware so lange Schaden auf diesen Netzlaufwerken anrichten, wie der Rechner bzw. die VM läuft. Hierzu könnte zählen, dass Inhalte verschlüsselt, virenbehaftete Dateien abgelegt, Dateien gelöscht werden usw.

Um darauf zu reagieren, empfehlen wir professionelle Fileserver, die beispielsweise mit Snapshots arbeiten und serverseitige Scans unterstützen. Snapshots sollten für Nutzer nur read-only erreichbar sein, damit es immer eine konfigurierbar lange Historie gibt, auf die gegebenenfalls zurückgegriffen werden kann. Auch hier möchten wir erwähnen, dass Verschlüsselungstrojaner schon an diversen Stellen (z.B. am Campus der Uni Freiburg) beobachtet wurden (mit teilweise erheblichem Schaden), bisher jedoch nicht im bwLehrpool-Kontext.

Ein weiterer Baustein, den wir seit längerem diskutieren ist, wie sich automatische Qualitätssicherungen nach dem Erstellen und Update von VMs für die Pools organisieren lassen, so dass in den Images keine Malware läuft. Der Aufwand hierfür ist jedoch vergleichsweise hoch und es entstehen Verzögerungen bei der Veröffentlichung der Lehrumgebungen. Da bisher noch kein kritischer Sicherheitsfall aufgetreten ist, wird dieser Pfad derzeit mit niedriger Priorität verfolgt und alle Nutzer, die Images updaten, dazu angehalten, einen finalen Sicherheitscheck durchzuführen.

Weitere Überlegungen

Systemupdates

Regelmäßige Systemupdates der eingesetzten Umgebungen sind natürlich in jedem Fall sinnvoll und zu empfehlen. Da automatische Updates in den VMs in der Regel bewusst deaktiviert sind, müssen diese ggf. vorher reaktiviert werden - anschließend für den Poolbetrieb bitte wieder deaktivieren! Eine Anleitung dazu findet sich hier im Wiki unter Virtuelle Maschinen anpassen.

Einsatz von Virenscannern

Vom bwLehrpool-Team bereitgestellte Vorlagen-VMs enthalten absichtlich keinen Virenscanner. Generell steht es natürlich jedem Nutzer frei, einen Virenscanner seiner Wahl, und für den eine entsprechende Lizenz vorliegt, in seine VM zu installieren.

Bedenken Sie jedoch folgende Punkte:

  • In den (Vorlagen-)VMs sind Nutzer mit einem lokalen Benutzerkonto ohne Administrationsrechte angemeldet,
  • VMs sind nicht-persistent, d.h.
    • Virensignaturen und der Scanner selbst veralten relativ schnell. Während Signaturen bei jedem Start automatisch aktualisiert werden könnten, ist dies bei der Scanengine und weiteren Programmbestandteilen normalerweise nicht so einfach möglich,
    • Viren, Trojaner und sonstige Schädlinge sind nach einem Neustart sowieso nicht mehr vorhanden4,
  • Virenscanner haben mitunter einen nicht unerheblichen, negativen Einfluss auf die Geschwindigkeit des Gesamtsystems,
    • Ursprünglich für die Zukunft, automatisch, geplante Voll-Scans werden u.U. bei jedem Start der VM ausgeführt, weil der geplante Ausführungszeitpunkt irgendwann in der Vergangenheit liegt und der Scanner versucht diesen nachzuholen.

Durch die beschriebenen Punkte (Nichtpersistenz, Abschottung des Netzwerkzugriffs über NAT, kurze Laufzeit, eingeschränktes Benutzerkonto, Beschränkung der Softwareausstattung auf das Wesentliche) und unserer bisherigen Erfahrungen halten wir den Einsatz von Virenscannern in bwLehrpool-VMs daher nicht für notwendig.

  1. Spectre, Meltdown, ZombieLoad ↩︎

  2. Das gilt natürlich auch für eventuell vorher bereits vorhandene Schwachstellen! ↩︎

  3. bwLehrpool bzw. dessen technischer Vorläufer ist bereits seit ungefähr 15 Jahren an der Universität Freiburg in Betrieb. ↩︎

  4. Vorausgesetzt die Ausgangsbasis war frei von Schadsoftware ↩︎