Vergleich von KernelCare
mit Red Hat kpatch

Die meisten Anbieter von Enterprise-Linux-Distributionen liefern mittlerweile ein Tool für Live-Patches mit; bei Red Hat ist dies „kpatch“, das bereits 2014 in RHEL integriert wurde. Das dazugehörige Open-Source-Upstream-Projekt wird jedoch mittlerweile nicht mehr weiterentwickelt. „kpatch“ wendet Kernel-Korrekturen auf einen laufenden Server an, sodass Sicherheitsupdates nicht mehr auf ein Wartungsfenster warten müssen.

Das Problem ist, wie wenig damit abgedeckt wird. kpatch patcht nur etwa 10 % der CVEs, die ein System betreffen, lässt den Userspace dabei komplett außer Acht, und die Gültigkeit der Abdeckung läuft pro Kernel nach etwa einem Jahr ab, was genau die Neustarts erzwingt, die durch Live-Patching eigentlich vermieden werden sollten. Hinzu kommt, dass ein derart begrenzter Schutz weiterhin an teure RHEL-Abonnements gebunden ist.

KernelCare von TuxCare wurde entwickelt, um diese Lücken zu schließen. Es patcht jede Kernel-CVE unabhängig vom Schweregrad, erstreckt sich über LibCare auch auf OpenSSL und glibc und bietet kontinuierlichen Schutz ohne erzwungene Neustarts – und das alles für nur 50 US-Dollar pro System und Jahr. Der folgende Vergleich zeigt im Detail, worin sich die beiden Lösungen unterscheiden.

	Red Hat kpatch	KernelCare
Unterstützte Distributionen	Nur Red Hat Enterprise Linux	Red Hat Enterprise Linux 6, 7, 8, 9 sowie Ubuntu, Oracle, AlmaLinux und viele andere
Schwachstellen gepatcht	❌ Nur ~10 % der CVEs (ausgewählte „Important“- und „Critical“-CVE-Einträge für den Kernel)	✅ Bis zu 100 % Abdeckung
Abdeckung des Linux-Kernels und kritischer Bereiche des Userspace (OpenSSL, glibc)	❌ Nur Kernel	✅ Ja
Unterstützung der ARM64-Architektur	❌ Nur x86-64	✅ Ja
Live-Patching für jeden laufenden Kernel	❌ Nur zulässige Kernel auswählen	✅ Ja
Praktisch unbegrenzte Lebensdauer des Kernel-Patchings	❌ Etwa ein Jahr pro Kern	✅ Ja
Integrierte automatische -Patches	❌ Kein spezieller Agent; Patches werden als RPMs bereitgestellt und über yum/dnf oder Satellite installiert	✅ Der Agent überprüft und installiert neue Patches automatisch
Live-Patching für „ “ Betriebssystem am Ende seines Lebenszyklus	❌ Nicht im kostenpflichtigen Add-on „Extended Life-cycle Support“ enthalten	✅ Red Hat Enterprise Linux 6, 7 sowie Ubuntu, Oracle, AlmaLinux und viele andere
Roll-Back-Funktion ohne Neustart	❌ Nach einem Neustart	✅ Ohne Neustart
Lieferung von individuell gestalteten Aufnähern	❌ Eigenimplementierung mit kpatch-build; wird nicht als Dienst bereitgestellt oder unterstützt	✅ Vollständig verwaltet
Zentralisierte und luftisolierte Verwaltung	❌ Erfordert Red Hat Satellite (separate Lizenz)	✅ Im Lieferumfang enthalten (ePortal)
API verfügbar	❌ Für die zentralisierte API ist Red Hat Satellite erforderlich (separate Lizenz)	✅ Im Lieferumfang enthalten (ePortal)
Verteilung eines einzigen Patchsets für alle Patches	✅ Ja	✅ Ja
Im Vorfeld aktiv entwickelt	❌ Veraltet, im Wartungsmodus	✅ Ja
24/7 Support	❌ Nur Schweregrade 1 und 2, Premium-Abonnenten	✅ Online, rund um die Uhr, 365 Tage im Jahr
Add-ons	–	LibCare, individuelle Aufnäher
Art des Patchings	Persistent	Persistent
Kosten	Erfordert ein aktives RHEL-Abonnement: 878,90 $ (Standard) oder 1.428,90 $ (Premium) pro System und Jahr; EUS-Erweiterung: +273,90 $	Ab 50 $ pro System und Jahr, Mengenrabatte möglich

Die Grafik zeigt, wo sich die beiden unterscheiden. Im weiteren Verlauf dieses Vergleichs wird erläutert, was die einzelnen Unterschiede für die von Ihnen tatsächlich betriebenen Systeme bedeuten.

Live-Patching sollte die Systeme abdecken, die Sie tatsächlich betreiben, ganz gleich, aus welcher Kombination von Distributionen diese bestehen. kpatch wird von Red Hat-Entwicklern erstellt und gepflegt, sodass es sich in der Praxis um ein RHEL-Tool handelt; und selbst innerhalb von RHEL fallen RHEL 6 und einige RHEL 7-Versionen nicht in den Supportbereich. Eine Handvoll Nicht-RHEL-Distributionen, wie bestimmte Ubuntu-, Debian- und Gentoo-Versionen, werden technisch unterstützt, jedoch nur, wenn Sie die Live-Patches selbst erstellen – was fundierte Kernel-Kenntnisse erfordert und ein echtes Risiko birgt, falls dabei Fehler auftreten.

KernelCare vertritt den gegenteiligen Standpunkt. Es führt von Haus aus Live-Patches für RHEL, Ubuntu, Debian, Oracle Linux, AlmaLinux, Rocky Linux, Amazon Linux und weitere Distributionen durch. Für Unternehmen, die derzeit nur eine einzige Distribution einsetzen, mag dies heute noch nicht entscheidend erscheinen, doch es bedeutet, dass Sie nur ein Tool und einen Arbeitsablauf benötigen, falls Ihre Infrastruktur jemals über RHEL hinauswachsen sollte.

Der Sinn und Zweck von Live-Patching besteht darin, Sicherheitslücken schnell zu beheben. Daher lautet die erste Frage: Welche Sicherheitslücken behebt ein Tool tatsächlich? Unsere eigenen Untersuchungen haben ergeben, dass kpatch nur etwa 10 % der CVEs, die ein System betreffen, per Live-Patching behebt, wobei ein Teil dieser Lücke beabsichtigt ist.

kpatch patcht live nur die Kernel-CVEs, die Red Hat selbst als „Important“ oder „Critical“ einstuft, und diese Schwelle ist niedriger, als es den Anschein hat. Red Hat vergibt eigene Schweregrade, die von der Einstufung eines CVE in der National Vulnerability Database abweichen können; daher kann eine Schwachstelle, die anderswo als „Critical“ eingestuft wird, herabgestuft und übersprungen werden. Diese Einstufungen gehen zudem von einer typischen Konfiguration aus. Daher kann ein CVE, das Red Hat niedriger einstuft, in Ihrer spezifischen Umgebung dennoch ein ernstes Sicherheitsrisiko darstellen – erhält jedoch keinen Live-Patch und muss bis zum nächsten Kernel-Update und einem Neustart warten. Und selbst unter den CVEs, die Red Hat als „Important“ oder „Critical“ einstuft, garantiert laut eigener Dokumentation nicht für alle ein Live-Patch.

KernelCare macht Schluss mit dem Rätselraten, indem es alle Kernel-CVEs unabhängig von ihrer Schweregradbewertung per Live-Patching behebt, sodass die Abdeckung nicht davon abhängt, wie eine bestimmte CVE bewertet wurde.

Live-Patching sollte die Sicherheit des gesamten Systems ohne Neustarts gewährleisten, doch kpatch greift ausschließlich auf den Kernel zu. Jede Sicherheitslücke in Bibliotheken des Userspace – einschließlich der OpenSSL- und glibc-Schwachstellen, die hinter Vorfällen wie Heartbleed, GHOST und Looney Tunables stehen – erfordert nach wie vor ein Paket-Update und einen Neustart des Dienstes oder der Anwendung. Da diese Bibliotheken fast allen von Ihnen ausgeführten Programmen zugrunde liegen, kann ein einziger glibc- oder OpenSSL-Patch einen Neustart eines Großteils des Stacks erfordern.

KernelCare schließt diese Lücke mit LibCare, indem es Shared Libraries wie OpenSSL und glibc im Speicher patcht, ohne die davon abhängigen Anwendungen neu zu starten. Das Patchen kritischer Bereiche im Userspace ohne Ausfallzeiten ermöglicht es Teams, die Fristen für Abhilfemaßnahmen gemäß PCI DSS, SOC 2 und FedRAMP auf Systemen einzuhalten, die nicht offline genommen werden können.

Live-Patching sollte jeden Server in Ihrer Infrastruktur schützen, nicht nur diejenigen, die auf einem bestimmten Prozessor laufen. kpatch führt Live-Patches für x86-64 und ppc64le durch, wodurch Arm64-Systeme gänzlich ohne Live-Patching bleiben. Da Arm zunehmend im Rechenzentrum und in der Cloud Einzug hält, wird dies zu einem immer größeren Schwachpunkt.

KernelCare unterstützt sowohl x86-64 als auch Arm64, sodass derselbe Schutz ohne Neustart gilt, unabhängig davon, ob eine Workload auf herkömmlicher x86-Hardware oder auf Arm-Hardware ausgeführt wird.

Live-Patches sollten den von Ihnen tatsächlich verwendeten Kernel abdecken, doch kpatch wendet nur auf einen Teil davon Patches an. Es führt Live-Patches für die von Red Hat einmal pro Quartal festgelegten, für kpatch geeigneten Basis-Errata-Kernel durch. Sofern Ihr System also nicht einen dieser festgelegten Kernel verwendet, erhalten Sie keine Live-Patches, bis Sie auf einen solchen umsteigen.

KernelCare unterliegt keinerlei Einschränkungen hinsichtlich der Eignung. Unabhängig davon, welcher Kernel geladen ist, wird dieser gepatcht, sodass sich der Schutz an Ihre Systeme anpasst, anstatt dass diese einer Liste folgen müssen.

Selbst wenn Sie einen unterstützten Kernel verwenden, ist der Support zeitlich begrenzt. Jeder unterstützte Kernel erhält etwa ein Jahr lang Live-Patches; danach müssen Sie den Kernel aktualisieren und einen Neustart durchführen, um weiterhin Fehlerbehebungen zu erhalten. Diese Einschränkung macht den Zweck der Lösung stillschweigend zunichte. Anstatt Neustarts zu vermeiden, verschiebt kpatch diese lediglich, sodass Sie letztendlich doch Wartungsfenster entsprechend dem Kalender des Anbieters planen müssen.

KernelCare legt keine solche Frist fest, sondern patcht jeden Kernel für eine praktisch unbegrenzte Lebensdauer, sodass Sie auf Ihrem bestehenden Kernel geschützt bleiben, ohne dass ein jährlicher Neustart erforderlich ist.

Live-Patching sollte unauffällig im Hintergrund ablaufen und nicht zu einer weiteren Verwaltungsaufgabe werden. kpatch verfügt über keinen eigenen Agenten für die automatische Patch-Verwaltung. Patches werden als RPMs bereitgestellt, die Sie über yum oder dnf installieren oder mit Satellite ausrollen können. Das bedeutet, dass die Aktualisierung entweder eine manuelle Verwaltungsaufgabe ist oder mithilfe allgemeiner Update-Tools durchgeführt wird.

KernelCare installiert einen schlanken Agenten, der automatisch nach neuen Patches sucht und diese anwendet und sich in Ihre bestehende IT-Automatisierung integrieren lässt. Sobald die Lösung implementiert ist, gehört die regelmäßige Aktualisierung der Systeme nicht mehr zu den wiederkehrenden Routineaufgaben.

Red Hat stellt während der Extended-Life-Phase keine „kpatch“-Live-Patches zur Verfügung, auch nicht im Rahmen des kostenpflichtigen Zusatzmoduls „Extended Life-Cycle Support“. Sobald eine Version das Ende ihres Lebenszyklus erreicht hat, entfällt die Möglichkeit zum Live-Patching, selbst wenn Sie weiterhin für Sicherheits-Errata bezahlen.

KernelCare geht den umgekehrten Weg. Das Unternehmen stellt weiterhin Live-Patches für Distributionsversionen bereit, deren Lebenszyklus bereits abgelaufen ist, wie beispielsweise CentOS 7, Ubuntu 18.04, Debian 10, RHEL 7 und viele andere. So bleiben die Systeme, die Sie nicht termingerecht außer Betrieb nehmen können, weiterhin geschützt, während Sie die Umstellung nach Ihrem eigenen Zeitplan planen.

Live-Patching sollte reversibel sein, da eine Korrektur gelegentlich wieder rückgängig gemacht werden muss, beispielsweise wenn eine Abhilfemaßnahme mit Leistungseinbußen verbunden ist (wie es bei einigen Spectre- und Meltdown-Korrekturen der Fall war) und eine alternative Abhilfemaßnahme zur Verfügung steht.

kpatch kann dies nicht leisten. Das Rückgängigmachen eines Live-Patches erfordert einen Neustart, wodurch aus einem problematischen Patch eine geplante Ausfallzeit wird und genau der Vorteil zunichte gemacht wird, der Live-Patching so attraktiv gemacht hat. Mit KernelCare hingegen können Sie jeden angewendeten Patch mit einem einzigen Befehl und ohne Neustart rückgängig machen, sodass das Rückgängigmachen eines Patches ebenso wenig Auswirkungen hat wie dessen Anwendung.

In manchen Umgebungen ist ein Fix erforderlich, den der Anbieter noch nicht bereitgestellt hat, oder ein auf den eigenen Code zugeschnittener Patch. Mit kpatch ist das eine Aufgabe, die man selbst erledigen muss: Man erstellt den Patch selbst mit kpatch-build, ohne dass eine verwaltete Bereitstellung oder Support dafür angeboten wird. Für die meisten Teams stellt das erforderliche Kernel-Fachwissen an sich schon eine Hürde dar.

KernelCare bietet vollständig verwaltete, maßgeschneiderte Patches, die TuxCare für Sie erstellt, testet und pflegt. Sie erhalten die benötigte Korrektur, ohne den Aufwand und das Risiko auf sich nehmen zu müssen, Live-Patches intern zu erstellen.

In jeder nennenswerten Größenordnung muss das Live-Patching zentral verwaltet werden, und zwar zunehmend in Umgebungen ohne Internetzugang. Bei kpatch bedeutet eine zentralisierte Bereitstellung die Einrichtung eines separat lizenzierten Red Hat Satellite – was zusätzliche Kosten verursacht und ein weiteres System mit sich bringt, das betrieben werden muss.

KernelCare umfasst ePortal, einen lokalen privaten Patch-Server für schrittweise Rollouts, kontrollierte Bereitstellungen und vollständig isolierte Netzwerke – und das ohne zusätzliche Lizenzkosten. Die Funktion, für die bei Red Hat zusätzliche Kosten anfallen, ist bei TuxCare bereits im Paket enthalten.

Moderne Patching-Vorgänge sollten skriptfähig sein und in die übrige Automatisierung eingebunden werden. kpatch bietet keine native API, sodass alle API-gesteuerten Vorgänge erneut über Red Hat Satellite abgewickelt werden.

KernelCare umfasst die ePortal-API für die Registrierung, Verwaltung und Ansible-Automatisierung, sodass sich Live-Patching ohne separates Verwaltungsprodukt in bestehende Pipelines integrieren lässt.

Die Wahl eines Patching-Tools ist eine langfristige Entscheidung, daher ist der Zustand des Projekts von großer Bedeutung. Das vorgelagerte Open-Source-Projekt „kpatch“ befindet sich mittlerweile im Wartungsmodus, wobei die Erstellung von Patches im Mainline-Kernel auf „klp-build“ umgestellt wurde. KernelCare hingegen wird aktiv weiterentwickelt und erhält kommerziellen Support für verschiedene Distributionen und Architekturen – genau diese Art von Entwicklungspfad wünscht man sich für eine Infrastruktur, die über Jahre hinweg laufen soll.

Wenn eine Frage zu einem Patch dringend wird, kommt es auf die Reaktionszeit an. Der Rund-um-die-Uhr-Support von kpatch ist auf Fälle der Schweregrade 1 und 2 beschränkt und steht nur Premium-Abonnenten zur Verfügung, sodass Probleme mit niedrigerem Schweregrad bis zu den Geschäftszeiten warten müssen. KernelCare umfasst einen Online-Support rund um die Uhr an 365 Tagen im Jahr für alle Abonnementstufen.

KernelCare Enterprise ist ab 50 US-Dollar pro System und Jahr für Kernel-Live-Patching erhältlich und läuft auf Ihren bestehenden RHEL-Systemen, ohne dass ein Red Hat-Abonnement erforderlich ist. Live-Patching im Userspace für OpenSSL und glibc ist über das LibCare-Add-on verfügbar. kpatch hingegen ist nicht separat kostenpflichtig, sondern setzt ein aktives RHEL-Abonnement voraus, das mit 878,90 US-Dollar für Standard oder 1.428,90 US-Dollar für Premium pro System und Jahr angegeben ist, wobei das EUS-Add-on weitere 273,90 US-Dollar kostet, um die Live-Patch-Fenster offen zu halten.

Am deutlichsten wird der Unterschied auf Flottenebene. Das Live-Patching des Kernels für 100 Systeme kostet mit KernelCare 5.000 US-Dollar pro Jahr. Um dies über Red Hat zu erreichen – mit einem RHEL-Standard-Abonnement plus EUS – fallen jährlich fast 115.280 US-Dollar an, also etwa das 23-Fache. Und selbst wenn man „kpatch“ innerhalb einer bestehenden RHEL-Umgebung als bereits bezahlt betrachtet, verursachen die EUS-Berechtigungen, die den Zugang dazu aufrechterhalten, immer noch Kosten von etwa 27.390 US-Dollar pro Jahr.

Wenn Sie ausschließlich RHEL einsetzen, mag kpatch als naheliegende Wahl erscheinen, da es im Rahmen Ihres Red Hat-Vertrags enthalten ist. Der springende Punkt dieses Vergleichs ist jedoch, dass selbst bei einer reinen RHEL-Umgebung die Standardkonfiguration mehr Lücken aufweist, als es auf den ersten Blick scheint. Viele Kernel-CVEs und alle Schwachstellen im Userspace bleiben ungepatcht, die Abdeckung beschränkt sich auf ausgewählte Basis-Kernel von Red Hat, jedes Patch-Fenster läuft nach etwa einem Jahr ab, und selbst das Zurücksetzen eines Patches erfordert einen Neustart.

KernelCare wurde entwickelt, um diese Kompromisse zu beseitigen. Es patcht den Kernel und den Userspace kontinuierlich, unabhängig vom Schweregrad, auf jedem Kernel, den Sie verwenden – und das auch weit über dessen Lebensdauer hinaus. Rollbacks erfolgen ohne Neustart, benutzerdefinierte Patches werden vollständig verwaltet, und das Ganze läuft auf Ihren bestehenden Systemen zu einem Bruchteil der Kosten, die Red Hat verlangt. Ganz gleich, ob Sie eine Mischung aus verschiedenen Distributionen betreiben oder jede Sicherheitslücke patchen möchten, ohne die Systeme herunterfahren zu müssen – KernelCare ist die bessere Wahl.

Der Umstieg von kpatch auf KernelCare ist ganz einfach. Ein einziges Schnellstart-Skript installiert KernelCare, Ihre Systeme erhalten durchgängig Live-Patches, und bestehende Workloads laufen so lange weiter, wie Sie es benötigen.

Für Teams, die sich zunächst ein Bild davon machen möchten, bietet KernelCare eine 30-tägige kostenlose Testversion mit vollem Funktionsumfang an, damit Sie sich vor einer Entscheidung von der lückenlosen Abdeckung überzeugen können.