[gull] SOCKS5 pour tout un lan - Redsocks ?

[Marc SCHAEFER]

On Wed, May 12, 2021 at 07:32:07AM +0200, Frédéric Dumas wrote:
> L???auteur explique qu???il fait ainsi précisément pour contourner la contrainte sur l???UDP; la « triche » consiste à faire comprendre aux clients que leurs requêtes DNS en UDP ne passent pas, ce qui les force à les reformuler en TCP.

Oui, pas de souci pour le DNS (il y a même un protocole DNS-via-SOCKS),
je parlais de tous les AUTRES protocoles UDP, comme la voix-sur-IP. Cela
ne marchera pas derrière tor.

D'ailleurs, oublier le DNS avec SOCKS c'est, dans un cas où le routage
normal est conservé, leaker via le DNS.  C'est une option de Firefox,
par exemple, qui n'est pas activée par défaut quand on active le SOCKS,
tu l'as d'ailleurs mentionné plus bas.

> voulais faire); d???après l'auteur, comme à l???instant t tout passe
> dans un seul et même circuit Tor, du coup si quelqu???un écoute les
> noeuds de sortie, c???est un sapin de noel assez reconnaissable

En première approche, on pourrait forcer tor à changer de circuit
régulièrement (le GUI le supporte, je n'ai jamais fait ça en ligne de
commande).

Une meilleure solution serait de mettre un load-balancer TCP qui
redirige 1.2.3.4:9050 vers 1.2.3.4:$((9050 + x)) et où chacune des
instances va sur une instance tor différente, donc des circuits
et noeuds de sortie vraisemblablement différents.

J'ai fait ça pour un scanner tor il y a de nombreuses années, pour
répartir la charge, pas pour anonymiser. Et c'était mon application qui
utilisait un x aléatoire, je n'avais pas mis en place de load-balancer
TCP.

> à travers le relais Tor. Il faut simplement forcer Firefox à router
> aussi ses requêtes DNS par le SOCKS5 (about:config ->
> network.proxy.socks_remote_dns = true); par défaut Firefox continue à
> interroger le DNS par la passerelle par défaut, et non par le socket
> (« dns leak »). Cerise sur le gâteau: maintenant qu???on résout les

Bien que tu aies vu ça.

> Evidemment, au-delà du test, ça n???a pas beaucoup de sens de faire
> ça. D???une part, Firefox est sans doute en lui-même beaucoup mieux «
> blindé" que TorBrowser, le dns leak n???est probablement qu???une des

La version de Firefox livrée avec TorBrowser a deux trois
caractéristiques d'anonymisation, comme interdire le redimensionnement
de la fenêtre (ou faire une mise en garde), vu que c'est une technique
de fingerprinting connue.

> failles que Tor Browser bouche par défaut. Mais surtout, comme le
> protocol socket ne chiffre rien sur l'Internet entre Firefox et le
> relais Tor distant, notre ISP local voit passer tout ce qu???on veut
> déporter sur Tor, si lui prend l???envie de regarder.

Ah, ok, j'ai toujours utilisé la version avec noeud d'entrée tor local,
jamais une version utilisant un proxy en clair distant. D'ailleurs, si
tu configures un bridge tor distant, le trafic est chiffré (pas SOCKS).

> beaucoup de doc là-dessus. Avec l'option TransPort, j???ai
> l???impression qu???il n???est plus du tout question du protocole
> socket dans l???affaire, puisque coté LAN à rediriger vers Tor,

J'ai un bridge tor (== noeud d'entrée publié de manière limitée,
permettant à des pays sous régime totalitaire d'entrer dans tor, même si
quelques IP de noeuds d'entrée connus sont bloquées, y compris avec
divers types d'obfuscation faisant ressembler le service tor à un
serveur HTTPS).

Résumons les moyens d'entrer dans un noeud d'entrée tor:

   - SOCKS (en clair, uniquement sur la même machine de préférence)

        exemple: noeud d'entrée tor et navigateur sur la même machine,
                 ou n'importe quel client TCP via tsocks

   - TransPort (proxy transparent supportant HTTP/HTTPS, redirigé par
     iptables, HTTPS possible uniquement si l'iptables est fait
     sur la même machine)

        probablement ce que tu veux faire, encore que redsocks offre
        une solution légèrement différente basée réécriture DNS

   - fonctionnement normal: noeud d'entrée tor (chiffré), y compris
     bridge

        à activer volontairement

   - fonctionnement `obfuscated': idem, mais simili-HTTPS ou autres
     protocoles

        à activer volontairement

> quelques règles iptables sur une machine servant de routeur
> sembleraient être tout ce dont on a besoin:

C'est ça. Mais il faut que cette machine soit la même que là où tourne
TransPort de tor, car sinon on perd l'info de destination HTTPS (l'adresse IP
destination est réécrite, mais toujours disponible au service de
proxy transparent *sur la même machine*).

N'ayant plus mis en place de proxy transparent depuis des années, je ne
sais pas s'il y a des astuces meilleures (style: redsocks qui sabote le
DNS pour, je crois, allouer des IP temporaires qui associent au nom
de domaine réel auquel le proxy transparent doit se connecter ensuite,
via tor).