TransparentTorProxy

Un utilitaire CLI Linux qui achemine de manière transparente tout le trafic système via le réseau Tor en utilisant nftables. Il permet une rotation rapide de l'IP et une activation/désactivation facile des paramètres de proxy globaux pour les tâches de confidentialité.

Fonctionnalités • Prérequis • Installation • Utilisation • Fonctionnement • Vérification • Contribuer

Aucune configuration par application nécessaire - il suffit de sudo ttp start et chaque connexion passe par Tor.

[!CAUTION] TTP est un outil conçu pour favoriser la confidentialité en routant le trafic à travers Tor. Cependant, aucun outil ne peut garantir une anonymisation à 100 %. Votre sécurité dépend également de votre comportement (par exemple, utiliser un navigateur classique plutôt que le Tor Browser, se connecter à des comptes, etc.). Utilisez toujours TTP dans le cadre d'une stratégie de sécurité à plusieurs niveaux.

[!WARNING] Si vous êtes un lanceur d'alerte ou si vous exercez des activités à haut risque, N'UTILISEZ PAS TTP. Utilisez plutôt des outils officiellement audités et fiables comme TailsOS ou directement le Tor Browser. Les auteurs et contributeurs de TTP déclinent toute responsabilité quant à votre sécurité ou aux conséquences de l'utilisation de ce logiciel.

Pourquoi TTP ?

Les anciens scripts de proxy transparent (TorGhost, Anonsurf) écrasent les fichiers de configuration et construisent des ensembles de règles iptables qui échouent en clair : lorsqu'ils tombent en panne, le trafic sort en clair. TTP est conçu dans la logique inverse - il échoue en mode fermé et ne conserve rien sur le disque.

Fonctionnalités

• Protection d'intégrité continue - un watchdog gouverné par une FSM formelle (transitions) surveille Tor, les chaînes nftables et la superposition DNS via une double surveillance inotify qui détecte la substitution de cible de lien symbolique. Il répare une fois, puis applique un killswitch d'urgence.
• Split tunnelling - exemptez des utilisateurs ou des groupes (--bypass-user, --bypass-group) avec la correspondance native UID/GID de nftables, ou exécutez une seule commande hors de Tor avec ttp bypass <cmd> via une slice cgroups v2.
• LAN préservé - les sous-réseaux RFC 1918 et link-local restent accessibles, ainsi votre imprimante et votre NAS continuent de fonctionner.
• Dual-stack, ou pas de stack - IPv6 est routé via Tor lorsque le routage loopback est disponible, et abandonné purement et simplement lorsqu'il ne l'est pas. Il n'existe pas de troisième option où il fuite.
• DoT et DoH bloqués - port 853 rejeté, résolveurs DoH publics connus rejetés sur 443 (TCP et QUIC), et domaines canaris des navigateurs empoisonnés dans torrc.
• Coexiste avec votre Tor système - exécute son propre ttp-tor.service volatil sur des ports non standard, laissant une instance Tor existante intacte.
• Bridges - obfs4 et snowflake, avec un mode BYOD (bring your own daemon).

Prérequis

• Linux avec systemd
• Python 3.10+
• nftables (préinstallé sur la plupart des distributions modernes)
• Privilèges root (requis pour les modifications du pare-feu et du DNS)

Installation

Choisissez la méthode qui correspond le mieux à vos besoins. Les paquets natifs sont fortement recommandés pour la stabilité du système, la sécurité et une désinstallation propre.

1. Paquets natifs (recommandé)

L'installation via des paquets natifs garantit que toutes les dépendances système (tor, nftables) et les optimisations au niveau du noyau (SELinux) sont gérées par le gestionnaire de paquets de votre OS.

Téléchargez le .deb ou le .rpm pour la version souhaitée depuis la dernière release - les paquets sont des assets de release et ne sont pas versionnés dans le dépôt - puis installez-le :

• Debian / Ubuntu : sudo apt install ./transparent-tor-proxy_0.4.9_all.deb
• Fedora / RHEL : sudo dnf install ./transparent-tor-proxy-0.4.9-1.noarch.rpm
• Arch Linux : compilez depuis le dépôt avec cd packaging && makepkg -si

Pour obtenir des instructions sur la façon de vérifier l'intégrité et l'authenticité des assets de release, consultez le Guide de vérification des releases.

2. Installation manuelle depuis les sources (développeur/universel)

Si vous êtes développeur ou souhaitez installer depuis le dépôt :

[!TIP] Pourquoi utiliser ./install.sh ?
Contrairement aux installateurs Python standards, ce script est « intelligent ». Sur les systèmes basés sur Red Hat, il détecte si SELinux est en mode Enforcing et compile dynamiquement un module de politique personnalisé (à partir de ttp_tor_policy.te) pour permettre à Tor de se lier aux ports non standard requis par TTP (9041, 9054). Cette optimisation au niveau du noyau ne peut pas être effectuée par pip.

3. Méthodes d'installation alternatives (repli)

Pour installer TTP via des gestionnaires de paquets spécifiques à Python (pipx ou pip avec environnements virtuels), consultez la Référence des méthodes d'installation alternatives.

Utilisation

TTP est conçu pour être simple et léger. Pour la liste complète des commandes CLI, options, codes de sortie et spécifications techniques, reportez-vous à la Référence des interfaces externes.

Démarrage rapide

La plupart des commandes modifiant le réseau nécessitent les privilèges root (sudo) :

• Démarrer le proxy :

  root@kitploit:~

  sudo ttp start
  

• Arrêter le proxy :

  root@kitploit:~

  sudo ttp stop
  

• Vérifier l'état de la session en cours :

  root@kitploit:~

  ttp status
  

• Vérifier le routage Tor et la latence :

  root@kitploit:~

  ttp check
  

• Demander une nouvelle IP de sortie (rotation des circuits) :

  root@kitploit:~

  sudo ttp refresh
  

Pour des configurations plus avancées et des profils de contournement, consultez la Référence des profils de sécurité et d'utilisation avancés ou la Référence des interfaces externes.

Vérification de votre session

Désinstallation complète

Pour supprimer complètement TTP du système :

Fonctionnement

TTP route de manière transparente tout le trafic réseau en orchestrant les sous-systèmes standard du noyau Linux, les utilitaires système et les interfaces de contrôle de Tor :

1. Redirection atomique du pare-feu : génère et charge atomiquement un ensemble de règles nftables isolé inet ttp pour intercepter le trafic TCP et DNS, en les redirigeant vers Tor tout en empêchant les fuites IPv6 et DoT/DoH.
2. Superposition par bind-mount DNS : superpose /etc/resolv.conf avec une configuration volatile en RAM via un bind-mount au niveau du noyau pour garantir que les appels DNS sont résolus par Tor.
3. Intégration du démon Tor : configure, exécute et surveille une instance Tor isolée via des services systemd volatils sur des ports non standard pour éviter les conflits de ports.
4. Watchdog de session : exécute un moniteur d'arrière-plan actif qui vérifie l'intégrité de la configuration et déclenche un killswitch d'urgence en mode échec fermé en cas de brèche de sécurité ou de modification du système.

Pour une présentation détaillée des flux d'exécution, des hooks système, des frontières de sécurité et des composants modulaires, veuillez consulter :

Guide d'architecture technique et de conception

Récupération après crash

TTP est conçu pour toujours restaurer votre réseau, même dans les cas limites :

Comportement connu et limitations

[!WARNING]

• Tor Browser : les applications utilisant un proxy SOCKS5 explicite créeront un double saut Tor. Utilisez plutôt un navigateur classique pendant que TTP est actif.
• DNS-over-HTTPS (DoH) : les navigateurs classiques (Firefox, Chrome, Brave, Edge) peuvent utiliser DoH, contournant le DNS système. TTP atténue DoH via une défense à 3 couches : (1) tout le trafic TCP sortant (y compris DoH) est redirigé vers le TransPort de Tor ; (2) les domaines canaris DoH courants sont mappés vers 0.0.0.0 dans torrc ; (3) les résolveurs IP DoH publics sont bloqués sur le port TCP/UDP 443 (bloquant le DoH HTTP/3 QUIC). Pour une sécurité maximale, désactivez DoH / « DNS sécurisé » dans les paramètres de votre navigateur.
• IPv6 : entièrement pris en charge lorsqu'il est disponible. TTP détecte dynamiquement le loopback IPv6 et route le trafic IPv6 via Tor. Si l'hôte ne dispose pas du support du loopback IPv6 OU si l'option --no-ipv6 est passée, TTP abandonne tout le trafic IPv6 sortant pour éviter les fuites.
• Variation de l'IP de sortie : différentes connexions peuvent afficher différentes IP de sortie en raison de l'isolation des flux Tor.

Pour une analyse complète des risques résiduels, des frontières de confiance architecturales et du modèle de menace STRIDE, consultez :

docs/security-assessment.md

Développement et tests

TTP utilise un Makefile pour automatiser et standardiser le pipeline de tests. Cela garantit que chaque modification est vérifiée par des tests unitaires et d'intégration avant d'être validée.

La règle du « Pre-Push »

[!IMPORTANT] Exécutez toujours make verify avant de pousser du code. Si cette commande échoue, le code n'est PAS prêt pour la production.

Commandes essentielles

Vérification

L'affirmation de TTP d'absence de fuite est mesurée, non affirmée. Le Network Sandbox Engine construit un namespace réseau isolé, y charge l'ensemble de règles réellement généré par TTP, génère le trafic dont consisterait une fuite, et surveille l'interface veth de frontière avec un sniffer Scapy.

Chaque test de confinement s'exécute deux fois. assert no leaks est également vrai lorsque le sniffer n'a jamais démarré, lorsque le nom de l'interface est erroné, ou lorsque le trafic n'a jamais quitté le processus, donc chaque test exécute d'abord le même stimulus avec le ruleset vidé et exige que le paquet soit vu. Ce n'est qu'ensuite qu'il affirme que le ruleset de TTP l'arrête. Un harnais qui ne peut pas observer une fuite échoue au test plutôt que de le réussir.

Couvert : DNS en clair (UDP et TCP), TCP ordinaire, DoT sur 853, DoH QUIC sur UDP/443, ICMP, UDP arbitraire, IPv6 — plus la direction inverse, qu'un UID contourné peut toujours atteindre le LAN. Un pare-feu qui bloquerait tout réussirait les sept premiers et échouerait au huitième.

Cela s'exécute en CI à chaque push (le job Zero-leak ruleset verification) et comme une étape dans scripts/verify.sh avant une release.

Avancé : tests en VM réelle

Bien que les tests d'intégration Docker soient rapides et atomiques, ils ne capturent pas 100 % des nuances du noyau/systemd. Pour les modifications critiques, il est fortement recommandé de tester dans une vraie VM QEMU :

Diagnostics

Si quelque chose ne va pas, exécutez la commande de diagnostic :

Structure du projet

Contribuer

Les contributions sont les bienvenues, et les domaines où l'aide compte le plus sont étroits et spécifiques :

1. Réseau Linux - nftables, tables de routage, namespaces réseau, détection d'interface VPN.
2. Internes de Tor - configuration du démon, Stem, bridges, cas limites de bootstrap.
3. CI/CD - maintenir les suites de tests privilégiées rapides et fiables sur GitHub Actions.

Commencez par CONTRIBUTING.md, qui documente les deux règles sur lesquelles ce codebase est construit : ne jamais corriger un bug sans ajouter la vérification qui l'aurait attrapé, et un test qui affirme une absence doit d'abord prouver qu'il peut détecter une présence.

Ce projet est maintenu sur du temps libre. Une étoile aide les autres à le trouver ; le sponsoring aide à le faire perdurer.

Licence

MIT. Voir LICENSE pour plus d'informations.