[gull] SOCKS5 pour tout un lan - Redsocks ?

[Frédéric Dumas]

Bonjour Marc,
Bonjour à tous,


> Déjà, TOR ne support pas l'UDP, donc rediriger "tout le trafic" est
> impossible.

> A voir, redsocks [1] a besoin de tricher avec le DNS, de modifier les
> règles iptables, etc.


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.

Sur la page du même auteur, derrière deux liens en cascade, on trouve une mise en garde intéressante, dans le cas où on veut rediriger de manière transparente tout le traffic d’un LAN sur Tor (ce que je 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 qu’il voit passer (il y a quasiment en permanence le bruit de fond des applis diverses et variées, toujours les mêmes sur ce LAN là, qui passent leur temps à « pooler » les serveurs dont elles dépendant). Du coup, quelque soit le circuit Tor et le noeud de sortie qui changent avec le temps, le LAN est facilement reconnaissable, car il produit en sortie toujours plus ou moins le même « bruit » caractéristique.

Source: https://github.com/epidemics-scepticism/writing/blob/master/misconception.md#transparent-proxying-lacks-context

Je copie l’extrait :


> It doesn't know what applications are making what requests, at best you could isolate by things like the user who is running the application but imagine a scenario like Tor Browser where all the traffic is coming out of single application to a single proxy port. Tor Browser, because it's been made to work with Tor, is able to use SOCKS5Auth based circuit isolation mechanisms, this isolate requests based on the first party domain of the tab the request is associated with. This means no single exit handles all the requests you're making. Tails also makes use a multiple SOCKS ports, each of which will be isolated from each other and different applications use different ports, meaning they do not share circuits.
> 
> When you take your whole operating system and stick it behind transparent proxying, everything goes over Tor if it can. Everything that goes over Tor will, by default, use the same circuit. Your operating system updates, your email, your browsing, and fetching information about media you play will all share the same circuit. The exit node could connect all of these things together and link them to a single entity. This means things intended to be anonymous could be linked to things which reveal your identity, or link distinct psuedonyms. Similarly to this see "Not All Applications Are Fit For Purpose" above.
> 
> Further, the set of applications and how they behave can act as a fingerprint that an Exit or potentially a careful observer watching Exit traffic could piece together. This is why doing this without using an operating system with a good anonymity set (with many users with the same set of software and thus the same fingerprint) will make you at best psuedonymous. This may suit your purposes but if the fingerprint is observed outside of Tor then it may be possible to link your psuedonym to your real identity. See "Use It Consistently".
> 
> It should only be used as a last resort if there is no other way and it should be used sparingly as possible, prefer to use native SOCKS5 or the torsocks wrapper.



Sinon, configurée directement sur Firefox (pas sur Tor Browser), le SOCKS5 sur port 9050 du relay Tor distant marche bien, la navigation n’est pas sensiblement ralentie: Firefox fait bien sortir ses requêtes et reçoit les réponses vers et depuis le socket distant, donc à 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 domaines par Tor, on a accès en prime aux services cachés .onion directement depuis Firefox. Il faut là aussi changer une option (about:config -> network.dns.blockDotOnion = false).

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 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.

En France, l’usage par les autorités d’outils DPI sur les backbones des fournisseurs de service Internet a été inscrit dans la loi en 2015. Cinq ans plus tard, c'était l’année dernière, nos députés ont inscrit dans la loi le fichage nominatif des opinions politiques et syndicales par l’administration. L’éternelle fable de la grenouille et de sa casserole d’eau chaude. Sans Tor et avec la mécanique des likes et retweets sur les réseaux sociaux, ça va devenir chaud de longtemps garder un profil vierge.

Pour revenir à la technique, si on n’a pas de relais Tor distant sous la main, on peut faire un test très semblable en lançant sur sa machine locale en parallèle Firefox et Tor Browser, et en configurant comme mandataire IP dans Firefox le socket SOCKS5 local créé par Tor Browser sur localhost:9150. Ça marche pareillement qu’en utilisant le SOCKS5 du relais Tor distant, preuve qu’un client Tor tourne sur la machine locale, dès qu’on met Tor Browser en route.


Toujours sur la page du même auteur, on trouve un lien vers une autre approche. La redirection du traffic du LAN vers le « TransPort » du relais Tor, et non plus vers son SocketPort. Je n’ai pas trouvé 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, quelques règles iptables sur une machine servant de routeur sembleraient être tout ce dont on a besoin:


> # Tor's TransPort
> _trans_port="9040"
> 
> # your internal interface
> _inc_if="eth1"
> 
> iptables -F
> iptables -t nat -F
> 
> iptables -t nat -A PREROUTING -i $_inc_if -p udp --dport 53 -j REDIRECT --to-ports 5353
> iptables -t nat -A PREROUTING -i $_inc_if -p udp --dport 5353 -j REDIRECT --to-ports 5353
> iptables -t nat -A PREROUTING -i $_inc_if -p tcp --syn -j REDIRECT --to-ports $_trans_port



Source: https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TransparentProxy#anonymizing-middlebox


Une autre source dit d’ajouter encore cette règle, pour s’assurer que le traffic ssh sorte directement, sans passer par Tor:


> iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 22



Source: http://digitalarmedforces.org/index.php/8-linux/19-how-to-setup-tor-as-a-transparent-proxy-on-ubuntu-linux


Du coup, plus besoin de l’application redsocks pour faire ce que je voulais (le LAN Guest #2 qui sort vers @ à travers Tor). Si c’est aussi facile à mettre en place sur n’importe quelle machine Linux servant de routeur, ça parait une piste  plus intéressante. Par contre, comme d’habitude, on perd le traffic UDP (sauf le DNS). Les téléphones SIP vont devoir passer en TCP.

La critique « un LAN en entier = un seul circuit Tor = pseudonymat faible » reste-t-elle valide ici ? Quand on utilise TransPort, est-ce qu'on ouvre sur le relais Tor autant de circuits qu’il y a de connexions TCP ? Si c’est bien le cas, le sapin de Noêl aura alors été découpé en petites planchettes. À vérifier. Et malheureusement, comme pour le trafic socket, ici non plus rien n’est chiffré entre le LAN et le relais Tor, iptables pousse juste les paquets « en l’état » en direction du relais. Donc ce n’est de toute façon pas adapté à la résistance aux équipements faisant du deep packet inspection entre le LAN et le relais Tor distant.


--
Frédéric Dumas
f.dumas at ellis.siteparc.fr