Dies ist eine alte Version des Dokuments!


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 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 bereit gestellten 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 heißt 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 nochmal 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 jeden 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 und auch keinen Virenscanner fahren, während des Betriebs, also so lange sie eingeschalten 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 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 werden und entsprechend konfigurieren, 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 Diensten 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 offline Scans unterstützen. Snapshots sollten für die Nutzer nur read-only erreichbar sein, d.h. es gibt immer eine konfigurierbar lange Historie, 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 derr Uni Freiburg) beobachtet wurden (mit teilweise erheblichen 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.

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.

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 knapp 15 Jahren an der Uni Freiburg in Betrieb
Melden Sie sich an, um einen Kommentar zu erstellen.
Drucken/exportieren