Enterprise Software Management mit dem Red Hat Satellite Server

© Dirk Ercken, 123RF

Paketversand

Red Hats Satellite Server, ein unternehmenstaugliches Patch-Management-System, hält das gesamte Netzwerk auf dem Laufenden.
Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

Unsere Organisation folgt momentan einem systematischen, händischen Ansatz beim Patch Management. Das schließt die Identifikation der Notwendigkeit von Patches, ihre Beschaffung, das Testen und die Lösung von Problemen im Zusammenhang mit Patches sowie das Einspielen der Patches ein. Bei uns erhalten die Administratoren Hinweise auf Patches in der Regel per E-Mail entweder von den Herstellern oder aufgrund von Recherchen. Das Information Assurance Team (IA) veröffentlicht außerdem Sicherheitswarnungen in der Regel etwa eine Woche nach den Herstellermeldungen.

Nachdem ein Admin einen Hinweis auf einen nötigen Patch erhalten hat, lädt er den Patch von den Webseiten eines Herstellers herunter und speichert ihn in einem eigenen Repository. Sobald der Patch dort angelangt ist, testet ihn der Admin in einer speziellen Test- oder Entwicklungsumgebung. Tauchen dabei Probleme auf, kontaktiert der Admin den Herausgeber des Patchs und löst sie.

Nach Abschluss der Tests ist der Patch für das Einspielen auf den Produktivsystemen im nächsten Wartungsfenster bereit. Danach wandert der Patch in ein anderes Repository, wo er archiviert wird.

Red Hats Methode der Automatisierung solcher Software-Updates ist der Satellite Server. Seine Rolle entspricht ungefähr der von Microsofts Systems Management Server (SMS). Die Einführung eines Satellite Server muss nicht notwendigerweise den ganzen Patch-Management-Prozess umkrempeln, aber ein solcher Server automatisiert fortan das Abrufen, Speichern und Ausbringen der Patches. Außerdem pflegt der Satellite Server eine Sammlung aller Software Packages auf allen von ihm verwalteten Systemen. Der Satellite Server besorgt sich automatisch zu jedem erforderlichen Patch auch die Dokumentation, aus der hervorgeht, warum er eingespielt wurde.

Forschungsansatz

Als primäre Tools für die vorliegende Recherche dienten die verschiedenen Handbücher zum Red Hat Satellite Server 5.4. Red Hats Solutions Architect war ebenfalls eine hilfreiche Quelle. Drei Monate lang testeten wir den Red Hat Satellite Server, der auf einem HP Proliant DL380 G5 installiert war, auf dem RHEL 6.1 mit einer Basisausstattung an Paketen lief.

Als Test-Clients dienten ein Proliant DL380 G5 und ein HP Proliant WS 460 G6, der in einem HP Blade-System C7000 steckte. Abbildung 1 zeigt die Testumgebung.

Abbildung 1: Die Testumgebung für die Versuche mit dem Red Hat Satellite Server.

Patchen mit dem Satellite Server

Red Hat generiert Patches nach Bedarf, manchmal vier- oder fünfmal die Woche für bestimmte Programme. Diese Patches haben oft mehrfache Abhängigkeiten. Wollte man die Patches manuell einspielen, könnte es leicht Stunden wenn nicht Tage dauern, die Abhängigkeiten aufzulösen und die nötigen Files zu den Rechnern zu transferieren, die gepatchet werden sollen.

Theoretisch kann man ein Red-Hat-System mit nichts als Yum aktuell halten (siehe Kasten "Patching mit Yum"), aber in der Praxis führt der Zeitbededarf, und das Risiko, dass einem ein wichtiger Patch durch die Lappen geht, dazu, dass man ein Tool braucht, das die Patches ordnet, verwaltet, zeitlich plant und einspielt.

Patching mit Yum

Der Yellowdog Updater Modified (Yum) ist ein freies Kommandozeilentool für den Red Hat Package Manager, den Red Hat, Suse, Fedora und einige andere Distributionen nutzen.

Um Yum benutzen zu können, muss der Server mit dem Internet verbunden sein. Yum unterstützt eine Anzahl verschiedener Package Repositories. Wer seine Pakete aus den Repositories im Red Hat Network bezieht, der muss das zu patchende System bei einem RHN-Server registrieren.

Der YUM Package-Management-Prozess öffnet die folgenden Sicherheitslöcher im Netzwerk:

  • Jeder Red Hat Server braucht eine Internetverbindung.
  • Die Serverkonfiguration ist für Red Hat einsehbar und damit im Falle eines Sicherheitslecks bei Red Hat auch für die Welt.

Die Herangehensweise mit Yum ist akzeptabel, wenn der fragliche Client ohnehin mit dem Internet verbunden ist, wie das etwa bei einem Webserver wäre, der ohnehin offene Ports hat, und für den Durchlässe in der Firewall sowieso existieren müssen.

Für alle Server mit Red Hat Enterprise Linux (RHEL) empfiehlt der Autor jedoch, auf Yum zu verzichten, weil so zu viele Angriffsmöglichkeiten eröffnet werden, die unter Umständen das ganze Netzwerk unsicher machen können. Jeder Rechner mit RHEL könnte zum Ziel einer Attacke werden, wenn seine Software auf einem Server außerhalb des eigenen Kontrollbereichs inventarisiert wird.

Ein solches Werkzeug, das Patches (Security Fixes wie Funktionserweiterungen) halbautomatisch implementiert, ist der Red hat Satellite Server. Die von ihm verwalteten Server müssen dabei keine Red Hat-Maschinen sein, Satellite Server unterstützen auch Solaris- und Microsoft-Systeme. Der Satellite Server hat eine Internetverbindung und ist – als einziger Server – bei dem Server des Red Hat Network registriert, der die Patches bereitstellt. Der Admin legt eine Zeit in der Nacht fest, zu der der Satellite Server im RHN nach Updates sucht.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite