# serveur_durci

**Rôle-catégorie** du durcissement : il ne porte **aucune tâche**. Son unique contenu est
`meta/supervision.yml` — la déclaration de la sonde `audit`.

## Pourquoi un rôle sans tâches

La dérivation de supervision agrège les `roles/<rôle>/meta/supervision.yml` **par nom de
groupe**. Déclarée dans `roles/auditd/`, qui est un rôle-tâche et non un groupe, la sonde
serait restée invisible d'Icinga — et le ménage de `client_sante` l'aurait effacée au
passage suivant. Même leçon que la sonde `correctifs`, déplacée de `common_packages` vers
`serveur_debian` le 2026-09-10.

Le fichier est déposé par `roles/auditd/` ; il est **déclaré** ici. La preuve **P64** garde
les deux moitiés ensemble.

## Le travail réel

Il est fait par le playbook du groupe, `playbooks/groupes/serveur_durci.yml`, qui applique
dans l'ordre :

| Rôle | Apport |
| --- | --- |
| `hardening_packages` | Paquets de durcissement |
| `sysctl_hardening` | Paramètres noyau |
| `core_dumps` | Vidages mémoire désarmés |
| `unattended_upgrades` | Mises à jour automatiques **masquées** (voir la sonde `correctifs`) |
| `apparmor` | Confinement des services |
| `auditd` | Piste d'audit : règles, rétention, sonde |
| `fail2ban_ssh` | Bannissement des tentatives SSH |

## La sonde `audit`

Elle mesure la **collecte**, pas l'armement — et c'est tout son objet. Le 2026-08-30, sur
les quinze machines de Chezlepro, `auditctl -l` affichait onze règles armées dans le noyau
pendant qu'`auditd` était mort : un doublon dans `rules.d/` faisait échouer
`audit-rules.service`, dont le démon dépend. Une sonde qui aurait compté les règles aurait
dit « vert » pendant toute la panne.

Le nombre de règles part donc en **perfdata**, jamais en verdict — pour que le diagnostic
distingue « rien d'armé » de « armé mais rien de collecté ».