Sections du handbook▾
Fondations
Comprendre les menaces qui pèsent sur un hôte LinuxPourquoi on durcitLes principes de défense derrière chaque règleConfiguration effective : la vérité qu'aucun fichier ne contientLes normes que Pavois cartographieModèle d'identifiant de contrôle SOCLEPreuves & exportsComment la note A-E est calculéeCe qu'un PASS prouve : le verdict qualifiéModèle de confiance du bundle de preuveSOCLE, n'est-ce pas votre propre norme ? (gouvernance & la question de la circularité)Ce que Pavois couvre, et ce qu'il ne couvre pasDomaines
Durcir SSHDurcir PAMContrôle d'accès obligatoire (SELinux / AppArmor)Durcir le pare-feu localDurcir sudoPermissions et propriété des fichiersDurcir les montages et le système de fichiersDurcir les modules noyauDurcir le noyau et le réseau avec sysctlJournalisation d'audit avec auditdDurcir la journalisation avec journald et rsyslogDurcir les services systemdHygiène des paquetsDurcir le chargeur d'amorçage (GRUB)Synchroniser l'heureBannières de connexion et MOTDContrôler l'accès à cron et atDurcir le bureau GNOME (dconf)Outillage
Annuler un durcissement : les points de restaurationExploiter Pavois : privilèges, air-gap, durée, dérogationsLancer Pavois en CI (GitHub Actions)État des fonctionnalités : livré, partiel, roadmapGouvernance : licence, versionnement, provenance, sécurité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/STIGVoyez 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.