news:aus_aktuellem_anlass_bwlehrpool_und_kritische_sicherheitsluecken

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== Aus aktuellem Anlass: bwLehrpool und kritische Sicherheitslücken ======


kjhjkj

===== Überschrift =====


Im Zuge der immer wiederkehrenden Diskussion um kritische Sicherheitslücken (u.a. [[https://www.intel.com/content/www/us/en/security-center/advisory/intel -sa-00233.html|Intel]]((Spectre, Meltdown, ZombieLoad)), [[https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE -2019-0708|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. 


<WRAP justify 800px>

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 Zustand 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 Jahren((bwLehrpool bzw. dessen technischer Vorläufer ist bereits seit knapp 15 Jahren an der Uni Freiburg in Betrieb)) 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 die Basisplattform 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 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. 

==== 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 einzelne Rechner 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 ==== 

Potenziell 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 [[client:vm_anpassen|Virtuelle Maschinen anpassen]].

</WRAP>



~~DISCUSSION~~
Zuletzt angesehen: • teilnahme_an_bwlehrpool • suite_changelog • bwlehrpoolsuite_einstellungen • 19 • aus_aktuellem_anlass_bwlehrpool_und_kritische_sicherheitsluecken
Suche

Navigation

Drucken/exportieren

Werkzeuge
