docs: update Réseaux/Tor

Réseaux/Tor.html

@@ -2,7 +2,7 @@
 title: Réseau - Tor
 description: Comprendre et utiliser le réseau Tor
 published: false
-date: 2021-05-14T07:33:06.037Z
+date: 2021-05-14T08:28:57.594Z
 tags: linux, tor, réseau
 editor: ckeditor
 dateCreated: 2021-05-11T19:26:41.152Z
@@ -356,9 +356,7 @@ az5tu5d6vqblla2ioccd6rng3o6rubqe55h6tm4oagapjk4behjdgfqd:descriptor:x25519:DK6XM
 <p style="text-align:justify;">&nbsp;</p>
 <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>. C'est outil hyper élégant présenté ici <a href="https://www.youtube.com/watch?v=rx4rS1gvp7Y">en vidéo</a> ici qui permet de faire transiter n'importe quel type de flux via Tor au travers d'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 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 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.</p>
-<p style="text-align:justify;">J'ai longtemps réfléchis à la manière dont j'allais vous faire expérimenter Onioncat et j'ai décidé que j'allais utiliser un serveur <a href="https://wiki.mumble.info/wiki/Murmurguide">murmur</a>. Sachez que Murmur peut être configuré pour remplacer UDP par TCP sur la voix mais au travers de cet exemple nous garderons UDP et nous en profiterons pour &nbsp;commencer à étudier sérieusement les options avancées de <code>/etc/tor/torrc</code>. Si ça vous plaît, on commence !</p>
-<p style="text-align:justify;">&nbsp;</p>
+<p style="text-align:justify;">Un 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 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.<br>&nbsp;</p>
 <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 /root/comp &amp;&amp; cd /root/comp
@@ -446,10 +444,7 @@ usage: ocat [OPTIONS] &lt;onion_hostname&gt;
    -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;">&nbsp;</p>
-<p style="text-align:justify;">Comme sur des roulettes. Après avoir évidemment fait la même chose sur votre machine cliente (puisqu'il faut que Onioncat soit installé de part et d'autre rappelez-vous…) nous pouvons installer notre serveur murmur. Il est dans les repos, chill !</p>
-<pre><code class="language-plaintext"># apt install mumble-server</code></pre>
-<p style="text-align:justify;">&nbsp;</p>
-<p style="text-align:justify;">Pour votre gouverne on configure Murmur via le fichier <code>/etc/mumble-server.ini</code>. Pour le moment on laisse les options par défaut. Notez juste que le port qui nous intéresse est le 64738. Pour le moment nous avons <code>sshd</code> qui tourne sur le serveur de test. Le démon 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 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 d'y intégrer des paires de clefs.</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 et pas les autres, c'est un AuthCookie par HSv3</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 d'y intégrer des 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 &nbsp;<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 utilisez 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. 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;">&nbsp;</p>
@@ -548,21 +543,7 @@ PING fd87:d87e:eb43:7b:9818:380:7a5b:303(fd87:d87e:eb43:7b:9818:380:7a5b:303) 56
   <li style="text-align:justify;">Note importante à propos de <code>ifconfig</code> : Oui <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&amp;ver=1">ou autres dérivés</a> bien connus. (ça me fait penser <code>systemctl reboot</code> j'ai très hâte de retrouver ma machine OpenBSD, hereusement que ce n'est qu'une machine de test).</li>
 </ul>
 <p style="text-align:justify;"><i>De mon côté j'ai bien galéré avec ma machine Kali qui gère les droits du démon Tor d'une manière très… humm… Enfin qui ne gère rien du tout. Au début ça ne fonctionnait pas j'ai vu des alertes sur les droits et dans le doute j'ai lancé Onioncat sur mon firewall OpenBSD qui répondait très bien avec la même conf. J'ai finis par cloner ma VM debian-tor pour les besoins de l'article sur laquelle tout fonctionne enfin.</i></p>
-<p style="text-align:justify;">&nbsp;</p>
-<p style="text-align:justify;">Bon ça ping. Nous pouvons joindre nos serveurs de part et d'autre en IP6. Nous parlerons des latences plus tard mais pour l'instant concentrons nous sur notre serveur Murmur. On lance la configuration automatique avec <code>sudo dpkg-reconfigure mumble-server</code>.Le soft va vous demander si vous voulez démarrer automatiquement et si vous voulez flaguer les paquets voix en prioritaire, dites oui… Un petit récap apparaîtra :&nbsp;</p>
-<p style="text-align:justify;">&nbsp;</p>
-<pre><code class="language-plaintext"># sudo dpkg-reconfigure mumble-server
-&lt;W&gt;2021-05-14 08:57:39.120 SSL: OpenSSL version is 'OpenSSL 1.1.1d  10 Sep 2019'
-&lt;W&gt;2021-05-14 08:57:39.121 Initializing settings from /etc/mumble-server.ini (basepath /etc)
-&lt;W&gt;2021-05-14 08:57:39.608 MetaParams: TLS cipher preference is "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA"
-&lt;W&gt;2021-05-14 08:57:39.650 ServerDB: Opened SQLite database /var/lib/mumble-server/mumble-server.sqlite
-&lt;W&gt;2021-05-14 08:57:39.650 ServerDB: Using SQLite's default rollback journal.
-Password: &lt;F&gt;2021-05-14 08:57:39.686 Superuser password set on server 1</code></pre>
-<p style="text-align:justify;">&nbsp;</p>
-<p style="text-align:justify;">Bon le serveur Murmur est opérationnel et vous remarquerez qu'en plus de la création de la base SQLite les clefs AES ont été générées automatiquement par <code>sudo dpkg-reconfigure mumble-server</code>. Avec mes galères sur Kali je me retrouve avec deux VM sans GUI mais il me faut trois machines : le serveur Murmur et deux clients (bah oui les gars <a href="https://en.wikipedia.org/wiki/Alice_and_Bob">Alice</a> n'a pas encore Alzheimer, 78 c'est encore jeune)… Pour les tests avec le client Mumble je vais installer un GUI sur ma VM cliente et la cloner avec VirtualBox pour obtenir deux clients XFCE que j'appellerais <code>client-01</code> et <code>client-02</code>. Je fais aussi le nécessaire avec Tor et Onioncat sur client-02 pour réinstaller Tor et Onioncat afin d'avoir des hostnames et des adresses <code>*.onion</code> différents. Je pourrais utiliser le serveur d'origine comme client mais je préfère simuler un vrai cas de figure puisqu'avec Tor les tests de latences seraient totalement biaisés.</p>
-<p style="text-align:justify;">&nbsp;</p>
-<p style="text-align:justify;">&nbsp;</p>
-<p style="text-align:justify;">&nbsp;</p>
+<p style="text-align:justify;">Bon ça ping. Nous pouvons joindre nos serveurs de part et d'autre en IP6.&nbsp;</p>
 <p style="text-align:justify;">&nbsp;</p>
 <p style="text-align:justify;">&nbsp;</p>
 <p style="text-align:justify;">&nbsp;</p>