Rapport de clôture — Tor sécurisé v3.1

Projet : tor-securise (rotation automatique des bridges d'entrée obfs4) Date : 15 octobre 2026 Machine : Kali One (poste c3b) Statut : INSTALLÉ ET EN PRODUCTION — vérifié 12 OK / 0 problème Publication : mémoire centralisée kvm8 /srv/memoire-projets/infra/tor-securise/publications/

1. Objet du présent rapport

Ce document clôt le chantier « Tor sécurisé » ouvert le 24/09/2026 et corrigé les 14 et 15/10. Il consigne trois choses :

1. ce qui est réellement installé sur la machine (mesuré, pas déclaré) ;
2. la preuve que la correction fonctionne (rotation réelle en root, bridges morts écartés) ;
3. les limites qui subsistent — pour qu'aucun lecteur ne prenne une hypothèse pour un fait.

Il corrige aussi deux entrées de journal devenues fausses : celles qui annonçaient encore « ⏳ installation Tor v3.1 attend le mot de passe » alors que l'installation a eu lieu.

2. Le problème d'origine

La v1 du mécanisme de rotation (installée le 24/09/2026) présentait deux défauts mesurés :

Conséquence : Tor fonctionnait malgré sa configuration, parce que 2 bridges sur 4 restaient vivants. Ce n'était pas une panne visible, c'était une dégradation silencieuse — le cas le plus coûteux à diagnostiquer.

Cause racine du défaut « bridges morts » : l'API moat ne filtre pas les bridges décédés. Elle renvoie 7 entrées obfs4 fixes, dont les 2 morts, et seul l'ordre change d'un tirage à l'autre — la v1 prenant « les N premiers », elle tombait aléatoirement sur les morts. Mesuré : sha256 de l'ensemble trié identique sur 4 tirages (bf72eed4bc7cbfc6), ordre variable.

3. Ce qui est installé — état vérifié

3.1 Binaires et empreintes

3.2 Unité de service

/etc/systemd/system/tor-securise-rotate.service
  Type=oneshot
  ExecStart=/usr/local/bin/tor-securise-rotation -q
  Environment=TOR_SECURISE_BRIDGE_COUNT=2     ← 2 bridges visés (choix de Pierre)
  Environment=TOR_MIN_ALIVE=2                 ← minimum 2 vivants exigés
  Environment=TOR_PRUNE_DEAD=1                ← élagage des morts en service
  Nice=10 / IOSchedulingClass=idle
  TimeoutStartSec=420
  ProtectHome=read-only / PrivateTmp=true / NoNewPrivileges=true
  ⚠ AUCUNE directive ProtectSystem=  (voir §5, correctif v3.1)

Ni User= ni Group= : systemd lance donc le service en root (défaut). C'est un point décisif : sudoers n'entre pas en jeu quand c'est systemd qui démarre le service — PID 1 est déjà root et n'appelle pas sudo. L'automatisme ne dépend donc d'aucun droit NOPASSWD.

3.3 Timer

/etc/systemd/system/tor-securise-rotate.timer
  OnBootSec=2min            ← rotation 2 minutes après CHAQUE démarrage
  OnCalendar=daily          ← puis une fois par jour
  RandomizedDelaySec=6h     ← évite les pics de charge
  Persistent=true           ← rattrapage si la machine était éteinte
  WantedBy=timers.target

Mesures : is-enabled → enabled · is-active → active · NEXT Fri 2026-10-16 01:48:31 CEST.

3.4 Bridges en production

/etc/tor/torrc.d/50-bridges.conf — md5 59e299bcbc2b84862d090d67eea783f3 :

Bridge obfs4 209.148.46.65:443 74FAD13168806246602538555B5521A0383A1875 …
Bridge obfs4 212.83.43.95:443  BFE712113A72899AD685764B211FACD30FF52C31 …

Deux bridges, tous deux vivants, générés par le script v3 (source : moat/live).

4. Preuve que ça fonctionne

4.1 Rotation réelle en root — trois passages, tous réussis

journalctl -u tor-securise-rotate.service :

11:09:17  moat: [51.222.13.177:80]  liste noire (mort recurrent) — rejete
11:09:17  moat: [146.57.248.225:22] liste noire (mort recurrent) — rejete
11:09:43  Finished … status=0

11:11:42  (les 2 mêmes rejets)
11:12:00  Finished … status=0

11:12:45  (les 2 mêmes rejets)
11:13:18  Finished … status=0

Lecture : la v3 rejette à chaque passage exactement les deux bridges que la v1 installait. C'est le correctif « filtre vivants » à l'œuvre, en production, pas en simulation.

4.2 Vérificateur officiel du livrable

bash VERIFIER-apres-installation.sh
→ BILAN : 12 OK / 0 problème(s)     rc=0
   [+] bridge mort 51.222.13.177 écarté
   [+] bridge mort 146.57.248.225 écarté
   [+] timer : armed / enabled (survit au redémarrage)
   [+] rotation prévue 2 min après chaque démarrage
   [+] sortie Tor : {"IsTor":true,"IP":"171.25.193.20"}

Intégrité du livrable : sha256sum -c MANIFESTE.sha256 → 7/7 OK (contrôle au moment de la rédaction de ce rapport).

4.3 Tor opérationnel

5. Le correctif v3.1 — la panne qui aurait été invisible

La v3 portait ProtectSystem=full. Cette option monte /etc en lecture seule pour le service. Or la rotation écrit dans /etc/tor/torrc.d/50-bridges.conf et sauvegarde dans /etc/tor/bridges-backup/.

Mesure faite : systemd-run -p ProtectSystem=full → /etc monté ro → toute écriture renvoie « Read-only file system ».

Pourquoi c'était grave : la rotation aurait échoué dans le timer, alors qu'un test manuel (hors namespacing) aurait réussi. Panne invisible, découverte des semaines plus tard sous forme de « Tor ne démarre plus ». La v3.1 retire cette directive et revient au comportement éprouvé de la v1, qui n'avait aucune protection de ce type.

Alternative écartée volontairement : ProtectSystem=strict + ReadWritePaths=/etc/tor/torrc.d /etc/tor/bridges-backup — plus élégant, mais un seul chemin oublié = rotation morte silencieusement. Le risque d'échec silencieux a été jugé pire que l'absence de protection.

6. Ce qui n'est PAS possible : « 1 bridge en sortie »

Point de protocole, pas de configuration. Un bridge ne peut pas être un nœud de sortie.

• Un bridge fournit obfs4 (camouflage) uniquement pour la première étape. Son descripteur n'est pas publié dans le consensus Tor, donc Tor ne peut pas le sélectionner comme exit.
• Il n'existe aucune directive ExitBridge.
• Vérifié dans /etc/tor/torrc : aucune ligne ExitNodes / EntryNodes / StrictNodes.

Sur Onionoo (l'intuition était partiellement juste) : Onionoo publie bien des entrées type=bridge, mais leurs adresses sont caviardées en IP privées (10.x.x.x) — par conception. Onionoo publie en revanche les relais de sortie avec adresse publique, fingerprint et flags, et l'API est exploitable (mesuré : 8 relais Exit+Fast, ORPort 8/8 ouverts, latence 0,6 s).

Ce qui serait faisable : remplir ExitNodes avec des fingerprints vivants et vérifiés, régénéré automatiquement comme les bridges d'entrée — « N relais de sortie choisis », pas « 1 bridge de sortie ». Le prix, dit franchement : forcer un petit ensemble de sorties identifiables réduit l'anonymat — un adversaire qui observe un exit sait que le trafic vient d'un des N relais de la configuration. C'est mécaniquement plus corrélé que la sortie aléatoire actuelle. Non installé, non recommandé en l'état.

Et le réglage « 1 seul bridge en entrée » a été écarté : avec un bridge unique, s'il tombe, Tor ne bootstrappe plus du tout. Le choix retenu est 2 (COUNT=2 / MIN_ALIVE=2), ce qui donne une redondance minimale sans diluer la maîtrise de l'entrée.

7. Décision A vs B — état réel

Deux options étaient posées :

• A — conserver le NOPASSWD ciblé sur tor-securise-rotation + tor-securise-verifier ;
• B — s'appuyer uniquement sur le service systemd (lancé en root par PID 1, sans sudoers).

B est démontré en pratique : le timer tourne, le service se lance en root, la rotation de 11:12 a réussi status=0, sans que les droits NOPASSWD aient servi. L'automatisme est intégralement couvert par B.

Mais : /etc/sudoers.d/tor-rotation est toujours en place (root:root, mtime 14/10 00:56). Son retrait n'a pas été effectué. Raison : un cycle timer complet n'a pas encore été observé (NEXT Fri 2026-10-16 01:48:31 CEST). Retirer le filet avant d'avoir vu un cycle passer serait une imprudence.

Coût de A qu'il faut connaître : A est le seul élément qui permet à un agent de lancer la rotation en root depuis une session utilisateur — exactement le vecteur que le registre d'autorisations signale. B ne le supprime pas tout seul : il faut retirer le fichier sudoers.

Procédure de retrait, quand ce sera le moment (jamais avant un cycle réussi) :

sudo cp -p /etc/sudoers.d/tor-rotation /root/tor-rotation.sudoers.bak-$(date +%Y%m%dT%H%M%S)
sudo visudo -c                       # doit répondre « parsed OK » AVANT toute modification
sudo visudo -f /etc/sudoers.d/tor-rotation

⚠ Ne jamais éditer /etc/sudoers.d/ avec > ou sed -i : une erreur de syntaxe casse sudo pour tout le système. D'où visudo obligatoire.

Conséquence à accepter : après retrait, sudo /usr/local/bin/tor-securise-rotation échouera ; seul systemctl start tor-securise-rotate.service (avec mot de passe) déclenchera une rotation à la main.

8. Correction des entrées de journal périmées

Deux entrées de ACTIONS-EN-COURS-20260907.md annonçaient encore une installation en attente :

Méthode : sauvegarde préalable …md.bak-avant-cloture-tor-20261015T092521Z (sha256 118c5ebd…), puis édition ciblée des deux seuls marqueurs de statut — pas de réécriture du fichier. Contrôles : grep -c "PÉRIMÉ" → 2 ; grep -c des anciens marqueurs → 0. Taille : 455 424 → 459 480 o (ajout de l'entrée de clôture comprise).

9. Limites assumées

1. L'installation n'est pas de mon fait. Mes sudo -n renvoient a password is required (rc=1, mesuré à chaque tour). Les mtime 11:09–11:12 correspondent à une exécution root humaine — vraisemblablement Pierre, ou la session DSH parallèle détectée le matin même. Je constate l'état, je ne le revendique pas.
2. La sauvegarde /root/tor-securise-sauvegarde-*/ n'a pas pu être listée : /root est en drwx------ root root, ls → Permission denied. Son existence est inférée de INSTALLER-v3.1.sh:88 (NSAVED -ne 5 ⇒ arrêt immédiat), pas constatée. Pour la vérifier : sudo ls -la /root/tor-securise-sauvegarde-*/
3. La sonde TCP prouve une socket, pas un handshake obfs4. Le test dit « le port répond », pas « le bridge fonctionne avec ce certificat ». Un test plus fort exigerait de lire les circuits — or ControlPort n'est pas configuré (9051 → Connection refused).
4. Point non élucidé : journalctl -u tor@default sur la fenêtre 11:12+ ne montre pas de ligne Bootstrapped 100%, alors que le vérificateur la rapporte. Écart relevé, non expliqué.
5. Un cycle timer complet n'a pas encore été observé. La prochaine échéance (Fri 2026-10-16 01:48:31 CEST) sera la première preuve d'endurance.
6. Le retrait du NOPASSWD n'est pas fait (§7).

10. Journal des actions de ce tour

• Sauvegarde du journal : ACTIONS-EN-COURS-20260907.md.bak-avant-cloture-tor-20261015T092521Z
• Correction des 2 entrées périmées + ajout de l'entrée de clôture
• Rejeu du vérificateur officiel : 12 OK / 0 problème, rc=0
• Contrôle du manifeste : 7/7 OK
• Mesure de sortie Tor : {"IsTor":true,"IP":"171.25.193.20"} rc=0
• Dépôt sur kvm8 : /srv/memoire-projets/infra/tor-securise/publications/

Aucune écriture dans /etc/ ce tour. Aucun secret dans ce document (contrôle grep -iE sur clés, jetons, password=, clés privées avant publication).

Rapport rédigé par DSH (agent c3b) — 15 octobre 2026. Les valeurs d'empreintes sont tronquées pour la lisibilité ; les valeurs complètes figurent dans MANIFESTE.sha256 et .sha256-complet.txt.