Sections du handbook

Pourquoi on durcit

Revu le

Une installation neuve livre des réglages permissifs. Durcir réduit la surface d'attaque et le rayon d'impact d'une compromission, et rend le système auditable et reproductible.

Pourquoi une installation Linux par défaut est-elle peu sûre ?

Une image de distribution est conçue pour une compatibilité large et un premier démarrage sans accroc, pas pour la sécurité. Une installation neuve livre donc des réglages permissifs : services inutilisés à l'écoute sur le réseau, modules noyau de systèmes de fichiers et protocoles obsolètes chargeables à la demande, politique de mot de passe faible, aucune piste d'audit, fichiers lisibles par tous, pas de pare-feu hôte. Chacun est un point d'entrée. L'attaquant n'a pas besoin d'un zero-day : c'est la configuration par défaut qui est la vulnérabilité, et ce même défaut est répliqué à l'identique sur chaque machine déployée. Le NIST SP 800-123 le dit clairement : un serveur doit être configuré sur une base sécurisée, car les réglages d'origine privilégient l'ergonomie sur la sécurité.

Pourquoi durcir

Durcir, c'est retirer délibérément tout ce dont on n'a pas besoin et resserrer tout ce que l'on garde. Deux choses se réduisent en même temps :

  • La surface d'attaque : moins de services actifs, moins de modules chargeables, moins de fonctions activées, donc moins de chemins d'entrée (NIST CM-7, fonctionnalité minimale).
  • Le rayon d'impact : quand un processus est compromis, le moindre privilège, les restrictions de montage, les mitigations noyau et une posture sudo/audit serrée limitent sa propagation et le temps qu'il reste invisible.

Le coût de NE PAS durcir est asymétrique : invisible jusqu'à l'incident, puis c'est toute la machine (mouvement latéral, exfiltration, persistance) sans compter les conséquences réglementaires et réputationnelles. Durcir rend aussi un système auditable (on peut prouver, règle par règle, dans quel état il se trouve) et reproductible (la même base sécurisée s'applique à l'identique à chaque hôte, au lieu de machines ajustées à la main qui dérivent).

Menace, contrôle Pavois, norme

Chaque règle répond à une menace concrète et porte ses correspondances de normes. Cinq exemples représentatifs :

Réglage permissif par défaut Menace concrète Contrôle Pavois Norme
PermitRootLogin yes bruteforce distant directement vers root ssh-disable-root-login CIS 5.1.x, ANSSI BP-028 R33, STIG
sudo sans mot de passe, pas de use_pty un compte cassé devient root, détournement de session règles sudo CIS 5.2.x, ANSSI BP-028 R39
ASLR désactivé, redirects ICMP acceptés exploits fiables, détournement de trafic on-path règles sysctl CIS 3.x, NIST SC-7, ANSSI BP-028 R8
pas de piste d'audit (auditd éteint) actions privilégiées non imputables règles auditd CIS 4.1.x, NIST AU-2, ANSSI BP-028 R73
fichier modifiable par tous, SUID parasite élévation de privilèges locale, injection de config règles permissions CIS 6.1.x, ANSSI BP-028 R50

Les principes de défense derrière chaque règle

Chaque règle Pavois découle d'un petit ensemble de principes de défense : moindre privilège, réduction de la surface d'attaque, défense en profondeur, réglages sûrs par défaut, traçabilité et reproductibilité. Les normes encodent les mêmes idées : NIST 800-53 CM-6 (réglages de configuration) et CM-7 (fonctionnalité minimale), ANSSI BP-028, et les CIS Benchmarks.

Ce que Pavois audite, et comment voir votre propre posture

Pavois vérifie cette surface au regard de la configuration effective, ce que le noyau et les démons ont réellement résolu à l'exécution, et non les fichiers sur disque. Il lit sysctl -a, systemctl show, sshd -T, l'état des modules chargés et la base des paquets, et voit donc les Include, drop-ins et surcharges runtime qu'un scan par fichier (OVAL/oscap) rate, évitant les faux négatifs et les faux positifs. Une seule commande note l'hôte et rattache chaque résultat à ses chapitres de norme :

pavois scan local --profile profiles/linux/debian12 --standard cis --sudo  # note A-E + detail par regle, mappe sur CIS/ANSSI/NIST/STIG

Voyez exactement ce qui est couvert et ce qui ne l'est pas, et parcourez la base de règles complète. Le durcissement devient un rapport noté, filtrable et reproductible plutôt qu'une checklist.

FAQ

Durcir, est-ce la même chose qu'une checklist de durcissement ? Non. Une checklist est une liste d'étapes ; une base de référence est l'état final mesurable que l'on peut vérifier et reproduire. Pavois audite la base (l'état effectif), donc vous prouvez la conformité au lieu de croire qu'un script s'est exécuté.

Durcir casse-t-il des choses ? Cela le peut, appliqué à l'aveugle : un noexec /tmp peut casser les mises à jour de paquets, un sysctl trop strict peut casser un routeur. C'est pourquoi chaque page de domaine documente les exceptions, et pourquoi on teste en pré-production avant d'appliquer.

Par où commencer ? Par les gains à fort impact et faible risque : désactiver le SSH root, imposer mot de passe sudo et use_pty, activer auditd, poser les mitigations sysctl du noyau, verrouiller les permissions de fichiers. La page de couverture montre où Pavois est profond.