Los auditores no aceptan «creemos que es seguro». El Anexo A de ISO 27001, el Artículo 21 de NIS2 y los requisitos de riesgo TIC de DORA exigen controles de seguridad documentados y repetibles, con evidencia de su implementación. Una línea base de hardening de Linux es el cimiento que hace creíble cualquier otro control. Esta guía cubre la capa de configuración: qué ajustar, por qué importa y cómo verificarlo en un VPS cloud o servidor bare-metal que ejecute una carga de trabajo europea regulada.

Los pasos que siguen respetan la lógica del benchmark CIS para Linux, adaptada a despliegues cloud donde algunos controles físicos no aplican pero la exposición de red es mayor. Síguelos en orden; las secciones posteriores asumen que las anteriores ya están en marcha.

Empieza por la superficie de ataque: usuarios, paquetes y servicios

Cada paquete instalado y cada servicio en ejecución es un posible punto de entrada. Parte de una imagen de sistema operativo mínima y audita lo que realmente está presente. En Debian o Ubuntu, dpkg --get-selections | grep -v deinstall lista los paquetes instalados; en sistemas de la familia RHEL, usa rpm -qa. Elimina todo lo que la carga de trabajo no requiera.

Desactiva y enmascara los servicios que nunca deberían ejecutarse en producción:

  • avahi-daemon (descubrimiento mDNS, innecesario en infraestructura de servidores)
  • cups (impresión)
  • rpcbind, salvo que NFS sea explícitamente necesario
  • bluetooth en cualquier instancia cloud

Usa systemctl disable --now <service> seguido de systemctl mask <service> para evitar reactivaciones accidentales. Verifica con systemctl list-units --type=service --state=running.

Las cuentas de usuario locales merecen el mismo escrutinio. Bloquea las que no requieren inicio de sesión: usermod -L -s /sbin/nologin <username>. Define una política de caducidad de contraseñas en /etc/login.defs y aplícala con chage. Las cuentas con UID 0 distintas de root son un hallazgo crítico en cualquier auditoría; confirma que no existe ninguna con awk -F: '($3 == 0) {print}' /etc/passwd.

Buenas prácticas de hardening SSH para servidores cloud

SSH es la interfaz administrativa principal en cualquier servidor Linux, lo que lo convierte en el componente más examinado dentro de una línea base de seguridad para servidores cloud. La configuración por defecto prioriza la compatibilidad sobre la seguridad; los sistemas en producción necesitan exactamente lo contrario.

La mala configuración de SSH es el hallazgo más frecuente en pruebas de penetración de infraestructura sobre sistemas Linux alojados en cloud. Corregirlo lleva diez minutos y elimina toda una categoría de ataques.

Aplica lo siguiente en /etc/ssh/sshd_config:

  • PermitRootLogin no: root nunca debe autenticarse directamente por SSH. Usa una cuenta de administrador con nombre propio y sudo.
  • PasswordAuthentication no: autenticación solo con clave. Las contraseñas son vulnerables a fuerza bruta; las claves no.
  • PubkeyAuthentication yes
  • AuthorizedKeysFile .ssh/authorized_keys: restringe a una única ubicación predecible.
  • MaxAuthTries 3: limita los intentos de fuerza bruta por conexión.
  • LoginGraceTime 30: cierra rápidamente las conexiones no autenticadas.
  • AllowUsers o AllowGroups: define explícitamente qué cuentas pueden conectarse.
  • Protocol 2: SSHv1 está roto; aunque ya debería ser el valor por defecto, verifícalo de forma explícita.
  • Ciphers: restringe a chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com.
  • MACs: restringe a hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com.
  • KexAlgorithms: elimina diffie-hellman-group1-sha1 y group14-sha1.
  • X11Forwarding no y AllowTcpForwarding no, salvo que sean explícitamente necesarios.
  • Banner /etc/issue.net: un banner de aviso legal satisface los requisitos de auditoría y es obligatorio en varios marcos sectoriales.

Valida la configuración con sshd -t antes de aplicarla y recarga con systemctl reload sshd. Prueba desde una segunda sesión antes de cerrar la existente.

Configuración del firewall en Linux: denegación por defecto a nivel de host

Los grupos de seguridad del proveedor cloud son un control perimetral. La configuración del firewall a nivel de host es un control de defensa en profundidad. Ambos son obligatorios según el benchmark CIS para Linux Nivel 1; depender únicamente de la capa del proveedor incumple el principio de controles independientes que NIS2 e ISO 27001 exigen.

nftables es el estándar actual en las distribuciones Linux modernas, sustituyendo a iptables como interfaz principal de filtrado de paquetes del kernel. Un conjunto de reglas mínimo tiene este aspecto:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    ct state invalid drop
    iif lo accept
    tcp dport 22 ct state new accept
    # añade aquí los puertos de aplicación
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

Denegación por defecto en entrada, aceptación explícita para conexiones establecidas, loopback y SSH. Todo lo demás queda denegado hasta que se permita explícitamente. Activa y persiste con systemctl enable --now nftables y guarda el conjunto de reglas en /etc/nftables.conf.

Hardening del kernel mediante sysctl

Los parámetros en tiempo de ejecución del kernel controlan el comportamiento de la pila de red y las protecciones de memoria. Estos ajustes pertenecen a /etc/sysctl.d/99-hardening.conf y se aplican con sysctl --system:

  • net.ipv4.ip_forward = 0: desactiva el reenvío IP salvo que el servidor actúe como router.
  • net.ipv4.conf.all.accept_redirects = 0 y net.ipv6.conf.all.accept_redirects = 0: rechaza redirecciones ICMP.
  • net.ipv4.conf.all.rp_filter = 1: activa el filtrado de ruta inversa para bloquear paquetes falsificados.
  • net.ipv4.tcp_syncookies = 1: protección contra inundaciones SYN.
  • kernel.randomize_va_space = 2: ASLR completo.
  • kernel.dmesg_restrict = 1: impide que usuarios sin privilegios lean el buffer de anillo del kernel.
  • fs.protected_hardlinks = 1 y fs.protected_symlinks = 1: bloquea vectores comunes de escalada de privilegios.
  • kernel.yama.ptrace_scope = 1: restringe ptrace a procesos padre.

Registro de auditoría y monitorización de integridad de archivos

Los controles solo son auditables si existe un registro de actividad. El marco de auditoría de Linux (auditd) proporciona un registro estructurado y resistente a manipulaciones de las llamadas al sistema. Instálalo, actívalo y configura reglas en /etc/audit/rules.d/ para registrar eventos de autenticación, escalada de privilegios, cambios en /etc/passwd, /etc/shadow y /etc/sudoers, y cualquier ejecución de comandos mediante sudo.

Para la monitorización de integridad de archivos, AIDE (Advanced Intrusion Detection Environment) genera una línea base criptográfica del sistema de archivos y alerta ante cambios inesperados. Inicializa con aide --init, mueve la base de datos a una ubicación de solo lectura o remota, y programa comprobaciones mediante cron o un temporizador de systemd. Bajo los requisitos de integridad TIC de DORA y las obligaciones de detección de incidentes de NIS2, esto no es opcional para cargas de trabajo reguladas; es la evidencia de que existen controles de detección de cambios.

Reenvía los logs fuera del host de inmediato. Un servidor comprometido puede manipular los logs locales; un syslog remoto o un SIEM no puede ser alterado retroactivamente por el mismo atacante. En infraestructura europea, ese destino de logs debe encontrarse dentro de la jurisdicción de la UE para mantener la conformidad con el RGPD en relación con cualquier dato personal capturado en los registros.

Mantener la línea base actualizada

Una línea base de hardening documentada una sola vez y nunca revisada se degrada con el tiempo. Las vulnerabilidades del kernel, los nuevos CVE en OpenSSH y las recomendaciones actualizadas del benchmark CIS para Linux requieren revisiones periódicas. Integra la línea base en tu proceso de gestión de cambios: cualquier actualización del sistema operativo, actualización mayor de paquetes o cambio de arquitectura debe desencadenar una revalidación frente a los controles documentados.

Automatiza la verificación. Herramientas como oscap, del proyecto OpenSCAP, pueden analizar un sistema en ejecución frente a un perfil SCAP y generar un informe de conformidad legible por máquina, que es exactamente el formato de evidencia que aceptan los auditores de ISO 27001 y las autoridades competentes de NIS2. Programa análisis mensuales y conserva los informes como parte de la documentación de tu sistema de gestión de seguridad de la información.

La configuración anterior es una línea base, no un techo. Las cargas de trabajo que manejan datos de pago, historiales clínicos o infraestructuras críticas necesitarán controles adicionales por encima de esta base. Pero todo despliegue Linux regulado en Europa debería poder demostrar, con evidencia, que este cimiento está en su lugar.