Härtung von systemd-Diensten

• systemd bietet leistungsstarke Funktionen zur Dienstverwaltung, doch die Standardeinstellungen sind eher auf Benutzerfreundlichkeit als auf Sicherheit optimiert, weshalb zusätzliche Härtungsoptionen angewendet werden sollten
• Mit dem Befehl systemd-analyze security lassen sich die Sicherheits-Expositionswerte aller oder einzelner Dienste analysieren und priorisieren
• Es gibt verschiedene Sicherheitsoptionen, die auf Dienstebene angewendet werden können; sie lassen sich individuell über /etc/systemd/system/ServiceName.service.d/override.conf usw. anpassen
• Zu den wichtigsten Optionen gehören ProtectSystem, PrivateTmp, NoNewPrivileges, SystemCallFilter, MemoryDenyWriteExecute und weitere Einstellungen, die Prozessrechte und den Zugriff auf Ressourcen einschränken
• Statt perfekte Sicherheit anzustreben, lässt sich das Risiko wirksam senken, indem man nach außen exponierte Dienste zuerst härtet; auch in Self-Hosting-Umgebungen ist der Effekt groß

---

Überblick über systemd

• systemd bietet bei der Dienstverwaltung einen sehr ausgereiften und robusten Ansatz
• Allerdings sind die Standardeinstellungen locker gehalten, weil sofortige Nutzbarkeit höher gewichtet wird als Sicherheit
• Dieses Dokument stellt verschiedene Härtungsoptionen vor, die auf systemd-Service-Units und podman quadlets angewendet werden können, um die Wahrscheinlichkeit einer Kompromittierung zu senken und im Fall eines Vorfalls den Schaden zu begrenzen
• Es ist kein Leitfaden zur pauschalen Anwendung auf alle Dienste; je nach Eigenschaften und Anforderungen eines Dienstes sind individuelle Tests, Log-Prüfungen und Anpassungen erforderlich
• Die Verantwortung für die Sicherheit der Infrastruktur liegt vollständig beim Betreiber; dieses Dokument ist ein Hilfsmittel zur Orientierung

Sicherheitsanalyse von systemd

• Mit dem Befehl systemd-analyze security lässt sich der Sicherheitsstatus aller Dienste prüfen oder die Detailkonfiguration eines bestimmten Dienstes (z. B. sshd.service) analysieren
  • Die Ausgabe enthält Prüfergebnis, Funktionsname, Beschreibung und den Exposure-Wert; je höher der Exposure-Wert, desto größer das Risiko
• Sicherheitsoptionen können im Abschnitt [Service] (systemd) oder [Container] (podman quadlet) zusätzlich gesetzt werden
• Empfohlen wird die Erstellung einer Override-Datei über systemctl edit ServiceName.service; bei Fehlern sollten die benötigten Berechtigungen geprüft und angepasst werden

Sicherheitsoptionen für Dienste

• systemd bietet verschiedene Schlüsselwörter für Sicherheitsoptionen, die sich über man systemd.exec 5, man capabilities 7 usw. nachschlagen lassen
• Typische sicherheitsrelevante Optionen
  • ProtectSystem → beschränkt das Dateisystem auf schreibgeschützten Zugriff
  • ProtectHome → blockiert den Zugriff auf /home, /root, /run/user
  • PrivateDevices → blockiert den Zugriff auf physische Geräte und erlaubt nur virtuelle Geräte wie /dev/null
  • ProtectKernelTunables, ProtectKernelModules, ProtectKernelLogs → blockieren den Zugriff auf Kernel-Ressourcen
  • NoNewPrivileges → verhindert den Erwerb neuer Rechte über setuid/setgid usw.
  • MemoryDenyWriteExecute → verhindert die gleichzeitige Nutzung von beschreibbarem und ausführbarem Speicher; kann bei einigen JIT-Sprachen Probleme verursachen
  • SystemCallFilter → beschränkt zulässige System-Calls; bei Verstößen kann der Prozess beendet oder EPERM zurückgegeben werden

Erläuterung der einzelnen Optionen

• ProtectSystem: Mit der Einstellung strict wird das gesamte Dateisystem schreibgeschützt eingehängt; für /dev, /proc, /sys sind separate Schutzoptionen nötig
• ReadWritePaths: Erlaubt das Schreiben wieder nur auf bestimmten Pfaden
• ProtectHome: Blockiert den Zugriff auf /home, /root, /run/user
• PrivateDevices: Deaktiviert den Zugriff auf physische Geräte und erlaubt nur Pseudo-Geräte wie /dev/null
• ProtectKernelTunables: Behandelt /proc und /sys als schreibgeschützt
• ProtectControlGroups: Erlaubt nur schreibgeschützten Zugriff auf cgroups
• ProtectKernelModules: Verbietet das explizite Laden von Kernel-Modulen
• ProtectKernelLogs: Beschränkt den Zugriff auf den Kernel-Log-Puffer
• ProtectProc: Mit der Einstellung invisible werden Prozesse anderer Benutzer in /proc/ verborgen
• ProcSubset: Blendet in /proc Inhalte aus, die nicht zu bestimmten PID-bezogenen Einträgen gehören
• NoNewPrivileges: Verhindert neue Privilegieneskalation über setuid, setgid und Dateisystem-Capabilities
• ProtectClock: Blockiert Schreibzugriffe auf System- und Hardware-Uhr
• SystemCallArchitectures: Mit native sind nur native Syscalls wie x86-64 erlaubt
• RestrictNamespaces: Beschränkt containerbezogene Namespaces
• RestrictSUIDSGID: Verhindert das Setzen der Dateibits setuid und setgid
• LockPersonality: Verhindert Änderungen der Ausführungsdomäne (nur für ältere Anwendungen relevant)
• RestrictRealtime: Beschränkt Echtzeit-Scheduling (nur für bestimmte Spezialdienste nötig)
• RestrictAddressFamilies: Beschränkt erlaubte Socket-Adressfamilien (z. B. AF_INET, AF_INET6, AF_UNIX usw.)
• MemoryDenyWriteExecute: Verhindert das zusätzliche Anlegen von Speicherbereichen mit Schreib- und Ausführungsrechten zugleich (Vorsicht bei Diensten mit JIT)
• ProtectHostname: Verbietet die Verwendung der Syscalls sethostname und setdomainname
• SystemCallFilter: Erlaubt dienstspezifische Regeln zum Zulassen oder Sperren von Syscalls und eine feingranulare Filterung
  • Gruppen, einzelne Syscalls sowie Allow-/Deny-Strategien lassen sich anpassen
  • Bei Verstößen kann statt eines Prozessabbruchs auch die Rückgabe eines Fehlercodes wie EPERM konfiguriert werden
  • Die vollständige Liste ist über systemd-analyze syscall-filter oder man systemd.exec(5) einsehbar
  • Mit dem Präfix ~ lässt sich eine gesamte Liste negieren (z. B. CapabilityBoundingSet=~CAP_SETUID usw.)

Vorgehen zum Anpassen von SystemCallFilter-Beschränkungen

• Mit auditd lässt sich beim Fehlschlagen eines Dienstes im Log prüfen, welcher Syscall blockiert wurde
  • sudo ausearch -i -m SECCOMP -ts recent ausführen und anschließend den Syscall-Wert prüfen
  • Den betreffenden Syscall oder die zugehörige Gruppe zu SystemCallFilter hinzufügen, um das Problem schrittweise zu beheben

Priorisierung der Härtung und Betriebstipps

• Es ist nicht nötig, alles auf jeden Dienst anzuwenden
• Entscheidend sind Bedrohungsmodell und Risikomanagement; insbesondere nach außen exponierte Dienste (httpd, nginx, ssh usw.) sollten zwingend berücksichtigt werden
• Auch bei benutzerdefinierten Kommandos und Timer-Units (als Ersatz für cron) ist eine frühzeitige Anwendung wirksam
• Je weniger komplex ein Dienst ist, desto eher ist eine feine Abstimmung möglich

Checkliste: empfohlene Kombination von Sicherheitsoptionen (Priorität für die erste Anwendung)

• ProtectSystem=strict
• PrivateTmp=yes
• ProtectHome=yes oder ProtectHome=tmpfs
• ProtectClock=yes, ProtectKernelLogs=yes, ProtectKernelModules=yes
• RestrictSUIDGUID=yes
• UMask=0077
• LockPersonality=yes
• RestrictRealtime=yes
• MemoryDenyWriteExecute=yes
• DynamicUser=yes oder User auf einen bestimmten Nicht-Root-Benutzer setzen

• Diese Punkte sind in der Regel eine Kombination, die sich für Dienste fast ohne Beeinträchtigung verwenden lässt
• Wenn zusätzlich Syscall-Filterung (SystemCallFilter) eingesetzt werden soll, sind detaillierte Tests erforderlich

Beispielkonfiguration für Traefik

• Ein Beispiel für einen containerbasierten Traefik-Dienst, der als systemd quadlet läuft und viele Sicherheitsoptionen anwendet
  • Verwendet werden u. a. ProtectSystem=full, ProtectHome=yes, SystemCallFilter=@system-service @mount @privileged
  • Mit CapabilityBoundingSet=~CAP_SETUID CAP_SETPCAP werden bestimmte Rechte entfernt
  • Mit RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK usw. wird der Netzwerkzugriff eingeschränkt

Fazit

• Die Härtungsoptionen von systemd sind für Administratoren von Unix-artigen Systemen ein praktisches Werkzeug, das in keinen Werkzeugkasten fehlen muss
• Sie sind kein perfektes Sicherheitsmittel, sondern ein Werkzeug zur Risikoreduzierung; es ist nicht nötig, wahllos auf alle Dienste Sicherheitseinstellungen anzuwenden
• Besonders für Administratoren in Self-Hosting-Umgebungen kann der Einsatz die Sicherheitslage deutlich verbessern
• Mit dem Grundsatz „Praktikabilität vor Perfektion“ wird empfohlen, die Optionen zumindest teilweise und passend zu Arbeitsabläufen und Umgebung einzusetzen