Systemd Hardening Workshop

Vorwort

• In diesem Workshop geht es darum einen systemd Dienst sicherer zumachen

Debuggen

• Wir benutzen hierzu systemd-analyze
• Dieses Tool analysiert die Sicherheit und die Sandboxing-Einstellungen der Dienste.
• Der Befehl prüft auf verschiedene sicherheitsrelevante Diensteinstellungen
• Er weist jeder einen numerischen „Exposure Level“-Wert zu, je nachdem, wie wichtig die Einstellung ist.
• Anschließend berechnet es ein Gesamtexpositionsniveau für die gesamte Einheit durch eine Schätzung
• Diese lieht im Bereich von 0,0 bis 10,0, die uns sagt, wie exponiert ein Dienst sicherheitstechnisch ist.
• systemd-analyze security

UNIT                                 EXPOSURE PREDICATE HAPPY
cron.service                              9.6 UNSAFE    😨
dbus.service                              9.6 UNSAFE    😨
emergency.service                         9.5 UNSAFE    😨
getty@tty1.service                        9.6 UNSAFE    😨
rc-local.service                          9.6 UNSAFE    😨
rescue.service                            9.5 UNSAFE    😨
rsyslog.service                           9.6 UNSAFE    😨
ssh.service                               9.6 UNSAFE    😨
strongswan-starter.service                9.6 UNSAFE    😨
systemd-ask-password-console.service      9.4 UNSAFE    😨
systemd-ask-password-wall.service         9.4 UNSAFE    😨
systemd-fsckd.service                     9.5 UNSAFE    😨
systemd-initctl.service                   9.4 UNSAFE    😨
systemd-journald.service                  4.3 OK        🙂
systemd-logind.service                    2.6 OK        🙂
systemd-networkd.service                  2.9 OK        🙂
systemd-timesyncd.service                 2.1 OK        🙂
systemd-udevd.service                     8.0 EXPOSED   🙁
user@0.service                            9.8 UNSAFE    😨
user@1000.service                         9.4 UNSAFE    😨
webserver.service                         9.6 UNSAFE    😨

Vorgehensweise

• Wir können nun Schritt für Schritt die Verbesserungen überprüfen, die an unserem systemd-Dienst vorgenommen wurden.
• Wie Sie sehen können, sind jetzt mehrere Dienste als UNSAFE gekennzeichnet, was wahrscheinlich daran liegt, dass nicht alle Anwendungen die von systemd bereitgestellten Funktionen anwenden.

Einstieg

• Beginnen wir mit einem einfachen Beispiel.
• Wir wollen eine systemd-Unit erstellen, um den Befehl python3 -m http.server als Dienst zu starten:

[Unit]
Description=Simple Http Server
Documentation=https://docs.python.org/3/library/http.server.html

[Service]
Type=simple
ExecStart=/usr/bin/python3 -m http.server
ExecStop=/bin/kill -9 $MAINPID

[Install]
WantedBy=multi-user.target

• Wir speichern diese Datei unter /etc/systemd/system/simplehttp.service ab

Überprüfung

• systemd-analyze security | grep simp

simplehttp.service                        9.6 UNSAFE    😨

PrivateTmp

• Es erstellt einen Dateisystem-Namensraum unter /tmp/systemd-private-*-[Unit-Name]-*/tmp
• Dies wird anstelle eines gemeinsam genutzten /tmp oder /var/tmp benutzt.
• Viele der mit Red Hat Enterprise Linux veröffentlichten Unit-Dateien enthalten diese Einstellung.
• Dies entfernt die eine ganze Klasse von Schwachstellen im Zusammenhang mit der Vorhersage und Ersetzung von Dateien entfernt, die in /tmp verwendet werden.

Links

• https://www.linuxjournal.com/content/systemd-service-strengthening