ClickCease Rebooten oder nicht rebooten? Das ist die Frage für viele Sysadmins - TuxCare

Abonnieren Sie unseren beliebten Newsletter

Schließen Sie sich 4.500+ Linux- und Open-Source-Experten an!

2x im Monat. Kein Spam.

Rebooten oder nicht rebooten? Das ist die Frage für viele Sysadmins

12. November 2020. TuxCare PR Team

Rebooten oder nicht rebooten? Das ist die Frage für viele Sysadmins.Ein Server-Neustart-Zyklus ist ein allgemeiner Name für den Prozess des Neustarts einer Serverflotte in einem Unternehmen. Dies kann verschiedene Gründe haben, aber oft ist es so, dass Patches und Updates einen Neustart erfordern - sie betreffen entweder eine kritische Komponente des Betriebssystems oder eine gemeinsam genutzte Bibliothek, die von mehreren Komponenten oder Programmen verwendet wird. Die Anzahl der Server, die neu gebootet werden müssen, wirkt sich direkt auf die Dauer der Operation und das damit verbundene Risiko aus. Je mehr Server aktualisiert werden müssen, desto schwieriger ist der Planungs- und Ausführungsprozess.

Um Unternehmen eine Möglichkeit zu bieten, solche Sicherheitsaktualisierungen ohne Neustart durchzuführen, wurde das Live-Patching entwickelt. Der Hauptvorteil dieser Methode besteht darin, dass kein Neustart erforderlich ist, wodurch sich die typischen Patching-Zyklen um 60 Prozent reduzieren. Dennoch arbeiten viele Unternehmen mit Reboot-Zyklen und nicht mit der Live-Patching-Methode. Gibt es dafür einen Grund? Hier werden wir das Problem untersuchen.

Inhalte:

  1. Risiko der Aktualisierung. Risiko bei Nichtaktualisierung:
    Equifax: Ein abschreckendes Beispiel
    Verlangsamt Live-Patching die Systeme?
  2. Rebooting vs. Rebootless
  3. Der Gewinner: Pfadfindung ohne Neustart
  4. Schlussfolgerung

 

Risiken der Aktualisierung. Risiken bei Nichtaktualisierung.

Risiken der Aktualisierung. Risiken bei Nichtaktualisierung.

Wenn Sie Ihren Kernel aktualisieren, gibt es immer neue potenzielle Risiken Das ist einer der Gründe, warum manche Unternehmen die Live-Patching-Updates noch nicht angenommen haben. Wenn ihre Server bereits stabil sind, eine angemessene Geschwindigkeit aufweisen und keine neuen Funktionen benötigen, möchten sie vielleicht nicht die für die Anwendung der Patches erforderliche Ausfallzeit des Servers riskieren. Auch wenn diese Gründe durchaus nachvollziehbar erscheinen, gibt es einen Grund, warum Sie unbedingt einen Patch einspielen sollten, selbst wenn Sie einen oder mehrere dieser Gründe haben: Sicherheit.

Sobald ein neuer Kernel-Patch angekündigt wird, suchen Hacker nach Möglichkeiten, die gepatchte Sicherheitslücke auszunutzen. Wenn Sie diesen Patch nie aktualisieren, lassen Sie Hackern immer eine Hintertür offen, um in Ihre Systeme einzudringen. Genau aus diesem Grund finden wir immer noch Hacker die HeartBleed-Sicherheitslücke ausnutzen ausnutzen, obwohl der Patch zur Behebung dieser Schwachstelle bereits 2014 veröffentlicht wurde. Es handelt sich um eine der verheerendsten Sicherheitslücken, und dennoch haben einige Systeme immer noch nicht den Patch angewendet, um Hackern diese Hintertür zu nehmen.

 

Equifax: Ein abschreckendes Beispiel

Equifax: Ein abschreckendes Beispiel

Laut einer Ponemon-Umfrage gaben 60 Prozent der Befragten an, dass eine oder mehrere der Sicherheitsverletzungen, die ihr Unternehmen im letzten Jahr erlitten hat, auf eine bekannte Sicherheitslücke zurückzuführen sind, für die ein Patch zur Verfügung steht, das jedoch nie angewendet wurde. Etwa 88 Prozent der Befragten gaben an, dass sie sich mit anderen Abteilungen in ihrem Unternehmen abstimmen müssen, bevor sie ein Patch aufspielen können, was die Aufspielung um bis zu 12 Tage verzögern kann. Je länger die Verzögerung, desto mehr Zeit haben Hacker, eine Hintertür in Ihr System zu finden.

Die Sicherheitsverletzung bei Equifax 2017 ist ein Paradebeispiel für eine Sicherheitslücke, für die ein Patch nicht angewendet wurde. Equifax war sich der Apache-Struts-Schwachstelle (CVE-2017-5638) bewusst, hat das System aber nicht gepatcht. Der damalige CEO von Equifax sagte, dass sie die Schwachstelle bei ihren Scans des Systems nicht gefunden hätten, so dass der Patch nicht wie vorgesehen angewendet worden sei. Da das Patch nicht angewendet wurde, wurden die Daten von 145,5 Millionen Amerikanern gestohlen. Hätten sie ein Live-Patching-System verwendet, hätte diese Datenpanne vermieden werden können.

 

Verlangsamt Live-Patching die Systeme?

Verlangsamt Live-Patching die Systeme?

Manche entscheiden sich gegen den Wechsel zu Live-Patching, weil sie glauben, dass Live-Updates ihre Systeme verlangsamenund selbst eine geringe Verlangsamung kann zu Problemen für ein Unternehmen führen. Es gibt eine Reihe von Faktoren, die ein System verlangsamen können, darunter Schwachstellen selbst und die Verwendung von temporären Patches anstelle von dauerhaften.

Beim temporären Patching werden die Updates zwar auf den Server aufgespielt, aber Sie müssen ihn neu starten, um die Patches vollständig anzuwenden. Außerdem werden die Patches immer noch übereinander gestapelt und können das System von selbst verlangsamen. Beim persistenten Live-Patching wird alles erledigt, ohne dass ein Neustart erforderlich ist oder das System verlangsamt wird.

 

Rebooting vs. Rebootless

Rebooting vs. Rebootless

Beim Vergleich von Live-Patching und regulärem Patching mit Reboots müssen mehrere Aspekte berücksichtigt werden, da sich der Vergleich je nach Art des Systems ändert.

Physische Server: Bei physischen Servern dauert ein Neustart immer mindestens ein paar Minuten, da der Selbsttest beim Einschalten (POST) durchgeführt wird, um die Hardwarekomponenten zu überprüfen. In diesem Fall ist es immer schneller und effizienter, ein Live-Patching durchzuführen, da es weniger Zeit in Anspruch nimmt und die Serviceverfügbarkeit höher ist. Dies ist der typische Fall, in dem Live-Patching mit KernelCare Enterprise in jeder Hinsicht besser ist.

Thick virtualisierte Server: Bei stark virtualisierten Servern ist die Neustartzeit ein geringerer Faktor, aber auch hier kommt es zu einer gewissen Ausfallzeit, wenn regelmäßige Patches und Neustarts durchgeführt werden. Dies wirkt sich auf andere Systeme aus, beeinträchtigt die Redundanz der bereitgestellten Dienste, erfordert ein Wartungsfenster und hat größere Auswirkungen als Live-Patching.

Dünn virtualisierte Server: Auf dünn virtualisierten Systemen könnten die Dinge ausgewogener sein, da der Neustart eines Containers der Zerstörung und Neuerstellung desselben gleichkommt, und dies ist der optimale Anwendungsfall für Container. Ein Container teilt sich jedoch den Kernel mit dem Host, auf dem er läuft, so dass das Live-Patching des Host-Kernels mit KernelCare Enterprise bedeutet, dass auch die Container automatisch gepatcht werden. Das ist besser, denn so entfällt die Notwendigkeit, den Container herunterzufahren und neu zu erstellen, wie schnell oder langsam das auch sein mag.

Server vergleichen Tabelle

Bei der Durchführung dieses Vorgangs auf mehreren Servern muss die Verfügbarkeit der Dienste aufrechterhalten werden, und das ist einfacher, wenn man viele Server hat. Das bedeutet, dass größere Organisationen dies effizienter durchführen können als kleinere Organisationen, da sie über mehr redundante Server verfügen. Doch selbst im besten Fall vollständig containerisierter Dienste hat das Live-Patching auf den Host-Servern weniger Auswirkungen als die Neuerstellung der Container mit aktualisierten Versionen.

 

Der Gewinner: Patchen ohne Neustart

Der Gewinner: Patchen ohne Neustart

Wie die Sicherheitslücke bei Equifax und die fortgesetzte Ausnutzung der HeartBleed-Schwachstelle sechs Jahre später gezeigt haben, besteht die einzige Möglichkeit, Sicherheitslücken zu vermeiden, darin, Patches schnell zu installieren. Die für den Neustart eines Systems erforderliche Ausfallzeit kann jedoch dazu führen, dass das System verwundbar bleibt. Die einzige Lösung ist ein Live-Patching-System, das keinen Neustart erfordert.

 

Schlussfolgerung

Wenn ein System aus 1.000 oder mehr Servern besteht, kann es schwierig sein, sie alle allein auf dem neuesten Stand zu halten, insbesondere wenn Sie Ausfallzeiten zwischen den Abteilungen koordinieren müssen. KernelCare Enterprise bietet Live-Patching ohne Neustart, so dass Sie keine Ausfallzeiten haben und Ihr System nicht durch ungepatchte Schwachstellen gefährdet wird. Halten Sie Ihre Unternehmensserver immer auf dem neuesten Stand und schützen Sie sie mit KernelCare Enterprise vor Datenverletzungen.

Erhalten Sie eine KOSTENLOSE 7-Tage-Testversion von KernelCare 

 

 

Möchten Sie das Patchen von Sicherheitslücken ohne Kernel-Neustart, Systemausfallzeiten oder geplante Wartungsfenster automatisieren?

Erfahren Sie mehr über Live-Patching mit TuxCare

Werden Sie ein TuxCare-Gastautor

Los geht's

E-Mail

Beitreten

4,500

Linux & Open Source
Fachleute!

Abonnieren Sie
unseren Newsletter