Pavois : auditer la configuration que vos services appliquent

Pavois audite la configuration qu'un serveur Linux applique réellement, pas le texte de ses fichiers. Il interroge sshd -T, sysctl et systemctl show, note chaque contrôle de A à E, puis produit un plan de durcissement que rien n'applique tant que vous ne l'avez pas armé, règle par règle.

Ce guide installe l'outil en vérifiant ce qu'il installe, lance un premier scan sur une machine neuve, et explique comment lire le grade obtenu. Il s'adresse à qui administre des serveurs Linux et doit démontrer une conformité CIS, ANSSI-BP-028, NIST, PCI-DSS ou STIG.

Ce que vous allez apprendre

Comprendre ce que « configuration effective » change par rapport à un scan de fichiers.
Installer le binaire en vérifiant son empreinte et sa provenance de build.
Lancer un premier scan et obtenir un rapport noté.
Lire la ventilation du grade, qui sépare ce qui se corrige de ce qui ne se corrige pas.
Produire un plan de durcissement sans rien modifier sur la machine.

Prérequis

Un serveur Linux parmi les neuf systèmes couverts : Debian 12 et 13, Ubuntu 22.04, 24.04 et 26.04, RHEL 8, 9 et 10 avec leurs dérivés Rocky et AlmaLinux, et Fedora. Un accès sudo, et le moteur CINC Auditor, traité plus bas.

Pourquoi auditer l'effectif plutôt que les fichiers

C'est la thèse de l'outil, et elle tient dans un cas concret. Un scanner classique lit /etc/ssh/sshd_config, y trouve PermitRootLogin no, et conclut que la machine est conforme.

Mais sshd ne lit pas que ce fichier. Un Include /etc/ssh/sshd_config.d/* en tête, un fragment déposé par un paquet ou par un outil de configuration, et la directive effective devient l'inverse de celle que vous venez de lire. Seul sshd -T, qui affiche la configuration que le démon applique, tranche.

Pavois interroge donc l'état effectif : sshd -T pour SSH, sysctl pour le noyau, systemctl show pour les services, auditctl pour l'audit. Ce que l'attaquant rencontre, c'est cet état, jamais le texte sur le disque.

Le corpus couvre SSH, PAM, le contrôle d'accès obligatoire SELinux et AppArmor, le pare-feu local, sudo, les permissions, les montages, les modules noyau, auditd, la journalisation, les services systemd, les paquets, GRUB et la synchronisation horaire.

Installer Pavois sans faire confiance au hasard

Pavois est un binaire statique unique. Chaque release publie les sommes de contrôle, un SBOM CycloneDX, une provenance SLSA et une signature Cosign. Un outil de durcissement qu'on installe sans vérifier commence mal :

gh release download --repo stephrobert/pavois \
  --pattern 'pavois-linux-amd64' --pattern 'checksums.txt'
sha256sum --ignore-missing --check checksums.txt
gh attestation verify pavois-linux-amd64 --repo stephrobert/pavois
chmod +x pavois-linux-amd64
sudo mv pavois-linux-amd64 /usr/local/bin/pavois

La vérification d'attestation doit rendre une provenance qui pointe le tag de la version, ici refs/tags/v0.1.3, et le workflow qui l'a construite. Si elle échoue, le binaire ne vient pas de la chaîne de publication annoncée.

Le moteur d'exécution : CINC Auditor

Pavois n'embarque pas son moteur d'exécution. Il s'appuie sur CINC Auditor, le build libre de Chef InSpec, qui exécute les contrôles sur la cible. Le corpus de règles, lui, est bien dans le binaire.

Sur une machine qui ne l'a pas, pavois doctor refuse de travailler et le dit. L'installation se fait par le paquet officiel, empreinte vérifiée, jamais par un script téléchargé et exécuté à la volée :

META=$(curl -fsSL "https://omnitruck.cinc.sh/stable/cinc-auditor/metadata?p=ubuntu&pv=24.04&m=x86_64")
URL=$(printf '%s\n' "$META" | awk '/^url/ {print $2}')
SHA=$(printf '%s\n' "$META" | awk '/^sha256/ {print $2}')
curl -fsSL "$URL" -o cinc-auditor.deb
echo "$SHA  cinc-auditor.deb" | sha256sum --check -
sudo dpkg -i ./cinc-auditor.deb

Version installée lors de la rédaction : CINC Auditor 7.2.1.

Le diagnostic confirme ensuite que tout est en place :

pavois doctor

  [OK  ] norm catalogue         6 standard(s)
  [OK  ] baseline identity      Pavois Effective-Configuration Hardening Baseline 0.2.0, released 2026-06-26
  [OK  ] audit ruleset          62 rule(s)
  [OK  ] behavioral probes      8 probe(s)
  [OK  ] local OS detected      ubuntu 24.04

ready: try: pavois scan local --sudo

Lancer le premier scan

Une seule commande, en lecture seule. Elle prend plusieurs minutes, le temps d'évaluer les centaines de contrôles du corpus :

pavois scan local --sudo

Sur une Ubuntu 24.04 fraîchement installée, sans aucun durcissement, le résultat est sans appel :

  Grade E  Critical · runtime-qualified
  252/544 controls passing

    auto          E  181/408 passing
    manual        B   32/39  passing  (no auto-remediation)
    dangerous     C    2/7   passing  (high-risk remediation)
    install-time  C    1/34  passing  (architecture, e.g. a separate partition)
    kernel-build  C   36/56  passing  (needs a kernel rebuild)

  Remediable posture: grade E (215/454, excludes install-time + kernel-build)

Un rapport HTML autonome est écrit à côté, couvrant 652 contrôles et 5 standards. Les trois écarts les plus graves sont remontés en tête, et sur une installation par défaut ce sont toujours les mêmes : ssh-disable-empty-passwords et ssh-disable-root-login arrivent en critique.

Lire le grade, et surtout sa ventilation

Le chiffre global ne sert à rien seul, la ventilation fait tout le travail. C'est ce qui distingue Pavois d'un pourcentage de conformité classique.

Classe	Ce qu'elle regroupe
`auto`	Ce qu'une remédiation sait corriger toute seule
`manual`	Ce qui demande une décision humaine, sans correction automatique
`dangerous`	Ce dont la correction peut casser un service ou vous verrouiller
`install-time`	Ce qui se décide à l'installation, comme une partition séparée
`kernel-build`	Ce qui exige un noyau recompilé

La ligne « Remediable posture » exclut les deux dernières classes, et c'est la seule qui réponde à la question utile : que puis-je corriger ce soir, sur cette machine, sans la réinstaller ni recompiler son noyau ?

La mention runtime-qualified compte autant. Un contrôle qui passe « maintenant » sans survivre à un redémarrage plafonne la note tant que la persistance n'est pas prouvée. Une conformité qui disparaît au reboot n'en est pas une.

Du constat au plan de durcissement

Pavois ne se contente pas de mesurer. La commande harden plan produit un fichier de remédiation à partir du scan :

pavois harden plan local

pavois: plan → hardening-plan-ubuntu2404.yml  (compliant 252 · gaps 292 · n/a 108 · baseline installs 3)
pavois: every gap is off by design. Flip `apply: true` per rule, or re-plan with --enable auto

Rien n'est armé par défaut, et c'est le bon choix : le plan se relit, règle par règle, et chaque correction voulue passe à apply: true. Les règles capables de vous couper l'accès portent une ligne danger: et exigent en plus un acknowledged: true.

L'en-tête du fichier signale les deux pièges classiques, le pare-feu en refus par défaut et la restriction des utilisateurs SSH, avec les clés qui permettent de garder son propre accès en restreignant celui des autres. Lisez-les avant d'armer quoi que ce soit.

Sur une Debian 13 équivalente, le même binaire rend un plan comparable : 229 conformes, 276 écarts, 114 sans objet.

Ce que Pavois ne remplace pas

Pavois mesure la configuration d'un système. Il ne lit ni le code de vos applications, ni le contenu de vos images de conteneurs, ni la posture de votre chaîne de production logicielle. Pour ces périmètres, les outils du site restent les bons : Trivy sur les images, CINC Auditor pour vos propres profils, OpenSCAP quand un référentiel SCAP officiel est exigé par un auditeur, et Lynis pour un premier état des lieux sans installation de moteur.

Le projet est jeune : la version documentée ici est la 0.1.3. Le manuel complet et le catalogue de règles vivent sur www.pavois.dev.

À retenir

Pavois audite la configuration effective (sshd -T, sysctl, systemctl show), pas le texte des fichiers, ce qui attrape les fragments qui écrasent silencieusement une directive.
Le binaire est statique et vérifiable : sommes de contrôle, SBOM, provenance SLSA et signature Cosign à chaque release.
Le moteur CINC Auditor n'est pas embarqué et s'installe à part, empreinte vérifiée.
La ventilation du grade vaut mieux que le grade : la ligne « remediable » dit ce qui est corrigeable sans réinstaller ni recompiler.
Un contrôle non persistant plafonne la note : ce qui ne survit pas au redémarrage ne compte pas.
harden plan produit un plan entièrement désarmé : chaque correction s'active à la main, et les plus risquées demandent une confirmation de plus.
Une Ubuntu 24.04 par défaut obtient un grade E, avec 252 contrôles conformes sur 544. C'est la situation normale d'une installation neuve.

Prochaines étapes

Durcir les configurations Linux Les principes, les référentiels et les étapes clés

ANSSI-BP-028 Le référentiel français de durcissement, recommandation par recommandation

CIS Benchmarks Les niveaux 1 et 2, et ce qu'ils impliquent en production

CINC Auditor Le moteur qui exécute les contrôles, et vos propres profils