Linux-Patch-Management: Prozess, Fristen und Nachweis

Sie möchten Sicherheitsupdates auf Linux-Servern planbar einspielen lassen? Die Linux-Server-Betreuung übernimmt Updates in Wartungsfenstern mit Nachweis. Das CVE-Monitoring meldet neue Schwachstellen, die Ihre eingesetzten Versionen betreffen.

Sicherheitsupdates erscheinen für Linux-Distributionen fast täglich. Das Einspielen selbst ist mit apt upgrade oder dnf upgrade schnell erledigt. Schwierig sind die Fragen davor und danach: Welche Updates sind dringend, welche können bis zum nächsten Wartungsfenster warten, wann braucht der Server einen Neustart, und wie lässt sich gegenüber Kunden, Prüfern oder nach NIS2 nachweisen, dass der Prozess funktioniert?

Dieser Ratgeber beschreibt den Prozess in sechs Schritten, Fristen nach Kritikalität mit den zugehörigen Quellen, die Automatisierung mit unattended-upgrades und dnf-automatic, den Umgang mit Kernel-Updates und die Dokumentation für Audits.

Inhalt

• Was Linux-Patch-Management umfasst
• Der Prozess in sechs Schritten
• Fristen nach Kritikalität
• Automatische Updates: unattended-upgrades und dnf-automatic
• Kernel-Updates, Livepatching und Neustart-Fenster
• Container und Software außerhalb des Paketmanagers
• Nachweis für Audits und NIS2
• Unser Vorgehen bei WZ-IT
• Stand und Methodik

Was Linux-Patch-Management umfasst

Patch-Management betrifft mehr als die Pakete der Distribution. Ein typischer Server enthält mehrere Ebenen, die getrennt aktualisiert werden:

Ein Prozess, der nur die erste Ebene abdeckt, lässt die übrigen ungeschützt. Das ist der häufigste Befund in gewachsenen Umgebungen.

Der Prozess in sechs Schritten

Der BSI IT-Grundschutz beschreibt die Anforderungen im Baustein OPS.1.1.3 Patch- und Änderungsmanagement: ein Konzept, festgelegte Zuständigkeiten, geregelte Autoupdate-Mechanismen und die zeitnahe Bewertung und Priorisierung von Patches (BSI OPS.1.1.3, Edition 2023). In der Praxis ergibt das sechs Schritte:

1. Inventar: Welche Server, Distributionen, Versionen, Paketquellen, Container und Anwendungen gibt es? Ohne Inventar lässt sich keine Schwachstelle einem System zuordnen.
2. Quellen überwachen: Sicherheitshinweise der Distributionen (Debian Security, Ubuntu Security Notices, Red Hat Errata), Herstellerhinweise der Drittquellen und Schwachstellendatenbanken wie die NVD.
3. Bewerten und priorisieren: Schweregrad, aktive Ausnutzung, Erreichbarkeit des Systems, vorhandene Schutzmaßnahmen. Daraus ergibt sich die Frist.
4. Testen: Updates zuerst auf einem Test- oder weniger kritischen System, bei Clustern Knoten für Knoten. Rückfallweg festlegen, etwa Snapshot oder Backup.
5. Einspielen: im Wartungsfenster oder, bei kritischen Lücken, außerplanmäßig. Danach Neustartbedarf prüfen und Funktionen testen.
6. Nachweisen: Was wurde wann auf welchem System installiert, was wurde bewusst nicht installiert und warum? Das BSI verlangt, dass Entscheidungen gegen einen Patch mit Gründen dokumentiert werden (OPS.1.1.3.A15).

NIST beschreibt in SP 800-40 Rev. 4 vier Szenarien, für die jeweils ein eigener Ablauf festgelegt sein sollte: routinemäßiges Patchen, Notfall-Patchen, Notfall-Mitigation vor Verfügbarkeit eines Patches und nicht patchbare Systeme, etwa nach dem Supportende (NIST SP 800-40 Rev. 4). Für Systeme ohne Updates gilt der Ratgeber Linux End of Life.

Fristen nach Kritikalität

Für Unternehmen gibt es keine allgemein verbindliche Frist in Tagen. Das BSI spricht von „zeitnah“, die NIS2-Durchführungsverordnung (EU) 2024/2690 von „angemessener Zeit“. Konkrete Fristen entstehen in der eigenen Richtlinie. Drei Kriterien tragen sie:

• Schweregrad nach CVSS: Die Spezifikation ordnet Werte so ein: 0,1 bis 3,9 niedrig, 4,0 bis 6,9 mittel, 7,0 bis 8,9 hoch, 9,0 bis 10,0 kritisch (FIRST CVSS v3.1).
• Aktive Ausnutzung: Der Katalog Known Exploited Vulnerabilities (KEV) der US-Behörde CISA listet Lücken, die nachweislich angegriffen werden. Für US-Bundesbehörden legt seit Juni 2026 die Richtlinie BOD 26-04 die Fristen fest, die BOD 22-01 ersetzt: Sie richten sich nach KEV-Eintrag, Erreichbarkeit aus dem Internet, Automatisierbarkeit der Ausnutzung und Umfang der erlangten Kontrolle; die kürzeste Frist beträgt drei Tage, weniger dringende Fälle haben zwei Wochen (CISA BOD 26-04, BleepingComputer). Für Unternehmen in Deutschland ist das nicht verbindlich, aber ein brauchbarer Maßstab.
• Erreichbarkeit: Ein aus dem Internet erreichbarer Dienst ist dringender als ein interner Dienst hinter VPN und Firewall.

Eine Richtlinie kann daraus zum Beispiel diese Stufen ableiten. Die Werte sind ein Ausgangspunkt und werden an Schutzbedarf und Betriebsfenster angepasst:

Wichtig ist, dass die Frist dokumentiert ist und eingehalten wird. Eine kurze Frist, die regelmäßig verfehlt wird, ist im Audit schwerer zu vertreten als eine realistische Frist mit sauberem Nachweis.

Automatische Updates: unattended-upgrades und dnf-automatic

Debian und Ubuntu: Das Paket unattended-upgrades installiert Updates aus festgelegten Quellen automatisch. Auf Ubuntu Server ist es standardmäßig installiert und spielt Sicherheitsupdates einmal täglich ein; Updates aus -updates und -backports sind standardmäßig nicht aktiv (Ubuntu Server Docs). Auf Debian ist es meist installiert, kann je nach Installation aber fehlen oder deaktiviert sein und wird mit dpkg-reconfigure unattended-upgrades eingeschaltet (Debian Wiki). Einen automatischen Neustart führt es nur aus, wenn Unattended-Upgrade::Automatic-Reboot auf true gesetzt ist; der Standard ist laut Ubuntu-Dokumentation false.

RHEL, AlmaLinux, Rocky Linux: dnf-automatic wird über die Datei /etc/dnf/automatic.conf und systemd-Timer gesteuert. Red Hat dokumentiert die Timer dnf-automatic-notifyonly.timer (nur melden), dnf-automatic-download.timer (herunterladen) und dnf-automatic-install.timer (herunterladen und installieren) (Red Hat Dokumentation). Mit upgrade_type = security beschränkt sich die Installation auf Updates mit Sicherheitshinweis (dnf-automatic).

Automatik ist sinnvoll für Sicherheitsupdates mit geringem Risiko. Sie ersetzt nicht die Kontrolle: Ob Updates tatsächlich durchliefen, ob Dienste nach dem Update laufen und ob ein Neustart aussteht, gehört ins Monitoring.

Kernel-Updates, Livepatching und Neustart-Fenster

Ein neuer Kernel wirkt erst nach dem Neustart. Bibliotheken wie OpenSSL oder glibc wirken erst, wenn die Dienste, die sie nutzen, neu gestartet werden. Ob etwas aussteht, zeigen:

• Debian und Ubuntu: das Werkzeug needrestart, das laufende Prozesse mit veralteten Bibliotheken erkennt (Debian Wiki), auf Ubuntu zusätzlich die Datei /var/run/reboot-required.
• RHEL-Familie: dnf needs-restarting -r meldet, ob ein Neustart nötig ist (Dokumentation).
• Alle: Vergleich von uname -r mit der zuletzt installierten Kernel-Version.

Livepatching spielt ausgewählte Kernel-Korrekturen im laufenden Betrieb ein. Canonical Livepatch ist Teil von Ubuntu Pro, deckt Kernel-Lücken mit hohem oder kritischem Schweregrad ab und ist für bis zu 5 Maschinen privat kostenlos. Canonical schreibt ausdrücklich: „Canonical Livepatch is not a replacement for rebooting“ (Ubuntu Livepatch). Red Hat liefert für RHEL Live-Patches über kpatch, jeweils für einen bestimmten Kernel-Build. Livepatching verschiebt den Neustart in ein geplantes Fenster, ersetzt ihn aber nicht.

Neustart-Fenster werden deshalb fest vereinbart, zum Beispiel monatlich außerhalb der Geschäftszeiten. Bei Clustern und redundanten Diensten werden Knoten nacheinander neu gestartet, damit der Dienst erreichbar bleibt.

Container und Software außerhalb des Paketmanagers

• Container: Ein apt upgrade auf dem Host aktualisiert keine Container. Images müssen neu gezogen und Container neu erstellt werden. Feste Image-Versionen statt latest machen Updates nachvollziehbar.
• Drittquellen: Herstellerrepositorys für Docker, PostgreSQL oder Node.js haben eigene Zyklen und Sicherheitshinweise, die getrennt verfolgt werden.
• Anwendungen: CMS, Groupware und selbst kompilierte Software haben eigene Updatemechanismen. Der BSI-Baustein SYS.1.3 sieht für aus Quellcode übersetzte Software eine dokumentierte, reproduzierbare Installation vor (BSI SYS.1.3, Edition 2023).

Nachweis für Audits und NIS2

Das BSI-Gesetz verpflichtet wichtige und besonders wichtige Einrichtungen in § 30 zu Risikomanagementmaßnahmen, darunter nach Abs. 2 Nr. 5 „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen“. Die Einhaltung ist zu dokumentieren (§ 30 Abs. 1) (§ 30 BSIG). Für bestimmte digitale Dienste, etwa Cloud- und Rechenzentrumsdienste sowie Managed Service Provider, konkretisiert die Durchführungsverordnung (EU) 2024/2690 im Anhang unter 6.6 das Einspielen von Sicherheitspatches innerhalb angemessener Zeit und die begründete Ausnahme (Durchführungsverordnung (EU) 2024/2690).

Ein belastbarer Nachweis enthält:

• Richtlinie: Fristen je Stufe, Wartungsfenster, Zuständigkeiten, Ausnahmeregel
• Inventar: Systeme, Versionen, Paketquellen, Supportende
• Protokoll je Wartung: installierte Pakete mit Version, Zeitpunkt, durchgeführte Neustarts, Funktionstest
• Ausnahmen: nicht installierte Patches mit Begründung, Schutzmaßnahme und Wiedervorlage
• Kennzahl: Anteil der Systeme ohne offene Sicherheitsupdates älter als die Frist

Die Paketmanager liefern die Rohdaten: /var/log/apt/history.log auf Debian und Ubuntu, dnf history auf der RHEL-Familie.

Unser Vorgehen bei WZ-IT

In der Linux-Server-Betreuung ab 149,90 Euro netto je Server und Monat spielen wir Updates in vereinbarten Wartungsfenstern ein und dokumentieren den Betrieb je Server. Das Monitoring läuft 24/7, Backups sind mit bis zu 250 GB Speicher je Server enthalten. Die Reaktion auf P1-Incidents richtet sich nach dem gebuchten Service Level.

Das CVE-Monitoring gleicht neue Schwachstellen aus NVD, Herstellerhinweisen und den Security-Trackern der Distributionen mit dem Software-Inventar ab und priorisiert sie nach CVSS-Score. Wir bewerten Betroffenheit, Ausnutzbarkeit und Exposition; das Service Level regelt die Reaktion, nicht pauschal die Fertigstellung eines Patches. Wo der Ausgangsstand unklar ist, beginnt die Arbeit mit dem Server-Audit ab 290 Euro netto einmalig. Wie erreichbar Ihre Systeme tatsächlich sind, zeigt ein Schwachstellenscan mit OpenVAS.

Weiterführende Ratgeber

• Linux End of Life: Supportende und Optionen für Systeme ohne Updates
• Linux-Server härten: Checkliste mit CIS und BSI als Referenz
• Linux-Server-Wartungscheckliste: Patch-Zyklen im Rahmen der laufenden Wartung
• Linux-Kernel-Schwachstellen 2026: Patch-Management am Beispiel aktueller Kernel-Lücken

Stand und Methodik

• Erhebung: 26.10.2026.
• Regelwerke: BSI IT-Grundschutz-Kompendium Edition 2023 (OPS.1.1.3, SYS.1.3), NIST SP 800-40 Rev. 4 (April 2022), CVSS v3.1, CISA BOD 26-04 (ersetzt BOD 22-01), § 30 BSIG, Durchführungsverordnung (EU) 2024/2690.
• Werkzeuge: Standardverhalten nach Herstellerdokumentation von Canonical, Debian und Red Hat für RHEL 9.
• Beispiel-Fristen: eigene Ableitung aus den genannten Kriterien, keine Vorgabe eines Regelwerks.

Quellen

• BSI IT-Grundschutz OPS.1.1.3 Patch- und Änderungsmanagement (Edition 2023)
• BSI IT-Grundschutz SYS.1.3 Server unter Linux und Unix (Edition 2023)
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
• FIRST: CVSS v3.1 Specification
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• dnf-automatic und dnf needs-restarting
• § 30 BSI-Gesetz
• Durchführungsverordnung (EU) 2024/2690
• Ubuntu Server Docs: Automatic updates
• Debian Wiki: UnattendedUpgrades
• Red Hat: Automating software updates in RHEL 9
• Ubuntu Livepatch
• Debian Security Information und Ubuntu Security Notices