Durcir les configurations Linux

Durcir un serveur Linux, c'est réduire méthodiquement sa surface d'attaque. Un système fraîchement installé est configuré pour fonctionner, pas pour résister : services inutiles, droits trop larges, traces insuffisantes. Cette formation vous fait appliquer, mesure par mesure, les recommandations des référentiels ANSSI-BP-028 (le guide de l'agence française de cybersécurité) et CIS Benchmarks (celui du Center for Internet Security), des comptes et des privilèges jusqu'au noyau et au confinement des services. Elle s'adresse aux administrateurs et aux équipes DevOps qui savent déjà administrer un serveur Linux et veulent le rendre défendable.

Ce que vous allez apprendre

Comprendre ce qu'est le durcissement et pourquoi il est indispensable
Lire les référentiels ANSSI-BP-028 et CIS Benchmarks pour décider quoi durcir d'abord
Durcir l'authentification et les privilèges : SSH, PAM, sudo, permissions, binaires détournables (GTFObins) et planification de tâches
Ne laisser entrer que le trafic prévu avec un pare-feu (firewalld, UFW, nftables)
Protéger les fichiers, le démarrage et le noyau
Confiner les services avec SELinux, AppArmor et le sandboxing systemd
Déclarer un durcissement sous NixOS, le tester avant de le rendre permanent et revenir à une génération saine

Pour qui est cette formation ?

La formation suppose que vous savez déjà administrer un serveur Linux : gérer les paquets, les services systemd, les utilisateurs et les permissions. Si ce n'est pas encore le cas, la formation Linux pose ces bases ; plusieurs de ses leçons, SELinux, AppArmor, permissions, sysctl, GRUB et pare-feu, sont d'ailleurs communes aux deux formations, et votre progression y compte des deux côtés.

Trois profils en tirent le plus : l'administrateur qui doit faire passer un audit de conformité, l'équipe DevOps qui veut des images et des rôles Ansible durcis par défaut, et l'ingénieur sécurité qui doit expliquer chaque mesure à ceux qui l'appliquent.

Qu'est-ce que le durcissement ?

Le durcissement (hardening en anglais) désigne le processus qui améliore la sécurité d'un système en réduisant sa surface d'attaque : chaque service désactivé, chaque droit retiré, chaque option de montage ajoutée ferme une porte d'entrée possible. En termes simples, durcir un serveur, c'est renforcer les murs et verrouiller les portes avant qu'on ne les force.

Un serveur Linux n'est pas sécurisé par défaut. À l'installation, des services inutiles écoutent sur le réseau, les permissions sont souvent trop larges, la journalisation est minimale et toutes les protections du noyau ne sont pas activées. Le durcissement corrige ces réglages un par un, avec une raison et une vérification pour chacun. Pour la journalisation, la formation couvre celle de sudo (page sudoers) ; l'audit au niveau du noyau est enseigné par la leçon auditd.

Pourquoi durcir vos serveurs ?

Les serveurs Linux portent les infrastructures cloud, les sites web et les applications métier, ce qui en fait une cible privilégiée. Les menaces les plus courantes exploitent précisément ce que le durcissement ferme :

force brute sur SSH, quand l'authentification par mot de passe reste ouverte ;
exploitation d'un service exposé dont on n'avait pas besoin ;
élévation de privilèges par une règle sudo trop large ou un binaire setuid oublié (un binaire qui s'exécute avec les droits de son propriétaire, souvent root) ;
mouvement latéral après une première compromission, quand rien ne confine le service atteint.

Les conséquences dépassent la technique : interruption de service, fuite de données, perte de confiance des clients, et non-conformité à des obligations comme le RGPD, PCI-DSS ou l'hébergement de données de santé.

Sur quels principes repose le durcissement ?

Toute mesure de cette formation applique l'un de trois principes, et les reconnaître aide à juger une recommandation qu'aucun référentiel ne couvre.

La minimisation consiste à n'installer et n'activer que ce dont le serveur a besoin : chaque composant est une porte d'entrée potentielle. Le guide minimisation de la surface d'attaque le développe.

Le moindre privilège donne à chaque utilisateur et à chaque programme le minimum de droits nécessaires, ni plus ni moins. C'est le fil des leçons sur sudo, les permissions et le confinement ; voir aussi le principe du moindre privilège.

La défense en profondeur multiplie les barrières : si une protection cède, une autre prend le relais. SSH durci, compte sans sudo, montage noexec et profil AppArmor se complètent ; aucun ne suffit seul. Les principes de sécurité en donnent le cadre général.

Comment la formation est-elle construite ?

Le parcours compte sept modules d'enseignement, à suivre dans l'ordre : chacun suppose le précédent appliqué. Le programme détaillé, avec les durées et votre progression, se trouve sur la page Mon parcours.

Les référentiels de durcissement ouvrent la formation, parce qu'ils disent quoi durcir et dans quel ordre. ANSSI-BP-028 propose quatre niveaux progressifs, de Minimal à Élevé ; les CIS Benchmarks en proposent deux. Vous y apprenez à choisir un niveau cible plutôt qu'à tout appliquer d'un coup.

Accès et privilèges traite ce qui fait entrer et agir : le service SSH, le plus exposé, l'authentification PAM (la couche modulaire qui décide comment Linux vérifie un utilisateur), les règles sudo et leur journalisation, les permissions des fichiers sensibles, les binaires détournables repérés avec GTFObins, leçon qui prolonge celle des bits setuid, puis la planification de tâches avec cron et at. Juste après sudo, la leçon auditd trace au niveau du noyau les accès aux fichiers sensibles et l'usage de sudo, avec des règles persistantes relues par ausearch et aureport.

Filtrer le réseau ne laisse entrer que ce qui est prévu : le modèle d'un pare-feu Linux, puis sa mise en œuvre avec firewalld, UFW et nftables. Ces leçons sont partagées avec la formation Linux.

Fichiers, démarrage et session empêche d'exécuter ou de modifier ce qui ne doit pas l'être : options de montage nodev, nosuid et noexec, mot de passe du chargeur GRUB, bannières légales et verrouillage d'une session GNOME avec dconf.

Durcir le noyau règle la pile réseau et les protections du noyau à chaud avec sysctl, interdit les modules inutiles, puis montre comment recompiler un noyau avec les options KSPP (celles du Kernel Self Protection Project) quand une protection ne se règle qu'à la compilation.

Confiner les services limite ce qu'un service compromis peut faire. SELinux et AppArmor sont deux contrôles d'accès obligatoires, qui bornent ce que chaque programme a le droit de toucher : la formation aide à choisir entre eux, puis les met en œuvre. Vient ensuite le sandboxing systemd, qui confine un service sans écrire de politique.

Système immuable change d'angle : au lieu de retoucher un serveur, on le reconstruit à partir d'une description. Le module situe les OS immuables, présente NixOS et ses limites réelles, puis réapplique en déclaratif les mesures des modules précédents (auditd, enseigné dans le module « Accès », et fail2ban, qui a son tutoriel, s'y ajoutent), avec nixos-rebuild test avant toute bascule et le retour à une génération saine quand une mesure casse le système. Il se termine par l'étude de Sécurix, un poste NixOS durci selon l'ANSSI. Ses leçons supposent la base Nix de la formation Linux.

Comment mesurer le durcissement ?

Un durcissement qui ne se mesure pas se dégrade sans qu'on le voie. Trois outils servent à auditer un serveur avant et après chaque module ; ce sont des tutoriels à part, que vous installez une fois et rejouez à chaque étape.

Lynis donne un score de durcissement et des recommandations en une commande : c'est l'audit le plus rapide pour commencer. OpenSCAP vérifie la conformité à un profil ANSSI ou CIS et produit le rapport qu'un auditeur attend. Pavois contrôle la configuration effective (sshd -T, sysctl) plutôt que les fichiers. La leçon auditd du module Accès complète ces audits ponctuels par une trace continue au niveau du noyau. Sur RHEL, fapolicyd complète SELinux en décidant quels binaires ont le droit de s'exécuter.

Comment automatiser le durcissement ?

À l'échelle d'un parc, un durcissement appliqué à la main dérive : l'automatisation garantit que chaque serveur reçoit les mêmes mesures et le garde. Ansible applique des rôles de durcissement, comme ceux de la collection devsec.hardening présentés dans cet article sur les collections Ansible de durcissement. Packer construit des images déjà durcies, et Rudder pilote la conformité OpenSCAP à grande échelle. Le dernier module de la formation pousse la logique plus loin avec les systèmes d'exploitation immuables : au lieu de corriger une dérive, le système est reconstruit depuis sa description.

Par où commencer ?

Le point d'entrée normal est le premier module, en commençant par ANSSI-BP-028. Si un serveur est déjà exposé et que le temps presse, suivez cet ordre, qui traite le risque le plus immédiat d'abord :

Mesurer l'état actuel

Lancez un audit Lynis pour obtenir un score de départ et la liste des écarts.
Durcir SSH

Durcissez SSH, le service le plus exposé d'un serveur.
Appliquer le niveau Minimal

Appliquez le niveau Minimal de l'ANSSI, ou le Level 1 du CIS, puis relancez l'audit pour mesurer l'écart comblé.

Le durcissement n'est jamais terminé : planifiez des audits réguliers, car chaque mise à jour, chaque nouveau service peut rouvrir une porte fermée.

À retenir

Le durcissement des serveurs Linux est une étape indispensable pour protéger vos données et infrastructures. Les référentiels ANSSI et CIS fournissent des guides éprouvés, et Lynis comme OpenSCAP mesurent vos progrès. Ce n'est pas un objectif final mais un processus d'amélioration continue : chaque recommandation appliquée réduit votre exposition.

Commencez par le niveau Minimal de l'ANSSI ou Level 1 du CIS.
Durcissez d'abord le plus exposé : SSH, pare-feu, permissions, points de montage.
Appuyez chaque mesure sur un principe : minimisation, moindre privilège, défense en profondeur.
Auditez avec Lynis (rapide) et OpenSCAP (conformité réglementaire), avant et après chaque module.
Automatisez avec Ansible pour la cohérence à grande échelle, ou déclarez le système entier avec un OS immuable comme NixOS.
Planifiez des audits réguliers : le durcissement n'est jamais « terminé ».