Un serveur Linux installé par défaut est fonctionnel, pas sûr : comptes trop permissifs, SSH ouvert à tous, aucun pare-feu, services qui tournent en root sans confinement, aucune trace exploitable. Ce volet du parcours Linux montre comment le durcir couche par couche, sans casser la production et en gardant un accès de secours à chaque étape. Il réunit 26 guides répartis en 8 couches : identités et sudo, SSH, permissions, pare-feu, noyau et démarrage, confinement des services avec systemd, SELinux et AppArmor, journalisation d'audit, puis audit de conformité avec Lynis, OpenSCAP, CIS et ANSSI. C'est aussi le socle pratique de la certification RHCSA.
Pourquoi durcir un serveur Linux, et contre quoi ?
Section intitulée « Pourquoi durcir un serveur Linux, et contre quoi ? »Chaque réglage de durcissement répond à une technique d'attaque précise : ce n'est pas une exigence de norme, c'est une réponse à un mode opératoire connu. Le tableau ci-dessous se lit de gauche à droite : une situation que vous pouvez rencontrer, puis le mécanisme du parcours qui la neutralise. Si une seule ligne vous parle, commencez par la couche correspondante.
| Situation réelle | Réponse du parcours |
|---|---|
| Un attaquant a un accès console et édite la ligne de démarrage pour obtenir un shell root | Mot de passe GRUB |
| Un compte de service compromis tente une élévation via un binaire setuid | sudo durci, nosuid sur les montages |
Un script déposé dans /tmp est exécuté | noexec sur /tmp et /dev/shm |
Un service web piraté veut lire /etc/shadow ou écrire partout | Sandboxing systemd, SELinux/AppArmor |
Une CVE dans un protocole réseau inutilisé (dccp) devient exploitable | Modules noyau désactivés |
| Du spoofing d'adresse source sur le réseau | rp_filter et durcissement sysctl |
| Après un incident, « qui a modifié ce fichier, avec quel compte ? » | auditd |
| Un audit client exige une preuve de conformité | Lynis, OpenSCAP, CIS, ANSSI |
Les 26 guides de durcissement, couche par couche
Section intitulée « Les 26 guides de durcissement, couche par couche »Le durcissement se construit en couches, de l'identité jusqu'à la preuve. Suivez-les dans l'ordre ci-dessous pour un serveur neuf, ou piochez la couche qui vous manque si le reste est déjà en place.
Comptes, sudo et authentification
Section intitulée « Comptes, sudo et authentification »La première porte d'entrée d'un attaquant, ce sont les identités. On commence par maîtriser les comptes locaux, on branche l'annuaire quand le parc grandit, puis on délègue les privilèges proprement et on renforce l'authentification en amont de la connexion.
Accès distant SSH
Section intitulée « Accès distant SSH »SSH est le service le plus exposé d'un serveur, donc la cible numéro un des attaques par force brute. Le durcir ferme la porte la plus visible, et c'est le réglage dont le rapport effort/gain est le meilleur de tout le parcours.
Permissions et système de fichiers
Section intitulée « Permissions et système de fichiers »Au-delà des droits classiques, on affine les permissions avec les ACL, on reprend la main sur les fichiers sensibles du système, et on neutralise des vecteurs d'exécution au niveau des options de montage.
Pare-feu et exposition réseau
Section intitulée « Pare-feu et exposition réseau »Réduire ce qui est joignable depuis le réseau est l'un des gains les plus rapides. On comprend d'abord le modèle de filtrage, on choisit ensuite l'outil de sa distribution, et on descend au besoin jusqu'à nftables, le moteur commun.
Noyau, modules et démarrage
Section intitulée « Noyau, modules et démarrage »Le durcissement descend jusqu'au noyau et au démarrage : on règle les paramètres de la pile réseau et mémoire, on retire les modules inutiles, on peut recompiler avec les options KSPP, et on protège le chargeur de démarrage.
Confiner les services
Section intitulée « Confiner les services »Un service compromis ne doit pas pouvoir toucher au reste du système. Trois mécanismes de cloisonnement, du plus simple au plus strict : les options de sandboxing d'une unité systemd, puis le contrôle d'accès obligatoire de votre distribution.
Journalisation et traçabilité
Section intitulée « Journalisation et traçabilité »Durcir ne suffit pas : il faut garder une trace résistante de ce qui se passe, pour détecter pendant l'incident et pour investiguer après. C'est la couche qu'on regrette de ne pas avoir posée le jour où la question « qui a fait ça ? » se pose.
Audit et conformité
Section intitulée « Audit et conformité »Enfin, on mesure et on prouve le durcissement avec deux outils d'audit et les deux référentiels de référence. C'est ce qui transforme un travail invisible en document opposable à un client ou à un auditeur.
SELinux ou AppArmor, firewalld ou UFW : que change la distribution ?
Section intitulée « SELinux ou AppArmor, firewalld ou UFW : que change la distribution ? »Deux briques seulement diffèrent selon la famille de distribution, le contrôle d'accès obligatoire et le pare-feu ; tout le reste du parcours est commun. Mieux vaut trancher dès le départ, parce que revenir en arrière sur ces deux choix coûte cher.
- Contrôle d'accès obligatoire : SELinux est natif et activé par défaut sur RHEL, Rocky et AlmaLinux ; AppArmor est le standard sur Debian et Ubuntu. On ne fait pas tourner les deux.
- Pare-feu : firewalld (filtrage par zones) côté RHEL, UFW (règles
simples) côté Debian/Ubuntu. Les deux pilotent nftables en dessous, ce qui
explique qu'une règle posée par l'un soit visible dans
nft list ruleset.
Tout le reste (comptes, sudo, SSH, sysctl, modules noyau, GRUB,
systemd, auditd, Lynis) est commun à toutes les distributions, avec parfois une
commande qui change, comme apt contre dnf ou update-grub contre
grub2-mkconfig.
Dans quel ordre durcir un serveur Linux neuf ?
Section intitulée « Dans quel ordre durcir un serveur Linux neuf ? »L'ordre sûr commence par les identités et finit par la mesure : identités, accès distant, réduction de surface, confinement, traçabilité, mesure. Il maximise la sécurité gagnée à chaque étape tout en minimisant le risque de vous couper l'accès. Gardez toujours une session root ouverte pendant les manipulations réseau et SSH.
-
Identités d'abord : comptes propres, sudo durci, PAM. C'est sans risque et ça ferme la porte principale.
-
Accès distant : durcissez SSH (clés, pas de root), puis posez le pare-feu en gardant le port SSH ouvert.
-
Réduction de surface : options de montage, modules noyau, paramètres sysctl. Testez la connectivité après chaque réglage réseau.
-
Confinement : activez SELinux ou AppArmor selon la distribution, puis durcissez les services exposés avec le sandboxing systemd.
-
Traçabilité et boot : déployez auditd, protégez GRUB.
-
Mesure : passez Lynis ou OpenSCAP, corrigez les écarts, et alignez sur CIS ou ANSSI selon votre exigence.
Quels principes guident un durcissement qui tient ?
Section intitulée « Quels principes guident un durcissement qui tient ? »Quatre principes suffisent, et ils valent quelle que soit la distribution : moindre privilège, défense en profondeur, rollback préparé, preuve plutôt qu'intuition. Ils expliquent la plupart des choix des guides qui précèdent.
- Moindre privilège partout : chaque compte, service et règle n'a que ce dont
il a strictement besoin. Un
(root)ou unALLde trop dans/etc/sudoersest une dette. - Défense en profondeur : aucune couche n'est suffisante seule. Un service derrière un pare-feu, confiné par systemd et par SELinux survit à la défaillance d'une couche.
- Toujours un rollback : avant chaque réglage qui peut bloquer (SSH, pare-feu, GRUB, montages), gardez un accès de secours et sachez revenir en arrière.
- Prouver, pas supposer : un score Lynis ou un rapport OpenSCAP vaut mieux qu'une intuition. Mais un score bas n'est pas une preuve absolue : la valeur est dans les réglages pertinents, pas dans le chiffre.
Comment valider ce que vous avez durci ?
Section intitulée « Comment valider ce que vous avez durci ? »La validation se fait sur une VM jetable, en mesurant avant et après avec un audit Lynis. Ce volet est aligné sur le bloc identités, permissions et sécurité du parcours Linux, et sur les spécificités RHCSA que sont SELinux, firewalld et le mode de récupération.
La méthode tient en trois temps. Vous lancez un audit Lynis sur une machine fraîchement installée et vous notez son score de départ. Vous appliquez ensuite les guides du volet, en vérifiant chaque réglage avec la commande de contrôle que le guide indique, sestatus, firewall-cmd --list-all ou systemd-analyze security selon la couche. Vous relancez enfin l'audit et vous comparez. Un serveur que vous savez durcir, auditer et restaurer est un serveur que vous maîtrisez ; les trois verbes comptent, et le troisième est celui qu'on oublie.
À retenir
Section intitulée « À retenir »- Un serveur par défaut est fonctionnel mais pas sûr : le durcissement se fait par couches, ici 26 guides répartis en 8 couches
- L'ordre sûr : identités → accès distant → surface → confinement → traçabilité → mesure
- Toujours un accès de secours avant les réglages qui peuvent bloquer (SSH, pare-feu, GRUB)
- Moindre privilège et défense en profondeur sont les deux fils rouges
- SELinux côté RHEL, AppArmor côté Debian/Ubuntu : choisissez selon la distribution
- Lynis, OpenSCAP, CIS, ANSSI transforment le durcissement en preuve auditable
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Comprendre les pare-feu Linux : Choisir entre UFW, firewalld et nftables avant d'écrire la première règle.
- SELinux (RHEL, Rocky) : Confiner les services avec le contrôle d'accès obligatoire, sans le désactiver au premier refus.
- Dépanner un serveur Linux : Diagnostiquer et réparer, y compris quand c'est le durcissement qui a cassé le service.