Controlar el cumplimiento de un sistema Linux respecto a la guía ANSSI BP-028

Cyberwatch evalúa el cumplimiento de los sistemas Linux respecto a la guía ANSSI-BP-028 v2.0 «Recommandations de configuration d’un système GNU/Linux», publicada por la ANSSI.

El benchmark ANSSI_BP028_Linux cubre las 80 recomendaciones de la guía, repartidas en 176 reglas de cumplimiento: 164 se verifican automáticamente y 12 deben verificarse manualmente. Se aplica a todas las distribuciones Linux compatibles con el módulo de cumplimiento: Debian, Ubuntu, Red Hat Enterprise Linux y sus derivadas (AlmaLinux, Rocky Linux, Oracle Linux, CentOS), Fedora, SUSE Linux Enterprise Server y openSUSE Leap, Amazon Linux y Photon OS.

Marcos de cumplimiento

La guía clasifica cada recomendación en uno de sus cuatro niveles: Mínimo, Intermedio, Reforzado y Alto (ver la interpretación de los niveles). Estos niveles son acumulativos: las recomendaciones se aplican desde el nivel mínimo hasta el nivel objetivo. Por tanto, cada marco de cumplimiento de nivel contiene las reglas de ese nivel y de los niveles inferiores:

Marco de cumplimiento	Nivel objetivo	Recomendaciones	Reglas verificadas automáticamente
`ANSSI_BP028_level_1`	Mínimo	11	19
`ANSSI_BP028_level_2`	Intermedio	40	110
`ANSSI_BP028_level_3`	Reforzado	58	140
`ANSSI_BP028_level_4`	Alto	80	164

El marco de cumplimiento ANSSI_BP028 contiene todas las reglas del benchmark, como ANSSI_BP028_level_4.

Para evaluar un activo, añadirle el marco de cumplimiento del nivel objetivo, y solo ese: añadir varios niveles no añade ninguna regla. Estos marcos de cumplimiento están presentes por defecto en Cyberwatch, pero no están asignados a ningún activo. Para asignarlos automáticamente, por ejemplo a todos los servidores Linux, utilizar reglas de activos.

Organización de las reglas

Cada regla tiene una referencia de la forma ANSSI-BP028-R<n>-<nnn>, donde R<n> es el número de la recomendación en la guía, por ejemplo ANSSI-BP028-R12-001.
La categoría de la regla retoma el número y el título de la recomendación, por ejemplo «R12 – Paramétrer les options de configuration du réseau IPv4»: permite filtrar las reglas por recomendación.
Una recomendación cuenta con una regla por parámetro que se debe verificar (un parámetro del núcleo, una opción de montaje, una directiva sudo), de modo que cada parámetro pueda corregirse o ignorarse por separado. Las recomendaciones R15 a R27, que tratan de las opciones de compilación del núcleo, son la excepción: una regla por recomendación.
El nivel de una regla es siempre el de su recomendación en la guía.
El título, la descripción, el objetivo y la remediación de las reglas están redactados en inglés. La descripción precisa lo que verifica la regla, dónde lo lee, y el comportamiento por defecto de las distribuciones.

Tipos de reglas

Reglas automatizadas: la regla verifica lo que pide la guía.
Controles parciales: cuando una recomendación es en parte organizativa, la regla verifica su parte técnica. Su descripción empieza por lo que se verifica y lo que no («This rule checks… It does not check…»). Por ejemplo, la regla de R80 verifica que un cortafuegos local está activo, pero no que cada servicio solo escuche en las interfaces de red necesarias.
Reglas manuales: la recomendación no puede verificarse en el sistema. La regla no se evalúa en ningún activo y no pertenece a ningún marco de cumplimiento. Aparece con la mención «Regla manual» en la página del benchmark ANSSI_BP028_Linux, en Administración > Benchmarks.

Las recomendaciones que deben verificarse manualmente son las siguientes:

Recomendación	Nivel
R2 – Configurer le BIOS/UEFI	Intermedio
R4 – Remplacer les clés préchargées	Alto
R51 – Changer les secrets et droits d’accès dès l’installation	Reforzado
R58 – N’installer que les paquets strictement nécessaires	Mínimo
R60 – Utiliser des dépôts de paquets durcis	Reforzado
R64 – Configurer les privilèges des services	Reforzado
R65 – Cloisonner les services	Reforzado
R66 – Durcir les composants de cloisonnement	Alto
R70 – Séparer les comptes système et d’administrateur de l’annuaire	Intermedio
R77 – Protéger la base de données des scellés	Alto
R78 – Cloisonner les services réseau	Reforzado
R79 – Durcir et surveiller les services exposés	Intermedio

Leer los resultados

Las reglas se ejecutan con permisos de administrador. Por tanto, un activo analizado sin agente debe disponer de una cuenta de escaneo con permisos sudo (ver los requisitos previos de la cuenta de escaneo).

Los estados de las reglas son los mismos que para los demás marcos de cumplimiento:

Éxito: el activo es conforme a la regla
Fallo: el activo no es conforme a la regla
Pasado: el activo se ha analizado sin permisos sudo
No aplicable: la regla no se aplica al activo, por ejemplo una regla de particionado en un contenedor, una regla sudo sin sudo instalado, o una regla de arranque seguro en una arquitectura sin UEFI; la salida empieza entonces por N/A: seguido del motivo
Anomalía: el control no ha podido ejecutarse

La salida de cada regla, visible en la pestaña «Cumplimiento» del activo, detalla lo que se ha constatado. Para los scripts propios del marco de cumplimiento, la primera línea indica el veredicto (PASSED, FAILED o N/A: <motivo>), seguido del valor esperado y del valor constatado.

Las reglas R53-001, R54-001, R54-002, R56-001 y R57-001 recorren los sistemas de archivos locales. Cada una se detiene al cabo de 5 minutos: queda entonces en fallo, y su salida indica el sistema de archivos en el que se detuvo el recorrido.

Requisitos previos de la cuenta de escaneo sin agente

Sin agente, Cyberwatch eleva sus permisos con sudo -n, sin terminal, y después lanza un shell que ejecuta otros programas. La cuenta de escaneo debe tener los permisos sudo descritos en Información técnica sobre las conexiones sin agente para sistemas Linux, por ejemplo cyberwatch ALL=(ALL) NOPASSWD:ALL.

Varias recomendaciones de la guía restringen sudo o el acceso al sistema, y pueden bloquear esta cuenta. Al aplicarlas, prever las excepciones siguientes, sustituyendo cyberwatch por el nombre de la cuenta de escaneo:

R38 (grupo dedicado a sudo): añadir la cuenta de escaneo al grupo autorizado a ejecutar sudo; de lo contrario, ya no puede elevar sus permisos:
```
usermod -aG sudogrp cyberwatch
```
R39 (directivas de configuración de sudo): las directivas noexec y requiretty impiden el análisis. Añadir para la cuenta de escaneo las dos excepciones siguientes, en dos líneas distintas:
```
Defaults:cyberwatch !noexec
Defaults:cyberwatch !requiretty
```
sudo-rs, el sudo por defecto a partir de Ubuntu 25.10, ignora toda línea Defaults que contenga un ajuste que no conoce: una línea única Defaults:cyberwatch !noexec,!requiretty se ignoraría, !noexec incluido. sudo-rs no conoce requiretty: en un activo en el que es el único sudo instalado, añadir solo la línea !noexec, ya que su visudo rechaza la segunda. Las reglas de R39 enumeran estas excepciones en su salida, sin contarlas como desviaciones.
R40 a R44 (especificaciones sudo): las reglas ignoran las especificaciones cuya lista de usuarios es exactamente la cuenta que ejecuta el análisis. Por tanto, la línea cyberwatch ALL=(ALL) NOPASSWD:ALL no las hace fallar.
R47 (confinamiento SELinux de los usuarios): un usuario SELinux user_u no puede utilizar sudo. Antes de asociar los usuarios por defecto a user_u, asociar la cuenta de escaneo a unconfined_u:
```
semanage login -a -s unconfined_u cyberwatch
```
R80 (superficie de ataque de los servicios de red): autorizar SSH antes de activar el cortafuegos, para no interrumpir los análisis.

El agente Cyberwatch, ejecutado por defecto como root, no se ve afectado por estas excepciones.

Recomendaciones de alto impacto

Algunas recomendaciones no se corrigen con un simple cambio de configuración, o pueden afectar a la explotación. Antes de aplicarlas, consultar la guía y la remediación de cada regla:

R15 a R27 (nivel Alto): opciones de compilación del núcleo. Los núcleos de las distribuciones no activan todas estas opciones: la única corrección es recompilar el núcleo o cambiarlo.
R10 (nivel Reforzado): con kernel.modules_disabled = 1, el núcleo rechaza cualquier carga de módulo hasta el siguiente reinicio, incluso para root. Los módulos necesarios (controladores de almacenamiento, red o USB, sistemas de archivos) deben cargarse en el arranque.
R28 (nivel Intermedio): particionado tipo. Crear una partición después de la instalación requiere mover datos, o incluso reinstalar el sistema.
R39 (nivel Intermedio): la directiva noexec hace fallar los comandos sudo que lanzan otros programas (gestores de paquetes, scripts, reinicios de servicios) mientras no estén autorizados uno a uno con la etiqueta EXEC.

Cuando se acepta una desviación, la regla puede ignorarse, con un comentario que justifique esta decisión.

Diferencias con los demás marcos de cumplimiento

Security_Best_Practices

El marco de cumplimiento Security_Best_Practices es una base de buenas prácticas asignada por defecto a los servidores y a las estaciones de trabajo. Para Linux, cuenta con 45 reglas, una parte de las cuales retoma recomendaciones de la guía BP-028, pero no implementa la guía: sus niveles se eligen según el esfuerzo de corrección esperado, y no según el nivel de la recomendación.

Los marcos de cumplimiento ANSSI_BP028 cubren toda la guía, con el nivel de cada recomendación. Ambos pueden asignarse al mismo activo: cuando una regla ANSSI retoma el control de una regla Security_Best_Practices, dan el mismo resultado.

Importación de un DataStream ComplianceAsCode

El proyecto ComplianceAsCode (paquete scap-security-guide) publica perfiles ANSSI BP-028 en sus DataStreams. Estos pueden importarse como benchmarks, pero Cyberwatch no aplica sus perfiles: se importan todas las reglas del DataStream, sea cual sea el perfil, y solo una parte de sus controles es compatible. ComplianceAsCode tampoco propone perfil ANSSI para Ubuntu.

Para evaluar un sistema Linux respecto a la guía, Cyberwatch recomienda los marcos de cumplimiento ANSSI_BP028.