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
56 lines
2.8 KiB
YAML
56 lines
2.8 KiB
YAML
---
|
|
auditd_enabled: true
|
|
|
|
# LES FICHIERS QU'UNE NOMENCLATURE ABANDONNEE A LAISSES DERRIERE ELLE.
|
|
#
|
|
# Ce role a porte le nom `chezlepro` avant de porter celui du moteur. Le renommage a
|
|
# change le fichier DEPOSE sans retirer le precedent — meme mue que `ssh_baseline`, meme
|
|
# registre, et une consequence PIRE ici.
|
|
#
|
|
# `augenrules` CONCATENE tout `rules.d/`. Deux fichiers portant la meme regle la
|
|
# presentent donc deux fois au noyau, qui refuse la seconde :
|
|
#
|
|
# Error sending add rule data request (Rule exists)
|
|
# There was an error in line 16 of /etc/audit/audit.rules
|
|
#
|
|
# `audit-rules.service` echoue, et `auditd.service` ne demarre pas — c'est sa dependance.
|
|
# Resultat mesure le 2026-08-30 sur les quinze machines de Chezlepro : ONZE REGLES
|
|
# ARMEES DANS LE NOYAU, ET PERSONNE POUR COLLECTER. `auditctl -l` les affiche, ce qui
|
|
# donne toutes les apparences d'un audit qui fonctionne.
|
|
#
|
|
# On n'ajoute a cette liste que des noms qu'on a REELLEMENT deposes un jour : retirer un
|
|
# fichier qu'on n'a jamais ecrit serait s'arroger le droit de supprimer la configuration
|
|
# de quelqu'un d'autre.
|
|
auditd_fichiers_perimes:
|
|
- 99-chezlepro.rules
|
|
|
|
# RETENTION LOCALE : UN TAMPON, PLUS UNE ARCHIVE (2026-09-11).
|
|
#
|
|
# Debian livre 8 Mo x 5 fichiers = 40 Mo. Mesure sur `infra-edge-01` au repos,
|
|
# deploiement termine : 3 380 octets en 60 s, soit ~4,6 Mo/jour. Les 40 Mo tiennent
|
|
# donc environ NEUF JOURS — sauf qu'une reconstruction a elle seule en brule 4 Mo : les
|
|
# trois du 2026-09-10 auraient mange trois jours de piste.
|
|
#
|
|
# CE QUI CHANGE LE RAISONNEMENT : depuis aujourd'hui, Alloy expedie `audit.log` vers Loki
|
|
# (`client_journal`). L'archive n'est plus ici — elle est chez le collecteur, hors de la
|
|
# machine auditee, ce qui est le seul endroit ou elle ait une valeur de preuve. Ce qui
|
|
# reste en local n'est plus qu'un TAMPON : de quoi traverser une panne de Loki sans
|
|
# perdre la piste.
|
|
#
|
|
# 16 Mo x 8 = 128 Mo, soit ~28 jours au repos. Sur un disque de 40 Go c'est negligeable,
|
|
# et ca couvre largement toute indisponibilite plausible du collecteur.
|
|
#
|
|
# CE CHOIX EST UNE DECISION D'EXPLOITATION, pas une derivation : deux lignes a changer si
|
|
# la mesure du debit evolue.
|
|
auditd_max_log_file: 16 # Mo par fichier
|
|
auditd_num_logs: 8 # fichiers conserves
|
|
|
|
# SONDE « audit » — AGE MAXIMAL TOLERE SANS UNE SEULE ECRITURE.
|
|
#
|
|
# Repose sur une observation, et il faut le savoir : le journal bouge meme SANS activite
|
|
# humaine. La regle `time-change` capte les ajustements d'horloge (218 evenements sur la
|
|
# premiere heure d'une machine neuve), et les sessions `sudo` du deploiement le reste du
|
|
# temps. Une heure de silence COMPLET n'est donc pas un creux normal : c'est soit
|
|
# `disk_full_action = SUSPEND` qui a mordu, soit la collecte qui s'est arretee sans que le
|
|
# service meure.
|
|
auditd_sonde_age_max: 3600
|