Ein notwendiger Neustart verzögert das Kernel-Patching und macht Sie nicht konform

Kernel-Patching ist eine nicht enden wollende Aufgabe. Und warum? Weil Linux der König unter den Betriebssystemen ist. Aber es ist sehr, sehr kompliziert. Der Master-Zweig des Linux-Kernel-Git-Repository enthält mehr als 20.000.000 Zeilen von Menschen geschriebenen Code. Diese Komplexität macht Sicherheitslücken unvermeidlich. Jedes Jahr gibt es Hunderte von Schwachstellen, von denen einige sehr schwerwiegend sind.

Wie werden diese Schwachstellen bekämpft? Durch ständiges Kernel-Patching. Die Linux-Hersteller stellen laufend partielle Patch-Updates für den Kernel bereit. Einige Patches ändern eine einzige Codezeile, während andere fehlende Prüfungen hinzufügen oder Datenstrukturen oder Funktionen ändern. 

Die Sache ist die: Momentan kann das Kernel-Patching in 99 % der Unternehmen nur auf eine Weise erfolgen: durch einen Neustart der Server. 

Aber SysAdmins zögern (verständlicherweise) sehr, diesen Neustart durchzuführen, bis sie es unbedingt müssen. Ein Neustart kann ein langsamer und mühsamer Prozess sein. Um die Beeinträchtigung von Diensten in Spitzenzeiten zu minimieren, wird er in der Regel spät nachts und oft am Wochenende durchgeführt. Während die Server neu gebootet werden, fallen die Websites, die sie hosten, aus; Fehlermeldungen ersetzen schöne, funktionierende Websites. Und selbst nach dem Neustart kann es eine Weile dauern, bis sich die Leistung stabilisiert. Manchmal kommen die Umgebungen nach einem Neustart nie wieder richtig in Gang.

Aus diesem Grund verzögern SysAdmins den Neustart und damit auch das Kernel-Patching. Sie neigen dazu, zu warten, bis sich die Patch-Veröffentlichungen so weit angehäuft haben, dass sie nicht mehr ignoriert werden können. Sie bündeln Korrekturen, was bedeutet, dass die frühesten Korrekturen lange Zeit verfügbar sein können, bevor sie tatsächlich angewendet werden. Manchmal kann die Zeitspanne zwischen der Veröffentlichung eines Patches und seiner Anwendung Wochen oder sogar Monate betragen. 

Aber wenn man nicht alle Kernel-Patches so früh wie möglich durchführt, kann man sich Ärger einhandeln. 

• Zum einen ist es gefährlich. In einer Open-Source-Umgebung wird eine Kernel-Schwachstelle, sobald sie öffentlich bekannt wird, auch öffentlich bekannt. Das bedeutet, dass nicht nur die Linux-Betreiber davon wissen, sondern auch schlechte Akteure - Hacker und andere digitale Angreifer. Dies gilt umso mehr, als es in der Cybersicherheitsgemeinschaft üblich ist, die Bekanntgabe einer Sicherheitslücke mit der Veröffentlichung einer detaillierten Fallstudie zu verbinden. Diese Fallstudien sind für Sicherheitsexperten sehr nützlich, aber sie sind für Hacker ebenso nützlich.
• Zweitens birgt die Verzögerung des Kernel-Patchings für Unternehmen das Risiko der Nichteinhaltung von Vorschriften. In den Versicherungspolicen der meisten Unternehmen für Fehler und Auslassungen (E&O) und in den Klauseln ihrer SLA-Verträge ist die Einhaltung der Best Practices festgelegt. Normalerweise beträgt dieser Zeitraum gemäß den Best Practices der Branche nicht mehr als einen Monat. Der Druck des Neustarts bedeutet, dass Unternehmen häufig (viel) länger als einen Monat brauchen und damit gegen ihre Versicherungspolicen verstoßen. 

Ein Neustart bereitet Kopfzerbrechen, weshalb die Leute ihn so lange wie möglich aufschieben. Aber: Wenn Sie nicht neu booten müssen, müssen Sie auch Ihr Kernel-Patching nicht aufschieben. Die Lösung? Rebootloses Live-Kernel-Patching.

Mit KernelCare lädt der Agent einen neuen Patch für den aktiven Kernel herunter und wendet ihn sofort an, sobald er verfügbar ist. Mit diesem System werden Kernel-Updates so schnell wie möglich angewendet, um Sie vor böswilligen Akteuren zu schützen und die Einhaltung der Vorschriften zu gewährleisten. Dies geschieht, ohne dass der Kernel auch nur einen Moment ausfällt oder sein Betrieb unterbrochen wird. 

Aber bei KernelCare haben wir 300.000 Server, die seit vier Jahren nicht mehr neu gebootet werden mussten, um ihren Kernel zu patchen. KernelCare ist einfach, in fünf Minuten installiert und läuft dann im Hintergrund weiter, ohne dass jemand daran denken muss.

Um zu erfahren, warum das Neustarten Ihrer Server Sie unsicher und nicht konform macht - und warum es nur eine Frage der Zeit ist, bis Sie dies auf die harte Tour feststellen - lesen Sie hier unser vollständiges Whitepaper.

Lesen Sie weiter:

Die Gefahr von Kernel-Schwachstellen und die Bedeutung von Live-Patching