ANSSI-BP-028 : guide pratique de durcissement Linux

Ce que vous allez apprendre

Situer les 4 niveaux de durcissement ANSSI (M, I, R, E) et choisir celui qui correspond à votre serveur
Lire le marquage de niveau d'une recommandation dans le guide officiel
Appliquer les recommandations des niveaux M et I avec les commandes correspondantes
Mesurer l'écart avant et après avec Lynis et OpenSCAP
Maintenir la conformité dans le temps avec Ansible ou Rudder

À qui s'adresse ce guide

Ce guide est conçu pour toute personne souhaitant sécuriser un serveur Linux, quel que soit son niveau technique :

Débutants : vous découvrirez ce qu'est le durcissement et pourquoi c'est important
Administrateurs : vous trouverez des commandes concrètes à appliquer
RSSI et auditeurs : vous disposerez d'un cadre de conformité documenté

Qu'est-ce que le durcissement

Le durcissement consiste à modifier la configuration d'un système déjà installé pour réduire ce qu'un attaquant peut atteindre et ce qu'il peut faire une fois entré. Ce n'est ni un antivirus, ni un produit à installer : ce sont des paramètres du noyau, des permissions de fichiers, des services arrêtés et des journaux activés. La suite de cette section explique pourquoi une installation par défaut n'est jamais durcie, ce que le durcissement change concrètement, et d'où vient le référentiel ANSSI-BP-028.

Voir aussi : Introduction au durcissement des serveurs Linux

Le problème : Linux n'est pas sécurisé par défaut

Quand vous installez un serveur Linux (Debian, Ubuntu, RHEL...), le système est configuré pour fonctionner facilement, pas pour être sécurisé. Par défaut :

Des services inutiles sont activés
Des ports réseau sont ouverts
Les mots de passe peuvent être faibles
Les journaux de connexion sont basiques
N'importe quel utilisateur peut lire certaines informations sensibles

Ces choix ne sont pas des négligences : ils servent à ce que le système fonctionne du premier coup sur le plus grand nombre de matériels et d'usages. Le prix à payer est une surface d'attaque large par défaut, que personne ne réduit tant que l'administrateur ne s'en occupe pas.

La solution : le durcissement

Le durcissement ne consiste pas à ajouter un produit de sécurité par-dessus, mais à retirer et restreindre ce qui existe déjà. Quatre familles d'actions résument la démarche, et elles se pratiquent dans cet ordre : ce qui est supprimé n'a plus besoin d'être surveillé.

Durcir un système, c'est le configurer pour :

Fermer ce qui n'est pas nécessaire (ports, services, comptes)
Restreindre les accès (permissions, droits)
Surveiller l'activité (journaux, alertes)
Protéger le démarrage et le noyau

Le guide ANSSI-BP-028

L'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) est l'autorité française en cybersécurité. Elle publie des guides de bonnes pratiques dont le BP-028 : "Recommandations de configuration d'un système GNU/Linux".

Ce guide est :

Gratuit et téléchargeable sur cyber.gouv.fr
En français (une version anglaise existe)
Régulièrement mis à jour (version 2.0 depuis octobre 2022)
Reconnu par les professionnels de la sécurité

Les 4 niveaux de durcissement

Le guide ANSSI propose 4 niveaux progressifs. Vous n'êtes pas obligé de tout appliquer : choisissez le niveau adapté à votre situation.

Comprendre les niveaux

Niveau	Nom	Pour qui	Effort
M	Minimal	Tous les serveurs, même internes	Faible
I	Intermédiaire	Serveurs en production	Moyen
R	Renforcé	Serveurs exposés sur Internet	Important
E	Élevé	Infrastructures critiques, données sensibles	Expert

Quel niveau choisir

Le critère principal n'est pas la criticité ressentie de l'application, mais l'exposition réelle de la machine et la sensibilité des données qu'elle manipule. Un serveur de développement accessible depuis Internet relève du niveau R, pas du niveau M. Les durées indiquées dans chaque onglet couvrent la première application sur une machine, pas le maintien dans le temps : prévoyez en plus un audit récurrent, décrit plus bas.

Appliquez ce niveau si :

C'est votre premier durcissement
Serveur de test ou développement
Serveur interne isolé

Temps estimé : 1-2 heures

Comment lire une recommandation ANSSI

Chaque recommandation du guide officiel suit le même format. Voici comment la décrypter :

Anatomie d'une recommandation

Chaque entrée du PDF tient sur quatre éléments alignés sur une seule ligne, suivis d'un texte explicatif. Le numéro est votre identifiant de travail : c'est lui que vous citerez dans un ticket, dans un fichier d'exceptions ou face à un auditeur, jamais l'intitulé qui peut être reformulé d'une version à l'autre.

R61   M . . .   Effectuer des mises à jour régulières

Il est recommandé d'avoir une procédure de mise à jour de sécurité
régulière et réactive.

Décomposons :

Élément	Signification
R61	Numéro de la recommandation (R1 à R80+)
M . . .	Niveaux concernés (ici : niveau Minimal uniquement)
Titre	"Effectuer des mises à jour régulières"
Description	Le texte explicatif qui suit

Les lettres de niveau expliquées

Chaque lettre présente désigne un niveau concerné, chaque point un niveau non concerné. Deux exemples réels tirés de la version 2.0 :

R46   M I R E   Activer SELinux avec la politique targeted
R30   M . . .   Désactiver les comptes utilisateur inutilisés

Un détail change la façon de lire le guide officiel : en version 2.0, les 80 recommandations n'utilisent que quatre marquages, et toutes commencent par la lettre M. Vous ne croiserez donc jamais un marquage du type . . R E dans le PDF, contrairement à ce que la logique des quatre lettres pourrait laisser croire.

Notation	Nombre de recommandations en v2.0
`M . . .`	11
`M I . .`	29
`M I R .`	18
`M I R E`	22

Conséquence pratique pour votre plan de travail : le socle M couvre à lui seul l'intégralité des 80 recommandations, et monter en niveau ne consiste pas à en découvrir de nouvelles, mais à resserrer les exigences de mise en oeuvre détaillées dans le corps du guide officiel.

Exemple pratique

Imaginons que vous souhaitez durcir un serveur web en production. Vous visez le niveau I (Intermédiaire).

Vous devez appliquer :

Toutes les recommandations marquées M (Minimal)
Toutes les recommandations marquées I (Intermédiaire)

Autrement dit l'intégralité du guide, puisque les 80 recommandations portent toutes le marquage M. Ce qui distingue votre plan de celui d'une équipe visant le niveau R ou E, ce sont les modalités de mise en oeuvre : par exemple, tout le monde doit restreindre les droits d'accès aux fichiers (R50), mais la liste des fichiers surveillés et la fréquence de contrôle se durcissent avec le niveau.

Les 3 principes fondamentaux

Avant de plonger dans les recommandations techniques, comprenez ces 3 principes qui guident tout le durcissement. Voir aussi : Principes de sécurité.

1. Minimisation

"N'installez que ce dont vous avez besoin"

Chaque programme installé est une porte d'entrée potentielle. Moins il y a de composants, moins il y a de risques. Consultez notre guide dédié : Minimisation de la surface d'attaque.

Exemples concrets :

Pas besoin d'interface graphique sur un serveur
Désinstallez les compilateurs si vous ne compilez pas
Supprimez les services comme Telnet, FTP si vous ne les utilisez pas

2. Moindre privilège

"Donnez le minimum de droits nécessaires"

Un utilisateur ou un programme ne doit avoir accès qu'à ce dont il a strictement besoin. Ce principe est détaillé dans notre guide Moindre privilège.

Exemples concrets :

L'application web n'a pas besoin d'être root
Le développeur n'a pas besoin d'accès sudo sur tous les serveurs
Le script de backup ne doit pas pouvoir modifier les fichiers système

3. Défense en profondeur

"Multipliez les barrières de sécurité"

Si une protection échoue, une autre doit prendre le relais.

Exemples concrets :

Pare-feu + configuration SSH restrictive + clés SSH
Mots de passe forts + limitation des tentatives + journalisation
Chiffrement réseau + chiffrement disque + permissions fichiers

Mettre en œuvre le durcissement

Étape 1 : auditer l'état actuel

Avant de modifier quoi que ce soit, mesurez l'état de sécurité actuel de votre système avec Lynis.

Installer Lynis (outil d'audit gratuit)

# Debian/Ubuntu
sudo apt update && sudo apt install lynis

# RHEL/CentOS/Rocky
sudo dnf install lynis

Lancer un audit complet
Fenêtre de terminal
```
sudo lynis audit system
```
Noter votre score initial

À la fin de l'audit, Lynis affiche un score sur 100. Notez-le, c'est votre point de départ.
Consulter le rapport
Fenêtre de terminal
```
cat /var/log/lynis-report.dat
```

Étape 2 : appliquer les recommandations niveau M

Commencez par les recommandations Minimal (obligatoires pour tous).

2.1 Mises à jour de sécurité (R61)

# Debian/Ubuntu
sudo apt update && sudo apt upgrade -y

# RHEL/CentOS
sudo dnf update -y

Automatisez les mises à jour de sécurité :

# Debian/Ubuntu - activer les mises à jour automatiques
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

2.2 Protection mémoire ASLR (R9)

Vérifiez que l'ASLR est activé :

cat /proc/sys/kernel/randomize_va_space

Le résultat doit être 2. Si ce n'est pas le cas :

# Application immédiate
sudo sysctl -w kernel.randomize_va_space=2

# Persistance après redémarrage
echo "kernel.randomize_va_space = 2" | sudo tee -a /etc/sysctl.conf

2.3 Désactiver les core dumps (R14)

Les core dumps peuvent révéler des informations sensibles :

# Vérification
cat /proc/sys/fs/suid_dumpable

# Correction si nécessaire (doit être 0)
sudo sysctl -w fs.suid_dumpable=0
echo "fs.suid_dumpable = 0" | sudo tee -a /etc/sysctl.conf

2.4 Mot de passe root robuste (R31)

Changez le mot de passe root avec un mot de passe fort :

sudo passwd root

Critères d'un mot de passe robuste :

Minimum 15 caractères
Majuscules, minuscules, chiffres, caractères spéciaux
Unique (jamais utilisé ailleurs)
Pas plus de 4 caractères consécutifs de la même catégorie

2.5 Dépôts officiels uniquement (R59)

Vérifiez que vous n'utilisez que des dépôts officiels :

# Debian/Ubuntu
cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/

Supprimez tout dépôt tiers non indispensable.

2.6 Supprimer les services inutiles (R62)

Listez les services actifs :

systemctl list-units --type=service --state=running

Désactivez ceux dont vous n'avez pas besoin :

# Exemple : désactiver le serveur Avahi (mDNS)
sudo systemctl stop avahi-daemon
sudo systemctl disable avahi-daemon

# Exemple : désactiver CUPS (impression) si pas nécessaire
sudo systemctl stop cups
sudo systemctl disable cups

Étape 3 : appliquer les recommandations niveau I

Une fois le niveau M appliqué, passez au niveau Intermédiaire.

3.1 Paramètres sysctl réseau (R12)

Créez un fichier de configuration sécurisée :

sudo tee /etc/sysctl.d/99-hardening.conf << 'EOF'
# Désactiver le routage IP
net.ipv4.ip_forward = 0

# Filtrage par chemin inverse (anti-spoofing)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignorer les redirections ICMP
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0

# Ne pas envoyer de redirections ICMP
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Refuser le source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Activer les SYN cookies (protection DDoS)
net.ipv4.tcp_syncookies = 1

# Journaliser les paquets suspects
net.ipv4.conf.all.log_martians = 1
EOF

Appliquez les changements :

sudo sysctl --system

3.2 Paramètres sysctl système (R9)

Ajoutez ces paramètres au fichier précédent :

sudo tee -a /etc/sysctl.d/99-hardening.conf << 'EOF'

# Masquer les adresses kernel
kernel.kptr_restrict = 2

# Restreindre l'accès à dmesg
kernel.dmesg_restrict = 1

# Protéger les liens symboliques
fs.protected_symlinks = 1
fs.protected_hardlinks = 1

# Désactiver les SysReq magiques
kernel.sysrq = 0
EOF

sudo sysctl --system

3.3 Désactiver IPv6 si non utilisé (R13)

Si vous n'utilisez pas IPv6 :

sudo tee -a /etc/sysctl.d/99-hardening.conf << 'EOF'

# Désactiver IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
EOF

sudo sysctl --system

3.4 Permissions des fichiers sensibles (R50)

Commencez par constater l'existant avant de modifier quoi que ce soit : les distributions ne posent pas les mêmes valeurs, et un chmod appliqué à l'aveugle sur ces fichiers casse l'authentification.

ls -l /etc/shadow /etc/gshadow /etc/passwd /etc/ssh/sshd_config
ls -ld /etc/ssh

Sur Debian et Ubuntu, /etc/shadow appartient à root:shadow en mode 640. Ce groupe n'est pas décoratif : le binaire /usr/sbin/unix_chkpwd, utilisé par PAM pour vérifier un mot de passe depuis un processus non privilégié, est setgid shadow. Lui retirer le groupe le prive de la lecture du fichier et casse la vérification des mots de passe hors root. Sur RHEL, le fichier est en 000 root:root et l'accès passe par d'autres mécanismes.

# Debian / Ubuntu : valeurs attendues, à rétablir seulement si elles ont dérivé
sudo chown root:shadow /etc/shadow /etc/gshadow
sudo chmod 640 /etc/shadow /etc/gshadow

# Le fichier de configuration du serveur SSH n'a pas à être lisible par tous
sudo chmod 600 /etc/ssh/sshd_config

3.5 Configurer sudo correctement (R38, R39)

La configuration de sudo s'appuie sur PAM pour l'authentification. Éditez la configuration sudo :

sudo visudo

Bonnes pratiques :

Évitez NOPASSWD sauf nécessité absolue
Utilisez des groupes plutôt que des utilisateurs individuels
Limitez les commandes autorisées

Exemple de configuration restrictive :

# Groupe admin peut utiliser sudo avec mot de passe
%admin ALL=(ALL) ALL

# Logs détaillés
Defaults logfile=/var/log/sudo.log
Defaults log_input, log_output

3.6 Configurer un pare-feu (R78)

Le pare-feu relève de la recommandation R78, « Cloisonner les services réseau », marquée M I R. Ne la confondez pas avec R80, « Réduire la surface d'attaque des services réseau », marquée M, qui porte sur les services que vous laissez écouter et non sur le filtrage.

La règle qui compte est celle du refus par défaut en entrée : on bloque tout, puis on ouvre au cas par cas. Ouvrez SSH avant d'activer le pare-feu, sous peine de vous couper l'accès à une machine distante.

UFW (Debian/Ubuntu)
Firewalld (RHEL/CentOS)

# Installer et activer UFW
sudo apt install ufw

# Règle par défaut : bloquer tout
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Autoriser SSH (ajustez le port si nécessaire)
sudo ufw allow 22/tcp

# Activer le pare-feu
sudo ufw enable

# Vérifier le statut
sudo ufw status verbose

# Vérifier que firewalld est actif
sudo systemctl enable firewalld
sudo systemctl start firewalld

# Voir la zone par défaut
sudo firewall-cmd --get-default-zone

# Lister les services autorisés
sudo firewall-cmd --list-all

# Autoriser uniquement SSH
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Étape 4 : vérifier le durcissement

Après avoir appliqué les recommandations, relancez un audit :

sudo lynis audit system

Comparez le nouveau score avec le score initial. Vous devriez constater une amélioration significative.

Tableau récapitulatif des recommandations

Ce tableau présente les principales recommandations avec leur niveau et la commande de vérification.

Socle système (matériel, démarrage, comptes, paquets)

Ce premier bloc porte sur ce qui se joue avant même que le système ne démarre, puis sur les comptes et les paquets. Deux lignes ne se vérifient pas en ligne de commande : R2 et R5 supposent un accès physique ou à la console de gestion à distance. Traitez-les en premier malgré tout, car un attaquant qui atteint le chargeur de démarrage contourne toutes les protections configurées plus haut dans la liste.

Code	Recommandation (intitulé officiel v2.0)	Niveau	Vérification
R2	Configurer le BIOS/UEFI	M, I	Vérification physique
R3	Activer le démarrage sécurisé UEFI	M, I	`mokutil --sb-state`
R5	Configurer un mot de passe pour le chargeur de démarrage	M, I	Configuration GRUB
R28	Partitionnement type	M, I	`cat /etc/fstab`
R30	Désactiver les comptes utilisateur inutilisés	M	`cat /etc/passwd`
R31	Utiliser des mots de passe robustes	M	`chage -l <user>` + politique
R36	Modifier la valeur par défaut de UMASK	M, I, R	`umask` (027 ou 077)
R58	N'installer que les paquets strictement nécessaires	M	`dpkg -l` ou `rpm -qa`
R59	Utiliser des dépôts de paquets de confiance	M	`cat /etc/apt/sources.list`
R61	Effectuer des mises à jour régulières	M	`apt list --upgradable`

Noyau, réseau et modules

Ces six recommandations se traduisent presque toutes par des paramètres sysctl, ce qui les rend faciles à automatiser mais aussi faciles à perdre : un sysctl -w n'est pas persistant, la valeur revient au défaut au redémarrage. Écrivez-les dans /etc/sysctl.d/ et vérifiez après reboot. La ligne R10, qui verrouille le chargement de modules noyau, est la seule à demander une attention particulière : une fois modules_disabled à 1, plus aucun module ne peut être chargé jusqu'au prochain démarrage, y compris ceux dont un pilote a besoin.

Code	Recommandation (intitulé officiel v2.0)	Niveau	Vérification
R9	Paramétrer les options de configuration du noyau (kptr_restrict, ASLR, dmesg, BPF)	M, I	`cat /proc/sys/kernel/randomize_va_space`
R10	Désactiver le chargement des modules noyau	M, I, R	`cat /proc/sys/kernel/modules_disabled`
R11	Activer et configurer le LSM Yama (ptrace)	M, I	`cat /proc/sys/kernel/yama/ptrace_scope`
R12	Paramétrer les options de configuration du réseau	M, I	`sysctl -a \| grep -E "rp_filter\|redirect"`
R13	Désactiver le plan IPv6	M, I	`cat /proc/sys/net/ipv6/conf/all/disable_ipv6`
R14	Paramétrer les options de configuration des systèmes de fichiers (suid_dumpable, protected_*)	M, I	`cat /proc/sys/fs/suid_dumpable`

Fichiers, accès et privilèges

C'est le bloc qui décide de ce qu'un compte compromis peut faire ensuite. Commencez par R56 : la commande find / -perm /6000 -type f liste les binaires setuid et setgid, ceux qui s'exécutent avec les droits de leur propriétaire plutôt que de l'appelant. Chaque entrée inutile de cette liste est un chemin d'élévation de privilèges de moins. Les recommandations R38, R39 et R44 forment un ensemble cohérent autour de sudo : groupe dédié, directives restrictives, édition sécurisée.

Code	Recommandation (intitulé officiel v2.0)	Niveau	Vérification
R32	Expirer les sessions utilisateur locales	M, I	`grep TMOUT /etc/profile`
R38	Créer un groupe dédié à l'usage de sudo	M, I, R	`getent group sudo`
R39	Modifier les directives de configuration sudo	M, I	`sudo -l`
R44	Éditer les fichiers de manière sécurisée avec sudo	M, I	`visudo -c`
R50	Restreindre les droits d'accès aux fichiers et aux répertoires	M, I	`ls -la /etc/shadow /etc/passwd`
R54	Activer le sticky bit sur les répertoires inscriptibles	M	`find / -perm -1000 -type d 2>/dev/null`
R56	Éviter l'usage d'exécutables avec les droits spéciaux (setuid/setgid)	M	`find / -perm /6000 -type f 2>/dev/null`
R67	Sécuriser les authentifications distantes par PAM	M, I	`cat /etc/pam.d/common-*`

Services, journalisation et contrôle d'accès

Ce dernier bloc traite de ce qui tourne et de ce qui est tracé. Séparez bien les deux natures de recommandations : R62, R78, R79 et R80 réduisent l'exposition, tandis que R71 et R73 vous donnent les moyens de constater un incident après coup. Négliger la seconde catégorie revient à durcir sans jamais savoir si une tentative a eu lieu. R46 est la plus lourde à mettre en oeuvre : activer SELinux ou AppArmor sur un système existant demande une phase d'observation en mode permissif avant de passer en mode bloquant.

Code	Recommandation (intitulé officiel v2.0)	Niveau	Vérification
R46	Activer SELinux avec la politique targeted (ou AppArmor)	M, I, R, E	`getenforce` ou `aa-status`
R62	Désactiver les services non nécessaires	M	`systemctl list-units --type=service`
R71	Mettre en place un système de journalisation	M, I, R	`systemctl status rsyslog`
R73	Journaliser l'activité système avec auditd	M, I, R	`auditctl -l`
R78	Cloisonner les services réseau (pare-feu)	M, I, R	`ufw status` ou `firewall-cmd --list-all`
R79	Durcir et surveiller les services exposés (SSH)	M, I	Configuration par service
R80	Réduire la surface d'attaque des services réseau	M	`ss -tlnp`

Outils pour vous aider

Rudder, Audit et application automatique

Rudder est une solution de gestion de configuration qui va au-delà de l'audit en proposant l'application automatique des règles de durcissement. Contrairement aux outils d'audit qui détectent les écarts sans les corriger, Rudder détecte et remédie automatiquement toutes les 5 minutes.

Pourquoi Rudder se distingue

La plupart des outils auditent : ils détectent les problèmes, génèrent des rapports, mais c'est à vous de corriger manuellement. Rudder propose deux modes :

Mode	Comportement	Cas d'usage
Audit	Détecte les écarts sans modifier	Évaluation initiale, préparation d'audit
Enforce	Détecte et corrige automatiquement	Production, maintien continu de la conformité

Exemple concret : vous avez configuré kernel.randomize_va_space = 2 dans /etc/sysctl.conf (recommandation R9). Un script ou une mise à jour remet cette valeur à 0.

Avec Lynis ou OpenSCAP : le prochain audit détecte l'écart, vous recevez un rapport, vous devez corriger manuellement.
Avec Rudder en mode Enforce : l'agent détecte l'écart dans les 5 minutes et rétablit automatiquement kernel.randomize_va_space = 2.

CIS Benchmarks et transposition ANSSI

Rudder intègre nativement les CIS Benchmarks (500+ contrôles pour RHEL, Ubuntu, Debian). Les CIS Benchmarks et l'ANSSI-BP-028 partagent de nombreux objectifs communs :

Recommandation ANSSI	Équivalent CIS	Description
R9 : ASLR activé	CIS 1.5.1	`kernel.randomize_va_space = 2`
R79 : SSH durci	CIS 5.2.x	MaxAuthTries, PermitRootLogin, PubkeyAuthentication
R62 : Services inutiles désactivés	CIS 2.x	Désactiver telnet, xinetd, avahi, cups
R71 : Journalisation centralisée	CIS 4.2.x	Configuration rsyslog/syslog-ng
R50 : Permissions /etc restrictives	CIS 6.1.x	chmod 644 /etc/passwd, 640 /etc/shadow

De nombreux contrôles CIS peuvent être transposés aux exigences ANSSI. Par exemple, les règles SSH (R79) correspondent directement aux contrôles CIS 5.2 (SSH Server Configuration).

Rapports ANSSI en cours de développement

L'équipe Rudder travaille actuellement sur une fonctionnalité de rapports ANSSI-BP-028. À terme, Rudder pourra afficher :

Le niveau de conformité ANSSI (M, I, R, E)
Un score par catégorie de recommandations
Le mapping entre les contrôles CIS appliqués et les recommandations ANSSI équivalentes

Cette fonctionnalité permettra aux organisations françaises de démontrer leur conformité aux recommandations de l'ANSSI tout en bénéficiant de la remédiation automatique.

Fonctionnalités clés

Ces quatre points expliquent pourquoi Rudder s'adresse davantage à un parc qu'à une machine isolée. La granularité d'application est le critère décisif : elle permet de laisser un groupe de serveurs en observation pendant qu'un autre est déjà en correction automatique, ce qui rend le déploiement progressif possible sans dupliquer les règles.

Dashboard temps réel : score de conformité par section du benchmark
Remédiation automatique : maintien continu de l'état conforme
Granularité d'application : modes Audit/Enforce par groupe, système ou section
Documentation intégrée : chaque contrôle affiche sa justification

Distributions supportées

La liste ci-dessous correspond aux benchmarks livrés avec le plugin, pas aux systèmes sur lesquels l'agent Rudder s'installe, qui sont plus nombreux. Sur une distribution absente du tableau, l'agent fonctionne mais vous devez écrire vos propres règles. Vérifiez la couverture des versions récentes sur le site de l'éditeur avant de vous engager : les benchmarks CIS suivent le cycle des versions majeures avec un décalage de plusieurs mois.

Distribution	Versions	Benchmark CIS
Red Hat Enterprise Linux	8, 9	CIS RHEL 8/9 Benchmark
Ubuntu	20.04 LTS, 22.04 LTS	CIS Ubuntu Benchmark
Debian	11 (Bullseye), 12 (Bookworm)	CIS Debian Benchmark

Tarification

Le plugin Policy and Benchmark Compliance fait partie de l'offre Rudder Enterprise (non disponible dans la version open source). Pour obtenir un devis, contactez l'équipe commerciale Rudder.

Guide complet : Benchmarks CIS avec Rudder

Lynis : audit rapide

Lynis analyse votre système et liste les points à améliorer.

# Installation
sudo apt install lynis    # Debian/Ubuntu
sudo dnf install lynis    # RHEL/CentOS

# Audit complet
sudo lynis audit system

# Audit avec profil personnalisé
sudo lynis audit system --profile /etc/lynis/custom.prf

→ Guide complet Lynis

OpenSCAP : conformité ANSSI

OpenSCAP vérifie la conformité par rapport au profil ANSSI-BP-028.

# Installation
sudo apt install openscap-utils scap-security-guide

# Audit avec profil ANSSI
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_anssi_bp28_enhanced \
  --results results.xml \
  --report rapport.html \
  /usr/share/xml/scap/ssg/content/ssg-debian12-ds.xml

Le rapport HTML généré liste chaque contrôle avec son statut (PASS/FAIL).

→ Guide complet OpenSCAP

Ansible : automatisation

Pour appliquer le durcissement à grande échelle, utilisez Ansible :

- name: Durcissement niveau I
  hosts: all
  become: yes
  tasks:
    - name: Configurer sysctl
      sysctl:
        name: "{{ item.key }}"
        value: "{{ item.value }}"
        state: present
        reload: yes
      loop:
        - { key: 'kernel.randomize_va_space', value: '2' }
        - { key: 'kernel.kptr_restrict', value: '2' }
        - { key: 'fs.suid_dumpable', value: '0' }
        - { key: 'net.ipv4.conf.all.rp_filter', value: '1' }

Maintenir le durcissement

Le durcissement n'est pas une action ponctuelle. Pour rester sécurisé :

Audits réguliers

Un audit manuel finit toujours par être oublié. Planifiez-le avec cron et faites-le écrire dans un fichier daté, pour disposer d'un historique comparable. L'option --cronjob de Lynis existe précisément pour cet usage : elle supprime la mise en couleur et les pauses interactives qui rendraient la sortie illisible dans un fichier.

Planifiez un audit automatique chaque semaine :

# Ajouter au crontab
sudo crontab -e

# Audit Lynis hebdomadaire
@weekly /usr/sbin/lynis audit system --cronjob > /var/log/lynis-weekly.log

Surveillance des dérives

Comparez les scores au fil du temps. Ce qui vous intéresse n'est pas la valeur absolue mais la variation : une baisse signale presque toujours qu'un paquet installé, une mise à jour ou un script d'automatisation a réécrit une configuration durcie. Consignez la date et la cause à chaque écart, c'est ce journal qui rend la conformité démontrable lors d'un audit.

Date	Score Lynis	Remarque
01/12/2025	82	Après durcissement initial
08/12/2025	82	Stable
15/12/2025	78	Baisse → investiguer

Mises à jour du guide

L'ANSSI met à jour son guide régulièrement. Consultez cyber.gouv.fr pour les nouvelles versions.

À retenir

Le durcissement d'un système Linux n'est pas une option, c'est une nécessité. Avec le guide ANSSI-BP-028, vous disposez d'un référentiel clair, structuré et adapté au contexte français.

Commencez par le niveau M : c'est accessible à tous et apporte déjà une protection significative
Utilisez Lynis pour mesurer vos progrès et identifier les points à améliorer
Le durcissement est un processus continu : planifiez des audits réguliers
Automatisez avec Ansible ou Rudder pour garantir la cohérence sur l'ensemble de votre parc
Les CIS Benchmarks peuvent compléter les recommandations ANSSI : de nombreux contrôles se recoupent

Ne cherchez pas la perfection du premier coup. Chaque recommandation appliquée réduit votre surface d'attaque. Progressez à votre rythme, documentez vos choix, et n'hésitez pas à revenir sur ce guide au fil de votre montée en compétences.

Votre prochain pas : lancez un audit Lynis sur votre serveur et notez votre score. C'est le point de départ de votre parcours vers un système durci.

Pour aller plus loin

Rudder

Audit et application automatique des règles, transposition CIS vers ANSSI.

Lire le guide →

Lynis

Audit de sécurité automatisé, profils personnalisés, intégration CI/CD.

Lire le guide →

OpenSCAP

Conformité SCAP, profils ANSSI, rapports détaillés.

Lire le guide →

Durcissement SSH

Configuration sécurisée, algorithmes, clés, CVE récentes.

Lire le guide →

CIS Benchmarks

Référentiel complémentaire ANSSI, niveaux Level 1/2, automatisation.

Lire le guide →

Sécurix, BP-028 en NixOS

Implémentation NixOS open source des recommandations BP-028 par la DINUM : framework de compliance as code avec niveaux, catégories et exceptions motivées.

Lire le retex →

Contrôle d'accès avancé

Les trois guides ci-dessous couvrent la recommandation R46 et la R67. SELinux et AppArmor répondent au même besoin, le contrôle d'accès obligatoire (MAC), et ne s'installent pas l'un à côté de l'autre : choisissez celui que votre distribution active nativement. PAM se place en amont, sur la chaîne d'authentification elle-même.

SELinux : pour RHEL, CentOS, Fedora
AppArmor : pour Debian, Ubuntu
PAM : authentification et politiques

Ressources officielles

Guide ANSSI-BP-028 : document source complet (PDF)
Guides ANSSI : tous les guides de bonnes pratiques
Documentation Lynis : référence officielle
Site OpenSCAP : framework de conformité