Atelier : durcissement d'un hôte Linux
Appliquer un CIS Benchmark Linux pour durcir la configuration système d'un serveur.
À retenir
- Les CIS Benchmarks déclinent les CIS Controls en réglages techniques précis, par système et par niveau.
- Level 1 vise la disponibilité, Level 2 vise la sécurité maximale au prix de compatibilité réduite.
- Les outils CIS-CAT Lite et OpenSCAP permettent d'auditer automatiquement la conformité.
- Le durcissement doit être intégré dans l'automatisation d'infrastructure pour éviter la dérive de configuration.
Du contrôle générique au réglage précis
Les CIS Controls définissent quoi faire ; les CIS Benchmarks définissent comment le faire, système par système. Un CIS Benchmark pour Ubuntu Server ou Red Hat Enterprise Linux détaille des centaines de paramètres, chacun assorti d'un niveau (Level 1, orienté disponibilité ; Level 2, orienté sécurité maximale) et d'un rationnel expliquant le risque couvert.
Étapes d'un atelier de durcissement
- Choisir le bon Benchmark et le bon niveau selon la criticité de l'hôte (serveur exposé vs. poste interne).
- Auditer l'état actuel avec un outil comme CIS-CAT Lite ou OpenSCAP.
- Prioriser les écarts en fonction du risque, pas uniquement du nombre de règles.
- Appliquer les correctifs de configuration, idéalement via un outil d'automatisation (Ansible, Puppet).
- Documenter les exceptions justifiées (une application legacy peut imposer un service désactivé par le benchmark).
Exemples de réglages Level 1 courants
- Désactivation des protocoles réseau non utilisés (ex. modules de chargement automatique inutiles).
- Restriction des permissions sur les fichiers sensibles (
/etc/shadow,/etc/passwd). - Politique de mot de passe et de verrouillage de compte via PAM.
- Désactivation de la connexion SSH directe en tant que
root. - Activation et configuration d'un pare-feu local (nftables ou iptables).
Point clé
le durcissement n'est jamais un one-shot. Un hôte durci puis mis à jour, reconfiguré ou redéployé sans repasser par le benchmark redevient rapidement non conforme — d'où l'intérêt de l'intégrer dans le pipeline d'infrastructure as code.
Vérifier sans casser le service
Attention
appliquer un CIS Benchmark Level 2 en production sans tests préalables peut interrompre des services legitimes (certains démons SSH restreints, certains montages NFS bloqués). Toujours tester en environnement de pré-production et comparer les journaux d'erreurs avant et après application.
# Audit rapide avec OpenSCAP sur RHEL/CentOS
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis \
--results /tmp/resultats-cis.xml \
--report /tmp/rapport-cis.html \
/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
Suivre l'écart dans la durée
Un score de conformité au moment T n'a de valeur que s'il est suivi : dérive de configuration après une mise à jour, ajout d'un paquet non conforme, modification manuelle « temporaire » jamais annulée. Un contrôle de conformité continu (via Ansible en mode --check, ou un agent de conformité) permet de détecter ces dérives avant qu'elles ne s'accumulent.
Sur le terrain
sur les parcs Linux que nous accompagnons, la dérive de configuration la plus fréquente vient de correctifs d'urgence appliqués « à la main » un week-end, jamais reportés dans les playbooks d'automatisation — le serveur redevient donc non conforme au prochain audit sans que personne n'ait « rien changé » officiellement.
Astuce
conservez toujours un rapport d'écart horodaté avant remédiation ; il sert de preuve d'amélioration continue lors des audits de conformité.