Refuerzo de seguridad (hardening) de servicios systemd

• systemd ofrece potentes funciones de gestión de servicios, pero su configuración predeterminada está optimizada para la usabilidad más que para la seguridad, por lo que es necesario aplicar opciones adicionales de hardening
• Con el comando systemd-analyze security se puede analizar el indicador de exposición de seguridad de todos los servicios o de un servicio específico, y así definir prioridades
• Existen diversas opciones de seguridad que pueden aplicarse a nivel de unidad de servicio, y pueden modificarse de forma individual mediante /etc/systemd/system/ServiceName.service.d/override.conf y similares
• Entre las opciones principales están ProtectSystem, PrivateTmp, NoNewPrivileges, SystemCallFilter, MemoryDenyWriteExecute, entre otras que limitan los privilegios del proceso y el acceso a recursos
• Más que buscar una seguridad perfecta, conviene priorizar el hardening de los servicios expuestos al exterior para reducir riesgos; esto también puede ser muy útil en entornos de self-hosting

---

Resumen de systemd

• systemd ofrece un enfoque muy maduro y robusto para la gestión de servicios
• Sin embargo, prioriza la facilidad de uso inmediata por encima de la seguridad, por lo que la configuración predeterminada es flexible
• Este documento presenta varias opciones de refuerzo de seguridad que pueden aplicarse a unidades de servicio de systemd y a podman quadlet para reducir la posibilidad de compromiso y minimizar el impacto si ocurre una intrusión
• No es una guía para aplicar todo de forma masiva a todos los servicios; cada servicio requiere pruebas individuales, revisión de logs y ajustes según sus características y funciones necesarias
• La responsabilidad de la seguridad de la infraestructura recae por completo en el operador, y este documento es solo una herramienta de referencia

Análisis de seguridad de systemd

• Con el comando systemd-analyze security se puede revisar el estado de seguridad de todos los servicios o analizar la configuración detallada de un servicio específico (por ejemplo, sshd.service)
  • La salida incluye si cada verificación se cumple, el nombre de la función, la descripción y la puntuación de Exposure; cuanto mayor sea Exposure, mayor será el riesgo
• Las opciones de seguridad pueden agregarse en la sección [Service] (systemd) o en la sección [Container] (podman quadlet)
• Se recomienda crear un archivo override con systemctl edit ServiceName.service; si algo falla, hay que revisar los permisos necesarios y ajustarlos

Opciones de seguridad para servicios

• systemd ofrece varias palabras clave de opciones de seguridad, que pueden consultarse con man systemd.exec 5, man capabilities 7, etc.
• Opciones representativas relacionadas con seguridad
  • ProtectSystem → opción para restringir el sistema de archivos a solo lectura
  • ProtectHome → opción para bloquear el acceso a /home, /root, /run/user
  • PrivateDevices → opción para bloquear el acceso a dispositivos físicos y permitir solo dispositivos virtuales como /dev/null
  • ProtectKernelTunables, ProtectKernelModules, ProtectKernelLogs → opciones para bloquear el acceso a recursos del kernel
  • NoNewPrivileges → opción para impedir la obtención de nuevos privilegios mediante setuid/setgid, etc.
  • MemoryDenyWriteExecute → bloquea el uso simultáneo de memoria escribible y ejecutable; puede causar problemas en algunos lenguajes con JIT
  • SystemCallFilter → opción para limitar las system calls permitidas; en caso de violación puede terminar el proceso o devolver EPERM

Explicación de cada opción

• ProtectSystem: con strict, monta todo el sistema de archivos como solo lectura; /dev, /proc, /sys requieren opciones de protección aparte
• ReadWritePaths: vuelve a permitir escritura solo en rutas específicas
• ProtectHome: bloquea el acceso a /home, /root, /run/user
• PrivateDevices: desactiva el acceso a dispositivos físicos y permite solo pseudo-dispositivos como /dev/null
• ProtectKernelTunables: deja /proc y /sys en modo solo lectura
• ProtectControlGroups: permite solo acceso de lectura a cgroups
• ProtectKernelModules: prohíbe la carga explícita de módulos del kernel
• ProtectKernelLogs: restringe el acceso al búfer de logs del kernel
• ProtectProc: con invisible, oculta en /proc/ los procesos que pertenecen a otros usuarios
• ProcSubset: bloquea en /proc el contenido distinto de ciertos elementos relacionados con PID
• NoNewPrivileges: bloquea nuevas elevaciones de privilegios mediante setuid, setgid y filesystem capabilities
• ProtectClock: bloquea la escritura al reloj del sistema/hardware
• SystemCallArchitectures: con native, permite solo syscalls nativas como x86-64
• RestrictNamespaces: limita namespaces orientados a contenedores
• RestrictSUIDSGID: bloquea la configuración de los bits setuid y setgid en archivos
• LockPersonality: evita cambios del dominio de ejecución (solo necesario en aplicaciones antiguas, etc.)
• RestrictRealtime: limita la planificación en tiempo real (solo necesaria en algunos servicios de propósito especial)
• RestrictAddressFamilies: limita las familias de direcciones de socket permitidas (por ejemplo, AF_INET, AF_INET6, AF_UNIX, etc.)
• MemoryDenyWriteExecute: bloquea la creación adicional de regiones de memoria escribibles y ejecutables a la vez (precaución con servicios que usan JIT)
• ProtectHostname: prohíbe el uso de las syscalls sethostname y setdomainname
• SystemCallFilter: define syscalls permitidas o bloqueadas por servicio, con filtrado detallado
  • Se pueden ajustar grupos, syscalls individuales y el modo de permitir/bloquear
  • También permite devolver códigos de error como EPERM en lugar de terminar el proceso
  • La lista completa puede verse con systemd-analyze syscall-filter o man systemd.exec(5)
  • Con el prefijo ~ se puede negar una lista completa (por ejemplo, CapabilityBoundingSet=~CAP_SETUID)

Proceso de ajuste de restricciones de SystemCallFilter

• Con auditd se puede revisar en los logs qué syscall fue bloqueada cuando falla un servicio
  • Ejecutar sudo ausearch -i -m SECCOMP -ts recent y revisar el valor de syscall
  • Luego se puede agregar esa syscall o el grupo relacionado a SystemCallFilter para resolver el problema de forma gradual

Prioridades para aplicar hardening y consejos operativos

• No es necesario aplicar todo a todos los servicios
• El modelo de amenazas y la gestión del riesgo son la clave; en especial, los servicios expuestos al exterior (httpd, nginx, ssh, etc.) deben considerarse de forma prioritaria
• También es efectivo aplicarlo de forma preventiva a comandos personalizados, unidades timer (reemplazo moderno de cron), etc.
• Cuanto más simple sea el servicio, mayor suele ser la posibilidad de hacer ajustes finos

Lista de verificación: combinación recomendada de opciones de seguridad (prioridad inicial de aplicación)

• ProtectSystem=strict
• PrivateTmp=yes
• ProtectHome=yes o ProtectHome=tmpfs
• ProtectClock=yes, ProtectKernelLogs=yes, ProtectKernelModules=yes
• RestrictSUIDGUID=yes
• UMask=0077
• LockPersonality=yes
• RestrictRealtime=yes
• MemoryDenyWriteExecute=yes
• DynamicUser=yes o definir User como un usuario específico distinto de root

• En general, esta combinación puede usarse en servicios sin causar casi ningún problema
• Si además se quiere aplicar filtrado de syscalls (SystemCallFilter), se requiere una prueba detallada

Ejemplo de configuración de Traefik

• Es un caso de uso de un servicio Traefik basado en contenedores ejecutado con systemd quadlet y con varias opciones de seguridad aplicadas
  • Se aplican opciones como ProtectSystem=full, ProtectHome=yes, SystemCallFilter=@system-service @mount @privileged, etc.
  • Con CapabilityBoundingSet=~CAP_SETUID CAP_SETPCAP se eliminan ciertos privilegios
  • También se aplican restricciones de acceso de red como RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK

Conclusión

• Las opciones de hardening de systemd son una herramienta práctica que vale la pena tener en la caja de herramientas de cualquier administrador de sistemas tipo Unix
• No deben verse como una medida de seguridad perfecta, sino como una herramienta para reducir riesgos, y no es necesario aplicar configuraciones de seguridad indiscriminadamente a todos los servicios
• En especial, pueden ayudar mucho a elevar el nivel de seguridad si las aprovechan administradores de entornos de self-hosting
• Se recomienda priorizar la “practicidad por encima de la perfección” y aplicarlas хотя sea de forma parcial dentro del alcance que se ajuste al trabajo y al entorno