En algunas empresas todavía aparece algún servidor de un proveedor de software corriendo sobre CentOS 7. Esa distribución dejó de recibir parches gratuitos en junio de 2024. Existe soporte extendido de pago de terceros, pero solo aplaza la migración: el sistema sigue envejeciendo y el fabricante del software acabará sin homologarlo. Cuando por fin llega la migración, el proveedor suele pedir lo mínimo: «un servidor con IP y usuario root».
Si la empresa está certificada en ISO 27001 o trabaja con el Esquema Nacional de Seguridad, eso no basta. Alguien tiene que decidir cómo se bastiona ese servidor, y dejarlo documentado. En este artículo contamos cómo lo hemos hecho en un caso real: un servidor nuevo con AlmaLinux 9, bastionado con la guía CCN-STIC-610A22 del Centro Criptológico Nacional y sin herramientas de pago.
Por qué AlmaLinux 9 y no la última versión
Nuestra primera propuesta fue AlmaLinux 10, la versión más reciente. El fabricante del software nos indicó que la versión homologada para su aplicación es AlmaLinux 9, y es la que hemos instalado.
En un servidor de aplicación manda la homologación del fabricante, no la versión más nueva. Instalar una versión no soportada puede dejar al cliente sin soporte del proveedor justo cuando lo necesita. AlmaLinux 9 tiene parches de seguridad hasta 2032, así que no se renuncia a nada en ese aspecto.
AlmaLinux es una reconstrucción binaria compatible con Red Hat Enterprise Linux, gratuita y mantenida por una fundación. Para un servidor que venía de CentOS 7 es el sustituto natural.
El perfil CCN-STIC-610A22 viene en el instalador
El instalador de AlmaLinux 9 trae de serie los perfiles de bastionado del CCN. Están en el apartado «Política de seguridad», junto a los de CIS, PCI-DSS y otros, y vienen en tres niveles: básico, intermedio y avanzado.
Al elegir uno, el instalador comprueba el particionado y aplica las reglas del perfil durante la instalación. El servidor arranca por primera vez ya bastionado. La herramienta que hay detrás es OpenSCAP, software libre que también sirve después para auditar y corregir.
Nuestras decisiones para este servidor:
- Nivel intermedio del CCN, en lugar del CIS nivel 1. Para un cliente español con ISO 27001 es una referencia más fácil de defender ante el auditor.
- Sin modo FIPS. La aplicación del fabricante no lo requiere y puede dar problemas con componentes de terceros.
- Particiones separadas con LVM sobre XFS, como pide el perfil:
/home,/tmp,/var,/var/logy/var/log/auditpor separado. - root con contraseña pero sin acceso por SSH. Se entra con usuarios nominales y
sudo. - Instalación mínima, sin entorno gráfico: menos paquetes, menos superficie de ataque.
- Contraseña en el gestor de arranque, para que nadie con acceso a la consola pueda arrancar en modo de rescate.
Del primer informe a cero fallos
El perfil del instalador no lo resuelve todo: el primer informe dio 15 reglas sin cumplir. Tras corregirlas con la propia herramienta, el informe final quedó sin ningún fallo.
| Informe | Cumplen | Fallan | No aplican |
|---|---|---|---|
| Tras la instalación | 116 | 15 | 9 |
| Tras corregir y configurar el cortafuegos | 131 | 0 | 9 |
Los fallos eran sobre todo reglas de auditoría del sistema (14), más la opción nosuid en la partición de arranque EFI y el servicio de volcados del kernel, que no necesitamos. El informe se genera así:
sudo oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_ccn_intermediate \
--report informe-ccn.html \
/usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml
Con --remediate en la misma orden, OpenSCAP aplica las correcciones automáticas de las reglas que fallan. Conviene revisar antes qué va a tocar y ejecutarlo con una consola abierta.
El informe HTML es la evidencia que pide el auditor: qué se ha comprobado, con qué perfil, cuándo y con qué resultado. Lo guardamos junto a la documentación del cambio.
Un detalle práctico: la primera actualización falló porque la lista de réplicas de AlmaLinux nos dio una que el firewall perimetral bloqueaba por categoría. Apuntar los repositorios directamente a repo.almalinux.org por HTTPS lo resolvió.
Cortafuegos sin quedarse fuera
El servidor solo acepta lo imprescindible: la base de datos y SSH desde el servidor de la aplicación, y SSH desde dos equipos de administración. Todo lo demás se descarta en silencio.
En firewalld eso es la zona drop como zona por defecto y una regla por cada origen permitido:
sudo firewall-cmd --set-default-zone=drop
sudo firewall-cmd --permanent --zone=drop --add-rich-rule='rule family=ipv4 source address=<IP_APLICACIÓN> port port=27017 protocol=tcp accept'
sudo firewall-cmd --permanent --zone=drop --add-rich-rule='rule family=ipv4 source address=<IP_APLICACIÓN> service name=ssh accept'
# ... una regla de SSH por cada equipo de administración
sudo firewall-cmd --reload
El riesgo de hacer esto por SSH es evidente: un error en una regla y te quedas fuera. Por eso, antes de tocar nada, programamos la vuelta atrás:
sudo systemd-run --on-active=10min --unit=deshacer-fw \
/bin/sh -c 'firewall-cmd --set-default-zone=public && firewall-cmd --reload'
Si todo va bien y seguimos entrando desde una sesión nueva, cancelamos la vuelta atrás con sudo systemctl stop deshacer-fw.timer. Si algo falla, en diez minutos el servidor vuelve solo a la configuración anterior.
Como segunda capa, SSH limita quién puede entrar y desde dónde con AllowUsers usuario@IP en un fichero de /etc/ssh/sshd_config.d/. El usuario del fabricante solo puede entrar desde el servidor de la aplicación.
Excepciones, por escrito
Un servidor real nunca cumple el perfil al 100 % sin matices, y es mejor decirlo que esconderlo. El fabricante no aportó pautas de bastionado propias, así que las decisiones las tomamos nosotros y las sometimos a la conformidad del cliente.
Las excepciones que documentamos:
| Excepción | Por qué | Cómo se acota |
|---|---|---|
Cuenta del fabricante con sudo |
Instala y mantiene su base de datos y su aplicación | Solo entra por SSH desde el servidor de la aplicación; contraseña de un solo uso que cambia en el primer acceso |
| Agente del sistema de monitorización | Inventario, parches y alertas del servidor | Con SELinux en modo estricto, el instalador activa un booleano y añade un módulo de política propio: queda anotado |
| Acceso remoto del fabricante | Lo solicita para dar soporte | No se habilita en el servidor hasta que el cliente lo apruebe |
La contraseña inicial de la cuenta del fabricante se envía por un enlace que solo se puede abrir una vez, y caduca en el primer inicio de sesión (chage -d 0). Nosotros no la guardamos.
Todo esto, con los dos informes OpenSCAP, va a un documento de alta del servidor dentro del sistema de gestión de la ISO. Cuando el fabricante termine de instalar su aplicación, repetiremos el informe para comprobar que nada se ha degradado.
En resumen
Migrar un servidor de CentOS 7 no tiene por qué ser solo cambiar de sistema operativo. Con herramientas que ya vienen en AlmaLinux 9, el servidor nuevo sale bastionado con una guía del CCN y con evidencias que un auditor puede revisar.
- Usa la versión que homologa el fabricante del software, aunque haya una más nueva.
- Elige el perfil CCN en el instalador y comprueba el resultado con OpenSCAP.
- Cierra el cortafuegos a lo imprescindible, con una vuelta atrás programada.
- Documenta las excepciones y que las apruebe el cliente.
Si tienes servidores en CentOS 7 u otras versiones sin soporte, o necesitas preparar evidencias para la ISO 27001 o el ENS, habla con nosotros.
Referencias
Utilizadas:
- Guía CCN-STIC-610A22: perfilado de seguridad para Red Hat Enterprise Linux 9 (CCN-CERT)
- Guía de OpenSCAP para AlmaLinux 9
- OpenSCAP
- ComplianceAsCode / SCAP Security Guide: el contenido de los perfiles, CCN incluido
- Documentación de firewalld
- CCN-STIC en Red Hat: cómo encaja la guía en RHEL y sus derivadas
Alternativas comerciales, para entornos con muchos servidores:
- CIS-CAT Pro Assessor (Center for Internet Security)
- Tenable Nessus
- Qualys Policy Audit
- CalCom Hardening Suite
