© Maksym Kapusta / 123RF.com

Mit der Zahl der genutzten Softwareprodukte steigt auch die Zahl der anzuwendenden Patches an. Es gibt verschiedene Strategien, um der Update-Flut Herr zu werden.

Der Begriff Patch zählt zu den zahllosen Wörtern, die die IT der englischen Sprache entlehnt und mit einer anderen Bedeutung versehen hat. Ursprünglich bedeutet Patch eigentlich Pflaster oder – mit Blick auf Textilien – Flicken, mit dem sich Löcher schließen lassen. Damit repariert man also Kleidung, statt sie durch neue zu ersetzen. An Pflaster und Stoffflecken dürften die meisten Administratoren allerdings kaum denken, wenn sie den Begriff Patch hören. Im technischen Alltag geht es eher um virtuellen Flicken: Patches heißen in der IT kleine Quelltextfragmente, die Fehler in bestehendem Quelltext korrigieren, um die Funktionalität oder die Sicherheit der jeweiligen Software zu erhöhen.

Viele Admins haben den Eindruck, dass die Zahl der Patches, mit denen sie es zu tun haben, stetig wächst. Das ist ebenso richtig (Abbildung 1) wie auch logisch: Durch die zunehmende Digitalisierung von Diensten und Produkten kommt immer mehr Software zum Einsatz. Weil Software von Menschen gemacht wird, ist sie mit Fehlern behaftet und braucht regelmäßige Korrekturen in Form von Patches. Aus Sicht der Administratoren besteht die Herausforderung darin, die Menge an Patches zu überblicken, die für die eigene Installation relevanten herauszufiltern und nur diese auch anzuwenden.

Abbildung 1: Die Security-Teams der großen Anbieter (wie hier von Debian) überwachen Sicherheitsalarme und stellen die Patches in Form kompletter Pakete zur Verfügung.

Zusätzlich Anlass zur Sorge gibt ein weiterer Punkt im Hinblick auf Patches: Es tauchen immer mehr sogenannte Zero-Day-Lücken auf, also kritische Fehler, die Angreifer im Netz bereits für illegale Aktivitäten nutzen, noch bevor sie den Programmautoren und den für Patches zuständigen Sicherheitsteams der Hersteller bekannt werden.

Schützenhilfe

Dass Admins einerseits immer größere Umgebungen betreiben und es andererseits mit immer mehr Patches diverser Art zu tun bekommen, wissen freilich auch die Hersteller. Flugs haben sie deshalb das Patch-Management zum Teil des Lifecycle-Managements von (virtuellen) Servern und Applikationen erklärt und entsprechende Funktionen in ihren entsprechenden Produkten vorgesehen. Für meist gar nicht so wenig Geld erhält der Admin eine Steuerzentrale, die ihn über ausstehende Patches und Updates informiert und sie in Sekundenschnelle per Mausklick installiert. Dass diese Lösungen mit eigenen Herausforderungen daherkommen, unterschlagen die Hersteller geflissentlich.

Dieser Artikel führt grundlegend in die Patch-Problematik ein. Er erklärt, mit welchen Patches der Admin es in freier Wildbahn zu tun bekommt, wie er damit sinnvollerweise umgeht und wie Patch-Handling auch das Betriebskonzept großer Plattformen beeinflussen kann und muss. Am Ende erfolgt eine kleine Einführung in die Bereitstellung von Patches per se – das ist gar nicht so schwierig, wie manche glauben.

Die Guten ins Töpfchen

Was ist denn nun eigentlich ein Patch genau? Der Artikel hat diese Frage eingangs damit beantwortet, es handele sich um ein kleines Codefragment. Wenn allerdings die großen Hersteller Admins dazu auffordern, einen Patch auszurollen, meinen sie damit in aller Regel gerade nicht das Anwenden eines Codefragments auf eine bestehende Komponente. Was Patchen genau bedeutet, hängt allerdings stark vom Betriebskonzept ab, für das der Administrator sich bei seinem Setup entschieden hat.

Dieser Artikel setzt voraus, dass es sich um ein Setup klassischer Art handelt, bei der normale Linux-Distributionen und deren Paketverwaltung zum Einsatz kommen, nicht jedoch Container. Ein eigener Artikel in diesem Heft geht auf das Handling von Fehlerkorrekturen in Container-basierten Umgebungen genauer ein.

In klassischen Setups setzt der Admin ja gerade auf die Paketverwaltung des Systems, weil es im administrativen Alltag unmöglich wäre, Dutzende Teile der Installation selbst aus den Quellen zu übersetzen und produktiv zu betreiben. Man stelle sich vor, ein zentraler Teil des Setups wie die TLS-Bibliothek hätte ein Sicherheitsproblem und bräuchte dringend ein Update: Es ist kaum denkbar, dass der Admin auf all seinen Systemen eine Neukompilierung der Bibliothek anstößt und dass das ohne größere Probleme abläuft.

In produktiven Umgebungen bedeutet das Einspielen von Patches stattdessen in aller Regel die Installation einer neueren Version des betroffenen Pakets, die den nötigen Patch bereits enthält. Der Vorteil dabei: Die meisten Distributionen – zumindest jene, die sich für den Enterprise-Bereich anbieten – liefern Sicherheitsaktualisierungen tatsächlich separat aus. Wer ein Paket mit einem Sicherheits-Patch einspielt, braucht deshalb keine Sorge zu haben, dass während der Installation auch noch andere Änderungen der Komponente auf das System kommen, die diese möglicherweise inkompatibel zum Rest des Setups machen.

Aus Sicht des Systems handelt es sich beim Einspielen von Patches also um eine triviale Aufgabe, zumal der Akt üblicherweise in jene Werkzeuge integriert ist, mit denen der Admin sowieso seine Paketauswahl vornimmt – also Apt, Dnf, Zypper und Konsorten.

Option 1: Automatische Updates

“Mal eben” einen Patch einzuspielen, ist dennoch nicht trivial, obwohl manche Distributionen ihre Nutzer das durchaus glauben machen möchten. Debian und Ubuntu etwa bieten seit vielen Jahren die Möglichkeit, unbeaufsichtigte Upgrades zu aktivieren. Sicherheitsaktualisierungen installiert das System dann bei Verfügbarkeit nach kurzer Zeit automatisch, und in den meisten Fällen stellt das auch kein Problem dar.

Unangenehm wird die Sache, wenn Sicherheits-Updates für Komponenten anstehen, von denen andere Dienste in der Installation abhängen. Datenbanken bieten dafür ein gutes Beispiel, da sie in aller Regel viele Abhängigkeiten quer durch die ganze Installation aufweisen. Gerade deshalb machen Admins ihre Datenbanken ja mittels Clustering redundant, entweder per Cluster-Manager oder mit eingebauter Multi-Master-Funktion. Nimmt eine unbeaufsichtigte Aktualisierung der Datenbank dann allerdings alle Knoten der Datenbank gleichzeitig offline, gerät das Setup ins Straucheln. Weil sich das praktisch nicht vermeiden lässt – der Admin müsste sonst jeden Tag die Liste der verfügbaren Updates durchgehen oder bedrohte Pakete auf “hold” setzen – bleiben solche Unattended Upgrades meist ausgeschaltet.

Option 2: Manuelle Installation

Die verbreitetste Option für das Handling von Patches auf bestehenden Systemen dürfte bis heute die zyklische manuelle Installation darstellen – mit Ausnahmen, falls ein Security-Update besonders dringlich ist, etwa weil bereits ein Exploit kursiert. Den betreibenden Unternehmen verlangt das allerdings einiges ab.

Gibt es für sicherheitsrelevante Themen ein eigenes Team, studiert es meist täglich die Sicherheitsankündigungen der Hersteller und öffnet interne Tickets, um den Installationsfortschritt zu verfolgen. Im aus Sicht des Admins schlechtesten Fall bleibt diese Arbeit an ihm selbst hängen. Anders als bei automatischen Updates hat der Admin in diesem Betriebskonzept aber den Vorteil, dass er den eigentlichen Update-Vorgang an die lokalen Gegebenheiten anpassen kann.

Automatisierer wie Ansible leisten in manchen Situationen gute Dienste. Hier sortiert der Administrator schon über die Inventardatei seine Hosts in verschiedene Gruppen. Weil Ansible (und auch andere Automatisierer) ein Interface zur lokalen Paketverwaltung besitzen, genügt im Fall eines dringenden Updates ein einzelner Ansible-Befehl in einem Playbook, um eine spezifische Version eines Pakets auf die Server des Inventars zu holen. Diese Form von Automation lässt sich zudem hervorragend mit speziellen Voraussetzungen wie den beschriebenen Clustern kombinieren. Sie ermöglicht es auch, Updates gezielt auszuwählen, statt alle aktualisierbaren Pakete auf den letzten Stand zu bringen.

Die meisten Automatisierer verbauen entsprechende Update-Funktionen mittlerweile sogar als explizite Funktion in ihren Lifecycle-Managern. Wer etwa auf Ansible Tower von den roten Hüten setzt, bekommt eine grafische Darstellung seiner Systeme inklusive ausstehender kritischer Sicherheits-Updates. Direkt aus den jeweiligen GUIs heraus lässt sich dann auswählen, welche Pakete in welcher Reihenfolge der Automatisierer wann wie installiert.

Wie viel dieser Funktionalität wirklich zur Verfügung steht, steuert der Admin im Wesentlichen über die Menge des Gelds, die er zu investieren bereit ist. Ansible Tower Chef Automate oder das passende Puppet-Gegenstück kosten Geld, während die eigentlichen Automatisierer als freie Software kostenlos zur Verfügung stehen. Hier fehlt dann aber eben die Magie des Lifecycle-Managements der Hersteller.

Option 3: Distributoren

Apropos Hersteller: Wie bereits erwähnt wissen auch die Hersteller, dass gerade in größeren Umgebungen das Patch-Management speziell bei Sicherheitsthemen eine Herausforderung darstellt. Nur wenige Admins bekämen wohl nicht instinktiv Bauchweh bei dem Gedanken, eine Sicherheitsaktualisierung einer zentralen Komponente auf Tausenden Systemen gleichzeitig auszurollen. Weil die Anbieter stets das Beste ihrer Kunden wollen – deren Geld –, stehen Red Hat, Suse und Canonical längst mit leistungsfähigen Lösungen am Start.

Kleiner Satellit

Red Hat hat in den vergangenen Jahren seine Lifecycle-Lösung Satellite so aufgebohrt, dass sie Sicherheits-Patches erkennen und verwalten kann (Abbildung 2). Im Kern war Satellite ja eigentlich als lokaler Mirror konzipiert, der eine Brücke sowohl zu Red Hats Subskriptionsmanagement als auch zu den Red-Hat-Paketverzeichnissen sein kann. Eine lokale Satellite-Instanz fungiert dabei als Capsule, an der Clients ihre konsumierten Subskriptionen anmelden und die eine Kopie der nötigen Paketverzeichnisse lokal vorhält. Die Clients bedienen sich dann direkt an der Satellite-Instanz, ohne Zugriff auf das Internet oder die dortigen Dienste von Red Hat zu benötigen.

Abbildung 2: Red Hat hat in sein Produkt Satellite eine Funktion für die Softwareverwaltung eingebaut, die Sicherheitsaktualisierungen trackt. Quelle: Red Hat

Massiv verbessert hat Red Hat in den letzten Jahren das Softwaremanagement im Satellite-GUI. Loggt der Admin sich in seine Satellite-Instanz ein, sieht er sofort, auf welchen Systemen kritische Updates fehlen. Satellite bietet hier echten Mehrwert, denn es nimmt dem Admin die Arbeit ab, die veröffentlichten Errata-Einträge des Herstellers mit den lokal installierten Paketen abzugleichen. Alarm schlägt Satellite auf einem bestimmten System also nur, wenn ein Paket, für das eine Sicherheitskorrektur vorliegt, dort auch tatsächlich installiert ist.

Will der Admin das Update dann auf den betroffenen Systemen hinzufügen, gelingt das mit wenigen Mausklicks – oder mit vielen, wenn er detaillierte Regeln etwa hinsichtlich der Reihenfolge über mehrere Hosts angeben will. Den Luxus lässt Red Hat sich allerdings einigermaßen fürstlich bezahlen.

Landschaftsmalerei

Wo Red Hat das All erkundet, beschäftigt Canonical sich lieber mit Malerei und veröffentlicht den eigenen Lifecycle-Manager unter dem Namen Landscape. Es wäre an dieser Stelle auch ungerecht und auf jeden Fall unvollständig, Landscape nur als Werkzeug für die Installation von Sicherheits-Updates zu betrachten. Ähnlich wie Satellite kann Landscape unter der Haube viel mehr und bietet wie der Konkurrent die bequeme Vorauswahl von Patches für betroffene Systeme an, die dem Admin das Leben leichter macht.

Ist ein System in eine Landscape-Installation integriert, schlägt Landscape Alarm, sobald dafür ein Update vorliegt (Abbildung 3). Der Admin kann dann entscheiden, ob und wie er den Rollout der neuen Version über alle Server seiner Umgebung vornehmen will. Landscape ist allerdings an einen Support-Vertrag mit Canonical gebunden; wer Landscape betreibt, hat mithin auch Ubuntu Advantage, und das ist wie Satellite nicht gerade ein Schnäppchen. Hier stellt sich also ebenfalls die Frage, wie viel Komfort der Admin sich gönnen will beziehungsweise kann.

Abbildung 3: Auch bei Canonicals Landscape gehört zum Lieferumfang ein Tracker für Updates auf einzelnen Systemen, der auch die entfernte Installation ermöglicht. Quelle: Canonical

Zentraler Manager

Da sowohl Red Hat als auch Canonical Werkzeuge für die zentrale Administration von Patches anbietet, kann sich Suse ebenfalls nicht lumpen lassen und integriert in Suse Manager einen umfassenden Support für Security-Updates.

Zunächst konfiguriert der Admin die Channels, aus denen Patches kommen können, meist also die Paketverzeichnisse des Anbieters. Dann wählt er die Systeme aus, die für einzelne Flicken aus der Patch-Liste infrage kommen. Der Rollout des Patches selbst ist dann eine Lappalie (Abbildung 4), denn wie Satellite und Landscape nutzt Suse Manager einen Server-Client-Ansatz, um seine Arbeit zu verrichten. Unter der Haube werkelt Salt und sorgt auf Zuruf des Admins dafür, dass die nötigen Patches ihren Weg auf die Zielsysteme finden. Auch Suse lässt sich für diese Funktionalität fürstlich entlohnen.

Abbildung 4: Wo Red Hat und Canonical liefern, kann Suse nicht untätig bleiben, und bietet mit Suse Manager ebenfalls Fernverwaltungsfunktionen für Sicherheits-Updates. Quelle: Suse

Viele Admins stellen sich die Frage, ob die beschriebenen Systeme für das Lifecycle-Management den Aufpreis wert sind. Geht es lediglich darum, eine sinnvolle Herangehensweise für das Einspielen von Updates zu finden, lautet die Antwort auf diese Frage eher nein als ja. Hat man es nicht gerade mit riesigen Umgebungen zu tun, die sich ohne grafische Darstellung der einzelnen Host-Gruppen nicht mehr gut verwalten lassen, erzielen die gängigen Automatisierer zufriedenstellende Automationsergebnisse. Es wirkt jedenfalls übertrieben, nur für das Patch-Management Satellite, Landscape oder Suse Manager in ein Setup zu integrieren und dafür zu bezahlen.

Der Weg zurück

Dass es viele Administratoren eher abschreckt, ein zentrales Paket auf vielen Systemen gleichzeitig einzuspielen, leuchtet ein. Grundsätzlich machen die großen Hersteller einen guten Job dabei, sicherheitsrelevante Patches auf Herz und Nieren zu testen, bevor sie sie über die gewohnten Kanäle als Update an die Nutzer ihrer Distributionen ausspielen. Gelegentlich helfen aber alle Pipelines und QA-Maßnahmen nicht, und ein Update geht in die Hose. Es kommt dann sogar vor, dass die Hersteller ein bereits erlassenes Erratum korrigieren oder zurückziehen. Wie geht der Admin mit so einer Situation um?

Das ist komplexer, als es im ersten Augenblick scheint. Bis heute gibt es unter Linux kein generelles System der Wiederherstellungspunkte, wie es etwa in Windows seit Jahren zur Verfügung steht. Suse hat vergleichbare Funktionalität im Angebot, die auf Btrfs basiert und vor Updates einen Snapshot anlegt. Das kommt den Wiederherstellungspunkten zwar recht nahe, hilft den Admin von Systemen mit Debian, Red Hat oder Ubuntu allerdings nicht weiter. Wer es mit heterogenen Setups zu tun hat, sieht sich gleich mehreren Herstellern gegenüber, bei denen er sich eigentlich mit Maßnahmen gegen schlechte Updates schützen müsste.

Es gibt zumindest ein paar Vorsichtsmaßnahmen, die der Admin im Vorfeld treffen kann. Es schadet beispielsweise nicht, die alte Version eines Pakets in Form der jeweiligen RPM- oder DEB-Datei lokal zu sichern. Sobald die Hersteller eine neuere Version eines Pakets veröffentlichen, verschwindet die alte Version nämlich regelmäßig von deren Spiegelservern und ist danach deutlich schwieriger zu bekommen.

Darüber hinaus gelten natürlich die grundsätzlichen Regeln: Wer ein Update selbst testen möchte, installiert es zunächst auf wenigen, anhand bestimmter Kriterien idealerweise für das gesamte Setup repräsentativen Systemen der Installation. Hier können Ansible, Chef und Konsorten wieder gute Dienste leisten.

Sonderfall Kernel-Updates

Bis hierhin hat der Artikel sich mit Funktionskorrekturen von Komponenten der jeweiligen Distributionen beschäftigt. Eine Sonderrolle nimmt dabei der Kern des Systems ein, der Linux-Kernel. Einerseits sind Sicherheitslöcher hier oft besonders problematisch: Zum einen verwaltet der Kernel den Zugriff auf alle Ressourcen des Systems, und Sicherheitslöcher erlauben schlimmstenfalls den unautorisierten Zugriff als Root. Zum anderen ist es besonders schwierig, den Linux-Kernel mit Patches zu versehen. Das gilt gerade dann, wenn der Admin es mit einem eher konventionellen Setup zu tun hat, wo die klassische Hochverfügbarkeit eine große Rolle spielt.

Bis vor wenigen Jahren war es schlicht unmöglich, den Linux-Kernel eines Systems zu reparieren. Sicherheitsaktualisierungen und Funktionskorrekturen installierten stattdessen immer eine neue Kernel-Version, in die anschließend ein Reboot zu erfolgen hatte. Das bedeutete Stress wegen eines oder mehrerer Fail-over-Vorgänge, und das unter erhöhtem Druck, weil etwa eine Remote-Root-Lücke sich ja parallel auf allen Systemen ausnutzen lässt. Das war unangenehm und erhöhte füe den Admin das Risiko, Fehler zu machen.

Die Hersteller der verschiedenen Linux-Distributionen starteten deshalb vor über einem Jahrzehnt einen Wettlauf hinsichtlich verschiedener Lösungen, mit denen der Kern sich im laufenden Betrieb aktualisieren lässt. Live-Patching-Mechanismen für den Linux-Kernel stehen heute auf allen Enterprise-Distributionen zur Verfügung, sind allerdings mit Vorsicht zu genießen.

Ja, nein, vielleicht

Einerseits sind die verschiedenen Systeme stets an einen Support-Vertrag gekoppelt. Egal, ob bei Red Hats Kpatch, Canonicals Livepatch oder Suses kGraft: Stets gilt, dass Pflaster für den Linux-Kernel ihren Weg nur gegen Bares auf das Zielsystem finden. Das alleine wäre ja noch akzeptabel, doch unterliegen die Kernel-Patches auch einigen technischen Einschränkungen.

Bestimmte kritische Teile des Linux-Kernels lassen sich im laufenden Betrieb gar nicht patchen, weil die jeweiligen Funktionen für den Patch-Mechanismus selbst benötigt werden. Obendrein machen viele, gleichzeitig angewandte Live-Patches den Kernel unter gewissen Umständen langsam und behäbig. Hier zeigt sich einmal mehr der eingangs schon erwähnte Faktor, dass Live-Patching nicht als dauerhafte Lösung konzipiert ist, sondern den Admin lediglich etwas von dem Stress entlastet, den ein großes Sicherheitsleck im Linux-Kernel hervorruft.

Grundsätzlich sollten Administratoren ihre Umgebung so konzipieren, dass eine beliebige Maschine zu jedem beliebigen Zeitpunkt für Kernel-Patches in den Neustart gehen kann. Das erfordert zwar möglicherweise bei der Planung eines Setups etwas mehr Hirnschmalz. Es schafft aber auch Alltagsszenarien, die nicht von halbgaren Features im Linux-Kernel abhängen – die laut Aussage ihrer eigenen Anbieter zudem gelegentlich mehr Schaden anrichten als zu nutzen. Es gilt: Was technisch (zum Teil) machbar ist, muss nicht zwingend auch operativ sinnvoll sein.

Patches selbst anbieten

Gar nicht so selten kommt es übrigens vor, dass Admins bei der Arbeit mit einem Programm selbst Fehler finden, die sie beheben möchten. Dabei handelt es sich zwar in aller Regel nicht um große Security-Bugs, doch sollte der Administrator nichtsdestoweniger wissen, was er tun kann, um selbst einen Patch zu erstellen und diesen in Richtung der Upstream-Autoren zu bugsieren.

Eine generelle Regel gibt es hier allerdings nicht. Auf welchen Wegen Projekte Patches annehmen, gestaltet sich ausgesprochen individuell. In den allermeisten Fällen wird man vom Administrator jedoch erwarten, dass er Git nutzt und den Entwicklern auch einen Git-kompatiblen Patch zuschickt. Linus Torvalds hat die IT hier so, wie er es bereits mit Linux getan hat, noch einmal stark beeinflusst – Git gilt heute als Universalprogramm für die Verwaltung von Quelltext.

Findet ein Administrator ein Problem, stellt sich zunächst einmal die Frage, wer denn für die Behebung der Malaise verantwortlich zeichnet. Handelt es sich um einen Bug in der Paketierung, ist der Lieferant – also der eigene Distributor – der logische erste Ansprechpartner. Generell sollten Admins sich darauf verlassen, dass ihnen hier kompetent geholfen wird. Selbst wenn der Admin einen Programmier-Bug findet und behebt, sollte der Hersteller auf einen passenden Bug Report reagieren und die Korrektur gen Upstream senden.

Alternativ kann der Admin einen Patch bei den Autoren der defekten Komponente einreichen. Die erwarten heute meist, dass er per Git (Abbildung 5) eine lokale Kopie der Quelltexte anlegt, in seinem lokalen Branch die Änderung vornimmt, sie mittels »git commit« anwendet und eine aussagekräftige Change-Erklärung einfügt, bevor er schließlich einen Pull Request an die Entwickler schickt. Hier ist allerdings zu beachten, dass ein auf diese Weise eingereichter Patch es von sich aus wohl eher nicht in die Distribution schaffen dürfte. Sollte das gewollt sein, muss der Admin doch wieder einen Bug Report an die Distribution richten und zusätzlich Verweise auf den Patch erstellen – falls er nicht eine eigene Infrastruktur betreibt, um ein lokales Paketverzeichnis für seine Umgebung anzubieten.

Abbildung 5: Wer selbst ins Patch-Geschäft einsteigen will, benötigt meist Git, etwa den grafischen Git-Client GitKraken. Quelle: GitKraken

Fazit

Das Einspielen von Patches, um Lücken mit Sicherheitsbezug zu schließen, gilt als SOP, als Standard Operating Procedure. In der Tat bieten sich dem Admin heute mannigfaltige Möglichkeiten, um Updates zu katalogisieren, zu ordnen und zu installieren. Wer sich mit den Standardwerkzeugen der Systeme nicht anfreunden kann, greift zu einem Automatisierer und erhält dadurch zusätzliche Features. Wollen Firmen sich langfristig an einen Hersteller binden, kommt auch die Verwendung von Lifecycle-Management-Werkzeugen grundsätzlich infrage. Kernel-Patches sind und bleiben allerdings ein Sonderfall.

Dieser Artikel zeigt aber auch: Das Betriebskonzept hinter zu patchenden Systemen ist viel wichtiger als die Patches selbst. Wer das Thema Hochverfügbarkeit sinnvoll angeht, braucht sich über Patches und ihre Auswirkungen naturgemäß weniger Sorgen zu machen als Betreiber von Setups, in denen der Ausfall einzelner Komponenten sofort zu großen Problemen führt. Konventionelle Installationen sollte man daher in Richtung High Availability weiterentwickeln. (jcb)