2026-06-24 20:17:46 -04:00
|
|
|
# Managed by Ansible — Set-OPS
|
|
|
|
|
-D
|
|
|
|
|
-b 8192
|
|
|
|
|
-f 1
|
|
|
|
|
|
|
|
|
|
-w /etc/passwd -p wa -k identity
|
|
|
|
|
-w /etc/group -p wa -k identity
|
|
|
|
|
-w /etc/shadow -p wa -k identity
|
|
|
|
|
-w /etc/gshadow -p wa -k identity
|
|
|
|
|
-w /etc/sudoers -p wa -k sudoers
|
|
|
|
|
-w /etc/sudoers.d/ -p wa -k sudoers
|
|
|
|
|
-w /etc/ssh/sshd_config -p wa -k sshd
|
|
|
|
|
-w /etc/ssh/sshd_config.d/ -p wa -k sshd
|
|
|
|
|
-w /etc/apt/ -p wa -k apt-config
|
|
|
|
|
|
audit : la piste sort de la machine auditee, et quelqu un regarde
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
2026-09-11 09:00:28 -04:00
|
|
|
# LE MATERIEL QUI SIGNE TOUT LE RESTE (2026-09-11).
|
|
|
|
|
#
|
|
|
|
|
# Les regles ci-dessus surveillent les fichiers par lesquels on prend un compte. Celles-ci
|
|
|
|
|
# surveillent ce par quoi on prend une IDENTITE DE MACHINE : `/etc/step/certs/` porte la
|
|
|
|
|
# cle privee de l'hote. Qui la copie parle ensuite au nom de la machine devant toute la
|
|
|
|
|
# flotte — PostgreSQL en `verify-full`, Loki, l'annuaire — sans jamais toucher a un
|
|
|
|
|
# mot de passe ni declencher une seule des regles precedentes.
|
|
|
|
|
-w /etc/step/ -p wa -k pki
|
|
|
|
|
{% if 'serveur_step_ca' in group_names %}
|
|
|
|
|
|
|
|
|
|
# LA RACINE DE CONFIANCE, ET ELLE N'EXISTE QUE SUR L'AUTORITE.
|
|
|
|
|
#
|
|
|
|
|
# `/etc/step-ca/` contient `password.txt` et `secrets/` : de quoi emettre un certificat
|
|
|
|
|
# valide pour N'IMPORTE QUEL nom de l'ecosysteme. C'est le seul secret dont la copie ne
|
|
|
|
|
# se repare pas par une rotation — il faut refaire la PKI entiere.
|
|
|
|
|
#
|
|
|
|
|
# LA GARDE EST CONDITIONNELLE, ET CE N'EST PAS UN DETAIL : `auditctl` REFUSE un `-w` vers
|
|
|
|
|
# un chemin absent, et `augenrules` fait alors echouer le chargement ENTIER. Poser cette
|
|
|
|
|
# ligne sur les treize machines qui ne sont pas l'autorite rejouerait exactement la panne
|
|
|
|
|
# du 2026-08-30 — regles armees, personne pour collecter.
|
|
|
|
|
-w /etc/step-ca/ -p wa -k pki-autorite
|
|
|
|
|
{% endif %}
|
|
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time-change
|
|
|
|
|
-a always,exit -F arch=b64 -S sethostname,setdomainname -k system-locale
|
|
|
|
|
|
|
|
|
|
-e 1
|
