Daniel Allaire
5f5af70a9c
auditd tournait, onze regles etaient armees, et rien de tout cela ne servait a grand-chose. Quatre manques, mesures avant d etre combles. 1. Rien ne sortait. Alloy ne contenait aucune reference a l audit et les cinq greffons etaient inactifs. Il lit maintenant audit.log et le pousse vers Loki — sans toucher une permission, alloy etant deja dans le groupe adm. On ecarte le greffon syslog : journald limite le debit, et une rafale d evenements est exactement le moment qui compte. 2. Aucune sonde. Elle mesure la COLLECTE, pas l armement : le nombre de regles est precisement le chiffre qui restait bon pendant la panne du 2026-08-30. Il part en perfdata, jamais en verdict. 3. Retention non declaree. Mesuree a 4,6 Mo/jour au repos ; portee de 40 a 128 Mo. Depuis (1), le local n est plus l archive mais un tampon. 4. Les regles ignoraient la cle privee de l hote. -w /etc/step/ partout, et -w /etc/step-ca/ sur la seule autorite : auditctl refuse un watch vers un chemin absent et fait echouer le chargement entier. Verifie sur l autorite seule d abord, puis 14/14 : regles armees, auditd actif, sonde a 0, et les quatorze hotes presents dans Loki sous job=audit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
41 lines
1.8 KiB
Markdown
41 lines
1.8 KiB
Markdown
# 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é ».
|