Absicherung von Diensten mit systemd

Sicherung Ihrer Dienste

• Eines der Kernmerkmale von Unix-Systemen ist die Idee der Privilegientrennung zwischen den verschiedenen Komponenten des Betriebssystems.
• Viele Systemdienste werden unter ihren eigenen Benutzer-IDs ausgeführt, was ihre Möglichkeiten und damit die Auswirkungen auf das Betriebssystem einschränkt, falls sie ausgenutzt werden.

• Diese Art der Privilegientrennung bietet jedoch nur einen sehr grundlegenden Schutz, da auf diese Weise ausgeführte Systemdienste im Allgemeinen immer noch mindestens so viel tun können wie ein normaler lokaler Benutzer, wenn auch nicht so viel wie root.
• Aus Sicherheitsgründen ist es jedoch sehr interessant, die Möglichkeiten von Diensten noch weiter einzuschränken und einige Dinge abzuschalten, die normale Benutzer tun dürfen.

• Eine gute Möglichkeit, die Auswirkungen von Diensten zu begrenzen, ist der Einsatz von MAC-Technologien wie SELinux.
• Wenn Sie daran interessiert sind, Ihren Server abzusichern, ist die Ausführung von SELinux eine sehr gute Idee. systemd ermöglicht es Entwicklern und Administratoren, unabhängig von einem MAC zusätzliche Einschränkungen auf lokale Dienste anzuwenden.
• Unabhängig davon, ob Sie SELinux nutzen können, können Sie daher immer noch bestimmte Sicherheitsbeschränkungen für Ihre Dienste durchsetzen.

Systemd absichern

• Diese systemd-Funktionen wurden so konzipiert, dass sie so einfach wie möglich zu verwenden sind, um sie für Administratoren und Upstream-Entwickler attraktiv zu machen:

• Isolieren von Diensten vom Netzwerk=
• Service-private /tmp
• Verzeichnisse als schreibgeschützt oder für Dienste unzugänglich erscheinen lassen
• Funktionen von Diensten wegnehmen
• Verbieten von Forking, Einschränkung der Dateierstellung für Dienste
• Steuern des Geräteknotenzugriffs auf Dienste

Alle hier beschriebenen Optionen sind in den Manpages von systemd dokumentiert, insbesondere in systemd.exec(5)

• Alle diese Optionen sind auf allen systemd-Systemen verfügbar, unabhängig davon, ob SELinux oder ein anderer MAC aktiviert ist oder nicht.
• Alle diese Optionen sind relativ günstig, also nutze sie im Zweifelsfall.
• Auch wenn Sie denken, dass Ihr Dienst nicht in /tmp schreibt und daher die Aktivierung von PrivateTmp=yes (wie unten beschrieben) möglicherweise nicht erforderlich ist, ist es aufgrund der heutigen komplexen Software immer noch vorteilhaft, diese Funktion zu aktivieren, einfach weil Sie auf Bibliotheken verlinken (und Plug-Ins für diese Bibliotheken), die Sie nicht kontrollieren, benötigen möglicherweise doch temporäre Dateien. Beispiel: Sie wissen nie, welche Art von NSS-Modul Ihre lokale Installation aktiviert hat und was dieses NSS-Modul mit /tmp macht.

• Diese Optionen sind hoffentlich sowohl für Administratoren interessant, um ihre lokalen Systeme zu sichern, als auch für Upstream-Entwickler, um ihre Dienste standardmäßig sicher bereitzustellen. Wir empfehlen Upstream-Entwicklern dringend, diese Optionen standardmäßig in ihren Upstream-Serviceeinheiten zu verwenden.
• Sie sind sehr einfach zu bedienen und bieten große Vorteile für die Sicherheit.

Isolieren von Diensten vom Netzwerk Eine sehr einfache, aber leistungsstarke Konfigurationsoption, die Sie in systemd-Dienstdefinitionen verwenden können, ist PrivateNetwork=:

... [Service] ExecStart=... PrivateNetwork=ja ... Mit diesem einfachen Schalter wird ein Dienst und alle Prozesse, aus denen er besteht, vollständig von jeglicher Art der Vernetzung getrennt. Netzwerkschnittstellen sind für die Prozesse nicht mehr verfügbar, die einzige, die sie sehen, ist das Loopback-Gerät "lo", aber es ist vom echten Host-Loopback isoliert. Dies ist ein sehr leistungsfähiger Schutz vor Netzwerkangriffen.

Vorbehalt: Einige Dienste erfordern, dass das Netzwerk betriebsbereit ist. Natürlich würde niemand in Betracht ziehen, PrivateNetwork=yes auf einem netzwerkorientierten Dienst wie Apache zu verwenden. Aber auch für nicht netzwerkorientierte Dienste kann Netzwerkunterstützung notwendig und nicht immer selbstverständlich sein. Beispiel: Wenn das lokale System für eine LDAP-basierte Benutzerdatenbank konfiguriert ist, kann das Suchen von Glibc-Namen mit Aufrufen wie getpwnam() zu einem Netzwerkzugriff führen. Das heißt, selbst in diesen Fällen ist es meistens in Ordnung, PrivateNetwork=yes zu verwenden, da Benutzer-IDs von Systemdienstbenutzern auch ohne Netzwerk auflösbar sein müssen. Das heißt, solange die einzigen Benutzer-IDs, die Ihr Dienst auflösen muss, unter der magischen Grenze von 1000 liegen, sollte die Verwendung von PrivateNetwork=yes in Ordnung sein.

Intern verwendet dieses Feature Netzwerknamensräume des Kernels. Wenn aktiviert, wird ein neuer Netzwerk-Namespace geöffnet und nur das Loopback-Gerät darin konfiguriert.

Dienst-Privat /tmp Ein weiterer sehr einfacher, aber leistungsfähiger Konfigurationsschalter ist PrivateTmp=:

... [Service] ExecStart=... PrivateTmp=ja ... Wenn diese Option aktiviert ist, stellt sie sicher, dass das /tmp-Verzeichnis, das der Dienst sieht, privat und vom /tmp des Hostsystems isoliert ist. /tmp war traditionell ein gemeinsam genutzter Bereich für alle lokalen Dienste und Benutzer. Im Laufe der Jahre war es eine große Saure

Links

• http://0pointer.de/blog/projects/security.html