Annuler un durcissement : les points de restauration

« Comment j'annule ? » est la question qui décide si une remédiation touchera un jour la production. Parmi les outils qui remédient, aucun n'y répond. OpenSCAP vous tend un script bash généré, sans inverse. La consigne de Canonical pour l'USG n'est pas « prenez un instantané », elle est plus brutale : « Always run the DISA-STIG hardening scripts on fresh installations of Ubuntu. » Les CIS Build Kits appliquent et ne désappliquent pas. Lynis et CIS-CAT Assessor ne remédient pas du tout : ils n'ont rien à annuler. Ce n'est pas une critique, c'est l'état de l'art, et c'est pourquoi la plupart des exploitants n'appliquent jamais une remédiation sur un hôte de production.

L'idée n'est pas neuve, et elle a déjà été tentée. Bastille Linux livrait RevertBastille vers 2003 et a disparu avec le projet ; CalCom vend un rollback en un clic dans une suite de durcissement commerciale ; HardeningKitty documente une procédure de sauvegarde et restauration sous Windows. Ce qui manque aux scanners Linux libres et adossés à des normes, c'est un inverse dont l'outil lui-même est propriétaire.

(Si vos machines sont sous NixOS ou rpm-ostree, vous avez déjà une meilleure réponse que cette page : utilisez-la. Tout ce qui suit s'adresse aux machines qui n'en ont pas.)

Pavois peut répondre, pour une raison précise : le plan est déclaratif, donc ce que le run va toucher est connu AVANT qu'il ne tourne.

Ce qu'est un point de restauration

Avant que harden apply ne converge une seule ressource, il photographie l'état antérieur de tout ce que la recette compilée nomme :

• le contenu de chaque fichier que la recette va écrire ;
• la liste des fichiers qui n'existaient pas encore : le rollback les supprime, plutôt que de restaurer un fantôme ;
• l'état installé/absent de chaque paquet qu'il va installer ou retirer ;
• l'état activé/actif de chaque service qu'il va activer, désactiver ou masquer.

Le tout atterrit dans un dossier local, et l'apply dit lequel :

./pavois harden apply --target user@host --key ~/.ssh/id --sudo-prompt --yes plan.yml
# pavois: 📸 restore point → restore-points/user_203-0-113-10-20260714-1505
#   (undo with: pavois harden rollback restore-points/user_203-0-113-10-20260714-1505 --yes)

--no-restore-point saute la photographie. Vous perdez le rollback ; l'option existe pour que le choix soit le vôtre et qu'il soit explicite.

Annuler

./pavois harden rollback restore-points/user_203-0-113-10-20260714-1505 \
  --key ~/.ssh/id --sudo-prompt --yes

Sans --yes, il affiche ce qu'il ferait puis s'arrête : combien de fichiers il restaure, combien il supprime, combien de paquets et de services il remet, et la liste des remédiations qu'il ne sait pas défaire. Lisez cette liste avant de taper --yes.

Le rollback restaure les fichiers à l'identique, supprime ceux que Pavois a créés, purge les paquets qu'il a installés (et retire ce que leur suppression laisse orphelin), remet les services, et recharge les démons. Ce dernier point n'est pas un détail : un sshd_config restauré que personne n'a rechargé n'a rien annulé. Pavois audite la configuration effective ; il restaure la configuration effective.

Ce qu'il restaure, mesuré

Sur une debian 12 neuve (image cloud Debian, 14 juillet 2026), un apply complet de 268 items, puis un rollback. C'est un run DIFFÉRENT de la campagne montrée sur le rapport d'exemple, qui est une construction golden convergée (noyau + partitions) : un rollback a besoin d'un apply unique et non convergé à défaire, donc les chiffres ci-dessous ne sont pas ceux de la campagne et ne doivent pas leur être comparés.

Le dénominateur bouge, et ce n'est pas un tour de passe-passe : un contrôle n'est évalué que s'il s'applique. Installer auditd rend applicables trente contrôles auditd qui étaient sautés avant ; le purger les rend sautables à nouveau. Lire le seul nombre de conformes n'aurait aucun sens, et c'est pourquoi la mesure ci-dessous n'est pas un nombre de conformes.

La mesure est l'identité contrôle par contrôle : sur les 620 contrôles du profil, combien finissent dans le même état (conforme / échec / non applicable) qu'avant l'apply ?

C'est le chiffre le plus strict qui doit nous être opposé. Les 23 contrôles qui divergent sont publiés, une ligne chacun, en CSV, et se rangent en quatre groupes :

Relisez la troisième ligne. Trois contrôles qui PASSAIENT avant l'apply ÉCHOUENT après le rollback. Un rollback n'est pas une opération neutre : défaire une installation laisse des traces, et sur ces trois-là, l'hôte finit légèrement moins bien qu'il n'a commencé. Rien sur cette page ne vaut grand-chose si elle le cache.

Et la réserve honnête, avant que quelqu'un d'autre ne la formule : c'est Pavois qui mesure son propre rollback avec son propre scanner. La raison d'y croire n'est pas le chiffre, c'est que les 23 exceptions sont nommées, publiées, et que chacune est vérifiable à la main sur l'hôte.

Ce qu'il ne sait pas défaire, et qu'il annonce

L'essentiel de la divergence est inhérent au fait de défaire une installation, ce ne sont pas des défauts. Chaque remédiation concernée est nommée dans le manifeste, sous irreversible, avant que vous ne confirmiez :

Un rollback est un filet, pas une machine à remonter le temps. Il ne vaut que par son honnêteté sur la différence.

« Pourquoi pas simplement un instantané ? »

Faites l'instantané. Cette fonction ne le remplace pas, et la page le dit deux fois exprès.

Mais un instantané annule toute la machine, à un instant donné. Il jette aussi tout ce qui s'est passé depuis : les logs, les écritures en base, les paquets qu'un collègue a installés, l'incident que vous étiez en train de déboguer. Sur une VM à vous, à deux heures du matin, c'est très bien. Sur un serveur qui répond au trafic depuis six heures, ce n'est pas un retour arrière, c'est une panne avec perte de données.

Un point de restauration annule un durcissement, et rien d'autre. La machine continue de tourner, garde ses logs, garde les six heures de travail. C'est un autre outil pour un autre moment, et la comparaison honnête est celle-ci :

« Puppet et Chef sont convergents : il suffit de remettre le manifeste »

C'est vrai, et vous le pouvez. Mais la convergence n'est pas un inverse : rien, dans Puppet, Chef ou Ansible, n'a capturé la valeur d'avant votre changement. « La remettre » suppose donc de la connaître, et pour 268 réglages répartis sur 45 fichiers, sur un hôte que vous n'avez pas construit, vous ne la connaissez pas. Vous écririez l'inverse à la main, de mémoire, sur une machine que vous venez de modifier.

Pavois ne vous demande pas de vous souvenir. Il a photographié.

La règle que cette fonction impose à la base de règles

Une remédiation qui installe un paquet depuis un exec (apt-get install -y acct) est invisible : elle n'apparaît pas dans le plan, l'exploitant ne l'a jamais activée, et un rollback ne peut pas la défaire. Trois règles faisaient cela, et un rollback laissait acct et sysstat derrière lui sur un hôte qu'il avait « restauré ».

Elles déclarent désormais leur paquet (requires_package), et un linter (exec-installs-package) refuse ce motif. Une remédiation qui cache ce qu'elle fait ne peut pas être annulée : elle n'a donc pas le droit de se cacher.

FAQ

Où vit le point de restauration, et contient-il des secrets ? Il est constitué sur la cible (en 0600, appartenant au compte avec lequel vous vous connectez, jamais lisible par tous), puis rapatrié sur le poste de contrôle et laissé dans restore-points/ : c'est cette copie-là que lit harden rollback. Il contient le contenu des fichiers de configuration que le run va modifier : traitez les deux copies comme sensibles, supprimez celle de la cible si cela compte pour vous, et rangez la locale là où vous rangez vos secrets.

Puis-je annuler un run vieux de plusieurs mois ? Oui, si vous avez gardé le dossier : il est autoporté (un manifeste et une archive). Il restaure l'état tel qu'il était au moment de la photographie, ce qui n'est pas la même chose que l'état d'aujourd'hui. Lisez le manifeste.

Puis-je annuler un seul contrôle ? Pas aujourd'hui. Le point de restauration vaut pour un run. La bonne réponse est de rendre le run lui-même plus fin : harden plan est opt-in règle par règle, donc appliquez ce que vous comprenez, dans une taille que vous pouvez raisonner.

Dois-je arrêter de faire des instantanés, alors ? Non. Faites l'instantané. Un rollback à 96 % est un filet pour un run qui a mal tourné, pas une assurance contre tout ce qui peut arriver à un hôte Linux.

Le rollback ne restaure-t-il que ce que l'apply a changé ? Il restaure les FICHIERS que l'apply allait écrire, à l'identique, dans leur contenu au moment de la photographie. C'est une granularité fichier, pas une granularité changement : si un collègue a édité l'un de ces fichiers entre l'apply et le rollback, son édition est écrasée aussi. Annulez tôt, ou lisez d'abord la liste de fichiers du manifeste.

À retenir

• harden apply photographie l'état antérieur avant de converger, et harden rollback le remet : fichiers, paquets, services, et un rechargement des démons pour que la restauration soit EFFECTIVE.
• Mesuré sur un hôte réel : 597 des 620 contrôles reviennent à un état identique (96 %), et les 23 qui n'y reviennent pas sont publiés, une ligne chacun. Trois d'entre eux PASSAIENT avant et ÉCHOUENT après : un rollback n'est pas une opération neutre.
• Ce qui ne peut pas être défait est nommé dans le manifeste avant confirmation : un montage déjà fait, un chmod piloté par find, l'utilisateur qu'une purge supprime, l'outil qu'un retrait emporte.
• Parmi les outils qui remédient (OpenSCAP, l'USG d'Ubuntu, les CIS Build Kits, ansible-lockdown), aucun ne livre l'inverse de sa propre remédiation (Lynis et CIS-CAT Assessor ne remédient pas : ils n'ont rien à annuler). Bastille Linux a essayé en 2003 et a disparu ; CalCom le vend en commercial. Pavois le livre, et la raison est structurelle : un plan déclaratif rend le rayon d'action connaissable avant que quoi que ce soit ne tourne.

Soyons clairs sur ce que cela ne prétend PAS. Là où vous disposez d'instantanés au niveau du système de fichiers ou de l'image (LVM, ZFS, btrfs, un instantané de VM, les générations NixOS, rpm-ostree rollback), ceux-là sont strictement meilleurs et vous devez les utiliser : ils sont exacts, totaux, et ne dépendent de l'énumération de rien. Un point de restauration existe pour les machines qui n'en ont pas, et pour vous dire, avant de converger, ce que le run va toucher.

Prochaines étapes

• Démarrer · Exploiter Pavois · Preuves & exports