Betriebssystem-Härtung für Linux

Linux wird vor allem im Server-, Cloud- und Infrastruktur-Bereich eingesetzt. Es zeichnet sich durch hohe Stabilität, geringe Ressourcenanforderungen und eine hohe Transparenz durch den Open-Source-Ansatz aus. Dadurch kann der Quellcode von Experten weltweit geprüft und verbessert werden, was die Sicherheit erhöht – jedoch keine vollständige Angriffsfreiheit garantiert.

Der Einsatzbereich von Linux umfasst insbesondere:

• Webserver
• Datenbankserver
• Mailserver
• Application Server

Auch Cloudumgebungen basieren überwiegend auf Linux, z.B.:

• Container-Technologien wie Docker und Kubernetes
• Microservices
• skalierbare Webanwendungen

Weiterhin ist Linux die Basis für Android und die meisten Embedded Systeme sowie im IoT-Umfeld stark vertreten. Diese Einsatzbereiche lassen wir an dieser Stelle jedoch zunächst außen vor, da hier besondere Rahmenbedingungen gelten, die wir gesondert betrachten.

Der Einsatz von Linux in Serverumgebungen sowie seine von Windows abweichende Architektur bestimmen maßgeblich die erforderlichen Hardening-Maßnahmen. Auch hier gilt: Gehe strukturiert und nach Best Practice vor. Nutze Ressourcen wie CIS Benchmarks oder die den BSI Grundschutz.

Die grundlegenden Härtungsprinzipien gelten sowohl für Windows- als auch für Linux-Systeme. Allerdings werden diese unter Linux technisch anders umgesetzt. Ein wesentlicher Vorteil von Linux liegt in seiner modularen Struktur und der damit verbundenen hohen Kontrolle über installierte Software. Dadurch sind Minimalinstallationen möglich, bei denen nur die tatsächlich benötigten Komponenten betrieben werden, was die Angriffsfläche effektiv reduziert.

Während bei Linux von Anfang an nur das installiert werden kann, was benötigt wird, ist es bei Windows im Nachhinein oft erforderlich, die Komponenten und Features zu deaktivieren, die nicht gebraucht werden.

Linux ist ein Betriebssystem, das hauptsächlich für die Arbeit in der Kommandozeile (Terminal, CLI) konzipiert ist. Daher sollten die grafischen Kompoenten wie:

• das grafische System (X11 bzw. X.Org),
• der Display Manager (GDM o.ä.),
• die Desktop-Umgebung (GNOME, KDE Plasma, XFCE, etc.) sowie
• der Window Manager (Mutter, KWin oder Openbox)

in der Regel nicht installiert werden. Der zentrale Remote-Zugangspunkt via SSH muss dagegen bestmöglich geschützt werden:

• Protokollversion 2 erzwingen
• Public Key-Authentifizierung
• Deaktivierung des Passwort-Logins
• Root-Login verbieten
• Zugriff auf bestimmte (Admin-)Benutzer beschränken
• Netzzugriff durch Firewall-Regeln begrenzen
• schwache Algorithmen deaktivieren
• Brute-Force-Schutz z.B. durch Fail2Ban einrichten

Wie du SSH unter Linux konfigurierst, hast du bereits im Kursmodul B5 gelernt.

Selbst bei einer zunächst restriktiven Paketwahl führt der laufende Betrieb eines Linux-Systems – insbesondere durch Nachinstallationen und automatische Abhängigkeitsauflösungen – im Laufe der Zeit zu einem gewissen Wildwuchs, der regelmäßig bereinigt werden sollte. Das erhöht die Angriffsfläche und muss daher im Rahmen des Hardening-Prozesses regelmäßig identifiziert und bereinigt werden.

Die Paketverwaltung sollte durch den jeweiligen Paketmanager der Linux-Distribution erfolgen. Bei Debian und debianbasierten Systemen ist das APT (Advanced Package Tool). Der Screenshot neben dem Titel des Abschnitts ist jedoch durch den Befehl dpkg -l entstanden. Damit werden alle installierten Pakete angezeigt. Dpkg ist das Basis-Tool für die Paketverwaltung, auf dem APT aufsetzt.

Neben dpkg und APT existieren diverse weitere Paketmanager. Ein Tool, das ebenfalls, aber nicht exklusiv in debian-basierenden Distributionen zum Einsatz kommt, ist snap. Dabei handelt es sich um ein containerisiertes Paketformat, das Anwendungen inklusive aller Abhängigkeiten isoliert bereitstellt. Die Anwendung läuft in einer isolierten Umgebung (Sandbox) und Updates führt snap automatisch im Hintergrund durch.

⚠️ Was bei snap zunächst positiv im Sinne der IT-Sicherheit klingt, entpuppt sich jedoch teilweise auch als Nachteil: durch die monolithische Bereitstellung der Software entsteht eine größere Angriffsfläche, der Ressourcenverbrauch steigt, es gibt eine zentrale Abhängigkeit vom Snap Store als zentraler Quelle und insgesamt hat der Administrator weniger Kontrolle.

Moderne Linux-Distributionen bringen jeweils eigene Paketverwaltungssysteme mit. Es ist in der Regel empfehlenswert, diese zu nutzen und Software ausschließlich aus den offiziellen Paketquellen der Distribution zu beziehen, da dies eine stabile Integration, konsistente Abhängigkeitsauflösung und regelmäßige Sicherheitsupdates gewährleistet.

Ist eine benötigte Software dort nicht verfügbar, können externe Pakete oder zusätzliche Paketquellen eingebunden werden. Dabei ist jedoch besondere Sorgfalt erforderlich, insbesondere hinsichtlich der Vertrauenswürdigkeit der Quelle, der Updatefähigkeit sowie möglicher zusätzlicher Angriffsflächen.

Auch auf Linux-Systemen ist die Dienst- und Prozesskontrolle ein zentraler Hebel im Hardening-Prozess. Ziel ist, nur notwendige Dienste laufen zu lassen, deren Verhalten strikt zu begrenzen und Abweichungen früh zu erkennen.

Die meisten Linux-Distributionen nutzen mittlerweile systemd zur Dienststeuerung. Die nachfolgende Abbildung zeigt, wie mit systemd alle aktiven Dienste angezeigt werden können:

Die Dienststeuerung geschieht mit dem Befehl systemctl. Die Syntax lautet:

systemctl <Aktion> <Dienst>

Beispiel: Zum Stoppen von Apache2 dient systemctl stop apache2. Soll der Dienst beim Systemstart nicht automatisch gestartet werden, kannst du den Befehl systemctl disable apache2 nutzen.

Normalerweise ist es möglich, den Dienst über systemctl start apache2 wieder zu starten. Um dies zu verhindern, kannst du systemctl mask apache2 eingeben, wodurch der Dienst komplett blockiert wird. Rückgängig machen lässt sich das durch systemctl unmask apache2.

Das Prinzip „Prozesse mit minimalen Rechten ausführen“ (Least Privilege auf Prozessebene) ist einer der wirksamsten Hardening-Hebel: Ein kompromittierter Dienst soll möglichst wenig Schaden anrichten können. Dies gilt übrigens gleichermaßen für Windows.

Das Ziel ist, dass jeder Dienst mit genau den Rechten läuft, die er benötigt – und mit keinen darüber hinausgehenden Privilegien. Du kennst bereits das Grundproblem: Läuft ein Dienst oder ein Prozess mit Root-Rechten und wird kompromittiert, kann der Angreifer weitere Prozesse mit diesen Rechten starten. Daher ist es elementar, die Root-Prozesse auf ein Minimum zu beschränken.

Jeder Dienst sollte einen eigenen Benutzer verwenden, der in seinen Rechten so weit wie möglich eingeschränkt ist. In der Abbildung neben dem Titel siehst du, wie z.B. Apache2 im Kontext des eingeschränkten Benutzers www-data läuft.

Nicht immer ist es möglich, einen Prozess mit geringen Rechten zu starten. Hier ist es wichtig, dass der jeweilige Prozess anderen Hardening-Maßnahmen unterliegt. Zum einen ist es nicht immer erforderlich, dass ein Prozess Root-Rechte hat. In diesem Fall kann unter Linux z.B. mit Capabilities gearbeitet werden.

Zudem ist es möglich, in der jeweiligen Service-Datei /etc/systemd/system/.service bestimmte Einstellungen festzulegen, die den Dienst schützen, z.B.:

NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes

Mit Mandatory Access Control (MAC), implementiert in AppArmor oder SELinux (siehe unten), steht ein weiterer sehr wirksamer Ansatz zur Rechtebegrenzung bereit.

Linux bietet durch seinen offenen Quellcode weitreichende Möglichkeiten zur Anpassung und Härtung des Kernels. Dazu gehören insbesondere

• die Konfiguration von Kernel-Parametern,
• das Deaktivieren unnötiger Module sowie
• die Nutzung integrierter Sicherheitsmechanismen.

Eine vollständige Neukompilierung des Kernels ist zwar möglich, spielt in der Praxis jedoch nur in speziellen Anwendungsfällen eine Rolle. Mit dem Programm sysctl können Kernel-Parameter zur Laufzeit konfiguriert werden. Das Verhalten des Kernel kann auch in der Konfigurationsdatei /etc/sysctl.conf festgelegt werden. Nachfolgend einige Beispiele zur Verdeutlichung der Vorgehensweise:

• net.ipv4.ip_forward = 0 – kein Routing
• net.ipv4.conf.all.rp_filter = 1 – Schutz vor IP-Soofing
• net.ipv4.tcp_syncookies = 1 – Schutz vor SYN-Flood
• kernel.randomize_va_space = 2 – ASLR aktiv (Adressrandomisierung)
• kernel.kptr_restrict = 2 – Kernel-Adressen verbergen
• kernel.dmesg_restrict = 1 – eingeschränkter Zugriff auf Kernel-Logs

Kernelmodule erweitern die Funktionalität des Kernels und werden dynamisch geladen. Sie erweitern ggf. die Angriffsfläche durch potenzielle Schachstellen und sind oft unnötig auf Serversystemen. Du kannst die Kernel-Module mit dem Befehl lsmod prüfen. Die Datei /etc/modprobe.d/blacklist.conf kann dazu verwendet werden, um Kernelmodule zu blockieren, so dass sie nicht mehr geladen werden. Die Syntax ist blacklist <Modulname>.

Beispiel für den Inhalt der Datei:

blacklist usb_storage
blacklist cramfs

Dadurch wird verhindert, dass USB-Sticks und dass das veraltete Compressed ROM File System gemountet werden können.

Sowohl AppArmor als auch SELinux sind Mandatory Access Control (MAC)-Systeme, die festlegen, was ein Prozess tun darf – unabhängig von Benutzerrechten.

Zur Unterscheidung: Die Linux-Rechte besagen, welcher Benutzer welche Zugriffsrechte hat. Die MAC-Systeme legen fest, welche Rechte ein Prozess hat.

AppArmor ist ein relativ einfach und pragmatisch zu konfigurierendes System, während SELinux komplex, dafür sehr mächtig und flexibel ist. Daraus ergibt sich auch die Entscheidungshilfe für den Einsatz.

AppArmor ist sinnvoll bei:

• schnellen Deployments
• kleineren/mittleren Umgebungen
• geringer Komplexität des Systems

SELinux ist dagegen sinnvoll bei:

• Enterprise-Umgebungen
• hohen Sicherheitsanforderungen
• komplexen Zugriffsszenarien

Sowohl AppArmor als auch SELinux ist auf debian-basierten Systemen verfügbar. Allerdings ist AppArmor in der Regel bereits vorinstalliert und mit einer Basiskonfiguration aktiv, während SELinux nachinstalliert und komplett konfiguriert werden muss.

💡 Gleich im Anschluss hast du die Gelegenheit AppArmor einmal in der Praxis kennenzulernen, um die Grundlagen dieses Systems zu verstehen.

Dies ist ein oft unterschätzter, aber kritischer Bestandteil des Linux-Hardening. Hintergrund: geplante Aufgaben sind ein beliebter Persistenzmechanismus – sowohl für legitime Administration als auch für Angreifer. Alle automatisch ausgeführten Aufgaben müssen bekannt, notwendig und vertrauenswürdig sein, denn: Was regelmäßig läuft, kann auch regelmäßig Schaden anrichten.

Cron ist ein Dienst, der zeitgesteuerte Befehle ausführt, z.B. Backups, Logrotation oder Updates. Die systemweiten Cronjobs kannst du dir mit cat /etc/crontab anschauen. Ein Beispiel findest du in der Abbildung neben der Überschrift zu diesem Abschnitt. Darüber hinaus gibt es Cron-Verzeichnisse für verschiedene Zeitabschnitte. Du Kannst sie dir mit dem Befehl ls /etc/cron.* anzeigen lassen. In der Ausgabe stehen oft:

• /etc/cron.hourly
• /etc/cron.daily
• /etc/cron.weekly
• /etc/cron monthly
• /etc/cron.yearly

Prüfe unbekannte Einträge, also fremde Skripte und verdächtige Befehle. Zudem sind externe Downloads mit curl oder wget immer kritisch zu hinterfragen. Angreifer nutzen Cronjobs für Backdoors, Datenexfiltration oder Nachladen von Malware.