Daniel Allaire
3ea0c95492
Some checks are pending
verifier / verifier (push) Waiting to run
Chezlepro rangeait ses instantanes sur une VM DE SA PROPRE FLOTTE. Raser l ecosysteme pour le reconstruire, c etait raser le filet avec. Le site a son depot ; les neuf detenteurs d etat y deposent ; une restitution est sortie (annuaire LDAP lisible, hors flotte). Isolation par compte Unix, pas par convention : home 0700, cle exclusive, racine partagee a root en 0711 (traversable, non listable). Les deux refus constates. Le site heberge du chiffre : il ne peut ni lire ni ouvrir, d ou la verification deplacee chez le locataire qui detient la cle. Quatre defauts reveles par ce deuxieme usage : - la racine des depots ne peut etre le home de personne (StrictModes rendait Permission denied publickey pour un refus de CHEMIN) - la racine nie le TLD internal, et harden-below-nxdomain etendait ce non a toute la zone sans jamais interroger l autoritatif : aucun locataire ne pouvait nommer un service du site - le gabarit transporte des fichiers de durcissement perimes, et les machines du site ne recoivent jamais ssh_hardening - MaxStartups compte les connexions non authentifiees : un depot de site en voit la somme de ses locataires Constat non corrige : les machines du site ne sont pas durcies. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
75 lines
4.5 KiB
YAML
75 lines
4.5 KiB
YAML
---
|
|
# CE RÔLE EN EXIGE UN AUTRE, ET C'EST À ANSIBLE DE LE SAVOIR.
|
|
#
|
|
# `serveur_backup_site` n'installe rien : il MARQUE un dépôt comme celui où les
|
|
# écosystèmes du site déposent leur état, et vérifie qu'il est réellement en mesure de le
|
|
# recevoir. Pour cela il lit les variables de `serveur_backup`.
|
|
#
|
|
# Les valeurs par défaut d'un rôle ne sont en portée que DANS LE PLAY QUI L'INCLUT. Une
|
|
# dépendance de rôle règle les deux choses d'un coup : Ansible applique l'installateur
|
|
# AVANT le marqueur, dans le MÊME play, donc ses variables sont en portée — et l'ordre
|
|
# cesse de dépendre de la façon dont on lance le déploiement.
|
|
#
|
|
# Même raisonnement que `serveur_cache_site`, `serveur_forge_site` et
|
|
# `serveur_resolveur_site`.
|
|
dependencies:
|
|
# EN PARAMÈTRE, PAS EN `defaults` — mesuré ici même le 2026-09-01.
|
|
#
|
|
# Une dépendance s'exécute AVANT le rôle qui la déclare, et les `defaults` du rôle
|
|
# dépendant ne sont pas encore en portée quand elle tourne. La valeur posée dans
|
|
# `serveur_backup_site/defaults` était donc lue par tout le monde SAUF par le rôle
|
|
# qu'elle visait. Passée ici, elle porte — c'est le seul endroit où elle porte.
|
|
#
|
|
# CE DÉPÔT NE PEUT PAS OUVRIR CE QU'IL GARDE, ET C'EST LE BUT. Les instantanés sont
|
|
# chiffrés par restic CHEZ LE LOCATAIRE, avec un mot de passe qui ne quitte jamais sa
|
|
# voûte. Le site héberge des octets opaques : il ne peut ni les lire, ni les ouvrir,
|
|
# ni les reconstituer. C'est la propriété qui rend la mutualisation acceptable — la
|
|
# même frontière que pour les voûtes : le site sert, il ne sait pas.
|
|
#
|
|
# La vérification n'est pas supprimée, elle est DÉPLACÉE chez celui qui peut
|
|
# l'exercer : le locataire, qui détient la clé et sait ce qu'il a envoyé.
|
|
- role: serveur_backup
|
|
serveur_backup_verification_locale: false
|
|
# LE SITE N'HABITE PAS LA RACINE DE SON PROPRE DÉPÔT.
|
|
#
|
|
# `serveur_backup` donne au compte `restic` la racine des dépôts pour home. C'est
|
|
# juste chez un écosystème : il n'y a qu'un déposant, la racine EST son home.
|
|
#
|
|
# Ici il y en a plusieurs, et la racine devient le PARENT de leurs homes. Elle ne
|
|
# peut donc appartenir à aucun d'eux — mesuré le 2026-09-01 : `/srv/restic` en 0700
|
|
# au compte `restic`, sshd a refusé `restic-chez` par `StrictModes`, qui exige que
|
|
# chaque répertoire menant au home appartienne à root ou à l'utilisateur lui-même.
|
|
# Le message rendu était « Permission denied (publickey) » — celui d'une mauvaise
|
|
# clé. La clé était la bonne ; c'est le CHEMIN qui était refusé. Rien dans ce
|
|
# message ne pouvait le dire.
|
|
#
|
|
# Le site prend donc un sous-répertoire comme tout le monde. Le parent est à root,
|
|
# traversable et non listable : voir `serveur_backup_site_parent`.
|
|
serveur_backup_racine: "/srv/restic/site"
|
|
|
|
# SSH DURCI, ET DESSERRÉ LÀ OÙ CE DÉPÔT L'EXIGE (mesuré le 2026-09-01).
|
|
#
|
|
# DEUX DÉFAUTS EN UN, TROUVÉS EN LANÇANT DOUZE SAUVEGARDES D'UN COUP.
|
|
#
|
|
# 1. Le gabarit transporte des fichiers de durcissement PÉRIMÉS — dont
|
|
# `20-chezlepro-hardening.conf`, celui-là même que `ssh_hardening_fichiers_perimes`
|
|
# existe pour retirer. Il a été figé dans l'image, donc chaque VM clonée en hérite.
|
|
# Les machines du SITE ne recevaient jamais `ssh_hardening` (leur socle est
|
|
# `serveur_debian` seul, là où un locataire reçoit aussi `serveur_durci`) : rien ne
|
|
# venait donc jamais le corriger. Le dépôt tournait avec `MaxStartups 5:30:20` et
|
|
# `MaxSessions 2`, des valeurs abandonnées depuis le 2026-08-09.
|
|
#
|
|
# 2. `MaxStartups` compte les connexions NON ENCORE AUTHENTIFIÉES. Un dépôt
|
|
# d'écosystème en voit une poignée ; celui d'un SITE en voit la somme de tous ses
|
|
# locataires, et leurs minuteurs se réveillent à la même heure. Au-delà du seuil,
|
|
# sshd coupe AVANT la bannière : le client rapporte
|
|
# `kex_exchange_identification: Connection reset by peer`, qui accuse le réseau
|
|
# pour un refus applicatif. Une sauvegarde perdue qui se lit comme un incident
|
|
# réseau ne sera pas cherchée au bon endroit.
|
|
#
|
|
# 60 : large devant la somme des flottes servies. Le port 22 de ce dépôt n'est
|
|
# atteignable que depuis les locataires déclarés (`meta/flux.yml`) ; l'inondation dont
|
|
# `MaxStartups` protège est déjà couverte à la frontière, la panne qu'il créait ne
|
|
# l'était pas. Même arbitrage que `ssh_hardening` a fait pour la voie d'administration.
|
|
- role: ssh_hardening
|
|
ssh_hardening_max_startups: "60:30:200"
|