Contrôler la conformité d’un système Linux au guide ANSSI BP-028

Cyberwatch évalue la conformité des systèmes Linux au guide ANSSI-BP-028 v2.0 « Recommandations de configuration d’un système GNU/Linux », publié par l’ANSSI.

Le benchmark ANSSI_BP028_Linux couvre les 80 recommandations du guide, réparties en 176 règles de conformité : 164 sont vérifiées automatiquement et 12 sont à vérifier manuellement. Il s’applique à toutes les distributions Linux prises en charge par le module de conformité : Debian, Ubuntu, Red Hat Enterprise Linux et ses dérivées (AlmaLinux, Rocky Linux, Oracle Linux, CentOS), Fedora, SUSE Linux Enterprise Server et openSUSE Leap, Amazon Linux et Photon OS.

Référentiels

Le guide classe chaque recommandation dans l’un de ses quatre niveaux : Minimal, Intermédiaire, Renforcé et Élevé (voir l’interprétation des niveaux). Ces niveaux sont cumulatifs : les recommandations s’appliquent du niveau minimal jusqu’au niveau visé. Chaque référentiel de niveau contient donc les règles de ce niveau et des niveaux inférieurs :

Référentiel	Niveau visé	Recommandations	Règles vérifiées automatiquement
`ANSSI_BP028_level_1`	Minimal	11	19
`ANSSI_BP028_level_2`	Intermédiaire	40	110
`ANSSI_BP028_level_3`	Renforcé	58	140
`ANSSI_BP028_level_4`	Élevé	80	164

Le référentiel ANSSI_BP028 contient toutes les règles du benchmark, comme ANSSI_BP028_level_4.

Pour évaluer un actif, lui ajouter le référentiel du niveau visé, et lui seul : ajouter plusieurs niveaux n’ajoute aucune règle. Ces référentiels sont présents par défaut dans Cyberwatch, mais ne sont attribués à aucun actif. Pour les attribuer automatiquement, par exemple à tous les serveurs Linux, utiliser des règles d’actifs.

Organisation des règles

Chaque règle a une référence de la forme ANSSI-BP028-R<n>-<nnn>, où R<n> est le numéro de la recommandation dans le guide, par exemple ANSSI-BP028-R12-001.
La catégorie de la règle reprend le numéro et le titre de la recommandation, par exemple « R12 – Paramétrer les options de configuration du réseau IPv4 » : elle permet de filtrer les règles par recommandation.
Une recommandation compte une règle par paramètre à vérifier (un paramètre du noyau, une option de montage, une directive sudo), de sorte que chaque paramètre puisse être corrigé ou ignoré séparément. Les recommandations R15 à R27, qui portent sur les options de compilation du noyau, font exception : une règle par recommandation.
Le niveau d’une règle est toujours celui de sa recommandation dans le guide.
Le titre, la description, l’objectif et la remédiation des règles sont rédigés en anglais. La description précise ce que la règle vérifie, où elle le lit, et le comportement par défaut des distributions.

Types de règles

Règles automatisées : la règle vérifie ce que le guide demande.
Contrôles partiels : quand une recommandation est en partie organisationnelle, la règle en vérifie la partie technique. Sa description commence par ce qui est vérifié et ce qui ne l’est pas (« This rule checks… It does not check… »). Par exemple, la règle de R80 vérifie qu’un pare-feu local est actif, mais pas que chaque service n’écoute que sur les interfaces réseau nécessaires.
Règles manuelles : la recommandation ne peut pas être vérifiée sur le système. La règle n’est évaluée sur aucun actif et n’appartient à aucun référentiel. Elle est listée avec la mention « Règle manuelle » sur la page du benchmark ANSSI_BP028_Linux, dans Administration > Benchmarks.

Les recommandations à vérifier manuellement sont les suivantes :

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

Lire les résultats

Les règles s’exécutent avec les droits d’administrateur. Un actif analysé sans agent doit donc disposer d’un compte de scan avec les droits sudo (voir les prérequis du compte de scan).

Les états des règles sont les mêmes que pour les autres référentiels :

Succès : l’actif est conforme à la règle
Échec : l’actif n’est pas conforme à la règle
Passé : l’actif a été analysé sans droits sudo
Non applicable : la règle ne s’applique pas à l’actif, par exemple une règle de partitionnement dans un conteneur, une règle sudo sans sudo installé, ou une règle de démarrage sécurisé sur une architecture sans UEFI ; la sortie commence alors par N/A: suivi de la raison
Anomalie : le contrôle n’a pas pu s’exécuter

La sortie de chaque règle, visible dans l’onglet « Conformité » de l’actif, détaille ce qui a été constaté. Pour les scripts propres au référentiel, la première ligne donne le verdict (PASSED, FAILED ou N/A: <raison>), suivi de la valeur attendue et de la valeur constatée.

Les règles R53-001, R54-001, R54-002, R56-001 et R57-001 parcourent les systèmes de fichiers locaux. Chacune s’arrête après 5 minutes : elle est alors en échec, et sa sortie indique le système de fichiers où le parcours s’est arrêté.

Prérequis du compte de scan sans agent

Sans agent, Cyberwatch élève ses droits avec sudo -n, sans terminal, puis lance un shell qui exécute d’autres programmes. Le compte de scan doit avoir les droits sudo décrits dans Informations techniques sur les connexions sans-agent pour les systèmes Linux, par exemple cyberwatch ALL=(ALL) NOPASSWD:ALL.

Plusieurs recommandations du guide restreignent sudo ou l’accès au système, et peuvent bloquer ce compte. Lors de leur mise en œuvre, prévoir les exceptions suivantes, en remplaçant cyberwatch par le nom du compte de scan :

R38 (groupe dédié à sudo) : ajouter le compte de scan au groupe autorisé à exécuter sudo, sans quoi il ne peut plus élever ses droits :
```
usermod -aG sudogrp cyberwatch
```
R39 (directives de configuration sudo) : les directives noexec et requiretty empêchent l’analyse. Ajouter pour le compte de scan les deux surcharges suivantes, sur deux lignes distinctes :
```
Defaults:cyberwatch !noexec
Defaults:cyberwatch !requiretty
```
sudo-rs, le sudo par défaut à partir d’Ubuntu 25.10, ignore toute ligne Defaults qui contient un réglage qu’il ne connaît pas : une ligne unique Defaults:cyberwatch !noexec,!requiretty serait ignorée, !noexec compris. sudo-rs ne connaît pas requiretty : sur un actif où il est le seul sudo installé, n’ajouter que la ligne !noexec, car son visudo refuse la seconde. Les règles de R39 listent ces surcharges dans leur sortie, sans les compter comme des écarts.
R40 à R44 (spécifications sudo) : les règles ignorent les spécifications dont la liste d’utilisateurs est exactement le compte qui exécute l’analyse. La ligne cyberwatch ALL=(ALL) NOPASSWD:ALL ne les fait donc pas échouer.
R47 (confinement SELinux des utilisateurs) : un utilisateur SELinux user_u ne peut pas utiliser sudo. Avant d’associer les utilisateurs par défaut à user_u, associer le compte de scan à unconfined_u :
```
semanage login -a -s unconfined_u cyberwatch
```
R80 (surface d’attaque des services réseau) : autoriser SSH avant d’activer le pare-feu, pour ne pas couper les analyses.

L’agent Cyberwatch, exécuté par défaut en tant que root, n’est pas concerné par ces exceptions.

Recommandations à fort impact

Certaines recommandations ne se corrigent pas par un simple changement de configuration, ou peuvent gêner l’exploitation. Avant de les appliquer, se reporter au guide et à la remédiation de chaque règle :

R15 à R27 (niveau Élevé) : options de compilation du noyau. Les noyaux des distributions n’activent pas toutes ces options : la seule correction est de recompiler le noyau ou d’en changer.
R10 (niveau Renforcé) : avec kernel.modules_disabled = 1, le noyau refuse tout chargement de module jusqu’au redémarrage suivant, y compris pour root. Les modules nécessaires (pilotes de stockage, réseau ou USB, systèmes de fichiers) doivent être chargés au démarrage.
R28 (niveau Intermédiaire) : partitionnement type. Créer une partition après l’installation demande de déplacer des données, voire de réinstaller le système.
R39 (niveau Intermédiaire) : la directive noexec fait échouer les commandes sudo qui lancent d’autres programmes (gestionnaires de paquets, scripts, redémarrages de services) tant qu’elles ne sont pas autorisées une à une avec l’étiquette EXEC.

Quand un écart est accepté, la règle peut être ignorée, avec un commentaire qui justifie ce choix.

Différences avec les autres référentiels

Security_Best_Practices

Le référentiel Security_Best_Practices est un socle de bonnes pratiques attribué par défaut aux serveurs et aux postes de travail. Pour Linux, il compte 45 règles, dont une partie reprend des recommandations du guide BP-028, mais il ne met pas en œuvre le guide : ses niveaux sont choisis selon l’effort de correction attendu, et non selon le niveau de la recommandation.

Les référentiels ANSSI_BP028 couvrent l’ensemble du guide, avec le niveau de chaque recommandation. Les deux peuvent être attribués au même actif : quand une règle ANSSI reprend le contrôle d’une règle Security_Best_Practices, elles donnent le même résultat.

Import d’un DataStream ComplianceAsCode

Le projet ComplianceAsCode (paquet scap-security-guide) publie des profils ANSSI BP-028 dans ses DataStreams. Ceux-ci peuvent être importés comme benchmarks, mais Cyberwatch n’en applique pas les profils : toutes les règles du DataStream sont importées, quel que soit le profil, et une partie seulement de leurs contrôles est prise en charge. ComplianceAsCode ne propose pas non plus de profil ANSSI pour Ubuntu.

Pour évaluer un système Linux au regard du guide, Cyberwatch recommande les référentiels ANSSI_BP028.