Fortalecimiento del servicio Systemd | Diario de Linux

por calpee
9 / 100

Introducción

En una época en la que los ataques de piratas informáticos ocurren a diario, es de fundamental importancia minimizar la superficie de ataque. La contenedorización es probablemente la mejor manera de aislar un servicio prestado al público, pero esto no siempre es posible por varias razones. Por ejemplo, piense en una aplicación de sistema heredada desarrollada en systemd. Esto podría aprovechar al máximo las capacidades proporcionadas por un sistema operativo basado en systemd y podría administrarse a través de una unidad systemd, o podría extraer actualizaciones automáticamente usando un temporizador systemd, y así sucesivamente.[

Por este motivo, vamos a explicar cómo mejorar la seguridad de un servicio systemd. Pero primero, debemos dar un paso atrás por un momento. Con las últimas versiones, systemd ha implementado algunas características interesantes relacionadas con la seguridad, especialmente el sandboxing. En este artículo, vamos a mostrar paso a paso cómo fortalecer los servicios utilizando directivas específicas y cómo verificarlas con la suite systemd proporcionada.[

Depuración

Systemd proporcionó una herramienta interesante llamada systemd-analyse. Este comando analiza la seguridad y la configuración de espacio aislado de uno o más servicios especificados. El comando verifica varias configuraciones de servicio relacionadas con la seguridad, asignando a cada una un valor numérico de “nivel de exposición”, dependiendo de la importancia de la configuración. Luego calcula un nivel de exposición general para toda la unidad a través de una estimación en el rango 0.0… 10.0, que nos dice qué tan expuesto está un servicio en términos de seguridad.

[

Esto nos permite comprobar paso a paso las mejoras aplicadas a nuestro servicio systemd. Como puede ver, varios servicios ahora están marcados como INSEGUROS, esto probablemente se deba al hecho de que no todas las aplicaciones están aplicando las funciones proporcionadas por systemd.[

Empezando

Comencemos con un ejemplo básico. Queremos crear una unidad systemd para iniciar el comando python3 -m http.server como servicio:[

[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-usuario.target

Guarde el fichero y colóquelo en el directorio systemd concreto de su distribución.[

Comprobando la exposición de seguridad a través de systemd-analyze security obtenemos el siguiente resultado:[

Inicio del servicio Systemd[

El valor de la seguridad es ahora 9,6/10 y está marcado como INSEGURO. Veamos ahora cómo fortalecer el servicio actual para hacerlo más seguro.[

PrivateTmp

Crea un espacio de nombres del sistema de archivos bajo /tmp/systemd-private-*-[unit name]-*/tmp en lugar de un compartido /tmp o /var/tmp. Muchos de los archivos de unidad publicados con Red Hat Enterprise Linux incluyen esta configuración, que elimina toda una clase de vulnerabilidades relacionadas con la predicción y el remplazo de archivos empleados en /tmp.[[4]

Es de esta forma como aparece el servicio después de insertar la próxima directiva:[

[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

# Sandboxing features
PrivateTmp=yes

[Install]
WantedBy=multi-user.target

Este es el resultado que obtenemos de systemd-analyze:[

simplehttp.service                        9.2 UNSAFE    😨

¡Bien! Lo bajamos de 9,6 a 9.2. Veamos cómo hacerlo aún más seguro.[

NoNewPrivileges

Evita que el servicio y los procesos secundarios relacionados aumenten los privilegios. [4] Agregue la próxima fila:[

NoNewPrivileges=true

El siguiente resultado es:[

simplehttp.service                        9.0 UNSAFE    😨

Restringir espacios de nombres

Limita todos o un subconjunto de espacios de nombres al servicio. La directiva acepta cgroup, ipc, net, mnt, pid, user, y uts. [4]. Añada la siguiente fila:[

RestrictNamespaces=uts ipc pid usuario cgroup

Como puede ver arriba, el net el espacio de nombres no se ha predeterminado en tanto que el servicio debe vincularse a sí mismo en una plataforma de trabajo de red. Aislar net de un servicio de red lo hará inútil.[

simplehttp.service                        8.8 EXPOSED   😨

Desenlaces finales[

En el momento en que agregamos las otras ordenes al servicio, obtenemos un servicio como este:[

[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

# Sandboxing features
PrivateTmp=yes
NoNewPrivileges=true
ProtectSystem=strict
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH
RestrictNamespaces=uts ipc pid user cgroup
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
PrivateDevices=yes
RestrictSUIDSGID=true
IPAddressAllow=192.168.1.0/24

[Install]
WantedBy=multi-usuario.target

Por último llega a este resultado:[

simplehttp.service                        4.9 OK       😃

Lo bajamos de 9,6 a 4.9, que es un muy excelente resultado. Ahora todo el sistema está medianamente seguro.[

Conclusiones[

Ahora podemos prosperar la seguridad de nuestro sistema. Pero recuerde que no en todos los casos necesitaremos utilizar todas y cada una de las directivas systemd. Por eso debemos comprobarlos punto por punto para confirmarnos de que todos son válidos. Tampoco necesitamos alcanzar un valor bajo para cada servicio. Lo importante es resguardar nuestro sistema con las precauciones correctas.[

Puede encontrar aquí un pequeño libro de jugadas de Ansible para configurar una demostración sobre el siguiente artículo. Esto podría ayudarlo a practicar con esta característica asombrosa introducida por systemd.[

Alessio Greggi es un informático graduado en la Facultad de Roma, Tor Vergata. Ha trabajado como analista de seguridad y DevOps. Trabaja eminentemente en Shell Scripting, Python, Go y Ansible. Puede estar comunicado con Alessio mediante LinkedIn.[

You may also like