bwLehrpool Neuigkeiten

• Satellitenserver 3.10
• Anwendertreffen 2020
• Satellitenserver WS19/20
• Aus aktuellem Anlass: bwLehrpool und kritische Sicherheitslücken

Satellitenserver 3.10

Der neue bwLehrpool-Satellitenserver 3.10 sowie Mini-/MaxiLinux 28 stehen zur Verfügung. Im Folgenden werden einige der Neuerungen ein wenig detailierter vorgestellt.

Die vollständigen Changelog finden Sie unter:
https://www.bwlehrpool.de/wiki/doku.php/allgemein/changelogs

Satellitenserver aktualisieren

Den Satellitenserver können Sie wie gewohnt per Skript aktualisieren.

Alternativ steht auch ein frisches OVF basierend auf Debian 11 zur Verfügung, falls Sie von einer sauberen Basis neustarten wollen Sat 3.10. Die alte Konfiguration können Sie natürlich über die Weboberfläche exportieren bzw. importieren. Falls Sie Ihren alten Sat per dist-upgrade händisch auf Debian 11 aktualisieren wollen, ist auch das möglich, wobei wir eher empfehlen würden, in diesem Fall direkt das neue OVF zu nutzen. Falls nach erfolgreichem dist-upgrade Fehler auftreten sollten (z.B. Webserver startet nicht), einfach nochmal das Sat-Updateskript einspielen.

Bitte prüfen Sie nach Update des Satellitenservers und Mini-/MaxiLinux, ob Sie eventuell alte generische Module einsetzen und diese noch benötigt werden. Unter Umständen überschreiben Sie damit aktualisierte Systemdateien des Linux-Grundsystems. Wir haben uns bemüht, alle Ihre gemeldeten Fehler und Probleme zu beheben, so dass von uns bereitgestellte Fixes als generisches Modul nicht mehr notwendig sein und entfernt werden sollten. Werfen Sie dazu auch einen Blick in die Changelogs.

Denken Sie wie üblich daran, zur Sicherheit vor dem Update einen Snapshot anzulegen und evtl. die Konfiguration über das Webinterface zu sichern, für den Fall, dass irgendetwas schiefgehen sollte.

Neuerungen

Neben den unten genannten neuen Funktionen wurden wieder viele kleine und größere Fehler oder Unstimmigkeiten in der Weboberfläche sowie im Linux-Grundsystem behoben. Im Folgenden werden daher nur einige Änderungen kurz beschrieben.

Netboot Grundsystem

Derzeit stehen 4 verschiedene Grundsysteme bereit (2x Mini- und 2x MaxiLinux jeweils basierend auf Ubuntu 18.04 bzw. Ubuntu 20.04). Wir empfehlen die Nutzung von MaxiLinux 28 basierend auf Ubuntu 20.04 mit Kernel 5.10. Die anderen Systeme stehen derzeit noch als Fallback zur Verfügung, werden aber mittelfristig nicht weiter gepflegt.

Die Authentifizierung numerischer Nutzeraccounts in MaxiLinux 20.04 sollte nun out-of-the-box möglich sein.

Sie können Satellitenserver und Grundsystem unabhängig voneinander aktualisieren. Da jedoch manche Funktionen erst in der jeweils aktuellen Version aktiv sind, empfehlen wir ein Update beider Komponenten.

Lokales Caching des Grundsystems

bwLehrpool-Clients konnten bereits Virtuelle Maschinen lokal cachen, sofern eine ID45-Partition in entsprechender Größe angelegt und die Funktion über den Satellitenserver aktiviert wurde Lokales Caching. Zusätzlich wird nun auch ein Teil des MaxiLinux gecachet. Dadurch reduziert sich die Netzwerklast beim Boot von Clients zusätzlich. Erste Tests zeigen Geschwindigkeitsvorteile beim Bootvorgang, wenn viele Clients zeitgleich starten und die Netzwerkverbindung limitiert und/oder SSDs im Client zum Einsatz kommen.

Neue Konfigurationsvariablen

Damit die neuen Konfigurationsvariablen aktiv werden, muss sowohl Satellitenserver als auch Linux-Grundsystem aktualisiert werden. Denken Sie auch daran, dass alle Konfigurationsvariablen global (für alle Rechner), für einzelne Räume oder sogar einzeln pro Client gesetzt werden können.

SLX_PRINT_REUSE_PASSWORD Wenn aktiviert, und der Druckserver Nutzername/Passwort anfordert, wird das Login-Passwort des aktuell angemeldeten Nutzers verwendet, anstatt wie bisher erneut das Passwort per Dialog abzufragen.

SLX_TTY_SWITCH Legt fest, ob der X-Server einen Wechsel zur Textkonsole mittels Strg-Alt-F1 etc. zulässt.

SLX_NTFSFREE Bestimmt, ob freier Speicherplatz auf NTFS-Partitionen als temporärer Speicher, äquivalent zu einer ID44-Partition, genutzt werden soll. Dies kann sinnvoll sein, wenn Sie eine große bestehende Windows-Lokalinstallation haben und keine neue ID44-Partition einrichten können.

Diese Funktionalität steht nur bei Verwendung des MaxiLinux zur Verfügung. Eine NTFS-Partition kann nur dann verwendet werden, wenn sie zuvor sauber ausgehängt wurde, d.h. i.d.R., dass Windows ordnungsgemäß heruntergefahren wurde.

SLX_RESOLUTION_MAPPING Hier können Sie eine statische Zuweisung von Bildschirmanschlüssen zu Auflösungen aus SLX_FORCE_RESOLUTION vornehmen. Das Format ist eine durch Leerzeichen getrennte Liste von OUTPUTNAME=Index, z.B.

HDMI1=0 HDMI2=0 HDMI3=1

Sofern die Variable SLX_FORCE_RESOLUTION den Wert 1024x768 800x600 hat, werden jetzt die Ausgänge HDMI1 und HDMI2 die Auflösung 1024x768 haben und den gleichen Inhalt zeigen (“linker Bildschirm”), und HDMI3 wird die Auflösung 800x600 haben, und den Desktop nach rechts erweitern.

Die Verwendung dieser Konfigurationsoption sollte nur für ungewöhnliche Bildschirm-Setups notwendig sein.

bwLehrpool-Suite

Bisher war der Login auf Mitarbeiter (und ausgewählte Personen mit speziellem Entitlement) beschränkt. Es gab jedoch häufiger den Wunsch, dass Studierende zur Verfügung stehende VMs mittels bwLehrpool-Suite herunterladen können sollten. Dafür wurden nun die ersten Voraussetzungen geschaffen. Die Funktion müssen Sie im Satellitenserver ggf. selbst noch freigeben (Satellitenserver -> bwLehrpool-Suite -> Limits und Standardwerte -> “Studenten den Download lizenzfreier VMs erlauben” ).

Studierende können anschließend //VMs ohne lizenzpflichtige Software// herunterladen, jedoch weder Veranstaltungen noch VMs bearbeiten oder neue VMs erstellen. Damit eine VM heruntergeladen werden kann, muss beim Upload der Haken “VM enthält lizenzpflichtige Software” entfernt werden. Dies ist nur bei nicht-Windows-VMs möglich und lässt sich derzeit auch nicht nachträglich verändern.

Die Funktion muss zusätzlich im Freiburger Masterserver freigegeben werden. Dies werden wir voraussichtlich in etwa einem Monat durchführen, wenn (hoffentlich) die meisten Satellitenserver aktualisiert wurden. Dies hat technische Gründe, da die Funktion u.U. Probleme im Betrieb mit alten Satellitenserver verursachen könnte. Wenn es soweit ist, geben wir nochmal Notiz über unsere Mailingliste.

Fernzugriff/Guacamole

Das auf dem Guacamole-Proxy befindliche Plugin zur Kommunikation mit dem Satellitenserver muss zwingend aktualisiert werden. Falls Sie noch Guacamole 1.2 einsetzen, benötigen Sie das Plugin 1.2.1. Falls Sie bereits Guacamole 1.3 verwenden, benötigen Sie analog das Plugin 1.3.1.

Falls notwendig, können Sie nun den Port der für die VNC Verbindung verwendet werden soll im Satellitenserver setzen (Mini-/MaxiLinux 28 vorausgesetzt). Dies kann beispielsweise notwendig sein, wenn auf Clients Intel AMT aktiviert ist. Dadurch kann teilweise der Standardport 5900 durch den VNC-Server von Intel AMT belegt sein und der von bwLehrpool gestartete eigene VNC-Server eingehende Verbindungen nicht annehmen. Generell empfehlen wir jedoch den Port auf der Standardeinstellung zu belassen.

Anwendertreffen 2020

Das Jahr 2020 war ein sehr spezielles Jahr. Kaum ein Lebensbereich wurde von den Auswirkungen der Corona-Pandemie verschont. Auch die Hochschullehre war immens betroffen, mussten doch viele Abläufe die sonst so selbstverständlich sind neu gedacht und umgesetzt werden.

Trotzdem oder gerade deswegen war es für bwLehrpool ein sehr spannendes Jahr mit interessanten Neu- und Weiterentwicklungen sowie neuen Ideen. Diese wurden, wie jedes Jahr, beim diesjährigen Anwendertreffen im Dezember vorgestellt und mit den über 50 Teilnehmern und Teilnehmerinnen diskutiert. Natürlich ganz coronakonform ausschließlich online über Video. Wenigstens wurden dadurch zahlreiche Fahrtkilometer eingespart, das Klima geschont und alle Teilnehmer waren frühzeitig wieder “zu Hause”.

Die Einschränkungen hatten unter anderem zur Folge, dass Vorlesungen und Laborübungen nicht mehr vor Ort, sondern zunehmend digital von Zuhause durchgeführt werden. Der reguläre Poolraumebtrieb kam praktisch über Nacht vollständig zum Erliegen mit großen Herausforderungen für Dozierende, Studierende und die Administratoren, die auf die Schnelle Lösungen finden mussten.

Die größte Neuentwicklung, die bereits von zahlreichen bwLehrpool-Standorten während des Semesters rege eingesetzt wurde, war der neue Remotezugriff. Der einfache Zugriff von extern über einen einfachen Webbrowser auf hochschuleigene Poolclients konnte in vielen Fällen praktische Übungen von Zuhause aus überhaupt erst möglich machen.

Diese und weitere Neuerungen wurde von der Nutzergemeinde sehr positiv und dankbar aufgenommen. Neben dem weiteren Fahrplan für das nächste Jahr wurde auch wieder viel über Wünsche und eventuelle Probleme der Anwenderschaft diskutiert.

Das bwLehrpool-Team bedankt sich für den spannenden Austausch und das große Interesse. Wir sehen uns spätestens nächstes Jahr - dann hoffentlich auch wieder ganz klassisch, analog und persönlich :).

Satellitenserver WS19/20

Es ist mal wieder soweit und wir geben die neue Hauptversion des bwLehrpool-Satellitenserver mit der Versionsnummer 3.9 frei. Die neuen Möglichkeiten und Funktionen wurden wie in den vorigen Jahren bereits auf unserem gemeinsamen Anwendertreffen - im Dezember 2019 an der Universität Mannheim - vorgestellt.

Damit Sie einen besseren Überblick über die Neuerungen haben und wissen, hinter welchem Bereich sich etwas Neues versteckt, stellen wir Ihnen diese im Folgenden nochmals vor. Bei Fragen können Sie sich wie immer gern direkt an uns wenden.

Satellitenserver aktualisieren

Die neue Version steht wie üblich als Updateskript zur Verfügung und kann auch über ältere Satellitenserver installiert werden. Bitte beachten Sie, dass auf dem Server jedoch mindestens Debian 9 vorausgesetzt wird. Falls Sie also noch einen sehr alten Satellitenserver einsetzen der unter Debian 8 läuft, müssen Sie diesen entweder händisch upgraden oder einen neuen Server mit dem letzten OVF (Sat 3.7) aufsetzen und anschließend das aktuelle Updateskript einspielen.

Achtung: Dies ist die letzte Version mit der alte 32 Bit Server und das alte PXE-Menü unterstützt werden. Ab der nächsten Version unterstützen wir nur noch Server, die unter 64 Bit laufen. Außerdem wird das alte pxelinux nicht mehr unterstützt, falls noch nicht geschehen wechseln Sie bitte auf den neuen iPXE-Ansatz.

Infos zum Einspielen des Updates finden Sie unter Satellitenserver aktualisieren. Denken Sie wie üblich daran, zur Sicherheit vor dem Update einen Snapshot anzulegen und evtl. die Konfiguration über das Webinterface zu sichern, für den Fall, dass irgendetwas schiefgehen sollte.

Die Changelogs finden Sie unter Changelogs.

Neuerungen

Neben den unten genannten neuen Funktionen wurden wieder viele kleine und größere Fehler oder Unstimmigkeiten in der Weboberfläche sowie im Linux-Grundsystem behoben. Im Folgenden werden daher nur die größten Änderungen kurz beschrieben.

Lokales Caching

bwLehrpool-Clients können nun VMs auf der lokalen Festplatte cachen. Erneute Starts der gleichen VM sind anschließend in den meisten Fällen schneller und belasten das Netzwerk deutlich weniger. Erste Tests haben jedoch gezeigt, dass eine Verbesserung der Bootgeschwindigkeit nur bei Clients mit SSDs zu beobachten ist.

Damit das lokale Caching aktiviert wird, müssen verschiedene Voraussetzungen erfüllt sein. Für weitere Informationen lesen Sie bitte den entsprechenden Wiki-Artikel: Lokales Caching

Netboot Grundsystem

MiniLinux vs. MaxiLinux

[{{ :allgemein:bwLehrpool-MaxiLinux-full.png?direct&300|MiniLinux vs. MaxiLinux}}]

bwLehrpool Clients booten bisher ein minimales Linux-Grundsystem (MiniLinux) auf dem anschließend Virtuelle Maschinen gestartet werden. Dieses MiniLinux wird auch noch einige Zeit parallel gewartet und weiterbetrieben. Auf lange Sicht wird es jedoch vom neuen MaxiLinux abgelöst werden. Dieses bietet ein vollwertiges Linux-System mit zusätzlichen Tools und Xfce4 als Desktopumgebung. In der Weboberfläche wurde der Punkt “bwLehrpool MiniLinux” folgerichtig in “Netboot Grundsystem” umbenannt. Dort können Sie die zur Verfügung stehenden Mini-/MaxiLinux Versionen auf Ihren Satellitenserver herunterladen. Über das Flaggen-Symbol definieren Sie den globalen Standard. Falls bestimmte Rechner oder Räume andere Versionen booten sollen, können Sie dies einfach über Menüeinträge (siehe unten Neuer Menüeintrag - “Netboot Grundsystem”) steuern.

Im Gegensatz zum MiniLinux, welches während des Bootvorgangs komplett über HTTP auf die Clients heruntergeladen wurde, wird das MaxiLinux on-demand über DNBD3 gestreamt und damit auch von verfügbaren DNBD3-Proxyservern verteilt. Benötigte Daten werden bei Bedarf einfach nachgeladen. Dadurch verändert sich die Bootzeit mit dem neuen MaxiLinux kaum, obwohl das Grundsystem von ~400MB auf über 2GB wächst. Der modernisierte Unterbau bietet viele neue Möglichkeiten. Studierende, die einfach nur kurz im Web recherchieren oder Drucken möchten, müssen keine VM mehr starten, sondern können die Aufgabe direkt im Linux-Grundsystem erledigen. Für Administratoren wird das Debugging leichter, weil im Grundsystem nun auch Tools wie z.B. iperf, wireshark, htop, manpages usw. zur Verfügung stehen oder kurzfristig nachinstalliert werden können. Die Infoscreens können nun Chromium zur Anzeige nutzen und müssen nicht mehr auf den minimalen slxbrowser ausweichen. Außerdem sind Docker und Singularity enthalten um containerbasierte Anwendungen auszuführen. Das ist insbesondere insofern interessant, als dass Docker-Container inzwischen auch nativ auf die Grafikkarte zugreifen können. Dies macht neuartige Anwendungsfälle wie beispielsweise im KI/ML-Bereich möglich. Dadurch, dass Daten nur bei Bedarf geladen werden, muss nicht mehr so stark auf ein möglichst schlankes Grundsystem geachtet werden und es können einfacher neue Tools integriert werden.

Kurze Zusammenfassung

Aus aktuellem Anlass: bwLehrpool und kritische Sicherheitslücken

Im Zuge der immer wiederkehrenden Diskussion um kritische Sicherheitslücken (aktuell u.a. Intel¹, 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 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³ 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 vorhanden⁴,
• 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.