Comment utiliser le darknet Tor pour protéger son système d’information ?
Dans l’article sur la problématique de l’exposition des services, et 10 cyberattaques qui ont exploité le principe d’exposition, nous mettions en évidence les risques liés à la mise en écoute des services sur internet.
Et si nous dissimulions ces services, pour éviter qu’ils ne puissent être trouvés par n’importe qui ?
Une des façons de faire est d’utiliser le réseau Chimere et le mécanisme des services cachés qu’il propose. Cependant, si vous avez peu de services et d’utilisateurs à gérer, que les questions de performance ne sont pas un sujet pour vous, et que vous aimez mettre les mains dans le cambouis, pourquoi ne pas directement utiliser le réseau Tor ? Cette méthode, est intéressante pour les particuliers, ou les petits systèmes d’information d’entreprise.
Voyons comment protéger un service SSH, et éviter d'être la cible d’attaques. En avant !
Le commencement : un service SSH exposé sur internet. Et attaqué.
Pour cet article, nous disposons d’un serveur Linux, ainsi que d’un service d’administration SSH en écoute sur internet.
Exposer le port SSH est très pratique pour administrer à distance son serveur. C’est également un risque de sécurité important. Pour bien se rendre compte du problème, il suffit d’analyser le trafic à destination du service.
Pour cela, nous utilisons l’outil TCPDUMP qui affiche en temps réel les paquets réseaux captés par la machine. Nous configurons l’outil pour n’afficher que les paquets TCP présentant le flag SYN activé et à destination du port 22. En d’autres termes, nous filtrons le trafic pour n’afficher que les tentatives de connexion à destination de notre service SSH, exposé sur internet. Nous exécutons la commande suivante :
tcpdump -ni ens3 'tcp[tcpflags] == tcp-syn and tcp[tcpflags] != tcp-ack and port 22'
Sans trop de surprises, à peine notre service SSH disponible, il est déjà ciblé par des attaques et des scans réseaux :
Qui vient toquer à notre porte ? Prenons la toute première adresse identifiée (200.52.65.41), et faisons une rapide recherche Google. Pas de doute, le service en ligne IPDB nous informe qu’il s’agit d’une adresse IP Mexicaine connue pour réaliser des actions malveillantes :
Nous pouvons également vérifier qu’il y a bien des tentatives d’attaques et d’authentification sur notre service SSH. Pour cela, il suffit de rechercher les tentatives d’authentification échouées dans la journalisation, via la commande suivante :
tail -f /var/log/auth.log | grep "Failed password"
Résultat :
Voyons comment empêcher ces attaques, en dissimulant notre service sur le darknet Tor.
Publier l’application sur le darknet
La première chose à effectuer est d’installer Tor sur la machine, afin de permettre d’enregistrer notre service sur le darknet :
apt install tor
Puis, nous vérifions que le processus Tor est bien en cours de fonctionnement :
systemctl status tor
Nous allons maintenant configurer la machine pour publier notre service SSH sur le darknet.
Tout d’abord, nous identifions les interfaces sur lesquelles le service est en écoute :
netstat -lpa
Le service écoute sur 0.0.0.0, soit toutes les interfaces. Nous savons donc qu’il est également accessible depuis la boucle locale 127.0.0.1. En d’autres terme, un programme de notre machine peut contacter localement le service SSH en initiant une connexion vers 127.0.0.1 port 22.
Utilisons cette information pour faire pointer le processus Tor vers 127.0.0.1 et le port 22, et rendre accessible ce service via le darknet.
Nous éditons le fichier de configuration tor /etc/tor/torrc et y ajoutons les lignes suivantes :
HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22
La première ligne indique d’utiliser le répertoire /var/lib/tor/ssh/ comme le répertoire de données de notre service. Ce répertoire contiendra notamment la clé cryptographique et l’adresse “onion” du service, que nous utiliserons ensuite pour contacter l’application SSH à travers le darknet Tor.
La seconde ligne indique de publier l’accès au service final 127.0.0.1:22 à travers le darknet, également via le port 22. En effet, l’adresse “onion” doit être couplée à un port pour accéder au service. Ici, nous précisons le même port que celui du service exposé. Ce n’est pas un problème car le port ne pourra pas être scanné par les attaquants sans la connaissance de l’adresse onion du service.
Redémarrons le service Tor pour prendre en compte les modifications :
systemctl restart tor
Accéder à l’application à travers le darknet
Maintenant que le service est publié, nous allons y accéder.
Le fichier /var/lib/tor/ssh/hostname contient l’adresse “onion” de notre service, qui a été générée lors de l’enregistrement :
Copions cette adresse qui nous sera utile pour accéder au service.
Sur notre poste de travail, nous allons également installer Tor. Nous travaillons avec un poste de travail Linux, mais ces étapes sont aussi adaptables sur Windows et MacOS :
apt install tor
Une fois installé, le processus Tor propose un proxy local, en écoute sur 127.0.0.1 et le port 9050. Toute requête socks5 envoyée à destination de cette adresse et de ce port est routée vers le réseau darknet Tor.
Il suffit donc de préciser l’adresse “onion” précédemment récupérée, pour se connecter au service.
Pour faciliter l’emploi du client SSH à travers le proxy Tor, nous utilisons le programme torsocks, et nous exécutons la commande de connexion au service :
torsocks ssh ubuntu@fjickkhzvwxpzokvfa5lqjow6ecwjsjfkkfbpozanziwjk4tphvpvlad.onion
Et nous voilà connectés au service SSH à travers Tor :
Nous allons maintenant utiliser cette connexion pour couper l’exposition du service d’internet et éviter d'être la cible d’attaques.
Couper l’exposition du service
Comme nous l’avons vu précédemment, le service SSH écoute sur toutes les interfaces et est donc exposé sur internet. Nous souhaitons faire en sorte que son exposition se limite à la boucle locale pour permettre au processus Tor d’y accéder, et non à des clients externes.
Il existe plusieurs façons de faire cela. Par exemple, nous pourrions ajouter une règle de pare-feu, ou modifier tout simplement l’interface d'écoute du service.
Penchons nous sur la deuxième option.
Nous éditons le fichier de configuration SSH /etc/ssh/sshd_config, puis nous y ajoutons la ligne suivante :
ListenAddress 127.0.0.1
Enfin, nous redémarrons le service SSH pour prendre en compte les modifications :
systemctl restart sshd
Si nous essayons de nous connecter directement au service, sans passer par le darknet, nous obtenons bien un refus :
Et maintenant, qu’en est-il des attaques ?
Regardons de nouveau le fichier de journalisation. Avons-nous toujours des tentatives d’authentification de la part des attaquants ?
Les tentatives d’authentification se sont arrêtées depuis la coupure d’exposition du service. Il est devenu indétectable, et seuls les connaisseurs de l’adresse onion (qui est en réalité une clé cryptographique) sont en mesure de négocier une connexion avec le service, désormais dissimulé sur le darknet Tor.
Généraliser la dissimulation des services
Bien sûr, le réseau Tor n’est pas adapté à une dissimulation massive des services d’entreprise.
Il est fastidieux d’automatiser la dissimulation de dizaines ou de centaines de service, d’amener les utilisateurs à manipuler des adresses .onion pour accéder à leurs services, ou encore d’accepter les faibles performances du réseau.
Pour toutes ces raisons, nous avons conçu le réseau Chimere : un darknet privé, facile à utiliser, performant, permettant de gérer de façon centralisée et “on-premise” les listes d’utilisateurs, de services et les droits d’accès associés. Chimere est aussi conçu pour permettre à tous les utilisateurs d’accéder aux services cachés en utilisant les programmes qu’ils ont l’habitude d’employer au quotidien.
Pour en savoir plus sur Chimere, n’hésitez-pas à visiter notre site, et inscrivez-vous à la newsletter pour ne pas manquer les prochains articles.