Der Linux-Kernel behebt mittlerweile mehr als 1.500 CVE pro Hauptversion, und die Prognosen für Linux 7.3 nähern sich 2.000 CVE pro Release. Diese Inflation, die durch KI-gestützte Codeanalyse-Tools vorangetrieben wird, verändert die Situation für Systemadministratoren radikal. Die Sicherung eines Linux-Systems beschränkt sich nicht mehr darauf, eine Firewall zu aktivieren und ein wöchentliches apt upgrade durchzuführen: Es ist eine Aufgabe der Sortierung, Priorisierung und kontinuierlichen defensiven Architektur.
Priorisierung der CVE des Linux-Kernels: Umgang mit der Flut von Patches
Zwischen den Versionen 6.9 und 6.19 des Kernels lag das Tempo bei etwa 500 behobenen CVE pro Release. Seit Linux 7.0 hat sich dieses Volumen verdoppelt und dann verdreifacht. Die Maintainer selbst geben an, “völlig überwältigt” von dem Fluss an Berichten zu sein, die über automatisierte Tools generiert werden.
Für einen Administrator bedeutet dies, dass das systematische Patchen jeder CVE ohne Priorisierungstools unrealistisch geworden ist. Alle Patches blind anzuwenden, führt dazu, dass die Dienste kontinuierlich neu gestartet werden, mit dem Risiko von funktionalen Regressionen bei Produktionslasten.
Ein roher CVSS-Score von 7.5 für eine Netzwerkverwundbarkeit hat nicht die gleiche Auswirkung auf einen isolierten Server hinter einem privaten Netzwerk wie auf eine Maschine, die in der DMZ exponiert ist. Ein kontextbezogener CVSS-Score-Ansatz ermöglicht es, die tatsächlich kritischen Patches zu priorisieren.
Tools wie KernelCare (Live-Patching ohne Neustart) oder die von den Distributionen bereitgestellten OVAL-Feeds filtern die für Ihre tatsächliche Konfiguration anwendbaren CVE. Die Ressourcen, die der Sicherheit auf Hebdo Linux gewidmet sind, ergänzen diese technische Überwachung sinnvoll.
SSH-Konfiguration und Kontrolle des privilegierten Zugriffs unter Linux
SSH bleibt der am häufigsten angegriffene Vektor auf exponierten Linux-Servern. Die Standardkonfiguration von OpenSSH auf den meisten Distributionen ist funktional, aber nicht sicher.
Wichtige sshd_config-Parameter, die priorisiert gesperrt werden sollten
- PermitRootLogin no und Deaktivierung der Passwortauthentifizierung (PasswordAuthentication no): Nur die Authentifizierung mit Ed25519- oder ECDSA-Schlüsseln sollte auf einem Produktionsserver erlaubt sein
- Einschränkung der Verschlüsselungsalgorithmen auf moderne Suiten über KexAlgorithms und Ciphers, wobei diffie-hellman-group1-sha1 und CBC ausdrücklich ausgeschlossen werden
- Aktivierung von AllowUsers oder AllowGroups, um den SSH-Zugang auf eine namentliche Liste von Konten zu beschränken, anstatt sich ausschließlich auf die Firewall zu verlassen
- MaxAuthTries auf 3 festgelegt und LoginGraceTime auf 30 Sekunden reduziert, um das Fenster für Brute-Force-Angriffe zu begrenzen
Verwaltung der Privilegieneskalation mit sudo
Die sudoers-Konfiguration verdient ebenso viel Aufmerksamkeit wie SSH. Eine zu großzügige sudoers-Datei hebt jede Politik der minimalen Privilegien auf. Es gibt immer noch regelmäßig Konfigurationen, bei denen ein Anwendungsbenutzer über ALL=(ALL) NOPASSWD: ALL verfügt, was ihm dauerhaften Root-Zugriff gewährt.
Die beste Praxis besteht darin, gezielte Befehlsalias (Cmnd_Alias) für jede Anwendungsrolle zu erstellen und jede sudo-Invocation über syslog zu protokollieren. In Kombination mit auditd bietet dies eine vollständige Nachverfolgbarkeit privilegierter Aktionen.
Reduzierung der Angriffsfläche im Netzwerk auf einem Linux-Server
Jeder offene Port und jeder aktive Dienst stellt einen potenziellen Einstiegspunkt dar. Die Reduzierung der Angriffsfläche beginnt mit einer gründlichen Bestandsaufnahme.
Der Befehl ss -tulnp (der netstat ersetzt) listet die lauschenden Sockets mit dem zugehörigen Prozess auf. Auf einem typischen Webserver sollten nur die Ports 22, 80 und 443 erscheinen. Jeder zusätzliche Dienst (postfix, cups, avahi-daemon, rpcbind) sollte über systemctl disable deaktiviert und dann mit systemctl mask maskiert werden, um eine versehentliche Reaktivierung zu verhindern.
Für die Netzwerkfilterung hat nftables iptables als Standard-Framework auf neueren Kernen ersetzt. Seine deklarative Syntax über Sets und Maps vereinfacht die Verwaltung von Regeln im großen Maßstab. Eine Standardrichtlinie, die auf den Chains input und forward auf drop eingestellt ist, mit expliziter Öffnung der erforderlichen Flüsse, bleibt die Grundlage.
Audit und Protokollierung: auditd, journald und Linux-Eindringungserkennung
Ohne zentrale Protokollierung bleibt jede Kompromittierung unsichtbar, bis die Schäden festgestellt werden. Das Audit-Framework des Linux-Kernels (auditd) ermöglicht die Überwachung kritischer Systemaufrufe mit feiner Granularität.
Die Regeln, die prioritär konfiguriert werden sollten, betreffen die Überwachung von Änderungen an /etc/passwd, /etc/shadow, /etc/sudoers und den SSH-Konfigurationsdateien. Eine auditctl-Regel vom Typ -w /etc/shadow -p wa -k shadow_changes protokolliert jede Schreib- oder Attributänderung an der Datei.
Für die dateibezogene Eindringungserkennung generiert AIDE (Advanced Intrusion Detection Environment) einen kryptografischen Fingerabdruck des Systemverzeichnisses. Jede unautorisierte Änderung einer Binärdatei oder einer Konfigurationsdatei löst beim nächsten Scan einen Alarm aus. Ein täglicher Scan über cron mit dem Versand des Berichts über einen verschlüsselten Kanal stellt ein minimales Viable dar.
Journald, kombiniert mit einer Remote-Aggregation (über systemd-journal-remote oder einen Collector wie rsyslog zu einem SIEM), ermöglicht die Korrelation von Ereignissen zwischen mehreren Servern. Ein Angreifer, der eine Maschine kompromittiert, wird versuchen, die lokalen Protokolle zu löschen. Das Senden der Protokolle an einen Drittserver macht diese Löschung ineffektiv.
Cyber Resilience Act und Konformität der Linux-Systeme in Europa
Der Cyber Resilience Act (CRA) verpflichtet Softwareanbieter, einschließlich solcher, die Open-Source-Komponenten integrieren, zur Nachverfolgung von Schwachstellen und zur Bereitstellung von Patches über die gesamte Lebensdauer des Produkts. Die ersten Berichtspflichten treten im September 2026 in Kraft.
Für die Teams, die Linux in professionellen Umgebungen bereitstellen, bedeutet der CRA konkret, dass die Nachverfolgbarkeit der Komponenten (SBOM, Software Bill of Materials) und die Fähigkeit, einen Patch-Management-Prozess nachzuweisen, regulatorische Anforderungen werden, nicht nur bewährte Praktiken. Die großen Distributionen haben begonnen, nutzbare SBOM bereitzustellen, aber die Verantwortung für die Einhaltung liegt weiterhin bei der Entität, die das Produkt auf dem europäischen Markt anbietet.
Die Kombination eines Kernels, der fast 2.000 CVE pro Release generiert, und eines regulatorischen Rahmens, der eine dokumentierte Verwaltung jeder Schwachstelle verlangt, macht Live-Patching-Tools und Automatisierung der Priorisierung nicht mehr optional, sondern strukturell notwendig für jede Linux-Infrastruktur in Produktion.
