Click here for the English version of this article
Sur mon infrastructure personnelle expérimentale, je configure toujours mon VPS pour exposer mes services d'administration à travers des hidden services Tor. Mon serveur n'accepte jamais directement de connexion SSH, seules les personnes qui connaissent l'adresse onion du service SSH et possèdent la clé privée spécifique peuvent se connecter. Je pense qu'exposer les services d'administration de cette manière les rend extrêmement sécurisés. J'ai mentionné SSH, mais la même approche fonctionne évidemment pour un panneau de contrôle web, etc.Principe
Tor est un réseau d’anonymisation qui vous permet de faire tourner des hidden services. Ces services sont anonymisés derrière trois relais et s’annoncent sur le réseau (via des “descriptors”).
Tor se fiche de l’accèssibilité du serveur d’origine, même derrière un NAT, c’est pourquoi je l’ai utilisé pour faire du home labbing.
Créer un service onion est aussi simple que d’installer le daemon tor et d’ajouter ces lignes au fichier de configuration torrc :
1 | HiddenServiceDir /var/lib/tor/secret_ssh/ |
Après avoir redémarré ou rechargé tor, il générera automatiquement une adresse onion dans le HiddenServiceDir (dans le fichier hostname).
Si on configure maintenant SSH pour écouter sur l’adresse de loopback, il recevra le trafic du hidden service sur le port 22.
Maintenant, si un attaquant scanne le serveur, il ne peut même pas faire du fingerprinting ni tenter de se connecter à SSH, puisque le port est fermé / il ne connaît pas l’adresse onion.
Les adresses onion de Tor sont publiques, par conséquent, pour empêcher quiconque d’interagir avec notre hidden service SSH privé, on peut utiliser le mécanisme de Client Authorization.
Avec cela, le hidden service n’accepte que les connexions des clients autorisés via une clé asymétrique x25519.
Maintenant, et si tous les services étaient derrière Tor, est-ce que ce serait intéressant ? Absolument, et j’ai réussi à répliquer cette configuration pour mon home lab.
L’idée est que toute l’infrastructure tourne en tant que hidden service, y compris les services web, etc. Un reverse proxy clearnet transfère ensuite le trafic web (via un reverse proxy nginx) et les autres protocoles (via par socat, par exemple) vers le service onion.
Le serveur exposé sur internet sert également de proxy d’uplink pour le serveur principal, pour qu’il reste complètement secrets.
Ce reverse proxy clearnet peut également gérer le filtrage en exécutant des rulesets personnalisés et en bloquant les requêtes suspectes vers le serveur principal en utilisant des outils tels que CrowdSec.
Est-ce que ça peut scaler / est-ce que c’est viable ?
Maintenant, ne pas dépendre d’un tiers comme cloudfare et avoir le même niveau de sécurité a forcément des inconvénients, non ? :
- D'abord et avant tout, la fiabilité : bien que Tor soit assez résilient, la surcharge du réseau et les attaques sur le réseau sont possible.
- Les hidden services Tor ajoutent une latence importante, et pire : la latence est complètement random, vous pouvez simplement tomber sur un circuit malchanceux avec une latence très élevée qui rend SSH à peine utilisable.
- Certains hébergeurs peuvent bloquer les gardes Tor ou devenir suspicieux à l'égard du serveur et bloquer le compte client, il est donc essentiel d'utiliser uniquement des hébergeurs qui autorisent Tor.
J’utilise personnellement Tor pour mes petits projets personnels et je comprends qu’une telle architecture ne scalerait pas très bien dans une entreprise où l’infrastructure critique nécessite un accès permanent, ce serait une galère de devoir troubleshooter une connexion SSH.
Ça devrait être “SSH fonctionne ou le serveur est down”, pas “peut-être que Tor est surchargé” ou “peut-être que le daemon tor a échoué à construire un circuit”. Cela ajoute juste une autre couche de choses dont il faut se soucier, mais peut-être que c’est le prix d’une très bonne sécurité zero-trust grâce à la décentralisation de Tor ?
Je suis actuellement à la recherche d’un job au fait, engagez-moi s’il vous plaît !