miroir de
https://github.com/PAPAMICA/Wiki-Tech.io.git
synchronisé 2024-11-18 23:40:34 +01:00
557 lignes
62 Kio
HTML
557 lignes
62 Kio
HTML
<!--
|
||
title: Réseau - Tor
|
||
description: Comprendre et utiliser le réseau Tor
|
||
published: false
|
||
date: 2021-05-20T14:35:27.075Z
|
||
tags: linux, tor, réseau
|
||
editor: ckeditor
|
||
dateCreated: 2021-05-11T19:26:41.152Z
|
||
-->
|
||
|
||
<figure class="image image_resized" style="width:30.58%;"><img src="https://upload.wikimedia.org/wikipedia/commons/thumb/1/15/Tor-logo-2011-flat.svg/1200px-Tor-logo-2011-flat.svg.png" alt="Tor (réseau) — Wikipédia"></figure>
|
||
<h1 style="text-align:justify;">Avant propos</h1>
|
||
<p style="text-align:justify;">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.</p>
|
||
<p style="text-align:justify;"><a href="https://en.wikipedia.org/wiki/Tor_(anonymity_network)">La page Wikipedia</a></p>
|
||
<p style="text-align:justify;"><a href="https://gitlab.torproject.org/tpo/team/-/wikis/home">L'incontournable documentation de Tor</a></p>
|
||
<p style="text-align:justify;">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.</p>
|
||
<h1 style="text-align:justify;">Un middle relay Tor sous Debian</h1>
|
||
<h2 style="text-align:justify;"><span class="text-big">Opérer un nœud Tor</span></h2>
|
||
<p style="text-align:justify;">Comme vous l’avez lu dans la documentation, lorsque vous vous connectez à 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 » (« hop » 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 <a href="https://support.torproject.org/tbb/tbb-editing-torrc/">/etc/tor/torrc</a> 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 souhaitiez expérimenter 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.</p>
|
||
<p style="text-align:justify;">Il existe <a href="https://community.torproject.org/relay/types-of-relays/">plusieurs types de relais</a> et les héberger est plus ou moins dangereux pour l’opérateur (vous-même). 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.</p>
|
||
<p style="text-align:justify;">Un relais intermédiaire (<i>middle relay</i>) 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 démon Tor du 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 mais son adresse IP est publique. Si vous opérez un middle relay l'adresse IP de ce dernier est connue et Tor était toujours attaqué votre noeud sera une cible. Il vous faut donc l'administrer avec soir et le maintenir dans d'excellentes conditions en termes de sécurité. </p>
|
||
<p style="text-align:justify;">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 « <i>d’entry guard </i>» (ou simplement « <i>guard </i>») 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.</p>
|
||
<h2 style="text-align:justify;"><span class="text-big">Création de la machine virtuelle</span></h2>
|
||
<h3 style="text-align:justify;"><br><strong>Préparation de la VM</strong></h3>
|
||
<p style="text-align:justify;">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 depuis les ports 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 quelque chose de choquant n’hésitez pas à le signaler.</p>
|
||
<p style="text-align:justify;">Pour créer la VM, quelques conseil sur les ressources :</p>
|
||
<figure class="table">
|
||
<table>
|
||
<tbody>
|
||
<tr>
|
||
<td><strong>HDD :</strong> 5Go<br><strong>CPU :</strong> 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. En tous cas Tor est multi-threadé et appréciera les ressources que vous allez lui attribuer.<br><strong>Mémoire :</strong> 512Mo si vous opérez moins de 40Mb en bande 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.<br><strong>Réseau :</strong> 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 n<strong>é</strong>cessaire il est toujours confortable de pouvoir accéder à votre machine via OpenSSH.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</figure>
|
||
<p style="text-align:justify;"><br><i>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 vous 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 </i><a href="https://fr.wikipedia.org/wiki/Serveur_informatique"><i>serveur.</i></a></p>
|
||
<h3 style="text-align:justify;"><strong>Préparation de l'environnement</strong></h3>
|
||
<p style="text-align:justify;">Commencez par vérifier que votre VM voit bien les instructions AES-NI sur votre CPU.</p>
|
||
<pre><code class="language-plaintext"># lscpu | grep aes</code></pre>
|
||
<p style="text-align:justify;"><br>Un relais Tor est extrêmement simple… N’installez que le strict nécessaire sur votre machine (<a href="https://en.wikipedia.org/wiki/KISS_principle">KISS</a>):</p>
|
||
<pre><code class="language-plaintext"># apt install -y net-tools sudo vim</code></pre>
|
||
<p style="text-align:justify;"><br>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 :</p>
|
||
<pre><code class="language-plaintext">$ 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
|
||
</code></pre>
|
||
<p style="text-align:justify;"><br>On redémarre le réseau :</p>
|
||
<pre><code class="language-plaintext"># systemctl restart networking</code></pre>
|
||
<p style="text-align:justify;"><br>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 :</p>
|
||
<pre><code class="language-plaintext"># 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</code></pre>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;">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.</p>
|
||
<pre><code class="language-plaintext"># 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)</code></pre>
|
||
<p style="text-align:justify;">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 <strong>JAMAIS</strong> les paquets maintenus par les distributions car ces derniers sont bien trop souvent anciens et vulnérables.</p>
|
||
<p style="text-align:justify;">Commencez par éditer <code>/etc/apt/sources</code></p>
|
||
<pre><code class="language-plaintext"># cat /etc/apt/sources
|
||
deb https://deb.torproject.org/torproject.org stretch main
|
||
deb-src https://deb.torproject.org/torproject.org stretch main</code></pre>
|
||
<p style="text-align:justify;"><br>Ajoutez les PGP du repo : </p>
|
||
<pre><code class="language-plaintext"># curl https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --import
|
||
# gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -</code></pre>
|
||
<p style="text-align:justify;"><br>Et pour finir on update : </p>
|
||
<pre><code class="language-plaintext"># apt update && apt install tor deb.torproject.org-keyring</code></pre>
|
||
<p style="text-align:justify;"><br>On installe finalement Tor et Nyx sur la machine. </p>
|
||
<pre><code class="language-plaintext"># apt install tor Nyx</code></pre>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;">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. </p>
|
||
<h2 style="text-align:justify;"><span class="text-big">Configuration du relai</span></h2>
|
||
<p style="text-align:justify;"><br>Par défaut sous OpenBSD on fait tourner le démon <code>tor(1)</code> avec l’utilisateur <code>_tor</code> et on cloisonne l’exécutable sous <a href="https://man.openbsd.org/pledge.2">pledge(2)</a>. 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 : </p>
|
||
<pre><code class="language-plaintext"># sudo useradd _tor
|
||
# sudo usermod -s /sbin/nologin _tor
|
||
# id _tor
|
||
# uid=1001(_tor) gid=1001(_tor) groupes=1001(_tor)</code></pre>
|
||
<p style="text-align:justify;"><br>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 <code>/etc/tor/torrc</code>. 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 : </p>
|
||
<pre><code class="language-plaintext">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 la sortie explicitement sur toutes les interfaces</code></pre>
|
||
<p style="text-align:justify;"><br>Nous créons maintenant <code>/var/log/tor/notices.log</code> pour… les logs (hohoho !)</p>
|
||
<pre><code class="language-plaintext"># touch /var/log/tor/notices.log
|
||
# chown _tor:_tor /var/log/tor/notices.log
|
||
# chrmod 650 /var/log/tor/notices.log</code></pre>
|
||
<p style="text-align:justify;">Si vous souhaitez débuger Tor ou avoir une meilleure granularité vous allez voir que d'autres options sont à votre disposition. Pour faire fonctionner un relai au quotidien un niveau “notices” suffira. Le tout est surtout de bien créer ce fichier afin de séparer les logs Tor des logs système.</p>
|
||
<p style="text-align:justify;"><br>Et on donne des droits à notre utilisateur <code>_tor</code> afin qu’il puisse écrire dans <code>/var/lib/tor</code> </p>
|
||
<pre><code class="language-plaintext"># chown -R _tor:_tor /var/lib/tor</code></pre>
|
||
<p style="text-align:justify;">Assurez-vous que les droits UNIX sur les répertoires auxquels le démon a accès soient bien en 650 pour <code>_tor:_tor</code> si non il va vous rappeler à l’ordre au lancement. On check que tout s’exécute correctement :<br> </p>
|
||
<pre><code class="language-plaintext"># 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</code></pre>
|
||
<p style="text-align:justify;"><br>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 démon et on reboot !</p>
|
||
<pre><code class="language-plaintext"># systemctl enable tor
|
||
# apt update && apt full-upgrade && systemctl reboot</code></pre>
|
||
<p style="text-align:justify;">wooOOT !</p>
|
||
<h2 style="text-align:justify;"><span class="text-big"><strong>Audit du trafic avec Nyx</strong></span></h2>
|
||
<p style="text-align:justify;">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. <code>nyx(1)</code> est la pour vous aider ! <i>Nyx c'est un outil qu'il est bien</i>. 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 et nous avons déjà écrit le nécessaire à son fonctionnement dans notre <code>/etc/tor/torrc</code> il ne nous reste plus qu'à le lancer !</p>
|
||
<p style="text-align:justify;"> </p>
|
||
<figure class="image image_resized" style="width:96.49%;"><img src="/nyx.png"></figure>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;">Je vous laisse checker la doc <a href="https://nyx.torproject.org/">à cet endroit</a> 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.</p>
|
||
<h2 style="text-align:justify;"><span class="text-big"><strong>Débits</strong></span></h2>
|
||
<p style="text-align:justify;">En ouvrant Nyx vous avez sûrement remarqué la ligne <code>Bandwidth (limit: 1 GB/s, burst: 1 GB/s)</code>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 beaucoup ne me gêne pas mais je comprendrais si vous vouliez ajouter cette petite option à la fin de votre <code>/etc/tor/torrc</code> :</p>
|
||
<p style="text-align:justify;"> </p>
|
||
<pre><code class="language-plaintext">RelayBandwidthRate 40000 KBytes
|
||
RelayBandwidthBurst 100000 KBytes</code></pre>
|
||
<p style="text-align:justify;">Il existe d'autres options (comme pour tout avec Tor) <a href="https://support.torproject.org/operators/limit-total-bandwidth/">mais je vous laisse les découvrir</a>. </p>
|
||
<h2 style="text-align:justify;"><span class="text-big"><strong>Maintenir le système à jour</strong></span></h2>
|
||
<p style="text-align:justify;">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 <code>cron(8)</code> 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, <a href="https://wiki.debian.org/UnattendedUpgrades">RTFM</a>. N'oubliez jamais que lorsque vous maintenez un relai Tor vous avez la responsabilité de la sécurité des autres, à savoir <a href="https://en.wikipedia.org/wiki/Internet_censorship_in_China">des gens qui ont un besoin impérieux</a> 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.</p>
|
||
<hr>
|
||
<h1 style="text-align:justify;">Un hidden service</h1>
|
||
<h2 style="text-align:justify;">Présentation</h2>
|
||
<p>Dans le jargon de Tor un Hidden Service 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.</p>
|
||
<p><i>Note à propos des Hidden Services V2 (HSv2) : 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. Le nouveau protocole (HSv3) est vraiment plus puissant bien qu'un tout petit peu plus complexe.</i></p>
|
||
<p>Beaucoup de gens utilisent Tor pour “rester anonymes sur Internet" et se prennent pour des hackers. <a href="https://www.niussp.org/wp-content/uploads/2016/11/Old_people2.jpg">Mon imaginaire les voit plutôt comme ça</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 <a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack">une position bien confortable</a>, récemment un hacker s'est créé des tonnes d'exits nodes toutes équipées de sslstrip et <a href="https://thehackernews.com/2021/05/over-25-of-tor-exit-relays-are-spying.html">ça représente 27% des sorties</a>. 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.</p>
|
||
<p><br>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 <a href="https://en.wikipedia.org/wiki/Facebookcorewwwi.onion">serveur de Facebook</a> 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.</p>
|
||
<h2>Installation</h2>
|
||
<p>Nous allons commencer par créer un serveur ssh joignable dans Tor comme un Hidden Service V3. 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 <code>/etc/tor/torrc</code></p>
|
||
<p> </p>
|
||
<pre><code class="language-plaintext">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</code></pre>
|
||
<p> </p>
|
||
<p>Le fichier <code>/etc/tor/torrc</code> est très clair et franchement bien fait. Rendons nous dans la partie intitulée <code>### This section is just for location-hidden services ###</code> et faites la ressembler à ça : </p>
|
||
<pre><code class="language-plaintext">############### 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</code></pre>
|
||
<p> </p>
|
||
<p>késako ?</p>
|
||
<p><code>HiddenServiceDir /var/lib/tor/openssh</code>: Lorsque Tor va redémarrer il va aller écrire les clefs de chiffrement de votre HS dans ce répertoire. Il va aussi y stocker l'adresse en <code>*.onion</code>. Faites très attention aux droits sur ce répertoire car il est critique. Nous allons le créer plus bas.</p>
|
||
<p><code>HiddenServicePort 2222 127.0.0.1:22</code> : 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.</p>
|
||
<p> </p>
|
||
<p>On s'en va créer <code>/var/lib/tor/openssh</code> </p>
|
||
<pre><code class="language-plaintext"># mkdir /var/lib/tor/openssh
|
||
# chown -R _tor:_tor /var/lib/tor/openssh
|
||
# chmod 700 /var/lib/tor/openssh</code></pre>
|
||
<p>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 <code>/etc/ssh/sshd_config</code> :</p>
|
||
<p> </p>
|
||
<pre><code class="language-plaintext">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 ::</code></pre>
|
||
<p> </p>
|
||
<p>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 avec nos nouveaux paramètres :</p>
|
||
<pre><code class="language-plaintext"># 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:9051</code></pre>
|
||
<p>Bon 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 <code>/var/lib/tor/openssh</code> au moment du lancement : </p>
|
||
<pre><code class="language-plaintext"># 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</code></pre>
|
||
<p><br>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 : </p>
|
||
<p><code>drwx--S--- 2 _tor _tor 4,0K mai 12 11:04 authorized_clients</code> : nous verrons l'utilité de ce répertoire avec les HS stealth.</p>
|
||
<p><code>-rw------- 1 _tor _tor 63 mai 12 11:04 hostname</code> : l'adresse de votre serveur ssh en <code>*.onion</code>. </p>
|
||
<p><code>-rw------- 1 _tor _tor 64 mai 12 11:04 hs_ed25519_public_key</code> : la clef publique de votre serveur.</p>
|
||
<p><code>-rw------- 1 _tor _tor 96 mai 12 11:04 hs_ed25519_secret_key</code> : 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.</p>
|
||
<p> </p>
|
||
<p>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 :</p>
|
||
<pre><code class="language-plaintext"># cat /var/lib/tor/openssh/hostname
|
||
bz5tu5d6vqblla4ioccd6rng3o6rubqe55h6tm4oagapjk9behjdgfqd.onion</code></pre>
|
||
<p> </p>
|
||
<p>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.</p>
|
||
<p>On installe les paquets nécessaires (avec les repos officiels, c'est mieux…. Voir la première partie du tuto) :</p>
|
||
<pre><code class="language-plaintext"># apt install tor torsocks</code></pre>
|
||
<p>Alors <code>torsocks(8)</code> 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é et à l'écoute. Les paramètres par défaut de <code>/etc/tor/torrc</code> iront très bien pour notre client. </p>
|
||
<pre><code class="language-plaintext"># 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.</code></pre>
|
||
<p> </p>
|
||
<p>Et la magie opère ! Utilisons <code>torsocks</code> comme préfixe à notre client ssh et connectons nous à notre serveur avec son adresse en <code>*.onion</code> sur le port d'écoute en 2222. </p>
|
||
<pre><code class="language-plaintext"># 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</code></pre>
|
||
<p>Lorsque vous voulez faire passer par Tor une application TCP, <code>torsocks</code> est une option extrêmement viable. <a href="https://tor.stackexchange.com/questions/20997/whats-the-difference-between-torify-usewithtor-tsocks-and-torsocks">D'autres outils existent</a> mais vous n'en aurez pas besoin, sachez juste qu'ils sont la.</p>
|
||
<p>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 presque tout (nous y reviendrons en détails, c'est très important). Le “<i>port d'écoute TCP</i>” 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 sur LocalHost. Vous devez voir cette ligne de torrc comme une redirection sur un firewall : <code>HiddenServicePort <strong>2222</strong> 127.0.0.1:<strong>22</strong></code></p>
|
||
<p><i>note : puisque aucun port n'est nécessairement ouvert pour trouver un HS Tor sur le réseau local vous imaginez bien qu'il faudra dégainer Wireshark pour détecter la présence de Tor au réseau. J'espère que ça vous donne quelques idées… Et encore, niveau obfuscation vous n'avez <u>vraiment rien vu</u> croyez moi (et continuez la lecture on commence juste à s'amuser !)</i></p>
|
||
<p> </p>
|
||
<h2><strong>Hidden Services Stealth V3 (HSv3)</strong></h2>
|
||
<p>Les<i> Hidden Services Stealth</i> sont un type particulier de de Hidden Services. Lorsque vous tentez de communiquer avec l'un d'entre eux vous aller tout d'abord envoyer un cookie (un <i>Auth Cookie </i>pour être exact). Si ce cookie correspond à une identité connue du serveur alors le démon Tor de ce dernier transmettra le paquet au service auquel vous souhaitez vous connecter. Si votre service est privé et que vous souhaitez le mettre à dispo de vos amis alors c'est ce qu'il vous faut. Le layer de sécurité supplémentaire qu'un HSv3 stealth offre est excellent. Il existe beaucoup de vecteurs d'attaque sur le réseau Tor mais ajouter ce type d'option permet réellement de gagner sûreté, je ne saurais suffisamment le recommander.</p>
|
||
<p><i>Plus loin dans l'article je vous montrerais comment auditer via Tor vos HS avec nmap et vous verrez à quel point un HS stealth est puissant. Dans cette config, si le AuthCookie n'est pas envoyé en préfixe d'une communication avec le serveur le démon Tor drop tous les paquets sans condition et ici pas de </i><a href="https://datatracker.ietf.org/doc/html/rfc793"><i>RFC 793</i></a><i> bizarre pour nous dire de répondre avec des RST à nos requêtes malformées, cette fois-ci Tor rulez ! <u>Imaginez un serveur qui n'existe que pour les utilisateurs authentifiés, le rêve</u> !</i><span class="text-small"><i> (au cas ou vous ne le remarquiez pas j'aime beaucoup écrire cet article).</i></span></p>
|
||
<p>Les HS Stealth V2 étaient déjà très performants et fonctionnaient simplement en auto-générant les AuthCookies des users lorsqu'on redémarrait <code>/usr/bin/tor</code>. Les HS V3 sont un peu plus compliqués puisqu'il faut générer des paires de clefs manuellement mais la complexité de ces dernières et le fait que l'on puisse les générer avec le moteur d'entropie de notre choix fait des Stealth V3 un incontournable.</p>
|
||
<p>Bob et Alice vont papoter un peu, faites chauffer ! Pour ce tuto je vais utiliser un script très simple (et très bien) <a href="https://github.com/pastly/python-snippits/blob/master/src/tor/x25519-gen.py">pompé ici</a>. Vous pouvez générer vos clefs de la manière de votre choix et d'ailleurs si le chiffrement vous intéresse<strong> n'utilisez surtout pas ce script</strong> mais plutôt votre cerveau. Bref pour notre machine Debian de RoxXor, normalement python (je veux dire pyton2) est déjà installé. On installe donc pip raipdos :</p>
|
||
<pre><code class="language-plaintext"># apt install python-pip</code></pre>
|
||
<p>Et on installe les dépendances de son script qu'il est bien :</p>
|
||
<pre><code class="language-plaintext"># pip install pynacl</code></pre>
|
||
<p>On se créé un petit espace dédié à nos scripts sur le serveur, on fait notre cuisine : </p>
|
||
<pre><code class="language-plaintext"># mkdir /root/scipts
|
||
# vim /root/scipts/keygen.py</code></pre>
|
||
<p>Puis on colle le script : </p>
|
||
<pre><code class="language-plaintext"># cat /root/scipts/keygen.py
|
||
#!/usr/bin/env python3
|
||
import base64
|
||
try:
|
||
import nacl.public
|
||
except ImportError:
|
||
print('PyNaCl is required: "pip install pynacl" or similar')
|
||
exit(1)
|
||
|
||
|
||
def key_str(key):
|
||
# bytes to base 32
|
||
key_bytes = bytes(key)
|
||
key_b32 = base64.b32encode(key_bytes)
|
||
# strip trailing ====
|
||
assert key_b32[-4:] == b'===='
|
||
key_b32 = key_b32[:-4]
|
||
# change from b'ASDF' to ASDF
|
||
s = key_b32.decode('utf-8')
|
||
return s
|
||
|
||
|
||
def main():
|
||
priv_key = nacl.public.PrivateKey.generate()
|
||
pub_key = priv_key.public_key
|
||
print('public: %s' % key_str(pub_key))
|
||
print('private: %s' % key_str(priv_key))
|
||
|
||
|
||
if __name__ == '__main__':
|
||
exit(main())</code></pre>
|
||
<p style="text-align:justify;"><br>Et on l'utilise !</p>
|
||
<pre><code class="language-plaintext"># python keygen.py
|
||
public: HJN3IK5HZVZR7JXO343JTKFATO5JHCBTZ3PQWRZWOCJMP3KY6VSQ
|
||
private: DK6XMZX7JJZNE464JI2HKIVANRT7ADDUS64PM5ERY6UMVDQW4BKQ</code></pre>
|
||
<p style="text-align:justify;"><br>On note notre sortie logique dans un coin…. Je veux dire <strong>la votre </strong>(<i>si vous utilisez cette paire de clefs vous n'irez pas loin dans la vie pauvre être inférieur</i>). Allez on édite <code>/var/lib/tor/openssh/authorized_clients/ton_user<strong>.auth_private</strong></code> et on y écrit notre clef . Nous devrions avoir quelque chose comme ça :</p>
|
||
<pre><code class="language-plaintext"># cat /var/lib/tor/openssh/authorized_clients/user01.auth_private
|
||
az5tu5d6vqblla2ioccd6rng3o6rubqe55h6tm4oagapjk4behjdgfqd:descriptor:x25519:HJN3IK5HZVZR7JXO343JTKFATO5JHCBTZ3PQWRZWOCJMP3KY6VSQ</code></pre>
|
||
<p style="text-align:justify;">Le format est donc : <code>adresse-en-onion-sans-le-onion<strong>:descriptor:x25519:</strong>la-clef-publique-en-entier</code></p>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;">On édite notre <code>/etc/tor/torrc</code> pour lui indiquer qu'on veut un service stealth et surtout on lui dit ou trouver la clef publique :</p>
|
||
<pre><code class="language-plaintext">ClientOnionAuthDir /var/lib/tor/openssh/authorized_clients</code></pre>
|
||
<p style="text-align:justify;">Toujours sur le serveur ajoutez ça à la fin de la section <code>### This section is just for location-hidden services ###</code></p>
|
||
<pre><code class="language-plaintext">ClientOnionAuthDir /var/lib/tor/openssh/authorized_clients</code></pre>
|
||
<p style="text-align:justify;"><strong>Sur le client </strong>ajoutez ça dans vote <code>/etc/tor/torrc</code> : </p>
|
||
<pre><code class="language-plaintext">ClientOnionAuthDir /var/lib/tor/authorized_clients # toujours dans la même section</code></pre>
|
||
<p style="text-align:justify;"><strong>Toujours sur le client</strong> on créé le répertoire qui va contenir notre clefs (bon voilà depuis que j'ai commencé ce tuto j'ai vu le user <code>debian-tor</code>, on va l'utiliser sur notre client)</p>
|
||
<pre><code class="language-plaintext"># mkdir /var/lib/tor/authorized_clients
|
||
# chmod -R 700 /var/lib/tor/authorized_clients
|
||
# chown -R debian-tor:debian-tor /var/lib/tor/authorized_clients
|
||
# vim /var/lib/tor/authorized_clients/user01.auth_private</code></pre>
|
||
<p>Et on y écrit notre clef privée toujours sous le même format que la clef publique à savoir :</p>
|
||
<p><code>adresse-en-onion-sans-le-onion<strong>:descriptor:x25519:</strong>la-clef-privée-en-entier</code></p>
|
||
<p> </p>
|
||
<pre><code class="language-plaintext"># cat /var/lib/tor/authorized_clients/user01.auth_private
|
||
az5tu5d6vqblla2ioccd6rng3o6rubqe55h6tm4oagapjk4behjdgfqd:descriptor:x25519:DK6XMZX7JJZNE464JI2HKIVANRT7ADDUS64PM5ERY6UMVDQW4BKQ</code></pre>
|
||
<p> </p>
|
||
<p style="text-align:center;"><span class="text-big">Un petit récapitulatif de ce que l'on vient de faire</span></p>
|
||
<figure class="table">
|
||
<table>
|
||
<tbody>
|
||
<tr>
|
||
<td>
|
||
<p style="text-align:justify;">0. Installer ce qu'il faut pour exécuter notre script python lamentablement volé à quelqu'un d'autre et générer les clefs. <br><br>1. Ajouter <code>ClientOnionAuthDir /chemin/vers/les/clefs/</code> dans <code>/etc/tor/torrc</code> sur le client et le serveur et bien gérer les droits sur les répertoires en question.</p>
|
||
<p style="text-align:justify;">2. Créer les paires de clefs et les écrire dans <code>/chemin/vers/les/clefs/clef-privée.auth_private</code> sur le client et <code>/chemin/vers/les/clefs/clef-publique.auth_private</code> sur le serveur.</p>
|
||
<p style="text-align:justify;">3. Redémarrer Tor sur le serveur ainsi que le client.</p>
|
||
</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</figure>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;">On peut tester notre HS en se reconnectant : tout fonctionne ! A ce stade si tout se passe bien vous devriez commencer à bien comprendre comment Tor Daemon va lire et écrire dans /var/lib et quelle est l'utilité de chaque fichiers. Je vous invite à tester avec des serveurs web et ce qui vous passe par la tête afin de bien maîtriser les services cachés. “<i>Il n'y a qu'en forgeant…</i>” :)</p>
|
||
<p style="text-align:justify;"> </p>
|
||
<h1 style="text-align:justify;"><strong>ONIONCAT</strong></h1>
|
||
<figure class="image image_resized image-style-align-left" style="width:10.85%;"><img src="/cat.png"></figure>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;">(meow)</p>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;"> </p>
|
||
<h2 style="text-align:justify;">Présentation</h2>
|
||
<p style="text-align:justify;">Depuis que nous avons commencé ce tuto je n'ai absolument pas abordé le sujet mais Tor ne peut router que du TCP et rien d'autre. C'est comme ça. Ne me demandez pas pourquoi, beaucoup de gens bien plus intelligents que moi pourraient répondre à cette question. Tor c'est TCP. Alors c'est la que vous allez me dire “<i>mais j'ai envie d'utiliser d'autres flux que du TCP moi, j'ai envie de créer un serveur de VoIP et même… Des DNS !</i>”. Et bien moi aussi mon pt'it ! haha !</p>
|
||
<p style="text-align:justify;">Il y a quelques temps deux types (Daniel Haslinger, Bernhard Fischer) on décidé qu'ils allaient développer <a href="https://www.onioncat.org/">Onioncat</a>. Cet outil hyper élégant présenté ici <a href="https://www.youtube.com/watch?v=rx4rS1gvp7Y">en vidéo</a> qui permet de faire transiter n'importe quel type de flux dans Tor via une interface TUN : de l'UDP, de l'ICMP bref, n'importe quoi. L'idée c'est d'installer Onioncat sur un serveur et sur un client… De chaque côté Onioncat va créer une interface TUN et lui attribuer une adresse IP de manière arbitraire (nous verrons comment parce que c'est la classe). A partir de ce moment les autres hosts équipés d'Onioncat et connectés à Tor vont pouvoir la joindre sur cette IP. Tout ce qui passe dans l'if TUN est routé dans Tor. Il va de soi qu'il s'agit d'une encapsulation car Tor ne comprend toujours que TCP mais c'est totalement transparent pour les applications qui elles peuvent utiliser n'importe quel protocole de couche 3 et supérieur sur le modèle TCP/IP.</p>
|
||
<p style="text-align:justify;">Un autre point important que je souhaite éclaircir, Onioncat ne chiffre rien lui-même et confie entièrement cette tâche au démon Tor. Quand vous allez envoyer des paquets dans l'interface TUN cette dernière va simplement les envoyer en clair au démon Tor qui fera ce qu'il fait toujours : les chiffrer plusieurs fois en les ré-encapsulant en AES et les envoyer par la route qu'il aura créé dans le réseau Tor. C'est simple mais tellement efficace et surtout infiniment pratique. Cela veut dire que le chiffrement de vos applications est toujours très loin d'être une option. Dans Tor traditionnellement on chiffre tous les flux.<br> </p>
|
||
<h2 style="text-align:justify;">Installation</h2>
|
||
<p style="text-align:justify;">Sous OpenBSD Onioncat est maintenu dans les ports, il y a même un joli binaire mais sous Debian apparemment il faut le compiler (ma version de Debian ne contient pas les paquets, ils y étaient avant mais je pense qu'il ne sont plus maintenus). </p>
|
||
<pre><code class="language-plaintext"># apt install autoconf automake git
|
||
# mkdir /tmp/comp && cd /tmp/comp
|
||
# git clone https://github.com/rahra/onioncat
|
||
# cd /onioncat
|
||
# autoreconf -f
|
||
# ./configure
|
||
# make
|
||
# make install</code></pre>
|
||
<p style="text-align:justify;">On check tout ça : </p>
|
||
<pre><code class="language-plaintext">debian-tor:~/ocat/onioncat# ls -lah
|
||
total 732K
|
||
drwxr-xr-x 11 root root 4,0K mai 13 11:32 .
|
||
drwxr-xr-x 3 root root 4,0K mai 13 11:30 ..
|
||
-rw-r--r-- 1 root root 41K mai 13 11:32 aclocal.m4
|
||
drwxr-xr-x 2 root root 4,0K mai 13 11:30 android
|
||
-rw-r--r-- 1 root root 262 mai 13 11:30 AUTHORS
|
||
drwxr-xr-x 2 root root 4,0K mai 13 11:32 autom4te.cache
|
||
-rw-r--r-- 1 root root 12K mai 13 11:30 ax_pthread.m4
|
||
-rw-r--r-- 1 root root 5,2K mai 13 11:30 ChangeLog
|
||
-rwxr-xr-x 1 root root 7,2K mai 13 11:30 compile
|
||
-rwxr-xr-x 1 root root 42K mai 13 11:30 config.guess
|
||
-rw-r--r-- 1 root root 5,5K mai 13 11:32 config.h
|
||
-rw-r--r-- 1 root root 5,1K mai 13 11:32 config.h.in
|
||
-rw-r--r-- 1 root root 62K mai 13 11:32 config.log
|
||
-rwxr-xr-x 1 root root 34K mai 13 11:32 config.status
|
||
-rwxr-xr-x 1 root root 36K mai 13 11:30 config.sub
|
||
-rwxr-xr-x 1 root root 182K mai 13 11:32 configure
|
||
-rw-r--r-- 1 root root 5,7K mai 13 11:30 configure.ac
|
||
-rw-r--r-- 1 root root 35K mai 13 11:30 COPYING
|
||
drwxr-xr-x 2 root root 4,0K mai 13 11:30 debian
|
||
-rwxr-xr-x 1 root root 24K mai 13 11:30 depcomp
|
||
drwxr-xr-x 2 root root 4,0K mai 13 11:30 freebsd
|
||
drwxr-xr-x 8 root root 4,0K mai 13 11:30 .git
|
||
-rw-r--r-- 1 root root 141 mai 13 11:30 .gitignore
|
||
-rw-r--r-- 1 root root 19K mai 13 11:30 GitLog
|
||
-rw-r--r-- 1 root root 529 mai 13 11:30 glob_id.txt
|
||
-rw-r--r-- 1 root root 104 mai 13 11:30 hosts.onioncat
|
||
drwxr-xr-x 2 root root 4,0K mai 13 11:32 i2p
|
||
-rw-r--r-- 1 root root 16K mai 13 11:30 INSTALL
|
||
-rwxr-xr-x 1 root root 15K mai 13 11:30 install-sh
|
||
-rw-r--r-- 1 root root 27K mai 13 11:32 Makefile
|
||
-rw-r--r-- 1 root root 114 mai 13 11:30 Makefile.am
|
||
-rw-r--r-- 1 root root 27K mai 13 11:32 Makefile.in
|
||
drwxr-xr-x 2 root root 4,0K mai 13 11:32 man
|
||
-rwxr-xr-x 1 root root 6,8K mai 13 11:30 missing
|
||
-rw-r--r-- 1 root root 67 mai 13 11:30 NEWS
|
||
-rwxr-xr-x 1 root root 442 mai 13 11:30 ocat-ifup
|
||
lrwxrwxrwx 1 root root 9 mai 13 11:30 README -> README.md
|
||
-rw-r--r-- 1 root root 15K mai 13 11:30 README.md
|
||
drwxr-xr-x 4 root root 4,0K mai 13 11:33 src
|
||
-rw-r--r-- 1 root root 23 mai 13 11:32 stamp-h1
|
||
drwxr-xr-x 2 root root 4,0K mai 13 11:30 systemd
|
||
-rw-r--r-- 1 root root 1,8K mai 13 11:30 TODO</code></pre>
|
||
<p style="text-align:justify;">Et on essaye de le lancer.</p>
|
||
<pre><code class="language-plaintext">debian-tor:~/ocat/onioncat# ocat
|
||
onioncat 0.3.8 (c) Bernhard R. Fischer (OnionCat mode)
|
||
usage: ocat [OPTIONS] <onion_hostname>
|
||
-a create connect log at "$HOME/.ocat/ocat_connect_log" (default = 0)
|
||
-b daemonize (default = 1)
|
||
-B do not daemonize (default = 0)
|
||
-h display usage message
|
||
-H toggle hosts lookup (default = 0, see also option -g)
|
||
-C disable local controller interface
|
||
-d <n> set debug level to n, default = 7
|
||
-e <ifup-script> execute ifup-script after opening interface
|
||
-f <config_file> read config from config_file (default = /usr/local/etc/ocat.conf)
|
||
-g <hosts_path> set path to hosts file for hosts lookup, defaults to system hosts file, if not set.
|
||
This option implicitly activates -H.
|
||
-i convert onion hostname to IPv6 and exit
|
||
-I GarliCat mode, use I2P instead of Tor
|
||
-l [<ip>:]<port> set ocat listen address and port, default = 127.0.0.1:8060
|
||
-L <log_file> log output to <log_file> (default = stderr)
|
||
-n <tunname> set the tun device name, may contain format string (e.g. tun%d)
|
||
-o <ipv6_addr> convert IPv6 address to onion url and exit
|
||
-p use TAP device instead of TUN
|
||
-P [<pid_file>] create pid file at location of <pid_file> (default = /var/run/ocat.pid)
|
||
-r run as root, i.e. do not change uid/gid
|
||
-R generate a random local onion URL
|
||
-s <port> set hidden service virtual port, default = 8060
|
||
-t [<ip>:]<port> set Tor SOCKS address and port, default = 127.0.0.1:9050
|
||
-T <tun_device> path to tun character device, default = "/dev/net/tun"
|
||
-U disable unidirectional mode
|
||
-u <user> change UID to user, default = "tor"
|
||
-4 enable IPv4 support (default = 0)
|
||
-5 [socks5|direct] use SOCKS5 or direct connections instead of SOCKS4A (default = 0)</code></pre>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;">Pour le moment Tor écoute sur 2222 et le serveur ssh écoute 22/TCP sur 127.0.0.1. Par ailleurs notre démon Tor n'accepte que les connexions de notre poste (<strong>pour le service ssh uniquement et pas les autres</strong>) puisque nous avons le AuthCookie et que notre HS est stealth. Cela ne veut pas dire que Onioncat aura besoin d’utilisateurs authentifiés, libre à vous de déclarer <code>ClientOnionAuthDir</code> pour Onioncat et de généerr de nouvelles paires de clefs ce qui serait un joli hardening à votre Tor-VPN.</p>
|
||
<p style="text-align:justify;">C'est le moment de créer notre interface TUN avec Onioncat mais vous ne vous en sortirez pas sans savoir comment ça fonctionne (au moins dans les grandes lignes) bande de script kiddies. Quand vous allez lancer Onioncat, l'outil va utiliser un driver particulier (celui de OpenVPN) pour créer l'interface TUN. Après il va chopper l'adresse en <code>*.onion</code> de votre host (que vous lui donnerez en entrée au moment du lancement) et via un mécanisme de hash il va créer une <i>adresse IP pseudo-unique</i>. De base, les développeurs d'Onioncat recommandent l'usage d'IP6 parce que faire un hash d'un <code>*.onion</code> comme ça <code>az5tu5d6vqblla2ioccd6rng3o6rubqe55h6tm4oagapjk4behjdgfqd.onion</code> et le transformer en IP6 comme ça <code>2001:db8:3c4d:15:7c37:e7d1:fc9c:d2cb/64</code> fait que <a href="https://fr.wikipedia.org/wiki/Collision_(informatique)">les collisions</a> (<i>si vous ne savez pas ce qu'est une collision merci de lire avant de continuer</i>) sont bien moins probables qu'avec une adresse comme ça <code>10.0.1.56</code> et qu'en théorie vous êtes le SEUL à avoir cette adresse IP6 sur l'ensemble du réseau Tor. L'option <code>-4</code> existe, vous pouvez l'utiliser mais ne le faites que si l'outil que vous souhaitez utiliser dans le tunel n'est pas compatible avec IP6.</p>
|
||
<p style="text-align:justify;">Bref, Onioncat est géré comme n'importe quel HS sur votre système. Comme vous l'avez compris Tor peut être configuré pour servir autant de HS que vous désirez sur un seul et même système (une seule instance du démon), chaque HS ayant son propre répertoire, sa propre identité, ses propres clefs et surtout sa propre adresse en <code>*.onion</code>. Cela signifie que vous pouvez garder votre HSv3 OpenSSH actif et créer un autre HSv3 pour Onioncat sans aucun problème. Commençons par éditer notre <code>/etc/tor/torrc</code> afin de lui signifier la présence d'Onioncat à la suite de notre HS OpenSSH !</p>
|
||
<p style="text-align:justify;"> </p>
|
||
<pre><code class="language-plaintext">############### 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
|
||
HiddenServicePort 2222 127.0.0.1:22
|
||
ClientOnionAuthDir /var/lib/tor/openssh/authorized_clients
|
||
|
||
HiddenServiceDir /var/lib/tor/onioncat/ # nous allons créer ce répertoire
|
||
HiddenServicePort 8060 127.0.0.1:8060 # Le port par défaut de Onioncat est le 8060... Il écoute toujours sur localhost</code></pre>
|
||
<p style="text-align:justify;">Ensuite on créé l'environnement du service : </p>
|
||
<pre><code class="language-plaintext"># mkdir onioncat
|
||
# chown _tor:_tor onioncat
|
||
# chmod 700 onioncat/
|
||
# touch /var/lib/tor/onioncat/hosts.oc && chmod 700 /var/lib/tor/onioncat/hosts.oc && chown _tor:_tor /var/lib/tor/onioncat/hosts.oc</code></pre>
|
||
<p style="text-align:justify;">Concernant la dernière ligne nous y reviendrons mais c'est un prérequis un peu lourd pour les HSv3 avec Onioncat.</p>
|
||
<p style="text-align:justify;">Avant de pouvoir lancer Onioncat il nous faut notre adresse en <code>*.onion</code> pour ce service. Il faut donc redémarrer Tor afin qu'il la génère.</p>
|
||
<pre><code class="language-plaintext"># systemctl restart tor
|
||
# cat /var/lib/tor/onioncat/hostname
|
||
conqontlv34qgp7nmedyldffy4rpjgneabr4zzsdab5zqgadqb5fwayd.onion</code></pre>
|
||
<p style="text-align:justify;">Sur chaque hosts de notre Tor-VPN nous allons devoir générer l'IP6 avec <code>ocat -i adresse-en-onion.onion</code> et aller écrire dans le fichier <code>/var/lib/tor/onioncat/hosts.oc</code>. Ensuite nous allons copier le contenu de <code>/var/lib/tor/onioncat/hosts.oc</code> sur les deux machines (à l'identique). Si vous avez plus de hosts alors il faudra les faire aussi. C'est un ajout un peu lourd des dernières versions d'Onioncat pour la V3 des HS, ce n'était pas présent auparavant. La syntaxe du fichier <code>/var/lib/tor/onioncat/hosts.oc</code> doit ressembler à ça : </p>
|
||
<pre><code class="language-plaintext"># machine01
|
||
745:b072:4fe0:82:a703 u5egdjwykspucpbvdmfgcxceu7hdfncu5wmupp2vk5c3a4sp4aaifjyd.onion onioncat-a
|
||
# machine02
|
||
fd87:d87e:eb43:7b:9818:380:7a5b:303 conqontlv34qgp7nmedyldffy4rpjgneabr4zzsdab5zqgadqb5fwayd.onion onioncat-b</code></pre>
|
||
<p style="text-align:justify;">Donc : <code>adresse-ip6 adresse-en.onion onioncat-a.</code> L'ordre des machines n'a aucune importance… Dans cette architecture il n'y a ni serveur ni client, tout cela importe peu.</p>
|
||
<p style="text-align:justify;">Lançons l'outil. Notez que par défaut Onioncat se lance avec l’utilisateur <code>tor</code> mais ce denier n'existe pas sur notre système. Nous allons donc utiliser l'option <code>-u</code> afin de lancer l'outil correctement, avec notre utilisateur <code>_tor</code>. Les autres options, je vous laisses les étudier par vous-même dans le help d'Onioncat en tapant la commande sans argument.</p>
|
||
<pre><code class="language-plaintext"># ocat -H -g /var/lib/tor/onioncat/hosts.oc -U -B -u _tor conqontlv34qgp7nmedyldffy4rpjgneabr4zzsdab5zqgadqb5fwayd.onion
|
||
Fri, 14 May 2021 10:42:58.447 +0200 [0:main : info] onioncat 0.3.8 (c) Bernhard R. Fischer (OnionCat mode)
|
||
Fri, 14 May 2021 10:42:58.448 +0200 [0:main : info] setting interface IPv6 address fd87:d87e:eb43:7b:9818:380:7a5b:303/48
|
||
Fri, 14 May 2021 10:42:58.448 +0200 [0:main : info] bringing up interface
|
||
Fri, 14 May 2021 10:42:58.448 +0200 [0:main : info] IPv6 address fd87:d87e:eb43:7b:9818:380:7a5b:303
|
||
Fri, 14 May 2021 10:42:58.448 +0200 [0:main : info] TUN/TAP device tun0
|
||
Fri, 14 May 2021 10:42:58.449 +0200 [0:main : info] running as root, changing uid/gid to _tor (uid 1001/gid 1001)
|
||
Fri, 14 May 2021 10:42:58.449 +0200 [2:receiver : err] select encountered error: "Interrupted system call", restarting
|
||
Fri, 14 May 2021 10:42:58.450 +0200 [2:receiver : err] select encountered error: "Interrupted system call", restarting
|
||
Fri, 14 May 2021 10:42:58.451 +0200 [0:main : info] starting packet forwarder
|
||
Fri, 14 May 2021 10:42:58.451 +0200 [0:main : err] no route to destination ff02::2, dropping frame.
|
||
Fri, 14 May 2021 10:42:58.451 +0200 [1:acceptor : info] connection 12 [0] accepted on listener 5 from 127.0.0.1 port 42618
|
||
Fri, 14 May 2021 10:42:58.451 +0200 [1:acceptor : info] inserting peer fd 12 to active peer list
|
||
Fri, 14 May 2021 10:42:58.451 +0200 [2:receiver : info] incoming connection on 12 from fd87:d87e:eb43::dead:beef is now identified
|
||
Fri, 14 May 2021 10:42:58.647 +0200 [6:lloopback : info] loopback_handler ready listening on fd87:d87e:eb43::dead:beef
|
||
Fri, 14 May 2021 10:43:02.762 +0200 [0:main : err] no route to destination ff02::2, dropping frame.</code></pre>
|
||
<p style="text-align:justify;">Onioncat fonctionne correctement. Dans un autre terminal je check à quoi ressemblent mes interfaces…</p>
|
||
<pre><code class="language-plaintext"># ip addr show
|
||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
|
||
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
||
inet 127.0.0.1/8 scope host lo
|
||
valid_lft forever preferred_lft forever
|
||
inet6 ::1/128 scope host
|
||
valid_lft forever preferred_lft forever
|
||
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
|
||
link/ether 08:00:27:23:b0:99 brd ff:ff:ff:ff:ff:ff
|
||
inet 10.0.0.82/24 brd 10.0.0.255 scope global dynamic enp0s3
|
||
valid_lft 27684sec preferred_lft 27684sec
|
||
inet6 fe80::a00:27ff:fe23:b099/64 scope link
|
||
valid_lft forever preferred_lft forever
|
||
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
|
||
link/none
|
||
inet6 fd87:d87e:eb43:7b:9818:380:7a5b:303/48 scope global
|
||
valid_lft forever preferred_lft forever
|
||
inet6 fe80::82ec:2574:ff:57a0/64 scope link stable-privacy
|
||
valid_lft forever preferred_lft forever</code></pre>
|
||
<p style="text-align:justify;">On voit que <code>tun0</code> a bien été créée et que nous avons une IP6 en <code>fd87:d87e:eb43:7b:9818:380:7a5b:303/48</code>. Parfait. On recommence l'opération sur notre machine cliente sur laquelle on va devoir créer <code>/var/lib/tor/onioncat</code> et lancer l'outil de la même manière. Je vous laisse faire. En attendant on peut kill Onioncat et le relancer en mode démon (donc sans l'argument <code>-B</code>) : </p>
|
||
<pre><code class="language-plaintext"> # ocat -u _tor conqontlv34qgp7nmedyldffy4rpjgneabr4zzsdab5zqgadqb5fwayd.onion</code></pre>
|
||
<p style="text-align:justify;">Sur l'autre machine j'ai mon HS qui tourne correctement, je peux reproduire la même opération afin d'obtenir mon IP6 : </p>
|
||
<pre><code class="language-plaintext"># ocat -u debian-tor 3fksfdz2zm2elmag5qd5rwhcpfw75gdr7b36rp6xeo5rug3cx2okj7ad.onion
|
||
# ip addr show
|
||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
|
||
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
||
inet 127.0.0.1/8 scope host lo
|
||
valid_lft forever preferred_lft forever
|
||
inet6 ::1/128 scope host
|
||
valid_lft forever preferred_lft forever
|
||
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
|
||
link/ether 00:68:eb:90:26:cd brd ff:ff:ff:ff:ff:ff
|
||
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
|
||
link/ether 40:23:43:c7:68:d5 brd ff:ff:ff:ff:ff:ff
|
||
inet 10.0.0.69/24 brd 10.0.0.255 scope global dynamic noprefixroute wlan0
|
||
valid_lft 26250sec preferred_lft 26250sec
|
||
inet6 fe80::6ca8:34ed:966a:bc2e/64 scope link noprefixroute
|
||
valid_lft forever preferred_lft forever
|
||
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
|
||
link/none
|
||
inet6 fd87:d87e:eb43:23bb:1a1b:62be:9ca4:fc03/48 scope global
|
||
valid_lft forever preferred_lft forever
|
||
inet6 fe80::652e:db47:6c97:d7e2/64 scope link stable-privacy
|
||
valid_lft forever preferred_lft forever</code></pre>
|
||
<p style="text-align:justify;"><br>Dites donc…. On ne pourrais pas pinger nos mahcines par hasard ? (avec <code>ping6</code> cela va de soi) Notre Tor-VPN a l'air de fonctionner ! Plusieurs choses : Si au premier paquet vous avez une latence d'une minute ou plus c'est normal puisque Tor doit créer la route avant que vous ne puissiez joindre l'hôte. Sachez par ailleurs le tunnel se désactive au bout de 120 secondes d'inactivité.</p>
|
||
<pre><code class="language-plaintext"># ping6 fd87:d87e:eb43:7b:9818:380:7a5b:303
|
||
PING fd87:d87e:eb43:7b:9818:380:7a5b:303(fd87:d87e:eb43:7b:9818:380:7a5b:303) 56 data bytes
|
||
64 bytes from fd87:d87e:eb43:7b:9818:380:7a5b:303: icmp_seq=3 ttl=64 time=235 ms
|
||
64 bytes from fd87:d87e:eb43:7b:9818:380:7a5b:303: icmp_seq=4 ttl=64 time=258 ms
|
||
64 bytes from fd87:d87e:eb43:7b:9818:380:7a5b:303: icmp_seq=5 ttl=64 time=285 ms
|
||
64 bytes from fd87:d87e:eb43:7b:9818:380:7a5b:303: icmp_seq=6 ttl=64 time=190 ms
|
||
64 bytes from fd87:d87e:eb43:7b:9818:380:7a5b:303: icmp_seq=7 ttl=64 time=317 ms
|
||
64 bytes from fd87:d87e:eb43:7b:9818:380:7a5b:303: icmp_seq=8 ttl=64 time=236 ms</code></pre>
|
||
<p style="text-align:justify;"> </p>
|
||
<ul>
|
||
<li style="text-align:justify;">Note importante : <code>ifconfig(8)</code> est un prérequis pour Onioncat, installez le paquet <code>net-tools</code> si vous êtes sous Debian <a href="https://imgr.cineserie.com/2021/01/elephant-man-sur-netflix-de-quelle-maladie-souffre-john.png?imgeng=/f_jpg/cmpr_0/w_2202/h_1150/m_cropbox&ver=1">ou autres dérivés</a>. (ça me fait penser <code>systemctl reboot</code> j'ai très hâte de retrouver ma machine OpenBSD, heureusement que ce n'est qu'une machine de test).</li>
|
||
</ul>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;"> </p>
|
||
<p style="text-align:justify;"> </p>
|