Cómo reforzar un servidor Linux de forma segura en 2026

Linux no tiene una consola centralizada para distribuir 250 configuraciones de seguridad entre 400 servidores. Una lista plana de 50 pasos de refuerzo deja el trabajo sin orientación. Empieza por los controles que reducen el acceso no autorizado y, después, avanza hacia restricciones más profundas del sistema.

Protege un servidor Linux haciendo coincidir el benchmark de CIS con su sistema operativo. Protege SSH y la escalada de privilegios, restringe la exposición de red, aplica controles compatibles del sistema de archivos y del kernel, parchea el host, reenvía los eventos de auditoría a un SIEM y comprueba el estado de los servicios después de cada lote.

Usa esta guía para ordenar el trabajo y revelar modos de fallo comunes. La certificación aún depende de la carga de trabajo del host, la configuración efectiva y los resultados de las pruebas.

En este artículo

• El refuerzo de Linux es gestión de configuraciones, no una búsqueda de ajustes
• Elige el benchmark que coincida con el sistema operativo
• Protege SSH antes de tocar la configuración del kernel
• Protege las rutas que llegan a root
• Cierra las rutas de red que no necesitas
• Refuerza cuidadosamente los sistemas de archivos temporales
• Usa sysctl para los controles que comprendas
• Parchea el host y después promueve un perfil probado
• Reenvía los eventos de auditoría para que impulsen la detección
• ¿Qué se romperá en un servidor real?
• Verifica el servidor en lugar de declarar la victoria

El refuerzo de Linux es gestión de configuraciones, no una búsqueda de ajustes

El refuerzo de Linux abarca configuraciones de paquetes, gestores de servicios, archivos de autenticación, módulos de seguridad, permisos y parámetros del kernel. La responsabilidad importa más que memorizar nombres de archivos.

Mantén un perfil para cada servidor. Registra su función y los servicios necesarios. Añade controles aprobados, excepciones, pasos de reversión y evidencias de verificación. Los sistemas de las familias Debian y RHEL necesitan procedimientos separados y, a escala, roles de Ansible separados. Un ajuste copiado de una guía de RHEL puede ser incorrecto para Debian aunque el nombre del archivo parezca conocido.

Aplica el trabajo en este orden:

1. protege SSH, las cuentas y la escalada de privilegios;
2. cierra las rutas de red innecesarias;
3. restringe los sistemas de archivos y el comportamiento del sistema;
4. parchea y mantén el host;
5. haz que los eventos de auditoría sean útiles para la detección;
6. verifica la configuración y el estado de los servicios.

Mantén SELinux en modo enforcing en sistemas de la familia RHEL y AppArmor habilitado en Ubuntu o Debian cuando la aplicación tenga un perfil funcional. Prueba las políticas antes de aplicarlas en modo enforcing.

Nuestro enfoque es deliberadamente aburrido: lotes pequeños, cambios registrados y una ruta de recuperación probada. Eso es mejor que recopilar comandos de shell de listas de comprobación incompatibles.

Elige el benchmark que coincida con el sistema operativo

Los CIS Benchmarks proporcionan la estructura inicial adecuada para el refuerzo de servidores Linux. El portal de CIS Benchmark ofrece los PDF de los benchmarks de forma gratuita para uso no comercial.

¿Qué versiones de Linux aparecen en la lista de 2026?

Plataforma	Versión del benchmark
AlmaLinux OS 8	4.0.0
AlmaLinux OS 9	3.0.0
AlmaLinux OS 10	1.0.0
Amazon Linux 2	4.0.0
Amazon Linux 2023	1.0.0
Debian Linux 11	2.0.0
Debian Linux 12	2.0.0
Debian Linux 13	1.1.0
Ubuntu 22.04	3.0.0
RHEL 10 STIG	1.0.0

La actividad de lanzamientos de 2026 incluye cobertura para Debian 13 y Ubuntu 22.04, mientras que RHEL 10 STIG 1.0.0 llegó durante el año. La actualización de CIS de enero de 2026 registra actividad adicional de benchmarks nuevos y revisados.

Empieza con el Nivel 1 para la mayoría de los sistemas de producción. Pasa al Nivel 2 cuando el requisito de seguridad justifique restricciones más estrictas y la aplicación haya superado sus pruebas. CIS es una línea base, no un script de despliegue en producción.

Un benchmark te proporciona un conjunto de controles defendible. No sabe si tu agente de monitorización necesita leer los logs de Nginx o si PostgreSQL depende de un límite concreto de memoria compartida.

Protege SSH antes de tocar la configuración del kernel

Deshabilitar la autenticación SSH mediante contraseña es más valioso que discutir sobre una lista perfecta de cifrados. Cierra primero la ruta de acceso a las cuentas.

Supón un host de producción Ubuntu o Debian que ejecuta Nginx, PostgreSQL y un agente de monitorización, administrado por un equipo pequeño de operaciones mediante SSH.

Antes de cambiar SSH, abre una segunda sesión administrativa con una clave probada. Mantén abierta la sesión actual. Confirma que otro administrador aprobado puede conectarse. Después, revisa un perfil como el siguiente:

PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 4
LoginGraceTime 60
ClientAliveInterval 300
ClientAliveCountMax 3
AllowGroups ssh-admins
Banner /etc/issue.net

PermitRootLogin no elimina el inicio de sesión remoto directo como root. PasswordAuthentication no elimina la autenticación mediante contraseña a través de SSH una vez que funciona el acceso basado en claves. AllowGroups limita el acceso SSH a las cuentas aprobadas; usa AllowUsers cuando sea más apropiada una lista explícita de usuarios.

Los ajustes de keepalive expresan una política de actividad prevista: sondear una conexión inactiva cada 300 segundos y cerrarla después de tres sondeos sin respuesta. Verifica la configuración efectiva, especialmente cuando los archivos incluidos o los drop-ins puedan anular el archivo principal.

El ajuste de algoritmos viene después. Lo siguiente es un ejemplo de política del material fuente, no una recomendación universal:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-256,hmac-sha2-512
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha256

Comprueba cada algoritmo frente a la versión instalada de OpenSSH y al conjunto de clientes antes de desplegarlo. Una lista de cifrados que deja aislado a tu único cliente administrativo es un control de seguridad con un criterio operativo deficiente. Banner /etc/issue.net sirve para avisos legales o de cumplimiento; no es una frontera de seguridad.

Valida con sshd -t, abre la nueva conexión y prueba el acceso administrativo. Usa el gestor de servicios de tu distribución para recargar OpenSSH solo después de que ambas comprobaciones sean correctas. Conserva la sesión existente hasta que la nueva funcione.

Protege las rutas que llegan a root

En los sistemas tratados aquí, root sigue formando parte del modelo de privilegios. Protege las rutas que llegan a él.

Usa cuentas humanas identificadas y exige sudo. Restringe la pertenencia a los grupos administrativos. Revisa qué comandos puede ejecutar cada administrador. Mantén separadas las identidades humanas de las cuentas de servicio. Nginx, PostgreSQL, las copias de seguridad y la monitorización deben ejecutarse con las identidades limitadas que requiere su trabajo.

Audita la ejecución de sudo y los cambios en la política de sudo. SSH controla la entrada; sudo controla lo que un usuario autenticado puede hacer después. Revisa ambos límites.

Ten cuidado con pam_faillock. El bloqueo puede reducir los intentos repetidos de autenticación interactiva, pero también bloquear una cuenta de servicio automatizada después de credenciales obsoletas o de un trabajo fallido. Limítalo a servicios PAM interactivos, como SSH y login, y prueba las tareas programadas por separado.

Cierra las rutas de red que no necesitas

Empieza con un inventario de listeners. Relaciona SSH, los servicios web y las bases de datos con las redes de origen que los necesitan. Haz lo mismo con la monitorización, las copias de seguridad y las interfaces de administración.

Identifica los listeners y sus responsables. Documenta las redes de origen necesarias y permite el acceso de recuperación para SSH. Después, aplica una política de allow-list. A continuación, inspecciona la exposición desde una sesión administrativa independiente.

Una vez definidos los permisos necesarios, deniega por defecto el tráfico entrante no solicitado. Elige las herramientas de firewall que encajen con la distribución y el entorno existente. UFW, nftables e iptables tienen usos legítimos, pero mezclar frameworks en un mismo host hace que la responsabilidad no esté clara.

Para el host de ejemplo, Nginx puede necesitar acceso público, mientras que PostgreSQL y la monitorización deberían aceptar conexiones únicamente desde redes aprobadas. Los puertos y las redes exactos deben figurar en tu inventario.

Deshabilitar IPv6 porque una lista de comprobación lo indica es teatro de seguridad hasta que hayas comprobado qué está escuchando en él. Las aplicaciones Java, Redis y algunos listeners de bases de datos pueden enlazarse a IPv6 de forma predeterminada. Audita primero los listeners y las rutas. Comprueba también los clientes. Protege IPv6 junto con IPv4, o deshabilítalo solo cuando la carga de trabajo demuestre que no se utiliza.

Refuerza cuidadosamente los sistemas de archivos temporales

Estas opciones suelen tener un impacto limitado, pero un host de producción aún puede depender de la ejecución, el acceso a dispositivos o el comportamiento SUID en esas rutas. Prueba cada montaje antes del despliegue.

Cuando sea compatible, establece noexec, nosuid y nodev para /tmp, /dev/shm y /var/tmp en /etc/fstab.

• noexec bloquea la ejecución de binarios desde el montaje.
• nosuid impide allí la ejecución de set-user-ID y set-group-ID.
• nodev impide que los archivos de dispositivo funcionen allí.

Prueba los instaladores y lanzadores de aplicaciones que utilizan estos directorios. Prueba también los agentes y los trabajos programados.

Para las sesiones gestionadas por PAM que no necesiten volcados de núcleo, usa límites como los siguientes:

* hard core 0
* soft core 0

Los archivos de núcleo pueden contener credenciales, claves y datos de aplicaciones. Esto limita las sesiones gestionadas por PAM; puede que no controle todos los demonios gestionados por systemd. Comprueba por separado el límite efectivo del demonio.

Verifica ASLR con:

kernel.randomize_va_space = 2

La mayoría de las distribuciones ya lo habilitan. Comprueba el valor efectivo en lugar de asumirlo.

Considera umask 027 una decisión de compatibilidad. En el host de ejemplo, prueba si el agente de monitorización todavía puede leer los logs de Nginx. Comprueba que las aplicaciones puedan crear los archivos temporales, de socket o PID que necesitan.

Usa sysctl para los controles que comprendas

Vucense describe el refuerzo mediante sysctl como un área de Nivel 1 de alto impacto y bajo esfuerzo. Eso respalda controles seleccionados, no un archivo genérico del kernel desplegado en todas partes.

Usa net.ipv4.tcp_syncookies=1 como ejemplo para evaluarlo frente al benchmark y la carga de trabajo seleccionados. No consideres universalmente seguro ningún valor sysctl aislado.

Los límites del kernel para hosts de bases de datos copiados de un benchmark genérico están sobrevalorados. Valores como kernel.shmmax, kernel.shmall y kernel.sem dependen de la configuración de la base de datos y de los requisitos del proveedor. Registra el valor anterior y define una ruta de reversión antes de cambiar cualquiera de ellos.

La deshabilitación de las páginas enormes transparentes es un área en la que las directrices de CIS y los proveedores de bases de datos, incluidos MongoDB, Redis y Oracle, apuntan en la misma dirección (para contenedores, consulta nuestra guía para asegurar contenedores Docker en producción). El método operativo exacto y su impacto aún requieren una validación específica de la base de datos.

Parchea el host y después promueve un perfil probado

Parchear es un control de refuerzo con un plazo asociado. Haz un inventario de las actualizaciones pendientes y pruébalas, cuando sea posible, en un entorno comparable. Programa la ventana de mantenimiento, aplica las actualizaciones, reinicia cuando sea necesario y, después, comprueba los servicios afectados.

La afirmación de “menos de 30 minutos” se aplica a un servidor Ubuntu nuevo y a un paso limitado de Nivel 1 en cinco áreas. Dice poco sobre un host de producción con dependencias de aplicaciones.

Después de las actualizaciones, comprueba el estado activo del gestor de servicios y el endpoint de estado de la aplicación. Prueba la conexión a la base de datos y el heartbeat de monitorización. Comprueba las copias de seguridad y el acceso administrativo. Registra el resultado y cualquier excepción.

Para el despliegue en una flota, promueve el perfil probado mediante roles de Ansible separados para las familias Debian y RHEL. Aplica los controles en lotes, revisa las excepciones y libera el rol en producción solo después de que el perfil supere sus comprobaciones de servicio.

Reenvía los eventos de auditoría para que impulsen la detección

Tener auditd en el servidor no es una estrategia de detección. Si un atacante puede borrar el log local, la mejora es principalmente cosmética; reenvía los eventos a un SIEM.

“Un servidor reforzado sin auditd configurado proporciona mejoras de cumplimiento, pero una capacidad de detección limitada. auditd con el conjunto de reglas adecuado convierte el servidor reforzado en un sistema de detección.”

Prioriza la ejecución de comandos privilegiados y los cambios en /etc/passwd, /etc/shadow, /etc/sudoers y /etc/sudoers.d/. Cubre también la política de sudo y la autenticación. Incluye su, los inicios de sesión SSH y la creación de sockets de red.

Entre las reglas representativas se incluyen:

-a always,exit -F arch=b64 -F euid=0 -S execve
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa
-w /etc/sudoers.d/ -p wa
-a always,exit -F arch=b64 -S socket

No copies este bloque como un perfil de producción completo. La sintaxis de las reglas, la cobertura de arquitecturas, la persistencia y el perfil de CIS seleccionado deben coincidir con el host. -S socket puede generar un volumen considerable de eventos, así que prioriza los eventos y configura deliberadamente los límites de frecuencia.

Reenvía los eventos mediante el dispatcher de auditd o un plugin audisp-syslog al transporte syslog compatible del host y, después, al SIEM. La ruta exacta varía según la distribución. Confírmala:

auditd → audit dispatcher or plugin → supported syslog transport → SIEM

Genera un comando privilegiado y un evento de autenticación. Cambia también un archivo supervisado. Confirma que el SIEM recibe registros consultables y que las detecciones relevantes funcionan.

¿Qué se romperá en un servidor real?

Considera esta tabla una revisión previa al cambio: encuentra el control, identifica el servicio dependiente y redacta la prueba antes de cambiar el ajuste.

Control	Fallo probable	Respuesta más segura
umask 027	La monitorización no puede leer los logs de Nginx o Apache; las aplicaciones pierden el acceso esperado a archivos temporales, de socket o PID.	Prueba la creación de archivos y los permisos de lectura de cada servicio; limita el umask cuando sea necesario.
pam_faillock	Una cuenta de servicio automatizada queda bloqueada.	Aplica el bloqueo a servicios interactivos como SSH y login; prueba la automatización por separado.
Deshabilitar IPv6	Java, Redis o un listener de base de datos falla porque se enlaza a IPv6 de forma predeterminada.	Audita los listeners y los clientes; protege IPv6 o deshabilítalo solo con evidencias.
Restringir kernel.shmmax o kernel.shmall	PostgreSQL puede no iniciarse.	Comprueba la memoria compartida necesaria frente a shared_buffers más la sobrecarga; después, prueba el inicio frente al mecanismo de memoria y la configuración del host.
Restringir kernel.sem	Los requisitos de semáforos documentados por Oracle entran en conflicto con los valores del benchmark.	Sigue las directrices de instalación de Oracle y registra la excepción del benchmark.
nosuid en /var	Una instalación de base de datos inusual que dependa de binarios SUID en /var deja de funcionar.	Comprueba la disposición de la instalación antes de aplicar la restricción de montaje.

Un perfil de Nivel 1 de aproximadamente 250 controles aplicado sin probar la carga de trabajo romperá previsiblemente los sistemas de producción, a menudo mediante fallos de inicio o pérdida de monitorización en lugar de un bloqueo evidente. Una puntuación de benchmark correcta junto a un agente de monitorización averiado significa que el trabajo de refuerzo ha fallado.

Verifica el servidor en lugar de declarar la victoria

Usa una secuencia de aceptación después de cada lote:

• Vuelve a comprobar SSH desde una sesión nueva con una clave administrativa probada.
• Confirma que el inicio de sesión como root y la autenticación mediante contraseña se comportan según lo previsto.
• Compara la exposición del firewall con el inventario de servicios.
• Inspecciona las opciones de montaje, los límites de volcados de núcleo, ASLR y los valores sysctl aprobados.
• Genera o inspecciona eventos de auditoría privilegiados, de autenticación, de sudo y de archivos supervisados.
• Confirma que llega un evento correspondiente al SIEM y que sigue siendo consultable.
• Ejecuta la evaluación de CIS seleccionada y registra las excepciones justificadas.
• Comprueba el estado activo del gestor de servicios y el endpoint de estado de la aplicación. Prueba la conexión a la base de datos y el heartbeat de monitorización. Comprueba las copias de seguridad y la automatización.

Una evaluación de benchmark mide la configuración frente a un perfil. No demuestra que la aplicación siga funcionando. Las comprobaciones de la carga de trabajo completan las evidencias.

Registra siete artefactos: versión del benchmark, configuración efectiva de SSH, exposición del firewall, valores de montaje y sysctl, comprobaciones de servicios, un identificador de evento del SIEM y las excepciones aprobadas.

Sin artefacto, no hay despliegue.