Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
89 lines
4.1 KiB
Markdown
89 lines
4.1 KiB
Markdown
# Sécurité & durcissement
|
|
|
|
> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.
|
|
|
|
---
|
|
|
|
## ① Le concept *(générique)*
|
|
|
|
Sécuriser un système, ce sont quelques principes qui se combinent :
|
|
- **Défense en profondeur** : plusieurs couches — si l'une cède, les autres tiennent.
|
|
- **Moindre privilège** : chacun (compte, service) n'a **que** les droits nécessaires.
|
|
- **Réduction de la surface d'attaque** : moins de services exposés = moins de portes.
|
|
- **Contrôle d'accès obligatoire (MAC)** : le noyau confine chaque programme (AppArmor/SELinux).
|
|
- **Audit** : tracer les événements sensibles pour pouvoir enquêter.
|
|
- **Anti-force-brute** : bloquer les tentatives répétées (fail2ban).
|
|
- **Pare-feu** : filtrer le trafic réseau.
|
|
- **Mises à jour** : combler les failles connues, automatiquement.
|
|
|
|
Aucune de ces couches ne suffit seule. Ensemble, elles rendent l'intrusion **coûteuse**.
|
|
|
|
---
|
|
|
|
## ② Comment Set-OPS le fait
|
|
|
|
Le **durcissement fait partie du socle** — il tourne sur **chaque** nœud (via `serveur_durci`),
|
|
pas en option :
|
|
|
|
| Couche | Rôle Set-OPS |
|
|
|---|---|
|
|
| MAC | `apparmor` |
|
|
| Audit | `auditd` |
|
|
| Anti-force-brute SSH | `fail2ban_ssh` |
|
|
| Durcissement noyau | `sysctl_hardening` |
|
|
| Pare-feu | `nftables_baseline` — **règles dérivées du registre des flux**, pas écrites à la main |
|
|
| Mises à jour | `unattended_upgrades` |
|
|
| Journaux | `journald` (rétention, persistance) |
|
|
| Vidages mémoire | `core_dumps` (désactivés — un *core* peut contenir des secrets) |
|
|
| Paquets | `hardening_packages` |
|
|
| SSH | `ssh_baseline` + `ssh_hardening` (clé d'abord, `PermitRootLogin no`…) |
|
|
| Moindre privilège | compte technique `ansible` + `sudo_ansible` (pas de root direct) |
|
|
|
|
Le groupe `serveur_durci` compose **dix** de ces rôles en un seul geste ; `ssh_baseline` et
|
|
`sudo_ansible` viennent du socle `serveur_debian`, en amont.
|
|
|
|
**Le pare-feu : préparé dans le gabarit, armé sur la flotte.** `nftables_baseline` vaut
|
|
`false` par défaut *dans le rôle* — couper l'accès à l'aveugle pendant la construction d'un
|
|
gabarit serait un risque gratuit. Mais l'instance le met à `true` pour `hotes_actifs` : sur
|
|
une machine réelle, **le pare-feu tourne**.
|
|
|
|
Et ses règles ne s'écrivent pas à la main. Chaque rôle déclare dans son `meta/flux.yml` ce
|
|
qu'il écoute et ce à quoi il se connecte ; `scripts/resoudre_flux.py` en dérive le jeu de
|
|
règles, en `policy drop` par défaut. Le **même** registre alimente le pare-feu de
|
|
l'hyperviseur et la frontière OPNsense : trois couches qui ne *peuvent pas* se contredire,
|
|
parce qu'elles descendent d'une seule décision. C'est la défense en profondeur du §① prise
|
|
au mot — sans le coût habituel, qui est de tenir trois politiques cohérentes à la main.
|
|
|
|
---
|
|
|
|
## ③ Pourquoi c'est transférable
|
|
|
|
| Set-OPS | Équivalents ailleurs |
|
|
|---|---|
|
|
| AppArmor | SELinux · les *security modules* Linux |
|
|
| fail2ban / auditd / sysctl | outils **standards** de tout durcissement Linux |
|
|
| démarche par couches | **CIS Benchmarks**, ANSSI, guides d'OS — mêmes principes |
|
|
|
|
Tu as appris **la défense en profondeur, le moindre privilège, MAC, l'audit** — pas « AppArmor ».
|
|
|
|
---
|
|
|
|
## ④ À toi de jouer
|
|
|
|
1. **Constate les couches** (sur n'importe quel nœud) :
|
|
```bash
|
|
aa-status | head # AppArmor : profils chargés
|
|
systemctl is-active auditd fail2ban
|
|
sysctl net.ipv4.conf.all.rp_filter # un durcissement noyau parmi d'autres
|
|
```
|
|
2. **Moindre privilège** : `PermitRootLogin` est à `no`, l'accès se fait par le compte `ansible` +
|
|
clé SSH. Vérifie : `sshd -T | grep -E 'permitrootlogin|passwordauthentication'`.
|
|
3. **Casse & répare (avec prudence, en lab).** Assouplis **un** réglage sysctl, observe, puis
|
|
**remets-le**. Tu *sens* que chaque ligne de durcissement ferme une porte précise.
|
|
|
|
---
|
|
|
|
## Pour aller plus loin *(dépôt)*
|
|
- Rôles du socle durci : `roles/apparmor`, `auditd`, `fail2ban_ssh`, `sysctl_hardening`,
|
|
`nftables_baseline`, `ssh_hardening`, `unattended_upgrades`…
|
|
- Actions destructives (SSH, pare-feu) exigent une **confirmation explicite** : voir `CLAUDE.md`/`AGENTS.md`.
|