Ce tutoriel n’a pas pour but d’enseigner ce qu’est Tor ou comment vous y rendre : la documentation officielle de Tor et des milliers d’autres ressources sont à votre disposition sur Internet et seront certainement de meilleure qualité que ce que je pourrais écrire ici. Commencez donc par lire du contenu.
L'incontournable documentation de Tor
Ce wiki a pour but de vous montrer à vous, utilisateur intermédiaire de l’outil, comment aller plus loin. Ce n’est pas un guide pour débutant et encore moins un tuto Linux. Des bases en Linux sont nécessaires avant de s’attaquer à Tor sous Linux.
Comme vous l’avez lu dans la documentation, lorsque vous vous contenez à Tor, une « route » est créée à l’intérieur du réseau afin que vos flux passent d'un ordinateur à l'autre et qu'au final personne ne puisse savoir ou se trouve l'hôte à l'origine de la requête. Les paquets sortant de votre poste sont chiffrés par trois fois (donc réencapsulés trois fois en AES localement) et à chaque nouveau « bond » (« hops » en anglais / dans le jargon) une couche de chiffrement est retirée du paquet puis ce dernier est passé au nœud suivant. Une fois arrivé à destination, la dernière couche est retirée afin que le host à qui vous vouliez communiquer au final puisse lire l’information en clair. Cette route n’est pas définitive et en fonction de votre configuration dans /etc/tor/torrc elle sera plus oui moins éphémère (dans le temps). Une fois expirée, une nouvelle route sera créée par le client et ainsi de suite. Laissez les réglages par défaut à ce sujet à moins que vous n’expérimentiez la modularité des fonctions de Tor ou que vous ayez une très bonne raison de mettre en danger votre anonymat. dans notre tuto sur les services cachés nous verrons aussi de quelle manière avoir un impact sur le nombre de “hops” qui par défaut est de 3.
Il existe plusieurs types de relais et les héberger est plus ou moins dangereux pour l’opérateur (donc vous). Je vous déconseille plus que vivement d’héberger un nœud de sortie à moins que vous ne souhaitiez très fort que la police sonne à votre porte dans les heures à venir. De multiples opérateurs dans des pays pourtant libres et civilisés on eu de très gros problèmes légaux. Vous êtes prévenus.
Un relais intermédiaire (middle relay) se charge de recevoir des paquets d’un côté à l’intérieur de Tor. Ces paquets sont chiffrés. A réception il retire une couche de chiffrement et les renvoie au prochain maillon de la chaîne, c'est à dire au host suivant selon la route déterminée par le client. Du point de vue du relai intermédiaire les paquets ne son pas totalement déchiffrés ce qui veut dire qu’entant qu’opérateur d’un nœud à ce niveau de la chaîne vous ne pouvez pas lire l’information qu’il contient. Ce type de nœud est plutôt simple à maintenir et pas très dangereux puisque votre relai est caché à l’intérieur de Tor, rien ne sort sur Internet. La localisation géographique de votre relai n’est jamais divulguée et votre identité non plus.
Avec le temps, votre relai va se voir confier de plus en plus de trafic à mesure que sa stabilité et sa fiabilité seront jugées « aptes » par l’algorithme du réseau. Si votre relai est robuste il se verra certainement attribuer le rôle « d’entry guard » (ou simplement « guard ») ce qui est une consécration puisque le rôle des guards est primordial pour la sécurité des utilisateurs de Tor et le fonctionnement du réseau.
C’est parti ! Comme souvent lorsqu’il s’agit de Tor, nous allons créer une machine virtuelle sur notre serveur. Je vous déconseille de faire fonctionner quoi que ce soit concernant Tor sur votre serveur en bare metal. Je préfère utiliser OpenBSD pour opérer des relais (principalement pour la possibilité de compiler Tor avec LibreSSL et pour le Secure Level 3) mais ce wiki est au sujet de Linux et surtout de Debian qui est un système plus que passable pour cet usage bien qu’un peu de hardening soit nécessaire à l’arrivée. Je n’ai pas utilisé Debian depuis 10 ans alors si vous voyez un truc choquant n’hésitez pas à le signaler.
Pour créer la VM, quelques conseil sur les ressources :
| HDD : 5Go CPU : Entre 2 et 4 threads devraient suffire sur un CPU moderne équipé des instructions AES-NI, tout dépend de l’amour que vous voulez donner à votre relai. Mémoire : 512Mo si vous opérez moins de 40Mb en bnande passante, 1024Mo pour 40Mb et plus. Nous prendrons le soin de désactiver ls services inutiles… Debian n’est pas trop bloat on devrait s’en sortir pas mal. Réseau : Une interface réseau virtuelle avec un driver moderne. Un faites un bridge avec une interface physique pour exposer votre VM à votre LAN. Bien qu’aucune redirection ne sera necessaire il est toujours confortable de pouvoir accéder à votre machine via OpenSSH. |
Petite note pour les utilisateurs de Raspberry Pi : mes chers amis, un Raspberry Pi ne possède pas d'instructions AES-NI. Il galère à mort avec le chiffrement et génère d'horribles latences sur le réseau. Si vus voulez faire des expériences ponctuelles et vous former à Tor vous pouvez utiliser un Pi comme lab. Si vous souhaitez aider la communauté Tor merci de l’installer sur un serveur ou bien allez voir ailleurs.
Commencez par vérifier que votre VM voit bien les instructions AES-NI sur votre CPU.
# lscpu | grep aes
Un relais Tor est extrêmement simple… N’installez que le strict nécessaire sur votre machine (KISS):
# apt install -y net-tools sudo vim
Une adresse IP fixe n’est pas requise par Tor pour fonctionner correctement mais j’ai envie de pouvoir me connecter à ma VM en ssh :
$ cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.17
netmask 255.255.255.0
gateway 192.168.1.1
On redémarre le réseau :
# systemctl restart networking
Le serveur doit impérativement être à l’heure. C’est un prérequis indispensable car le chiffrement se base sur le temps et Tor c'est du chiffrement. Vérifiez bien que l’heure réseau est activée, que votre TZ est correcte. Si ce n’est pas le cas il faut que vous l’activiez… Je trouve la gestion du temps très pourrie sous Debian, je vous laisse faire vous-même. Choisissez un démon entre chrony, ntp et je ne sais pas quoi d’autre à votre disposition . Personnellement j'aime ntpd(8) donc je l'utilise. Le résultat final doit ressembler à ça :
# timedatectl
Local time: mar. 2021-05-11 17:43:45 CEST
Universal time: mar. 2021-05-11 15:43:45 UTC
RTC time: mar. 2021-05-11 15:42:03
Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Bien que le firewall ne soit pas d'une utilité transcendante dans notre cas de figure je l'active par principe, surtout pour la sécurité du LAN.
# apt install nftables
# systemctl enable --now nftables
# systemctl status nftables
● nftables.service - nftables
Loaded: loaded (/lib/systemd/system/nftables.service; enabled; vendor preset: enabled)
Active: active (exited) since Tue 2021-05-11 20:08:40 CEST; 2h 2min ago
Docs: man:nft(8)
http://wiki.nftables.org
Process: 242 ExecStart=/usr/sbin/nft -f /etc/nftables.conf (code=exited, status=0/SUCCESS)
Main PID: 242 (code=exited, status=0/SUCCESS)Les repos du projet Tor sont toujours les premiers à recevoir les upgrades. C'est extrêmement important. Nous allons donc les installer afin d'être au top. N'utilisez JAMAIS les paquets maintenus par les distributions car ces derniers sont bien trop souvent anciens et vulnérables.
Commencez par éditer /etc/apt/sources
# cat /etc/apt/sources
deb https://deb.torproject.org/torproject.org stretch main
deb-src https://deb.torproject.org/torproject.org stretch main
Ajoutez les PGP du repo :
# curl https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --import
# gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -
Et pour finir on update :
# apt update && apt install tor deb.torproject.org-keyring
On installe finalement Tor et Nyx sur la machine.
# apt install tor Nyx
Maintenant que vous avez les derniers binaires et que votre VM ressemble de loin à un serveur, l'environnement est prêt. il ne nous reste plus qu'à créer notre relai.
Par défaut sous OpenBSD on fait tourner le daemon tor(1) avec l’utilisateur _tor et on cloisonne l’exécutable sous pledge(2). C’est la première fois que j’exécute le démon sous Linux en mode serveur et j’étais très surpris de voir que l’option « User » n’est pas activée par défaut dans le torrc. Je ne sais pas trop s'il le fait automatiquement (ou s'il le lance avec l'utilisateur daemon au hasard) mais ce n'est vraiment pas explicite… dans le doute :
# sudo useradd _tor
# sudo usermod -s /sbin/nologin _tor
# id _tor
# uid=1001(_tor) gid=1001(_tor) groupes=1001(_tor)
Dans une prochaine version de ce tuto nous intégrerons un chroot optionnel mais pour le moment nous en resterons la… Nous allons maintenant modifier notre fichier /etc/tor/torrc. Vous trouverez la version complète de mon fichier de sur le git mais en substance ce que vous devez modifier / dé-commenter / ajouter se trouve ici :
User _tor # pour doper les privilèges
DataDirectory /var/lib/tor # Si on se sert de notre VM pour autre chose qu'un relay
Log notice file /var/log/tor/notices.log # oui on log ce que fait Tor autrepart que dans syslog
ControlPort 9051 # Pour Nyx
SocksPort 0 # pas de proxy SOCKS
RunAsDaemon 1 # on le fait tourner comme un daemon en background
ORPort 9001 # man torrc
Nickname RoxXoRNOde666 # Le nom de votre node de HaxXoR
ContactInfo TonMailDeRoxXor@hacker.com # le mail de contact. Utilisez un mail que vous allez lire mais aussi votre cerveau
DirPort 9030 # notre serveur sera un directory mirror (voir doc)
ExitPolicy reject *:* # ce n’est pas un noeud de sortie, on interdit l'écoute explicitement sur toutes les interfaces
Nous créons maintenant les fichiers nécessaires pour les logs.
# touch /var/log/tor/notices.log
# chown _tor:_tor /var/log/tor/notices.log
# chrmod 650 /var/log/tor/notices.log
Et on donne des droits à notre utilisateur _tor afin qu’il puisse écrire dans /var/lib/tor
# chown -R _tor:_tor /var/lib/torAssurez-vous que les droits UNIX sur les répertoires auxquels le démon a accès soient bien en 650 pour _tor:_tor si non il va vous rappeler à l’ordre au lancement. On check que tout s’exécute correctement :
# tor
May 11 20:09:59.818 [notice] Tor 0.3.5.14 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
May 11 20:09:59.819 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 11 20:09:59.821 [notice] Read configuration file "/etc/tor/torrc".
May 11 20:09:59.836 [notice] Opening Socks listener on 127.0.0.1:9050
May 11 20:09:59.836 [notice] Opened Socks listener on 127.0.0.1:9050
Pas d'erreur ni de warning, la classe. Votre node de roxXor est bientôt prêt. On upgrade le système, on active le daemon et on reboot !
# systemctl enable tor
# apt update && apt full-upgrade && systemctl rebootwooOOT !
A ce stade votre relai est lancé. Comme pour n'importe quel serveur vous avez besoin de l'auditer, savoir combien de bande passante il consomme etc. nyx(1) est la pour vous aider ! Nyx c'est un outil qu'il est bien. Il va vous permettre d'observer en mode console votre trafic de manière semi-graphique un peu comme htop. Nous l'avons déjà installé plus haut. Nous avons déjà écrit le nécessaire à son fonctionnement dans notre /etc/tor/torrc il ne nous reste plus qu'à le lancer !
Je vous laisse checker la doc à cet endroit ainsi que dans le manuel e nyx(1). Ce qu'il y a de bien avec Nyx c'est qu'on peut faire beaucoup de choses. Il n'est pas indispensable pour tout mais toujours le bienvenu pour avoir un visuel sur nos ressources, c'est l'outil un peu eye candy de Tor ! Vous remarquerez que les notices s'affichent ici, bref il vous le faut.
En ouvrant Nyx vous avez sûrement remarqué la ligne Bandwidth (limit: 1 GB/s, burst: 1 GB/s)C'est que Tor va vous pomper votre bande passante. Beaucoup plus que vous ne le pensez surtout lorsque l’algorithme de Tor va juger votre serveur “apte à prendre du gros trafic”. Si vous opérez un relai il va saturer votre NIC. J'ai une grosse connexion et le fait que ma VM consomme 1Gb ne me gêne pas mais je comprendrais si vous vouliez ajouter cette petite option à la fin de votre /etc/tor/torrc :
RelayBandwidthRate 40000 KBytes
RelayBandwidthBurst 100000 KBytesIl existe d'autres options (comme pour tout avec Tor) mais je vous laisse les découvrir.
Comme vous l'avez constaté un relai Tor n'est vraiment pas compliqué à mettre en prod… Le travail que cela demande est quasi nul. Prenez le temps de donner un peu d'amour à votre VM avec un joli cron(8) de mise à jour automatique et un petit reboot par semaine. Je vais créer un papier dans ce wiki avec tout ça mais en attendant, RTFM. N'oubliez jamais que lorsque vous maintenez un relai Tor vous avez la responsabilité de la sécurité des autres, à savoir des gens qui ont un besoin impérieux de ne jamais divulguer leur identité. Si vous êtes capable de créer un relai vous êtes aussi capable de créer un cron et de maintenir votre VM dans des conditions opérationnelles optimales.
Un Hidden Service, dans le jargon de Tor, peut être n'importe quoi : un site web qui écoute sur les ports classiques (dans Tor), un service de VoIP, un serveur de messagerie… Il s'agit d'un serveur à l’intérieur du réseau Tor et qui ne sort pas de Tor. Si votre NextCloud écoute sur Tor alors votre Nextcloud est un hidden service. Le mécanisme avec lequel votre serveur se connecte à Tor est sensiblement le même que si votre poste était un simple client à la différence que le démon Tor va exposer les ports de votre choix. Je ne vais pas expliquer comment créer un serveur web dans cet article mais comment faire en sorte que le démon Tor route correctement les ports appropriés.
Note à propos des Hidden Services 2 : Si vous cherchez des ressources au sujet des hidden services vous verrez que l'on parle souvent de “hidden services V2” et “hidden services ”V3". Sachez que l'ancien protocole (V2) ne sera plus supporté en octobre 2021 donc ce tuto ne vous expliquera pas comment vous en servir.
Beaucoup de gens utilisent Tor pour “rester anonymes sur Internet" et se prennent pour des hackers. Mon imaginaire les voit plutôt comme ça. Je pense sincèrement que sortir (sur Internet) via Tor est une bêtise pour des tonnes de raisons très valables. Je pense que Tor ne doit pas servir à naviguer sur Internet puisque les exit relays voient passer vos requêtes… Même en SSL cela pose problème car les exit nodes ont évidement une position bien confortable, récemment un hacker s'est créé des tonnes d'exits nodes toutes équipées de sslstrip et ça représente 27% des sorties. Si Tor n'est pas une solution idéale pour naviguer sur Internet Tor est extrêmement efficace lorsqu'il s'agit de rester dans Tor. Si vous opérez vous-même le service c'est encore mieux.
Nous allons aussi voir plus loin dans cet article qu'un Hidden Service peut être classique mais aussi “stealth” et… Pas caché du tout. Si votre HS ne fait rien de bizarre et que vous souhaitez juste offrir la possibilité à vos utilisateurs de le visiter via Tor pour protéger leur propre anonymat c'est très possible. Le serveur de Facebook ne se cache pas par exemple, il permet en revanche aux personne vivant dans des pays “compliqués” de s'y connecter sans avoir besoin de “sortir” via un exit node ce qui comme nous l'avons vu est très appréciable.
Nous allons commencer par créer un serveur ssh joignable dans Tor comme un hidden service. C'est un exemple simple mais qui peut s'avérer utile. Reprenons notre machine Debian la ou nous en étions. Nous allons commencer par désactiver les options du relai dans /etc/tor/torrc
User _tor # pour doper les privilèges
DataDirectory /var/lib/tor # Si on se sert de notre VM pour autre chose qu'un relay
Log notice file /var/log/tor/notices.log # oui on log ce que fait Tor autrepart que dans syslog
ControlPort 9051 # Pour Nyx
SocksPort 0 # pas de proxy SOCKS
RunAsDaemon 1 # on le fait tourner comme un daemon en background
ORPort 9001 # man torrc
# Nickname RoxXoRNOde666 # Notre serveur n'est plus un relai,on commente
# ContactInfo TonMailDeRoxXor@hacker.com # Notre serveur n'est plus un relai,on commente
# DirPort 9030 # Notre serveur n'est plus un relai,on commente
ExitPolicy reject *:* # ce n’est pas un noeud de sortie, on interdit l'écoute explicitement sur toutes les interfaces
Le fichier /etc/tor/torrc est très clair et franchement bien fait. Rendons nous dans la partie intitulée ### This section is just for location-hidden services ### et faites la ressembler à ça :
############### This section is just for location-hidden services ###
## Once you have configured a hidden service, you can look at the
## contents of the file ".../hidden_service/hostname" for the address
## to tell people.
##
## HiddenServicePort x y:z says to redirect requests on port x to the
## address y:z.
HiddenServiceDir /var/lib/tor/openssh # le répertoire de notre HS
#HiddenServicePort 80 127.0.0.1:80
#HiddenServiceDir /var/lib/tor/other_hidden_service/
#HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 2222 127.0.0.1:22 # Depuis l'extérieur on écoute 2222 et on redirige vers 22 sur localhost
késako ?
HiddenServiceDir /var/lib/tor/openssh: Lorsque Tor va redémarrer il va aller écrire les clefs de chiffrement de votre hidden service dans ce répertoire. Il va aussi y stocker l'adresse en *.onion. Faites très attention aux droits sur ce répertoire car il est critique. Nous allons le créer plus bas.
HiddenServicePort 2222 127.0.0.1:22 : La beauté de tor c'est la simplicité. Imaginez-vous un NAT avec un port d'écoute et une redirection. Le démon écoute le port 2222 et le redirige sur le port 22 de localhost. le plus important c'est de toujours écouter 127.0.0.1. N'écoutez jamais une autre adresse car cela pourrait avoir des conséquences importantes sur la sécurité de votre serveur.
On s'en va créer /var/lib/tor/openssh
# mkdir /var/lib/tor/openssh
# chown -R _tor:_tor /var/lib/tor/openssh
# chmod 700 /var/lib/tor/opensshOn vérifie que les droits sont corrects :
# ls -alh
total 7,7M
drwx--S--- 4 _tor _tor 4,0K mai 12 10:46 .
drwxr-xr-x 30 root root 4,0K mai 11 17:48 ..
-rw------- 1 _tor _tor 20K mai 11 17:03 cached-certs
-rw------- 1 _tor _tor 2,2M mai 11 23:37 cached-microdesc-consensus
-rw------- 1 _tor _tor 5,5M mai 11 17:30 cached-microdescs
-rw------- 1 _tor _tor 47K mai 11 20:11 cached-microdescs.new
drwx--S--- 2 _tor _tor 4,0K mai 11 17:04 keys
-rw------- 1 _tor _tor 0 mai 12 00:42 lock
drwxr-sr-x 2 650 _tor 4,0K mai 12 10:46 openssh
-rw------- 1 _tor _tor 8,8K mai 12 00:42 state
Dans cet exemple nous n'allons pas nous attarder sur la sécurité de notre serveur ssh mais uniquement sur l'écoute de notre serveur. Il va de soi que si vous vouliez un véritable service vous installeriez sshguard et désactiveriez l'authentification par mot de passe, au minimum. Ce qui nous intéresse c'est surtout la manière dont le serveur ssh va écouter. Éditez votre /etc/ssh/sshd_config :
Port 22 # Dans notre exemple de torrc on redirige les requêtes 2222 (tor) vers 22 donc on écoute sur le port 22
#AddressFamily any
ListenAddress 127.0.0.1 # oui on écoute sur LocalHost puisque notre démon Tor écoute sur LocalHost... Et jamais autrement.
ListenAddress 192.168.1.17 # écouter localhost ne nous empêche pas de continuer à écouter sur notre interface classique.
#ListenAddress ::
Si tor est déjà lancé on le kill et on le relance depuis le terminal pour s'assurer que toutes les notices sont au vert :
# systemctl stop tor
# tor
May 12 11:04:36.357 [notice] Tor 0.3.5.14 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
May 12 11:04:36.357 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 12 11:04:36.357 [notice] Read configuration file "/etc/tor/torrc".
May 12 11:04:36.367 [notice] Opening Socks listener on 127.0.0.1:9050
May 12 11:04:36.367 [notice] Opened Socks listener on 127.0.0.1:9050
May 12 11:04:36.367 [notice] Opening Control listener on 127.0.0.1:9051
May 12 11:04:36.367 [notice] Opened Control listener on 127.0.0.1:9051Bon Tor se lance ça a l'air pas mal… Allons voir s'il a bien écrit les éléments nécessaires à notre HS OpenSSH dans /var/lib/tor/openssh :
# ls -lah /var/lib/tor/openssh/
total 24K
drwx--S--- 3 _tor _tor 4,0K mai 12 11:04 .
drwx--S--- 4 _tor _tor 4,0K mai 12 11:06 ..
drwx--S--- 2 _tor _tor 4,0K mai 12 11:04 authorized_clients
-rw------- 1 _tor _tor 63 mai 12 11:04 hostname
-rw------- 1 _tor _tor 64 mai 12 11:04 hs_ed25519_public_key
-rw------- 1 _tor _tor 96 mai 12 11:04 hs_ed25519_secret_key
Comme vous pouvez le constater le démon Tor a écrit des choses dans notre répertoire qui n'est plus vide du tout. Quelques explications :
drwx--S--- 2 _tor _tor 4,0K mai 12 11:04 authorized_clients : nous verrons l'utilité de ce répertoire avec les hidden services stealth.
-rw------- 1 _tor _tor 63 mai 12 11:04 hostname : l'adresse de votre serveur ssh en *.onion.
-rw------- 1 _tor _tor 64 mai 12 11:04 hs_ed25519_public_key : la clef publique de votre serveur.
-rw------- 1 _tor _tor 96 mai 12 11:04 hs_ed25519_secret_key : A chaque fois que les droits ne sont pas corrects sur ce fichier un bébé chat décède quelque part dans le monde.
Notez que si le démon trouve des problèmes au moment de son lancement en particulier au niveau des droits, les notices vous le diront, c'est très bien fait. Allons chercher notre hostname de hacker :
# cat /var/lib/tor/openssh/hostname
bz5tu5d6vqblla4ioccd6rng3o6rubqe55h6tm4oagapjk9behjdgfqd.onion
A ce stade si vous veniez de créer un serveur web vous pourriez immédiatement lui rendre visite avec Tor-Browser mais notre cas de figure est un serveur ssh… Nous allons devoir configurer le démon Tor de notre client pour y accéder, c'est ce qui rend ce service intéressant pour apprendre Tor. Sur votre poste, lancez un Terminal. Si vous êtes sous Windows ou Mac, installez Linux (rappelez-vous, on ne se rend pas sur Tor avec ces systèmes). Cet exemple de client se base sur Kali mais ça marche pareil partout.
On installe les paquets nécessaires (avec les repos officiels, c'est mieux…. Voir la première partie du tuto) :
# apt install tor torsocksAlors torsocks(8) est un outil extrêmement pratique qui va faire passer un flux réseau (comme une connexion ssh) par le proxy SOCKS que créé le démon Tor quand il se lance. Cela implique que notre client ait lui aussi un démon tor lancé. Les défauts de /etc/tor/torrc iront très bien pour notre client.
# systemctl enable --now tor 3 ⨯
Synchronizing state of tor.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable tor
Created symlink /etc/systemd/system/multi-user.target.wants/tor.service → /lib/systemd/system/tor.service.
Et la magie opère ! Utilisons torsocks comme préfixe à notre client ssh et connectons nous à notre serveur avec notre adrresse en *.onion sur le port d'écoute en 2222.
# torsocks ssh laudanum@bz5tu5d6vqblla4ioccd6rng3o6rubqe55h6tm4oagapjk9behjdgfqd.onion -p 2222 255 ⨯
The authenticity of host '[bz5tu5d6vqblla4ioccd6rng3o6rubqe55h6tm4oagapjk9behjdgfqd.onion]:2222 ([127.42.42.0]:2222)' can't be established.
ECDSA key fingerprint is SHA256:KF3IIltCCSTjf1bpcRN58y6UENJGMx55Axcjw/KXxt4.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[bz5tu5d6vqblla4ioccd6rng3o6rubqe55h6tm4oagapjk9behjdgfqd.onion]:2222' (ECDSA) to the list of known hosts.
laudanum@bz5tu5d6vqblla4ioccd6rng3o6rubqe55h6tm4oagapjk9behjdgfqd.onion's password:
Linux debian-tor 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed May 12 10:27:11 2021 from 10.0.0.69
Nous venons de créer un serveur ssh et de nous y connecter via Tor. Comme vous l'avez remarqué nous n'avons créé aucune règle de NAT sur notre firewall, rien. C'est parce que Tor bypass preque tout (nous y reviendrons en détails, c'est très important). Le “port d'écoute TCP” du démon Tor n'a de valeur que dans Tor, notre routeur lui pourrait être en full deny en entrée… C'est d'ailleurs le cas de ma VM de test dans cet exemple. De son côté OpenSSH écoute sur ses port habituels. Vous devez voir cette ligne de torrc comme une redirection sur un firewall : HiddenServicePort 2222 127.0.0.1:22
note : puisque aucun port n'est nécessairement ouvert pour faire écouter un HS Tor sur le réseau vous imaginez bien qu'il faudra dégainer un packet sniffer et voir le trafic Tor dans la trame pour détecter la présence de Tor au réseau. J'espère que ça vous donne quelques idées.