Red Hat Security 2026: Patches, Compliance und bewährte Verfahren

Wichtigste Erkenntnisse

• Die Sicherheitsmaßnahmen von RHEL bilden eine solide Grundlage für die Sicherheit bei Red Hat, doch ohne regelmäßige Patches, Audit-Zyklen und eine konsequente Lebenszyklusverwaltung nützen sie nichts.
• Der Betrieb von RHEL 7 oder einer anderen Version, deren Support ausgelaufen ist, ohne einen erweiterten Supportvertrag birgt Risiken bei Audits und führt zu Verstößen gegen Compliance-Vorgaben.
• Mit Live-Patching können Sie CVE-Korrekturen für den Kernel auf laufenden Systemen ohne Neustart anwenden – TuxCares KernelCare unterstützt dies für alle gängigen RHEL-Versionen.

Die meisten Teams, die Red Hat Enterprise Linux einsetzen, gehen davon aus, dass ihre Sicherheitslage solide ist, da Red Hat einen ausgezeichneten Ruf genießt. Die Plattform wird mit aktivierter SELinux-Sicherheit, signierten Paketen und einem ausgereiften Verfahren zur Offenlegung von Sicherheitslücken ausgeliefert. Dieser Ruf ist wohlverdient.

Dies führt jedoch zu einem spezifischen Fehlermuster in der Sicherheit bei Red Hat: Man geht davon aus, dass die Plattform die Arbeit erledigt, obwohl die eigentliche Arbeit – das Schließen von Sicherheitslücken, die Lebenszyklusplanung und die Einhaltung von Audit-Standards – beim Team liegt, das sie betreibt.

So sieht das in der Praxis konkret aus: An einem Dienstag wird eine CVE für den Linux-Kernel veröffentlicht. Der Patch ist am Freitag verfügbar. Ihr nächstes Wartungsfenster liegt in 18 Tagen. Ein Angreifer, der von dieser CVE weiß, hat nun 18 Tage Zeit, um Ihre Systeme anzugreifen. Das ist kein hypothetisches Szenario – so sieht der Alltag der Linux-Sicherheit in Unternehmen aus, und genau deshalb ist der Rhythmus der Patches genauso wichtig wie deren Verfügbarkeit.

Wie Red Hat-Sicherheit tatsächlich aussieht

Die Sicherheitsarchitektur von RHEL ist mehrschichtig aufgebaut, was sowohl ihre Stärke ist als auch der Grund dafür, dass ihre Wartung aktiven Einsatz erfordert und nicht auf passivem Vertrauen beruhen kann.

Auf Kernel-Ebene, SELinux sorgt für eine zwingende Zugriffskontrolle – das heißt, selbst ein kompromittierter Prozess kann nicht über die für ihn geltenden Richtlinien hinauszugreifen. Dies bietet einen wirksamen Schutz, wenn es korrekt konfiguriert ist, und ist völlig nutzlos, wenn jemand setenforce 0 während eines Vorfalls und macht diese Änderung niemals rückgängig. Darüber hinaus regelt die rollenbasierte Zugriffskontrolle die Grenzen von Identitäten und Berechtigungen. Hinzu kommen die signierte Update-Infrastruktur von Red Hat und deren Linux-Sicherheitslücke Der Tracking-Feed bietet Ihnen eine zuverlässige CVE-Pipeline und Patches, deren Herkunft Sie vertrauen können.

Der Haken daran ist, dass sich all dies nicht von selbst aufrechterhält. RHEL ist vom ersten Tag an sicher. Ob dies so bleibt, hängt ganz davon ab, was Ihr Team danach unternimmt. Ein RHEL-7-System, das 2020 ordnungsgemäß abgesichert wurde und seit Mitte 2024 keine Patches mehr erhalten hat, weist jahrelange, ungepatchte CVEs im Kernel und im Userspace auf. Das ursprüngliche Design schützt nicht vor Schwachstellen, die nach der Installation des letzten Patches bekannt wurden.

Für Teams, die nach Ablauf des EOL im Juni 2024 weiterhin auf RHEL 7 angewiesen sind, ist der „Endless Lifecycle Support“ von TuxCare eine der wenigen Möglichkeiten, weiterhin CVE-Patches zu erhalten, ohne zu einer Migration gezwungen zu sein, die betrieblich möglicherweise noch nicht realisierbar ist.

Warum Red Hat Security wichtig ist

RHEL wird meist für die langweilige, aber kritische Infrastruktur eingesetzt. Banken nutzen es für die Abwicklung von Handelsgeschäften. Telekommunikationsunternehmen setzen es für das Routing ein. Krankenhäuser betreiben darauf elektronische Patientenakten. Wenn große Fluggesellschaften und Finanzinstitute ihre Systemlandschaften auflisten, nimmt RHEL in der Regel eine tragende Rolle im Kernbereich ein. Das bedeutet, dass die Angriffsfläche groß ist und die Auswirkungen einer Sicherheitsverletzung erheblich sind.

Angriffe auf Linux-Systeme haben in den letzten Jahren deutlich zugenommen. Ransomware-Gruppen und staatlich unterstützte Angreifer haben ihren Fokus von Windows-Endgeräten auf Linux-Server verlagert, auf denen die tatsächlich wertvollen Arbeitslasten laufen. Die Backdoor „2024 XZ Utils“ (CVE-2024-3094) war ein Beinahe-Treffer, der einen erheblichen Teil der von RHEL abgeleiteten Distributionen betroffen hätte, wäre er in einer stabilen Version gelandet. Er wurde entdeckt. Der nächste wird es vielleicht nicht sein.

Die Einhaltung gesetzlicher Vorschriften verleiht der Sache eine zusätzliche Dringlichkeit. HIPAA, PCI DSS, DSGVO und SOC 2 basieren alle auf einer gemeinsamen Annahme: Sie setzen Software ein, für die weiterhin Sicherheitsupdates vom Hersteller bereitgestellt werden. Sobald ein System das Ende seines Lebenszyklus (EOL) erreicht, ohne dass eine Vereinbarung über erweiterten Support besteht, ist diese Annahme hinfällig – und das bleibt den Prüfern nicht verborgen. „Das System läuft einwandfrei“ ist kein stichhaltiges Argument in Bezug auf die Compliance. Um genauer zu verstehen, was dies in der Praxis bedeutet, lesen Sie, welche Auswirkungen das EOL von RHEL 7 auf Ihr Unternehmen hat.

Häufige Sicherheitsrisiken bei RHEL

Die folgenden Risiken sind keine theoretischen Sonderfälle. Sie tauchen immer wieder bei der Nachbetrachtung von Vorfällen auf und es lohnt sich, sie beim Namen zu kennen.

Risiko Nr. 1: Nicht behobene CVEs im Kernel

Kernel-Patches erfordern einen Neustart, und Neustarts werden immer wieder aufgeschoben. Ein Produktionsdatenbank-Cluster, ein Telekommunikations-Routing-Stack, ein Echtzeitverarbeitungssystem – sie alle haben triftige Gründe, ungeplante Ausfallzeiten zu vermeiden. Also bleiben die Patches ungenutzt. Für CVE-2022-0847 (Dirty Pipe) waren bereits wenige Tage nach der Offenlegung Patches verfügbar; doch in vielen Produktionssystemen wurden sie monatelang nicht installiert, weil niemand die schrittweisen Neustarts einplanen wollte.

Die CISA hat am 1. Mai 2026 die Schwachstelle CVE-2026-31431 (Copy Fail) in ihren KEV-Katalog aufgenommen – eine Schwachstelle zur Rechteausweitung, die es jedem lokalen Benutzer ohne Sonderrechte ermöglicht, Root-Rechte zu erlangen, indem er den im Arbeitsspeicher befindlichen Seitencache des Kernels – ohne auf die Festplatte zuzugreifen – manipuliert. Damit haben Bundesbehörden zwei Wochen Zeit, um das Problem zu beheben. Die meisten Linux-Umgebungen in Unternehmen können im Rahmen herkömmlicher Patch-Zyklen nicht so schnell reagieren. Die Schwachstelle erfordert an sich keinen Fernzugriff, doch in Verbindung mit etwas so Alltäglichem wie gestohlenen SSH-Anmeldedaten oder einem kompromittierten Container-Prozess führt sie zu einer vollständigen Root-Kompromittierung.

Risiko Nr. 2: SELinux deaktiviert oder falsch konfiguriert

Wenn in der Produktion etwas kaputtgeht, setenforce 0 ist die schnellste Lösung, aber auch die schlechteste. SELinux Im permissiven Modus werden Verstöße gegen Richtlinien protokolliert, aber nichts blockiert, und die Aussage „Wir werden die Funktion wieder aktivieren, sobald wir das Problem behoben haben“ wird oft zu einer dauerhaften Lösung. Zu weit gefasste Richtlinienmodule sind fast ebenso problematisch – wenn einem Dienst mehr Berechtigungen gewährt werden, als er benötigt, hat eine Kompromittierung dieses Dienstes weitreichendere Folgen, als es sein sollte.

Profi-Tipp: Bevor Sie SELinux zur Fehlerbehebung deaktivieren, wechseln Sie vorübergehend mit dem Befehl „setenforce 0“ in den permissiven Modus und überprüfen Sie ausearch -m avc -ts recent um die jüngsten Ablehnungen abzurufen. In den meisten Fällen gibt Ihnen das Ablehnungsprotokoll genau vor, welche Richtlinienregel Sie erstellen müssen – und Sie müssen den Durchsetzungsmodus nie dauerhaft verlassen.

Risiko Nr. 3: EOL-Systeme, die weiterhin in der Produktion laufen

RHEL 7 hat im Juni 2024 das Ende seines Lebenszyklus erreicht. Eine beträchtliche Anzahl von Unternehmen nutzt es nach wie vor – eine Migration ist kostspielig, mit Betriebsunterbrechungen verbunden und hat oft eine geringere Priorität als die dringenden Probleme, die in diesem Quartal tatsächlich anfallen. Ohne einen erweiterten Support-Service stellt jede nach dem EOL-Datum bekannt gegebene Kernel- und Paket-CVE eine dauerhafte, ungepatchte Sicherheitslücke dar. Sobald der Hersteller-Support endet, gibt es keinen Weg mehr, den Rückstand aufzuholen.

Risiko Nr. 4: Unklare Berechtigungsgrenzen

Dienstkonten, die als Root laufen. Sudoers-Dateien mit pauschalen „NOPASSWD“-Einträgen. SSH-Schlüssel, die 2019 eingerichtet und seitdem nie ausgetauscht wurden. Das sind keine ausgeklügelten Angriffsvektoren – es handelt sich um grundlegende Sicherheitsmängel, die den Unterschied zwischen einem kompromittierten Dienst und einem kompromittierten Host ausmachen.

Risiko Nr. 5: Nicht geprüfte Repositorys von Drittanbietern

EPEL, RPM-Repositorys von Drittanbietern und von Herstellern bereitgestellte Paket-Mirrors sind oft unverzichtbar. Sie stellen jedoch auch Angriffseingänge dar. Ein Team, das ein Repository hinzufügt, um ein einzelnes Paket zu installieren, und dabei nie überprüft, welchen weiteren Inhalten nun Vertrauen geschenkt wird, vergrößert damit seine Angriffsfläche, ohne dies bewusst zu beabsichtigen.

Bewährte Verfahren für die Sicherheit bei Red Hat

Die Abhilfemaßnahmen für die oben genannten Risiken sind nicht kompliziert. Die Schwierigkeit besteht darin, sie unter dem Druck des Tagesgeschäfts konsequent in großen Flotten umzusetzen.

Praxisbeispiel Nr. 1: Patches nach einem festen Zeitplan

In der Zeitspanne zwischen der Verfügbarkeit eines Patches und dessen Bereitstellung kommt es zu Sicherheitslücken. Ein wöchentlicher Rhythmus für Paketaktualisierungen und ein monatlicher Rhythmus für Kernel-Updates stellen für die meisten Unternehmen eine praktikable Mindestanforderung dar. Die Entscheidung ist operativer Natur:

• Sofern geplante Neustarts möglich sind – Standard-Patching mit dnf update Außerdem ist ein Neustart von Windows kein Problem.
• Wenn Neustarts den Betrieb stören, ist das Patchen ohne Neustart der einzige Ansatz, der mit der Geschwindigkeit der Sicherheitspatches Schritt hält, ohne die Verfügbarkeit zu gefährden.

Praxisbeispiel Nr. 2: Live-Patching für Kernel und gemeinsam genutzte Bibliotheken

Beim Live-Kernel-Patching werden CVE-Korrekturen auf einen laufenden Kernel angewendet, ohne dass ein Neustart erforderlich ist. Red Hat stellt „kpatch“ für einige Kernel-Zweige bereit, doch die Abdeckung beschränkt sich auf die aktuell unterstützten Versionen. „KernelCare“ von TuxCare deckt ein breiteres Spektrum an RHEL-Kernel-Versionen ab, einschließlich älterer und EOL-Versionen.

Eine detaillierte Übersicht über die Unterschiede zwischen KernelCare und kpatch hinsichtlich Abdeckung, unterstützter Kernel und Rollback-Fähigkeiten finden Sie unter „Vergleich zwischen KernelCare Enterprise und Red Hat kpatch“.

Hinweis:LibCare erweitert Live-Patching auf kritische gemeinsam genutzte Bibliotheken wie glibc und OpenSSL – Komponenten, die bei herkömmlicher Patching-Methode einen Neustart der abhängigen Dienste erfordern. Es handelt sich zwar nicht um einen vollständigen Systemneustart, doch ist dies dennoch störend genug für alles, was dauerhafte Verbindungen oder den Sitzungsstatus aufrechterhält. Das Patchen eines laufenden OpenSSL ohne Neustart der Dienste, die es nutzen, ist keine triviale Angelegenheit und von Bedeutung für Umgebungen mit hoher Verfügbarkeit.

Praxisbeispiel Nr. 3: Nutzen Sie die CVE-Priorisierung, nicht nur CVE-Listen

Die bloßen CVE-Zahlen allein lassen keine konkreten Maßnahmen zu. In den meisten Umgebungen häufen sich zu jedem Zeitpunkt Hunderte von bekannt gewordenen Schwachstellen an, und wenn Teams diese alle mit derselben Dringlichkeit behandeln, führt dies zu Burnout, ohne dass sich ihre Sicherheitslage verbessert.

Praxisbeispiel Nr. 4: SELinux im Modus „Enforcing“ belassen

Im Durchsetzungsmodus ausführen. Wenn etwas eine Ablehnung auslöst, untersuchen Sie dies mit ausearch und audit2allow anstatt die Richtlinie zu deaktivieren. Wenn eine benutzerdefinierte Regel wirklich notwendig ist, erstellen Sie ein zielgerichtetes Richtlinienmodul, das genau auf die tatsächlichen Anforderungen des Dienstes zugeschnitten ist. Teams, die sich an diese Vorgehensweise halten, stellen oft fest, dass SELinux-Ablehnungen ihr erstes Anzeichen dafür sind, dass etwas nicht richtig funktioniert – noch bevor andere Überwachungsmechanismen dies erkennen.

Maßnahme Nr. 5: Regelmäßige Überprüfung der Zugriffsrechte

Dienstkonten sollten mit den minimalen Berechtigungen ausgeführt werden, die sie tatsächlich benötigen, um zu funktionieren. „sudoers“-Einträge sollten konkret formuliert sein und keine pauschalen Regelungen enthalten. SSH-Schlüssel sollten nach einem festgelegten Zeitplan ausgetauscht werden, und die schlüsselbasierte Authentifizierung sollte die einzige zulässige Methode sein. Pipe auditd Protokolle an einem Ort, der überprüft wird, und richten Sie AIDE für die Überwachung der Dateiintegrität auf kritischen Pfaden ein.

Profi-Tipp: ausführen. sudo -l -U <serviceaccount> um genau zu überprüfen, über welche Berechtigungen ein bestimmtes Dienstkonto verfügt. Diese Überprüfung dauert nur 30 Sekunden und deckt oft „NOPASSWD“-Einträge oder zu weit gefasste Befehlsberechtigungen auf, die sich im Laufe der Jahre durch schrittweise Änderungen an der „sudoers“-Datei angesammelt haben.

Tipp Nr. 6: Planen Sie Ihr Lebensende, bevor es soweit ist

Red Hat veröffentlicht die Lebenszyklusdaten bereits Jahre im Voraus. Ein häufiges Fehlermuster besteht darin, die Migration als ein Problem der Zukunft zu betrachten, bis sie zu einem akuten Notfall wird. Es ist von entscheidender Bedeutung, die bevorstehenden Meilensteine für das EOL von RHEL 8 zu kennen, da der Wartungssupport im Mai 2029 endet – wenn Sie über eine große RHEL-8-Umgebung verfügen, läuft die Uhr bereits.

• Falls eine Migration auf RHEL 9 oder 10 vor dem EOL möglich ist – beginnen Sie jetzt mit der Planung. „Drei Monate im Voraus mit der Planung beginnen“ reicht für eine echte Flottenmigration nicht aus.
• Sollte eine Migration innerhalb dieses Zeitrahmens nicht möglich sein, sollten Sie noch vor Ablauf der Frist einen erweiterten Support sicherstellen. Der „Endless Lifecycle Support“ von TuxCare für RHEL 7 bietet fortlaufende CVE-Patches weit über den von Red Hat selbst angebotenen erweiterten Supportzeitraum hinaus – was besonders dann wichtig ist, wenn Sie ältere Anwendungsstacks haben, die weder in diesem noch im nächsten Geschäftsjahr migriert werden.

4 Tools zur Verbesserung der Sicherheit unter RHEL

Viele Tools versprechen, die Sicherheit unter Linux zu verbessern. Diese vier schließen tatsächlich Sicherheitslücken, die in RHEL-Produktionsumgebungen von Bedeutung sind.

TuxCare

TuxCare löst die beiden größten Herausforderungen im Bereich der Sicherheitsverwaltung von RHEL: das Patchen von CVEs im Kernel und in gemeinsam genutzten Bibliotheken ohne Neustart sowie die weitere Bereitstellung von Patches für Systeme, nachdem Red Hat die Veröffentlichung von Updates für diese eingestellt hat.

KernelCare wendet CVE-Korrekturen für den Kernel auf laufende Systeme einer Vielzahl von RHEL-Versionen an, darunter auch ältere und EOL-Versionen. LibCare erweitert dies auf gemeinsam genutzte Bibliotheken wie glibc und OpenSSL, die bei herkömmlicher Installation von Patches ebenfalls einen Neustart der Dienste erfordern. Zusammen schließen diese beiden Lösungen die Lücke bei der Aufschiebung von Neustarts, die die meisten Patching-Programme für Enterprise-Linux-Systeme beeinträchtigt.

Das „Endless Lifecycle Support“ (ELS)-Programm ist besonders für Unternehmen relevant, die RHEL 7 einsetzen. Der von Red Hat selbst angebotene erweiterte Support deckt nur einen begrenzten Zeitraum nach dem EOL im Juni 2024 ab. Das Angebot von TuxCare erweitert die Bereitstellung von CVE-Patches über diesen Zeitraum hinaus, solange ein Unternehmen dies benötigt – was von Bedeutung ist, wenn sich der Zeitrahmen für die Migration eher in Jahren als in Quartalen bemisst.

OpenSCAP

OpenSCAP ist der Compliance-Scanner, der im Lieferumfang von RHEL enthalten ist. Er arbeitet mit Sicherheitsrichtlinien im SCAP-Format – CIS-Benchmarks, DISA-STIGs, PCI-DSS-Profile – und erstellt einen detaillierten Bericht darüber, wo Ihr System davon abweicht. Die Berichte erfordern zwar eine gewisse Interpretation und das Tool ist nicht besonders schick, aber es ist der direkteste Weg zu einer echten Compliance-Baseline für eine RHEL-Umgebung, ohne dass Sie mehr ausgeben müssen, als Sie ohnehin schon bezahlen.

Red Hat Insights

Insights ist der in Red Hat integrierte Dienst für prädiktive Analysen. Er analysiert Telemetriedaten von registrierten Systemen und deckt bekannte Schwachstellen, Konfigurationsabweichungen und Leistungsprobleme auf. Er ist in den meisten aktiven RHEL-Abonnements enthalten, was bedeutet, dass Teams, die ihn nicht nutzen, eine Funktion ungenutzt lassen, für die sie bereits bezahlt haben. Der Haken daran ist, dass man die Systeme registrieren und das Dashboard tatsächlich einsehen muss – Insights nützt nicht viel, wenn niemand die Ergebnisse überprüft.

Wazuh

Wazuh ist eine Open-Source-SIEM- und Host-Intrusion-Detection-Plattform, die unter RHEL gut läuft. Sie vereint Dateiintegritätsüberwachung, Protokollanalyse, Schwachstellenerkennung und Compliance-Berichterstattung in einem einzigen Stack. Für Teams, die weder Splunk noch IBM QRadar einsetzen möchten, ist Wazuh eine überzeugende Alternative – mit dem Nachteil, dass Sie nun selbst für den Betrieb und die Wartung des SIEM verantwortlich sind.

Verbessern Sie die Sicherheit von Red Hat mit TuxCare

Red Hat bietet eine solide Sicherheitsgrundlage. Die Lücke besteht zwischen dem, was die Plattform am ersten Tag bietet, und dem, was erforderlich ist, um diesen Sicherheitsstandard über einen längeren Zeitraum hinweg in einer realen Infrastruktur unter Betriebsdruck aufrechtzuerhalten.

Die beiden Bereiche, in denen diese Lücke bei Red Hat Security am häufigsten auftritt, sind zum einen die Häufigkeit von Patches – insbesondere das Problem der aufgeschobenen Neustarts bei CVEs für den Kernel und gemeinsam genutzte Bibliotheken – und zum anderen die Lebenszyklusplanung, insbesondere die Frage, was mit Systemen geschieht, die das Ende ihrer Lebensdauer (EOL) erreicht haben oder sich diesem nähern, ohne dass ein Migrationspfad bereitsteht.

Wenn Ihr Team eine ganze Reihe aufgeschobener Kernel-Neustarts zu bewältigen hat, RHEL 7 ohne Supportvertrag einsetzt oder eine so große Serverflotte verwaltet, dass herkömmliche Patch-Zeitpläne mit der Geschwindigkeit der Sicherheitslückenveröffentlichungen nicht Schritt halten können, bietet TuxCare Lösungen für alle drei Probleme. KernelCare und LibCare schließen die Neustartlücke. Der „Endless Lifecycle Support“ erweitert die CVE-Abdeckung über das EOL hinaus.

Zusammenfassung

Artikel Name

Red Hat Security 2025: Patches, Compliance und bewährte Verfahren

Beschreibung

Schützen Sie Ihre Red Hat Enterprise Linux (RHEL)-Systeme mit bewährten Verfahren für Patching, Compliance und Sicherheit. Erfahren Sie mehr über Expertenstrategien für sichere RHEL-Umgebungen.

Autor

Rohan Timalsina

Name des Herausgebers

TuxCare

Logo des Herausgebers