Linux-Infrastruktur-Härtung für APAC-Systeme

Die meisten produktiven Linux-Systeme laufen näher an ihrer Standardkonfiguration, als irgendjemand zugeben möchte. Die Härtungsdokumente existieren, oft vor Jahren für ein Audit geschrieben, aber die Server entsprechen ihnen nicht. In der Lücke zwischen „dokumentierter Baseline" und „tatsächlicher Konfiguration" leben Angreifer zuverlässig.

Linux-Härtung ist die Disziplin, diese Lücke zu schließen, und das so, dass es das nächste Deployment übersteht.

Defaults sind ein Startpunkt, keine Sicherheitsposition #

Eine Linux-Standardinstallation priorisiert Kompatibilität, nicht Sicherheit. Sie liefert Dienste mit, die Sie nicht nutzen, Kernel-Funktionen, die Sie nicht brauchen, und Logging, das für einen Desktop genügt, nicht für einen kompromittierten Produktionshost. Härtung ist der Prozess, aus dieser Allzweckmaschine eine Spezialmaschine zu machen.

Die Hauptarbeit fällt in wenige Kategorien:

• Kernel- und Sysctl-Tuning: Netzwerkschutz (z. B. ICMP-Redirects ignorieren, Source-Route-Filterung aktivieren), Dateisystembeschränkungen und Speicherschutz wie Address Space Layout Randomisation.
• Dienstminimierung: Deaktivieren und Entfernen dessen, was der Host nicht betreibt, sodass nichts zu exploitieren übrig bleibt, was nicht in Gebrauch ist.
• Mandatory Access Control: SELinux oder AppArmor, um zu beschränken, was ein Prozess tun darf, selbst wenn er kompromittiert ist.
• Systemd- und Container-Härtung: Capabilities abgeben, Raw-Socket-Zugriff blockieren und Syscalls mit Seccomp-Profilen einschränken.
• Audit und Logging: die Ereignisse erfassen, die zählen, und sie vom Host versenden, damit ein Angreifer seine eigenen Spuren nicht tilgen kann.

Die CIS Benchmarks bleiben die praktischste, weithin anerkannte Kodifikation dieser Kontrollen, und OpenSCAP automatisiert sowohl ihre Anwendung als auch ihre Prüfung.

Konfiguration als Code, oder sie existiert nicht #

Ein Härtungsleitfaden, der in einem Wiki lebt, ist eine Wunschliste. Härtung, die in Code lebt (eine Ansible-Rolle, ein Packer-Image, eine Kubernetes-Admission-Policy), ist eine Tatsache. Wenn die Baseline Code ist, ändern sich drei Dinge:

1. Sie ist reproduzierbar. Jeder neue Host erbt die Baseline, nicht nur jene, an deren Konfiguration sich jemand erinnert hat.
2. Sie ist testbar. Ein Compliance-Scan in CI bricht den Build ab, wenn eine Einstellung driftet.
3. Sie ist reviewbar. Eine Änderung an der Baseline ist ein Pull Request mit derselben Review-Disziplin wie Anwendungscode.

Das ist der Unterschied zwischen Härtung als jährlichem Ereignis und Härtung als Eigenschaft der Plattform.

Unveränderlichkeit als Endzustand #

Die logische Konsequenz ist unveränderliche Infrastruktur: Hosts und Container werden nie in place gepatcht, sondern nur ersetzt. Ein neues Image wird gebaut, gescannt und deployed; das alte wird zerstört. Configuration Drift wird unmöglich, weil es nichts zum Driften gibt: Das laufende System ist ein Build-Artefakt.

Unveränderliche Infrastruktur passt natürlich zu Härtung-als-Code. Sie pflegen keine Baseline; Sie kompilieren Sicherheit ins Image. Und wenn eine Schwachstelle auftaucht, ist die Lösung ein Rebuild, keine SSH-Session um Mitternacht.

Jenseits des Hosts #

Härtung endet nicht am Betriebssystem. Dieselbe Disziplin erstreckt sich in mehrere Richtungen nach außen, jede mit ihren eigenen Fehlermustern.

Container erben alles und fügen eigene Risiken hinzu. Ein Container-Image auf einer ungehärteten Basisschicht trägt jede Schwäche auf Host-Ebene in jeden Pod, der es läuft. Die Lösung liegt vorgelagert: minimale Basisimages, in CI gescannt, als non-root mit Read-only-Dateisystemen betrieben, reduzierten Capabilities und Seccomp-Profilen, die nur die Syscalls zulassen, die der Workload tatsächlich braucht. Das Default-Seccomp-Profil blockiert viel; ein passgenaues Profil, abgestimmt auf beobachtetes Syscall-Verhalten, blockiert den Rest. Kubernetes-Admission-Policies erzwingen all das flottenweit, sodass eine nicht konforme Bereitstellung gar nicht erst eingeplant wird.

OT-Umgebungen erhöhen die Einsatzhöhe. In industriellen und Operational-Technology-Umgebungen kollidiert Härtung mit Verfügbarkeit auf Weise, die Büro-IT nie sieht. Eine falsch angewendete CIS-Kontrolle an einem Gebäudeleitsystem, einem Produktionslinien-PLC-Netz oder einem Krankenhausgerätesegment erzeugt kein Finding: Sie erzeugt Ausfallzeit, manchmal mit Folgen für die Sicherheit von Menschen. OT-Härtung dreht daher die übliche Sequenz um: passive Überwachung und Inventar kommen zuerst, Änderungen geschehen in Wartungsfenstern mit Rollback-Plänen, und Kontrollen werden an Produktions-Spiegeln pilotiert, bevor irgendetwas Echtes angefasst wird. Wo IT fragt „Ist dieses System sicher?", muss OT fragen „Können wir das absichern, ohne es zu stoppen?"

Drift-Erkennung schließt den Kreis. Baselines verfallen durch routinemäßige Änderung: Ein Ingenieur öffnet einen Port zum Debuggen, ein Installer aktiviert einen Dienst wieder, ein Hotfix findet nie zurück in den Code. Ohne Erkennung ist der heute gehärtete Host der weiche von nächstem Jahr. Das Muster, das funktioniert: Konfigurationsscans nach Tagesplan, die Live-Hosts und Images gegen die codierte Baseline vergleichen, mit Findings, die als Alerts an Eigentümer gehen statt in einem quartalsweisen Bericht zu landen, den niemand liest. Drift, innerhalb eines Tages entdeckt, ist ein Ticket; Drift, binnen eines Jahres entdeckt, ist eine Incident-Untersuchung.

Ein gehärteter Host hinter einer übermäßig großzügigen Cloud-IAM-Rolle oder in einer ungescannten Container-Pipeline bleibt exponiert. Die dauerhafte Position behandelt Host-Baseline, Container-Build-Kette, Cloud-Konfiguration und Identitätsgrenzen als eine kontinuierliche Oberfläche, entsprechend überwacht.

Unsere Linux- & Infrastruktur-Härtung liefert Baselines als Code und automatisierte Drift-Erkennung, und unser Configuration & Architecture Assessment prüft die Cloud- und Identitätsschicht rund um den Host. Für das volle Bild vereinbaren Sie eine Engineering & Scoping Session.