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 parcours montre comment le durcir de bout en bout, couche par couche, sans casser la production et en gardant un accès de secours à chaque étape. Vous y verrez les identités et sudo, SSH, les permissions, le pare-feu, le noyau et le démarrage, le confinement des services (systemd, SELinux, AppArmor), la journalisation d'audit et enfin l'audit de conformité (Lynis, CIS, ANSSI). C'est aussi le socle pratique de la certification RHCSA.
Au terme de ce parcours, vous saurez :
Section intitulée « Au terme de ce parcours, vous saurez : »- Verrouiller les accès : comptes, sudo, PAM, durcissement SSH
- Réduire la surface : permissions, options de montage, modules noyau, pare-feu
- Confiner les services : sandboxing systemd, SELinux, AppArmor
- Protéger le démarrage : mot de passe GRUB, paramètres noyau sysctl
- Tracer l'activité système avec auditd
- Prouver le durcissement avec Lynis, OpenSCAP et les référentiels CIS / ANSSI
Dans quel contexte ?
Section intitulée « Dans quel contexte ? »Le durcissement n'est pas un caprice de norme : chaque réglage répond à une technique d'attaque réelle. Voici des situations concrètes et la compétence qui y répond.
| 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 guides, par thème
Section intitulée « Les guides, par thème »Le durcissement se construit en couches. Suivez-les dans l'ordre ci-dessous pour un serveur neuf, ou piochez la couche qui vous manque.
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, puis on délègue les privilèges proprement et on renforce l'authentification en amont.
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.
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 et on neutralise des vecteurs au niveau des montages.
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 filtrage, puis on choisit l'outil de sa distribution.
Noyau, modules et démarrage
Section intitulée « Noyau, modules et démarrage »Le durcissement descend jusqu'au noyau et au boot : on règle les paramètres de la pile réseau et mémoire, on retire les modules inutiles 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.
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 et investiguer.
Audit et conformité
Section intitulée « Audit et conformité »Enfin, on mesure et on prouve le durcissement avec des outils d'audit et les deux référentiels de référence.
Debian/Ubuntu ou RHEL/Rocky ?
Section intitulée « Debian/Ubuntu ou RHEL/Rocky ? »Deux briques de durcissement diffèrent selon la famille de distribution, et il vaut mieux choisir la bonne dès le départ :
- 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.
Tout le reste du parcours (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.
Par où commencer ?
Section intitulée « Par où commencer ? »Sur un serveur neuf, un ordre raisonnable maximise la sécurité sans risque de blocage. 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.
La bonne mentalité
Section intitulée « La bonne mentalité »Le durcissement efficace tient en quelques principes, valables quelle que soit la distribution :
- Moindre privilège partout : chaque compte, service et règle n'a que ce dont
il a strictement besoin. Un
(root)ou unALLde trop est 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.
Valider vos acquis
Section intitulée « Valider vos acquis »Ce parcours est directement aligné sur le bloc identités, permissions, sécurité et sur les spécificités RHCSA (SELinux, firewalld, recovery). Pour vous entraîner, reproduisez chaque guide sur une VM jetable : appliquez le durcissement, vérifiez avec la commande de contrôle de chaque guide, puis lancez un audit Lynis avant/après pour mesurer la progression. Un serveur que vous savez durcir, auditer et restaurer est un serveur que vous maîtrisez.
À retenir
Section intitulée « À retenir »- Un serveur par défaut est fonctionnel mais pas sûr : le durcissement se fait par 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