Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
news:aus_aktuellem_anlass_bwlehrpool_und_kritische_sicherheitsluecken [2019/05/23 15:02 CEST] – chrnews:aus_aktuellem_anlass_bwlehrpool_und_kritische_sicherheitsluecken [2019/05/28 17:08 CEST] (aktuell) – sritter
Zeile 2: Zeile 2:
  
 <WRAP justify 800px> <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 dazu kurz vorstellen. +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. 
  
 </WRAP> </WRAP>
Zeile 16: Zeile 16:
  
   * 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 hinter einem weiteren 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 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. 
Zeile 30: Zeile 30:
 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.  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, wird 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. +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 das Firewalling entspreched konfiguriert, 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 ====  ==== Krypto-Trojaner und Homeverzeichnisse ==== 
Zeile 38: 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.  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, damit es gibt 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 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 ==== ==== Systemupdates ====
Zeile 47: Zeile 48:
 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~~ ~~DISCUSSION~~
  

Zuletzt angesehen:

Drucken/exportieren