ClickCease SACK-Panik & Langsamkeit: KernelCare Live-Patches sind da - TuxCare

Abonnieren Sie unseren beliebten Newsletter

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

2x im Monat. Kein Spam.

SACK-Panik und Langsamkeit: KernelCare Live-Patches sind da

24. Juni 2019. TuxCare PR Team

Kernel Care-03 (2)

Kürzlich wurde die falsche Art von Netflix Original der Öffentlichkeit vorgestellt. Der Streaming-Riese gab bekannt, dass er vier neue Denial-of-Service (DoS)- und Ressourcenverbrauchs-Schwachstellen entdeckt hat, die Linux- und FreeBSD-Server betreffen. Netflix hat alle Details in einem Advisory auf GitHub veröffentlicht. Die Schwachstellen bedrohen jedes Unternehmen, das große Flotten von Linux-Produktionscomputern betreibt.

Best-Case-Szenario: Verlangsamung

Alle Linux-Schwachstellen nutzen die TCP Selective Acknowledgement-Funktion des Kernels aus (daher "TCP SACK"). Zwei der Schwachstellen - CVE-2019-11478 und CVE-2019-11479 - führen dazu, dass die TCP-Wiederholungswarteschlange so stark fragmentiert wird, dass der Kernel übermäßig viele Ressourcen für die Verwaltung der SACK-Elemente der betreffenden TCP-Verbindung aufwendet. Dies ist zwar nicht katastrophal, kann aber zu einer erheblichen Verlangsamung der CPU führen. CVE-2019-11478 betrifft alle Kernel vor 4.15; CVE-2019-11479 betrifft alle Linux-Versionen seit 2.6.29.

Worst-Case-Szenario: Katastrophe

Die dritte Sicherheitslücke - CVE-2019-11477 - wurde zu Recht als "SACK Panic" bezeichnet. SACK Panic betrifft alle Kernel ab Version 2.6.29 und ist eine Integer-Überlaufschwachstelle, die die TCP Selective ACKnowledgement-Funktion des Kernels ausnutzt, indem sie die Werte der MSS (Maximum Segment Size) anpasst. Eine bestimmte Folge von Paketen kann eine Kernel-Panik auslösen.

Wie die Langsamkeitsschwachstellen ist auch die SACK-Panik besonders besorgniserregend, weil sie aus der Ferne ausgelöst werden kann. Böswillige Akteure können eine ausgewachsene Panik auslösen, die ein Betriebssystem völlig zum Erliegen bringt, einen Neustart des betroffenen Hosts erzwingt und eine vorübergehende Abschaltung von Diensten bewirkt. Das bedeutet abgestürzte Server, unterbrochene Kommunikation und das Risiko eines ernsthaften Datenverlusts. Dies ist eine sehr schlechte Nachricht für Dienste, die Linux-basierte Systeme zur Bereitstellung von Online-Diensten verwenden.

Als ob das nicht schon schlimm genug wäre: SACK Panic betrifft alle Kernel 2.6.29 und neuer.

Erhalten Sie eine KOSTENLOSE 7-Tage-Testversion von KernelCare 

 

Schützen Sie Ihre Kernel und Ihre IoT-Geräte - ohne Neustart

Die SACK Panic & Slowness Live-Patches von KernelCare, einschließlich des wichtigen PATCH_net_1_4.patchPATCH_net_1a.patch, sind hier für alle unterstützten Distributionen außer UEK (das gerade in Arbeit ist). Und bei einer so schwerwiegenden Sicherheitslücke wie SACK Panic wollen Sie so schnell wie möglich gepatcht werden. Ja, es gibt einige Workarounds für Konfigurationsdateien, aber diese sind alles andere als sicher.

Wenn Sie jedoch einen Neustart durchführen, um einen Patch aufzuspielen, bereitet dies ernsthafte Kopfschmerzen. Das Neustarten von Servern ist eine große Unannehmlichkeit. Man kann es nicht tun, ohne es im Voraus zu planen, und es ist sehr verlockend, es so lange wie möglich hinauszuzögern. (Dies gilt insbesondere für IoT-Geräte, deren Patching schwierig und zeitaufwändig sein kann.) Das bedeutet, dass Sie jedes Mal, wenn eine Sicherheitslücke auftaucht, nur verlieren können: Sie müssen entweder Ihre Serverflotte neu starten oder Sie riskieren, den Neustart bis Samstag Mitternacht hinauszuzögern, wenn die Ausfallzeit am wenigsten problematisch ist.

Außerdem sind Sie durch die Verzögerung von Neustarts nicht nur unsicher, sondern auch nicht konform. Die Versicherungspolicen der meisten Unternehmen für Fehler und Auslassungen (E&O) sowie die Klauseln in ihren SLA-Verträgen verlangen die Einhaltung der Best Practices für das Patchen. In der Regel bedeutet dies, dass zwischen der Veröffentlichung eines Patches und seiner Anwendung nicht mehr als 30 Tage liegen dürfen. Viele Unternehmen neigen jedoch immer noch dazu, ihre Reboot-Zyklen in Monaten oder Quartalen zu planen, wodurch sie ihre Versicherungspolicen ständig verletzen. Je früher Sie patchen, desto früher sind Sie geschützt - und desto konformer werden Sie.

An diesem Wochenende wurden die Patches an die KernelCare-Benutzer verteilt und automatisch angewendet, ohne dass ein Neustart erforderlich war. Wenn das nächste Mal ein gefährliches CVE auftaucht, müssen Sie Ihre Server nicht mehr neu starten. Sie müssen die Sicherheitsstandards der Branche nicht mehr verletzen. Mit einem Live-Patch von KernelCare sind Sie vollständig geschützt, ohne einen Finger rühren zu müssen.

Erhalten Sie eine KOSTENLOSE 7-Tage-Testversion von KernelCare 

 

Lesen Sie mehr:

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