Frage Bedeutet die Virtualisierung eines Servers eine andere Betriebssystemebene, die gepatcht und aktualisiert werden muss, mehr Arbeit und ein höheres Risiko?


Ich habe eine Suche durchgeführt und nichts gefunden, was Probleme bezüglich Patching und Systemupdates betrifft. Ich habe Richtlinien, die sagen, dass Server notwendige Patches haben müssen. Wenn ich einen VM-Host habe, ist das eine zusätzliche Ebene zum Patchen und Aktualisieren - sogar mit Bare-Metal-Hypervisoren? Im Gegensatz zu einem Metallserver? (dh mehr Arbeit und Tests und Dokumentation gemäß meinen Richtlinien).

Wie oft werden 1 / Bare-Metal-Hypervisoren aktualisiert? Spielt das eine Rolle? Führt die Tatsache, dass es sich um eine zusätzliche Softwareschicht handelt, zu mehr Komplexität und erhöhtem Risiko (Sicherheit und Zuverlässigkeit)? (zB 99% fehlerfreie Software x 99% fehlerfreie Software = 98% fehlerfreies System)?

(Meine praktische Erfahrung ist mit VMWare Workstation und Server und VirtualBox.)


26
2018-02-15 09:59


Ursprung


Beantwortet das deine Frage? - ewwhite
Ich denke, es beantwortet die Hälfte davon .... - user127379


Antworten:


Ja, Produkte wie VMware sollten manchmal gepatcht werden (die Aktualisierungen sind kumulativ), aber die Patches kommen seltener als ein Mainline-Betriebssystem und der potenzielle Angriffsvektor ist kleiner - Ihr Hypervisor sollte nicht öffentlich zugänglich sein.

Ich werde VMware ESXi Version 5.0 (nicht 5.1) als Beispiel verwenden ...

ESXi 5.0 hat den folgenden Update-Zeitplan:

Zwischen 9/2011 und heute gab es ZEHN Updates für das ESXi 5.0-Produkt. Aus diesen, SECHS wurden sicherheitsrelevante Updates in die Updates-Pakete mit Beschreibungen wie:

"ESXi NFS-Parsing-Schwachstelle" - CVE-2012-2448.

Diese Sicherheitslücken sind real, da sie manchmal allgemeine Linux-Sicherheitsfehler widerspiegeln, aber ich denke, die meisten Organisationen sind nicht sehr anfällig für die Risiken. Es liegt jedoch am Ingenieur, dieses Risiko zu bewerten. Würden Ihre Benutzer massive Downtime benötigen, um das Problem zu beheben? folgenden Exploit?

Msgstr "Der Makro encode_name in misc / mntent_r.c in der GNU C Library (aka   glibc oder libc6) 2.11.1 und früher, wie von ncpmount und verwendet   mount.cifs behandelt Newline-Zeichen in Mountpoint nicht korrekt   Namen, die es lokalen Benutzern ermöglichen, einen Denial of Service (mtab   Korruption), oder moechte mount moeglichkeiten modifizieren und Privilegien erlangen, via   eine präparierte Mount-Anfrage. "

Könnte sein? Vielleicht nicht.

ich renne VMware Update Manager, aber neigen nur dazu, zu aktualisieren, wenn ich von einem Fehler betroffen bin oder eine Funktionserweiterung benötige. Wenn es in einem Cluster-Setup ausgeführt wird, ist das Patchen einfach, ohne Ausfallzeiten für die laufenden VMs. Wenn keine anderen dringenden Gründe vorliegen, werde ich mich bemühen, vierteljährlich zu aktualisieren. Einzelne Hosts benötigen einen vollständigen Neustart, da die Patches als monolithische Images bereitgestellt werden.

Als Nebenbemerkung: Wenn ich ein VMware ESXi-Setup erwerbe oder an einem System arbeite, das ich normalerweise nicht betreue, sehe ich oft Hosts, die das haben noch nie hatte irgendwelche VMware-Patches angewendet. Das ist falsch!! Aber ich kann sehen, wie Administratoren diesen Fehler machen können, sobald die Systeme betriebsbereit sind.


20
2018-02-15 10:58



Fügen Sie dazu hinzu, dass eine normale VmWare-Infrastruktur freie Kapazität haben sollte - Sie können die VMs also auf andere Hosts verschieben und patchen. Mehr Arbeit - ja (MS iirc kann das automatisch machen), aber nicht mehr Ausfallzeiten. - TomTom
Noch besser ist es, wenn noch nie jemand Firmware oder Treiber aktualisiert hat - SpacemanSpiff
Sie sagen also: 1. Ja, es ist mehr Arbeit Patch-und Update, Dokumentation und Tests vs Metall-Server (jedoch weniger Ausfallzeiten, weil Sie den VM-Server "bewegen" und "Flip"). 2. Bare-Metal-Hypervisors erhalten / müssen weniger häufig aktualisiert werden als Mainline-Betriebssysteme. Beispiel ESXi 5.0 mit 10 Updates in 5 Monaten. Es wird jedoch einige Linux-Fehler für die Hypervisor auf Linux-Basis geben. - user127379


Das ist eine ziemlich gute Frage, wenn Sie mit der Virtualisierung mit Bare-Metal-Hosts noch nicht vertraut sind. Wenn Sie auf diese Art und Weise vorgehen, ist eine andere Denkweise erforderlich als bei Hypervisoren, die als Service / Anwendung auf einem konventionellen Betriebssystem ausgeführt werden.

Nach meiner Erfahrung ist es wahrscheinlich fair zu sagen, dass ESX und HyperV brauchen Weniger Patching insgesamt als herkömmliche Betriebssysteme. Diese nicht bedeutet, dass sie überhaupt nicht gepatcht werden müssen, oder dass die Anwendung einiger Patches unabhängig vom "Bedarf" nicht vorteilhaft wäre, aber dies bedeutet, dass Unterbrechungen zu Ihren Diensten, um den Host zu patchen, weniger häufig und mehr unter Ihrer Kontrolle sein sollten . Es besteht ein potenzielles Sicherheitsrisiko für die Hypervisor-Betriebssysteme, so wie es auch für andere gilt, und Sie können das Risiko minimieren (z. B. nur das Hypervisor-Management in einem isolierten VLAN, das von einem kompromittierten Server aus nicht erreichbar ist). es wäre töricht, so zu tun, als gäbe es überhaupt kein Risiko.

Wenn Sie zum Beispiel 4 nicht-virtuelle Server haben und diese alle auf den gleichen virtualisierten Host verschieben, erhöhen Sie die Anzahl der Unterbrechungen, die durch das Patchen des Host-Systems (oder durch das Problem mit dem System) entstehen könnten ein Hardware-Problem, usw., für diese Angelegenheit).

Ich würde zwar vorschlagen, dass dieses Risiko besteht verhältnismäßig low (Ich spreche vom Unterschied zwischen dem Patchen eines virtuellen Hosts und der Art des Patchens, das einen Neustart erfordert, den Sie mit einem eigenständigen System durchführen müssten sowieso), dass die Auswirkungen hoch sind.

Warum machen wir es dann?

Der wahre Vorteil der Virtualisierung besteht darin, dass Sie mehr als einen Host einrichten und die Hosts für die Zusammenarbeit konfigurieren können. So können Gäste von einem Host zum anderen verschoben werden, falls ein Host fehlschlägt oder Sie Patches planen möchten die Host-Systeme.

Mit diesem Ansatz habe ich es geschafft, 5 ESX-Hosts nacheinander zu patchen ohne jegliche Störung zu den 40 virtuellen Servern, die auf ihnen laufen. Dies ist einfach eine Frage der Größenvorteile - sobald Sie genug potenzielle virtuelle Gastmaschinen haben, um es sich zu lohnen, ein solches komplexes Setup zu bauen und es mit den Tools zu verwalten, die @ewwhite in seiner Antwort erwähnt, die Rückzahlung der Risiken Sie sind besorgt, dass es sehr schnell ankommt.


6
2018-02-15 10:59





Ein virtueller Server erfordert die gleiche Wartung und die gleichen Patches wie ein physischer Server. Bare-Metal-Hypervisors erfordern aus Sicherheitsgründen jedoch auch Updates, um Fehler zu beheben und die Leistung zu verbessern. Je mehr Server Sie haben, desto mehr Arbeit müssen Sie tun, um sie auf dem neuesten Stand zu halten, egal ob physisch oder virtuell.


4
2018-02-15 10:03





Basierend auf den obigen Antworten scheint es: Die Virtualisierung eines Servers hat zu mehr Komplexität und erhöhtem Risiko für Sicherheit und Zuverlässigkeit geführt. Dies muss jedoch gegen die Vorteile abgewogen werden, die sich aus der Reduzierung von Ausfallzeiten durch Virtualisierung eines Servers ergeben.

Wenn Ihre Umgebung Prüfungen, Tests und Dokumentationen erfordert, muss der Kosten-Nutzen-Effekt der zusätzlichen Arbeitslast einer virtualisierten Umgebung mit der Anzahl der Server und Systemmitarbeiter berücksichtigt werden, die Sie haben. In unserer Umgebung haben wir nicht die Zeit, um den Audit-Trail für eine virtualisierte Umgebung zu verwalten. In unseren Geschäftsprozessen können wir einige Ausfallzeiten hinnehmen, aber wir dürfen keinen Audit Trail und Dokumentation verpassen.


0
2018-05-09 10:47