ClickCease Ein Blick hinter die Kulissen von KernelCare: Wie wir Patches vor der Veröffentlichung testen - TuxCare

Abonnieren Sie unseren beliebten Newsletter

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

2x im Monat. Kein Spam.

Ein Blick hinter die Kulissen von KernelCare: Wie wir Patches vor der Veröffentlichung testen

23. Oktober 2020. TuxCare PR Team

Ein Blick hinter die Kulissen von KernelCare: Wie wir Patches vor der Veröffentlichung testen

Testen ist für jede Softwareaktualisierung, einschließlich Patches, unerlässlich, aber noch wichtiger ist es, wenn Änderungen an kritischen Infrastrukturen vorgenommen werden, die umsatzwirksame Dienste betreiben. Die Freigabe von Sicherheitsupdates, die nicht gründlich getestet wurden, kann zu Kernel-Abstürzen, Betriebssystem-Neustarts, System- oder Service-Level-Ausfällen führen - einige dieser Nachwirkungen sind kritisch und andere einfach nur unangenehm, aber alle können Ihrem Geschäft und Ihren Service-Level-Vereinbarungen schaden. KernelCare hat einen strengen Testprozess, den jeder Patch durchlaufen muss, bevor er in der Produktion eingesetzt wird. In diesem Artikel erfahren Sie, wie wir die Zuverlässigkeit und Betriebszeit der Kundeninfrastruktur nach dem Einsatz von Patches sicherstellen.

 

Inhalte:

  1. Patching-Verzögerungen sind riskant
  2. KernelCare Entwicklung und Prüfung
  3. Die vier Arten von Tests von KernelCare
  4. Schlussfolgerung

 

Patching-Verzögerungen sind riskant

Patching-Verzögerungen sind riskant

Es ist wichtig, dass die gesamte Software, einschließlich des Linux-Kernels, gepatcht wird, wenn die Entwickler ein Sicherheitsupdate veröffentlichen. Noch wichtiger ist es, so schnell wie möglich zu patchen, wenn eine Sicherheitslücke mit Exploit-Code veröffentlicht wird. Je länger Sie zulassen, dass Ihre Server nicht gepatcht werden, desto größer ist das Risiko, das nächste große Opfer einer Datenpanne zu werden. Es ist nicht ungewöhnlich, dass Administratoren einen Test durchführen und auf ein geplantes Datum warten, bevor sie Patches installieren. Innerhalb dieses Zeitrahmens könnte ein Angreifer den Server scannen, die Schwachstelle finden und sie ausnutzen.

 

Die Überlassung der Patch-Verwaltung an KernelCare erleichtert den Administratoren einen Großteil des Aufwands, aber unsere Kunden brauchen die Gewissheit, dass ordnungsgemäße Tests durchgeführt werden, bevor sie einem Drittanbieter die Bereitstellung für kritische Infrastrukturen gestatten. Die Patching-Lösungen von KernelCare werden vor der Bereitstellung auf unseren Kundenservern strengen Tests unterzogen. Unsere Tests verringern einen Großteil des Verwaltungsaufwands in großen Unternehmen, so dass Sie nicht mehr mehrere Rechner mit den Betriebssystemen der verschiedenen Hersteller benötigen, um eine saubere, fehlerfreie Patching-Erfahrung zu gewährleisten.

 

 

KernelCare Entwicklung und Prüfung

KernelCare Entwicklung und Prüfung

Fehlerhafter Code kann verschiedene Probleme verursachen, einschließlich der Einführung neuer Schwachstellen. Ein Beispiel dafür, warum es so wichtig ist, Patches vor dem Einsatz zu testen, ist die Entdeckung einer trivial ausnutzbaren Sicherheitslücke, die im Mai 2020. Der Patch namens Huawei Kernel Selbstschutz sollte eine Reihe von sicherheitssteigernden Optionen für den Linux-Kernel bieten. Stattdessen öffnete er das Betriebssystem für mögliche Hintertüren, bot keine Programmierung auf Bedrohungsebene und ermöglichte die Offenlegung des Kernelspeichers. Da der Patch getestet wurde, konnte das Linux-Team verhindern, dass er die Sicherheit des Kernels schwächte. Dies ist ein Beispiel dafür, warum es wichtig ist, Patches zu testen, bevor sie installiert werden, und KernelCare führt eine Reihe von Tests durch, bevor wir sie auf unseren Kundenservern installieren.

 

Um unseren Kunden zu helfen, die anspruchsvollen Tests zu verstehen, die wir von unseren Teams verlangen, haben wir den Prozess unten detailliert beschrieben.

 

  1. Wir stellen einen physischen Bare-Metal-Server oder eine virtuelle Maschine mit dem Zielbetriebssystem bereit. Wenn sich der Patch für eine bestimmte CVE (Common Vulnerability Exposures) auf eine bestimmte Hardwarekomponente bezieht (z. B. eine CPU-Schwachstelle), stellen wir die entsprechende Hardwarekomponente auf dem Server bereit. Bei einer kernelbasierten virtuellen Maschine (KVM) stellen wir verschachtelte virtuelle Maschinen und die erforderlichen Hardwarefunktionen bereit.
  2. Wir beziehen den Kernel, der für die Tests verwendet werden soll, vom Hersteller und installieren ihn auf unserem bereitgestellten Testserver.
  3. Starten Sie den Server mit dem neu installierten Kernel neu.
  4. Wir installieren KernelCare auf die gleiche Weise, wie es ein Kunde tun würde. Wir veröffentlichen die Anweisungen hier.
  5. Führen Sie den KernelCare-Patching-Befehl aus ($ /usr/bin/kcarectl -update).
  6. Laden Sie die für den Patch erstellten Kernelmodule.
  7. Validieren und testen Sie alle geänderten Funktionen des Moduls. 
  8. Wenn Exploit-Code verfügbar ist, verwenden wir diesen Code, um die Schwachstelle auf dem Server zu reproduzieren und zu testen, ob Patches die Schwachstelle beheben.
  9. Führen Sie unsere vier Tests durch (siehe unten).
  10. Wenn die Patches unsere Tests bestehen, werden sie in der Produktion eingesetzt.
  11. Wenn die Tests nicht erfolgreich sind, analysieren wir die Protokolle, um die Ursache des Fehlers zu finden, beheben das Problem und wiederholen diese Schritte, bis die Patches unsere Tests bestehen.

 

 

Die vier Arten von Tests von KernelCare

Die vier Arten von Tests von KernelCare

Gründliche Tests sind entscheidend für eine erfolgreiche Bereitstellung, und wir wissen, dass Bugs unsere Kunden beeinträchtigen. Wir haben vier Tests, die gleichzeitig für jeden Kernel laufen, um sicherzustellen, dass Patches keine kritischen Probleme verursachen. 

 

Bevor ein Patch bereitgestellt wird, durchläuft er die folgenden automatisierten Tests, je nachdem, wie schnell wir diese Patches in der Produktion benötigen und wie kritisch die Sicherheitslücke ist:

 

  1. Wir wenden unsere Patches auf den laufenden Kernel an und entpatchen ihn dann, um Rollbacks zu testen. Dieser Vorgang dauert etwa 10 Minuten pro Kernel.
  2. Wir wenden unsere Patches an und führen dann eine Untergruppe von Tests aus der Linux Test Project (LTP) Test-Suite durch, die das Betriebssystem zusätzlich belasten. Dieser Test dauert etwa 15 Minuten pro Kernel.
  3. Wie 2. aber mit dem vollständigen Satz von LTP-Tests. Dieser Test ist ein gründlicher 4-stündiger Prozess pro Kernel, der Folgendes umfasst:
    1. Dateisystem-Stresstest
    2. Speicher-E/A-Test
    3. Stresstest der Speicherverwaltung
    4. IPC-Stresstest
    5. Planer-Test
    6. Befehle für Funktionsprüfungstests
    7. Funktionsprüfung bei Systemaufrufen
    8. usw.
  4. LTP extra. Bei diesem Test handelt es sich um einen Hochlasttest mit ständigem Patchen und Entpatchen während des gesamten Tests. Dieser Test dauert 4 Stunden pro Kernel.

 

Schlussfolgerung

Um unseren Kunden einen stabilen und zuverlässigen Patching-Service zu bieten - auf den Sie sich verlassen und sogar vergessen können, dass er auf Ihren Servern existiert - testen wir jeden Patch auf jedem betroffenen Kernel für mindestens 4 Stunden/Kernel und geben Patches nur dann frei, wenn wir zu 100% sicher sind, dass sie Ihren Betrieb nicht stören werden. Mit KernelCarekönnen Administratoren nicht nur ihre Systeme ohne Neustart patchen, sondern sie wissen auch, dass diese Patches vor der Installation gründlich getestet werden.

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