Gestión de servidores Linux: aplicación de parches, supervisión y seguridad para proveedores de servicios de gestión (MSP)

La mayoría de los MSP funcionan con Windows. La mayoría de los clientes utilizan Windows. Sin embargo, el parque de servidores que da servicio a esos clientes es cada vez más heterogéneo, y Linux se encarga discretamente de alimentar los servidores web, los backends de aplicaciones, los servidores de bases de datos, las plataformas de contenedores y las cargas de trabajo nativas de la nube de las que dependen los clientes de Windows. Tanto si el MSP quiere gestionar Linux como si no, Linux está presente en el entorno.

Los MSP que lo hacen bien consideran a Linux como un componente de primer orden dentro de su entorno de gestión. Aplican la misma disciplina de aplicación de parches, la misma cobertura de supervisión, el mismo refuerzo de seguridad y la misma estrategia de copias de seguridad en ambos sistemas operativos, desde la misma consola siempre que sea posible. Los MSP que no lo hacen bien acaban con servidores Linux gestionados a base de conocimientos tribales, parcheados manualmente cuando alguien se acuerda, supervisados mediante cualquier script de bash que escribiera el último ingeniero y con copias de seguridad en lo que el propietario de la aplicación configuró hace años.

Esta guía aborda en qué consiste, en la práctica, la gestión de servidores Linux, en qué aspectos difiere esta disciplina de la gestión de Windows y cómo los proveedores de servicios gestionados (MSP) pueden gestionar ambos sistemas operativos desde un modelo operativo unificado.

¿Qué es la gestión de servidores Linux?

La gestión de servidores Linux es la disciplina que consiste en mantener los servidores Linux actualizados, supervisados, protegidos, con copias de seguridad y en buen estado operativo a lo largo de toda su vida útil. Abarca servidores físicos y virtuales, tanto locales como alojados en la nube, entornos con una sola distribución y entornos mixtos que ejecutan desde Ubuntu Server hasta RHEL, pasando por Debian y Amazon Linux.

En principio, el alcance es similar al de la gestión de servidores Windows. Hay que aplicar parches. Hay que supervisar los servicios. Hay que revisar los registros. Hay que verificar las copias de seguridad. Hay que reforzar las configuraciones. Sin embargo, los mecanismos son diferentes, y ahí es donde los MSP acostumbrados a entornos exclusivamente Windows se encuentran con dificultades.

En qué se diferencia la gestión de servidores Linux de la de Windows

Hay tres diferencias que son las más importantes.

El primero es la gestión de paquetes. Las actualizaciones de Windows se distribuyen a través de Windows Update o WSUS, un único canal de actualización para el sistema operativo y las aplicaciones de Microsoft. Las distribuciones de Linux utilizan gestores de paquetes (apt para Debian y Ubuntu, dnf o yum para RHEL, CentOS y Fedora, y zypper para SUSE) que gestionan las actualizaciones del sistema operativo, las actualizaciones de las aplicaciones y la resolución de dependencias desde una sola herramienta. El flujo de trabajo de aplicación de parches es diferente, los repositorios de paquetes son diferentes y las consecuencias de una actualización fallida son diferentes.

El segundo aspecto es la cultura de gestión de la configuración. Los entornos Windows se basan en gran medida en la interfaz gráfica de usuario y se gestionan mediante políticas de grupo. Los entornos Linux se basan en gran medida en archivos de configuración y, a menudo, se gestionan a través de Ansible, Puppet, Chef o scripts de shell. Un MSP que no cuente con una línea de base de configuración documentada para un servidor Linux hereda el estado en que lo dejó el propietario anterior, sin poder recurrir a un equivalente de las políticas de grupo.

El tercero es el silencio del fallo. Un servicio de Windows que funciona mal suele detectarse a través del Visor de eventos, el SCM o una señal clara en la interfaz de usuario. Un servicio de Linux que funciona mal escribe en un archivo de registro, se cierra con un código de estado distinto de cero y queda en silencio. Si nadie lee esos registros, nadie se da cuenta de que el servicio ha dejado de funcionar. La disciplina en la supervisión es más importante en Linux que en Windows, ya que el propio sistema operativo hace menos por señalar un problema.

Gestión de parches en Linux

La gestión de parches en Linux es la parte más habitual y crítica para la seguridad de esta disciplina. Kaseya VSA 10 permite gestionar parches en las principales distribuciones de Linux, automatizando el flujo de trabajo de detección, programación, aprobación e implementación que requieren las actualizaciones manuales de paquetes.

Hay algunas áreas de parcheo que merecen una atención especial.

Las actualizaciones del núcleo requieren reinicios y deben programarse en ventanas de mantenimiento, junto con comprobaciones de reinicio de los servicios. Las opciones de aplicación de parches en tiempo real, como Canonical Livepatch o kpatch, pueden reducir la frecuencia de los reinicios en los hosts críticos, pero no sustituyen a los reinicios programados, sino que los aplazan.

Las actualizaciones de OpenSSL y de las bibliotecas criptográficas afectan a un gran número de aplicaciones dependientes. Una vulnerabilidad del tipo Heartbleed en OpenSSL afecta a todos los servicios vinculados a él, y si se aplica un parche sin reiniciar dichos servicios, la versión antigua de la biblioteca permanece cargada en la memoria. La gestión de parches en Linux implica hacer un seguimiento de lo que está parcheado en el disco y de lo que realmente se está ejecutando.

Los servidores web, las bases de datos y otras aplicaciones (Apache, Nginx, MySQL, PostgreSQL, Redis) se ejecutan sobre el sistema operativo, pero tienen su propio ciclo de actualizaciones y sus propios canales de CVE. Los gestores de paquetes de la distribución se encargan de los paquetes básicos, pero los entornos de producción suelen utilizar repositorios proporcionados por los proveedores o imágenes de contenedores que deben gestionarse por separado.

Las utilidades del sistema con un historial de vulnerabilidades activo (sudo, polkit, glibc, systemd) suelen ser el blanco de ataques destinados a la escalada de privilegios. Aunque se corrigen en los ciclos habituales, conviene señalarlas en la gestión de cambios, ya que si se pasa por alto una actualización relacionada con un CVE de sudo, un punto de acceso con privilegios limitados puede convertirse en un acceso completo de root.

Supervisión y observabilidad en Linux

La supervisión de servidores Linux abarca cuatro áreas: recursos del sistema, disponibilidad de los servicios, actividad de los registros e integridad de los archivos.

La supervisión de los recursos del sistema controla la carga de la CPU, la presión sobre la memoria, la utilización del disco (tanto en espacio como en E/S), el uso del espacio de intercambio y el rendimiento de la red. El llenado del disco es la causa más habitual de fallo de los servicios en Linux; los directorios de registros o los registros de transacciones de bases de datos que llenan el volumen raíz pueden provocar la caída de todo el sistema del host sin previo aviso. La configuración de alertas de umbral para la utilización del disco es imprescindible.

La supervisión de la disponibilidad de los servicios confirma que los procesos que el servidor debería estar ejecutando se están ejecutando realmente y responden. Un servicio de systemd que aparece como activo pero que ha dejado de responder a las solicitudes no es detectable mediante el comando `systemctl status`; es necesario comprobarlo externamente para detectar el fallo. Las comprobaciones de HTTP, de conexión a la base de datos y de puertos TCP constituyen la base.

La supervisión de registros abarca los registros del sistema (journald, /var/log/syslog, /var/log/messages), los registros de aplicaciones (registros de acceso y de errores del servidor web, registros de consultas lentas de la base de datos) y los registros de seguridad (eventos de autenticación, ejecuciones de sudo, intentos de conexión SSH). Los patrones anómalos en estos registros suelen ser la primera señal de una intrusión.

La supervisión de la integridad de los archivos detecta cambios no autorizados en los archivos críticos del sistema. Herramientas como AIDE o Tripwire establecen un estado de referencia de los binarios y los archivos de configuración del sistema, y avisan cuando se producen cambios inesperados. Se trata de un control que distingue a los entornos Linux maduros de aquellos con una supervisión mínima.

Kaseya VSA 10 permite supervisar sistemas Linux mediante sondeos SNMP y comprobaciones basadas en agentes, con scripts personalizados que se pueden implementar para supervisar indicadores de estado específicos de las aplicaciones que la supervisión genérica no alcanza.

Seguridad y refuerzo de Linux

El refuerzo de la seguridad en Linux se basa en una aplicación rigurosa de los parches. Más allá de mantener los paquetes actualizados, las prácticas que reducen de forma significativa la superficie de ataque son bien conocidas y conviene aplicarlas como norma básica.

SSH debería exigir la autenticación mediante claves, no mediante contraseñas. La opción «PasswordAuthentication» debería establecerse en «no» en el archivo «sshd_config», la opción «PermitRootLogin» debería establecerse en «no», y el inicio de sesión debería realizarse a través de cuentas sin privilegios que amplíen sus privilegios mediante «sudo». La mayoría de los ataques de fuerza bruta que logran comprometer servidores Linux se deben a que se ha dejado habilitada la autenticación por contraseña en SSH, a menudo en el puerto predeterminado 22.

Se deben desactivar los servicios y puertos innecesarios. Un servidor web no necesita tener en marcha un servidor de retransmisión de correo, un servidor de bases de datos no necesita un servidor web, y un agente de compilación tampoco necesita ninguno de los dos. Al reducir la superficie de exposición de los servicios en escucha, se reducen las vías de acceso que un atacante tiene al servidor.

El acceso a sudo debe basarse en el principio del mínimo privilegio. Conceder un permiso general de sudo al grupo «wheel» a todos los usuarios administrativos resulta cómodo desde el punto de vista operativo, pero es poco seguro. Las entradas de sudo por comando, registradas a través de auditd, permiten saber qué comandos con privilegios se ejecutaron realmente y quién los ejecutó.

Se debe habilitar SELinux o AppArmor siempre que la distribución lo admita. Ambos son marcos de control de acceso obligatorio que limitan las acciones que pueden realizar los procesos más allá de los permisos de archivo tradicionales. Su configuración no es sencilla para aplicaciones personalizadas, pero en el caso de los servicios de distribución estándar aumentan considerablemente la dificultad de llevar a cabo un ataque con éxito.

Kaseya SIEM recopila los registros syslog de los servidores Linux y correlaciona los eventos de seguridad de Linux con la telemetría de terminales, redes y la nube procedente de más de 60 fuentes de datos. Los fallos de autenticación, los eventos de escalada de privilegios y la ejecución de procesos inusuales en servidores Linux son señales que se pierden cuando los registros de cada servidor permanecen aislados en el host. Con la correlación entre superficies, una ráfaga de SSH fallida seguida de un inicio de sesión correcto y, a continuación, una conexión saliente a un destino inusual se muestra como una única cadena de ataque, en lugar de tres eventos inconexos.

Copias de seguridad y recuperación ante desastres para servidores Linux

Los servidores Linux requieren las mismas medidas de recuperación que los servidores Windows. Copias de seguridad a nivel de imagen, capturas coherentes con las aplicaciones, pruebas periódicas de restauración y una copia replicada fuera de las instalaciones o en la nube para la recuperación ante desastres.

Datto BCDR ofrece copias de seguridad a nivel de imagen para máquinas virtuales Linux y servidores Linux bare-metal, con la misma captura coherente con las aplicaciones y la misma capacidad de virtualización instantánea que la plataforma proporciona para las copias de seguridad de máquinas virtuales Windows. Un mismo SIRIS puede albergar entornos protegidos tanto de Windows como de Linux, lo que simplifica las operaciones de recuperación en entornos con sistemas operativos mixtos.

Descubre Datto BCDR para la copia de seguridad de servidores Linux.

Gestión de servidores Linux para proveedores de servicios de gestión (MSP): gestión de entornos mixtos

La mayoría de los MSP no pueden elegir entre Windows y Linux. Se encuentran con un cliente cuya infraestructura principal es Windows, pero cuya plataforma web de cara al cliente funciona con Ubuntu; o con un cliente del sector manufacturero cuyo backend de ERP está en RHEL; o con un cliente de desarrollo de software cuya infraestructura de compilación completa se basa en contenedores Linux.

Lo que distingue a un MSP no es si ofrece soporte para Linux, sino si aplica el mismo rigor operativo a este sistema. Analicemos un caso típico. Un cliente de servicios profesionales con 40 usuarios cuenta con dos máquinas virtuales Linux que alojan su sitio web público y su wiki interna. La parte de Windows está totalmente gestionada por el servicio estándar del MSP. La parte de Linux está «cubierta», pero se le aplican parches manualmente cuando alguien se acuerda, sin más supervisión que comprobaciones de ping. Se publica un CVE del kernel, una estación de trabajo se ve comprometida a través de una vía no relacionada y el atacante se desplaza lateralmente hacia la máquina virtual Linux sin parches, que se convierte en el punto de persistencia. La parte de Windows aguantó. La parte de Linux, que el MSP no gestionaba realmente, no lo hizo.

El trabajo técnico necesario para que Linux alcance el mismo nivel no es muy complicado. Basta con instalar el agente VSA, programar la aplicación de parches, definir los umbrales de supervisión, integrar el syslog en el SIEM y añadir los hosts a la programación de copias de seguridad. Lo difícil es reconocer que un servidor Linux semigestionado es un riesgo que debe gestionarse adecuadamente o quedar explícitamente fuera del ámbito de actuación, y no quedarse a medio camino.

Cómo Kaseya Intelligence las operaciones en Linux

Kaseya Intelligence se basa en más de tres exabytes de datos agregados y anonimizados y en más de 17 millones de terminales gestionados, lo que permite la ejecución de acciones autónomas en toda la Kaseya 365 . El cambio consiste en pasar de ofrecer recomendaciones a ejecutar y validar resultados sin intervención manual.

En los entornos de servidores Linux, esto es especialmente importante en lo que respecta a la aplicación de parches, donde la programación manual y la verificación posterior a la aplicación han hecho que, históricamente, Linux requiera una inversión de tiempo desproporcionada en comparación con Windows. La implementación automatizada de parches a través de Kaseya VSA 10, junto con la validación de flujos de trabajo basada en inteligencia, reduce esa brecha. La misma eficiencia operativa que permite que la aplicación de parches en Windows se pueda escalar a miles de terminales empieza a aplicarse a Linux. Descubre Kaseya Intelligence.

Un servidor Linux al que se le aplican parches, se supervisa, se refuerza y del que se realizan copias de seguridad con el mismo nivel de exigencia que los servidores Windows que lo rodean no es un proyecto de ingeniería exótico. Se trata de la misma disciplina de gestión aplicada a un gestor de paquetes diferente. Los MSP que interiorizan esto y ejecutan Linux como una parte fundamental del parque informático son aquellos cuyos clientes no se ven sorprendidos por un incidente relacionado con Linux. Los MSP que no lo hacen son los que tienen que explicar al cliente, a posteriori, por qué el equipo del que no sabían mucho fue el que permitió la entrada del atacante.