Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- news:aus_aktuellem_anlass_bwlehrpool_und_kritische_sicherheitsluecken [2019/05/23 11:00 CEST] – sritter
+++ news:aus_aktuellem_anlass_bwlehrpool_und_kritische_sicherheitsluecken [2019/05/28 17:08 CEST] (aktuell) – sritter
@@ Zeile 1: / Zeile 1: @@
 ====== Aus aktuellem Anlass: bwLehrpool und kritische Sicherheitslücken ======
+<WRAP justify 800px>
+Im Zuge der immer wiederkehrenden Diskussion um kritische Sicherheitslücken (aktuell 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 basierend auf unseren bisherigen Erfahrungen dazu kurz vorstellen.
-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 \\
+</WRAP>
-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.
+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 Zustand((Das gilt natürlich auch für eventuell vorher bereits vorhandene Schwachstellen!)) 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 ungefähr 15 Jahren an der Universität Freiburg in Betrieb.)) 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 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:
+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
+  * 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.
+  * 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 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.
+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 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.
+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 ====
-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.
+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 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.
+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 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.
+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 ====
@@ Zeile 37: / Zeile 38: @@
 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.
+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.
+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 [[client:vm_anpassen|Virtuelle Maschinen anpassen]].
+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>
+==== 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 vorhanden((Vorausgesetzt die Ausgangsbasis war frei von Schadsoftware)),
+  * 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.
+</WRAP>
 ~~DISCUSSION~~

Zuletzt angesehen:

Unterschiede

Suche

Navigation

Drucken/exportieren

Werkzeuge