docs: backup restic remis en place, cron Nextcloud réparé, plan de migration

- Backup : l'ancien Duplicity (2020) ne tournait plus ; remplacé par restic
  vers OVH Swift (script versionné dans backup/restic-backup.sh, cron 03:30),
  premier snapshot complet et restauration testés le 2026-10-03
- Nextcloud : cron en panne depuis le 2026-08-09 (DNS overlay perdu) corrigé ;
  rétention corbeille/versions à "auto, 30"
- Incident Gitea : vérification de non-réinfection, mouvement latéral et
  intégrité de l'hôte (rien trouvé)
- plan-migration.md : état des lieux, décisions à prendre, phases

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

incidents/2026-09-14-gitea-cryptominer.md

@@ -106,13 +106,49 @@ La mise à jour CapRover de `DB_PASSWD` faite plus tôt (rotation des secrets, c
 
 **Leçon** : toute mise à jour via `POST /user/apps/appDefinitions/update` doit **toujours renvoyer l'intégralité des champs de la définition actuelle** (récupérés via un `GET /user/apps/appDefinitions` juste avant), pas seulement le(s) champ(s) qu'on veut changer — l'API ne fait pas de merge partiel, elle remplace.
 
+## Vérification de non-réinfection — 2026-10-03
+
+Contrôle en lecture seule, ~10 jours après le nettoyage. **Aucun signe de nouvelle compromission.**
+
+- `.gitconfig` propre (aucun `packObjectsHook`/`fsmonitor`/`sshCommand`/`hooksPath`, ni faux commentaire `;#router:`) ; seules occurrences dans le backup `.bak-20260922234958`
+- Aucun fichier IOC (`p0_*.sh`, `.sys_health*`, `.wp_s2*`, `.s3w`…) dans le conteneur, sur l'hôte ni dans `/var/lib/docker/volumes`
+- Processus du conteneur : uniquement `s6`, `gitea web`, `sshd` ; crontab Alpine par défaut
+- Hooks des 22 dépôts identiques entre eux et générés par Gitea (`# AUTO GENERATED BY GITEA`), aucun modifié depuis le nettoyage ; `config` des dépôts sans clé suspecte
+- Logs Gitea (conservés depuis le 2026-09-26) : aucun appel `add-logger`, seuls des appels internes légitimes (`/api/internal/ssh/.../update` depuis `10.0.0.2`), aucune mention `solarvest`/`moneroocean`/`hashvault`/`xmrig`
+- Hôte : load average 0,56, aucun processus gourmand, aucune connexion vers des ports de pools ; crontabs système inchangées depuis 2021-2022
+
+Limites : les logs du 23 au 25/09 ont été perdus par rotation ; vérification ciblée sur ce mode opératoire, ne remplace pas le scan antirootkit ci-dessous.
+
+## Mouvement latéral et intégrité de l'hôte — 2026-10-03
+
+Contrôle en lecture seule. **Aucun signe de mouvement latéral ni de compromission de l'hôte.**
+
+Surface d'évasion depuis Gitea :
+- Conteneur Gitea non privilégié, sans `CapAdd`, sans PID/réseau hôte, seul montage = son volume de données → pas d'accès direct à l'hôte
+- Seul conteneur montant `docker.sock` : `captain-captain` (CapRover, normal)
+
+Autres conteneurs :
+- Aucun processus suspect dans les ~40 conteneurs (faux positifs vérifiés : `p0f` dans `mail` = fingerprinting poste.io ; `jetty` dans `scenari`)
+- Aucun conteneur gourmand en CPU (max ~2 %)
+- Aucun fichier IOC ni chaîne IOC (`solarvest`, `moneroocean`, `hashvault`, `packObjectsHook`) dans les volumes, `/captain` ou les couches inscriptibles ; aucun fichier récent dans les `/tmp`, `/var/tmp`, `/dev/shm` des conteneurs
+- Redis : `une-espace-redis` protégé par mot de passe ; `peertube-redis` **sans authentification** (joignable depuis le réseau overlay, donc depuis Gitea pendant la compromission) mais config intacte (`dir=/data`, `dbfilename=dump.rdb`, pas de `slaveof`, pas de module chargé)
+
+Hôte :
+- `dpkg --verify` : aucun binaire/bibliothèque de paquet modifié (seule différence : `zoneinfo/Europe/Paris`, bénin)
+- Aucun fichier modifié depuis le 2026-09-01 dans `/etc`, `/bin`, `/sbin`, `/usr/bin`, `/usr/sbin`, `/usr/local`, systemd ; aucun binaire setuid modifié depuis 2025 ; pas de `/etc/ld.so.preload`
+- Aucun processus caché (comparaison `/proc` vs `ps`)
+- Comptes : `root`, `zuck`, `cloud`, `gemini` (serveur Gemini `agate`, 2023, jamais connecté), `postgres` ; `authorized_keys` : `zuck` (1 clé, modifié le 2026-09-22 pendant la remédiation), `cloud` (1 clé, 2023), `admin` (ancien utilisateur LDAP YunoHost UID 1007, 1 clé `pierre@pierre` de 2020, utilisateur non résolu par `getent` donc inutilisable en SSH) — aucune clé récente ; sudoers inchangés depuis 2021
+- SSH : `PasswordAuthentication no`, `PermitRootLogin no` ; connexions acceptées uniquement depuis `88.179.22.122` et `92.88.171.59` (à confirmer : IP mobile ?)
+- Crontabs système inchangées ; pare-feu `INPUT DROP` avec liste blanche (les ports publiés par Docker contournent `INPUT` : 3000, 996, 1001, 2242 exposés via l'ingress Swarm)
+
 ## Reste à faire
 
 - [ ] Changer les mots de passe des 3 comptes Gitea (pierre, Sans.pub, Duogeeks) par précaution
 - [ ] Révoquer et régénérer les 4 tokens d'accès personnels (LML, Piaire CI/Deploy, Piaire, Laptop .npmrc) — penser à mettre à jour partout où ils sont utilisés
 - [ ] Régénérer les 4 tokens de webhook CapRover (déploiement tmp-fc, dechets-agglo-muretain, etherpad, domi-marche) et mettre à jour les URLs de webhook correspondantes dans Gitea
-- [ ] Vérifier l'intégrité des autres services sur le même hôte (mouvement latéral) — rien trouvé à ce stade, mais l'hôte partagé fait tourner Vaultwarden, Nextcloud, mail
-- [ ] Envisager un scan antirootkit / vérification d'intégrité des binaires système sur l'hôte, vu la durée de la compromission (8 jours)
+- [x] Vérifier l'intégrité des autres services sur le même hôte (mouvement latéral) — fait le 2026-10-03, rien trouvé (voir section dédiée)
+- [x] Vérification d'intégrité des binaires système sur l'hôte — fait le 2026-10-03 via `dpkg --verify`, rien trouvé
+- [ ] Scan antirootkit outillé (rkhunter/chkrootkit) — aucun outil installé ; nécessite une installation (dépôts Debian 9 archivés) ou un scan hors ligne
 - [ ] Revoir si `DOMAIN = localhost` dans `app.ini` (`[server]`) est correct ou un reliquat de config
 
 ## Indicateurs de compromission (IOC)