Créer une porte dérobée chez soi

Publié le par

Pour accéder à mon réseau domestique depuis l’extérieur, j’ai mis en place un serveur VPN privé. C’est pratique, cela me permet d’accéder depuis l’extérieur à mes ressources autohébergées (serveur de flux RSS, serveurs de sauvegarde, partages familiaux, etc.) mais aussi de me protéger quand j’utilise un réseau Wifi, lorsque je me déplace avec mon matériel personnel (téléphone, tablette ou ordinateur portable).

Cela m’a permis de fermer tous les ports d’accès que j’avais ouverts sur ma box, sauf bien sûr le port d’accès au serveur VPN.

Mais ce serveur VPN est devenu pour moi un point de défaillance unique (SPOF). Et là, suite à une intervention malheureuse à distance, lors d’une maintenance admin sur ce serveur, j’ai coupé le tunnel VPN. Et pour le relancer, il me fallait… me connecter au serveur via le tunnel VPN. Bref, j’avais scié la branche sur laquelle j’étais assis. Classique.

Cette situation désagréable aurait pu être rapidement résolue si j’avais pu avoir accès à distance à un ordinateur de la maison. Hélas, Mme Zythom était au tribunal en train de défendre un innocent. J’ai donc attendu qu’elle revienne, pour pouvoir prendre le contrôle de son ordinateur (avec AnyDesk) et intervenir par rebond pour accéder à mon serveur VPN et le relancer. N’oubliez pas que je suis trois jours par semaine en télémaison ; je n’aurais pas pu tenir si longtemps sans l’accès à mes flux RSS…

En bon informaticien, je n’aime pas les SPOF mais j’aime hacker mes réseaux, par curiosité bien sûr. J’ai donc eu l’idée de mettre en place une porte dérobée, façon Elliot dans Mr Robot.

A ce stade de mon récit, et comme j’ai déjà eu à faire à la justice pour ce blog, je tiens à mettre en garde mes lecteurs, et à rassurer mes juges : l’auteur de ce blog continuera à respecter les qualités, notamment de conscience, d’impartialité et de réserve, nécessaires au plein accomplissement de sa mission d’expert, fut-il ancien expert judiciaire. La porte dérobée que je vais vous présenter n’est à installer que sur un réseau sur lequel vous disposez de toutes les autorisations du propriétaire dudit réseau. Si vous vivez encore chez vos parents, demandez leur la permission (en expliquant bien tous les risques). Bref, respectez la loi, et si vous avez un doute, abstenez-vous. Ce billet est écrit avec un esprit pédagogique, et avec en tête qu’il peut peut-être sauver les miches de quelques admins… Cette parenthèse est un peu longue, mais elle me paraissait nécessaire pour expliquer le contexte à mes lecteurs magistrats.

Je souhaite donc mettre en place une porte dérobée me permettant d’accéder à une console à distance sur mon réseau personnel pour rebondir sur mes serveurs à moi.

Cahier des charges sommaire : je veux que cette porte dérobée soit discrète pour le reste du monde, et que je sois le seul à pouvoir y accéder. Je ne veux pas faire de redirection de ports sur ma box. Elle doit me permettre de faire un ssh vers un terminal situé au cœur de mon réseau personnel. Personne d’autre que moi ne doit pouvoir y accéder, sauf à disposer de la puissance d’un ordinateur quantique. Elle doit fonctionner 24/7 et donc consommer peu d’énergie.

Voici la solution que j’ai mise en place : un service ssh caché privé Tor sur un Raspberry Pi sous Debian, c’est-à-dire un v3 Onion Hidden Service Stealth for ssh. Procédons par étapes.

Étape 1 : installer Debian sur un Raspberry Pi (ou une VM)

Je ne détaillerai pas cette étape, voici une liste de liens. Attention, Debian pour Raspberry Pi qui s’appelait Raspbian, s’appelle maintenant Raspberry Pi OS.
https://wiki.debian.org/RaspberryPi
https://www.raspberrypi-france.fr/guide/installer-raspbian-raspberry-pi/

Étape 2 : se connecter en ssh sur le serveur mis en place à l’étape 1

Idem : voir par exemple ce tuto https://raspberry-pi.fr/activer-ssh/
L’idée est d’arriver à se connecter au serveur depuis une machine cliente sous GNU/Linux avec la commande suivante :

zythom@Client:~$ ssh pi@ip-serveur

pi@Serveur:~$

Étape 3 : se connecter en ssh sans mot de passe
Source : Comment configurer une authentification par clé SSH sur un serveur Linux

L’objectif est de limiter les possibilités de connexion aux seuls comptes clients qui disposent de la clé privée. Si vous disposez déjà d’une paire de clés privée/publique, il vous suffit de placer la clé privée id_rsa dans le répertoire .ssh de votre compte (sans écraser celle qui s’y trouve !) et installer la clé publique sur le serveur avec la commande indiquée à la fin de l’étape 3. Sinon, vous pouvez générer la paire de clés avec la commande suivante :

zythom@Client:~$ ssh-keygen

L’ajout d’une phrase de passe est facultatif. Si vous en entrez une, vous devrez la saisir à chaque fois que vous utiliserez cette clé (à moins que vous utilisiez un logiciel d’agent SSH qui stocke la clé en clair). Je vous recommande d’utiliser une phrase de passe, mais si vous ne le souhaitez pas, il vous suffit d’appuyer sur ENTER pour contourner cette invite.

Your identification has been saved in /home/zythom/.ssh/id_rsa.
Your public key has been saved in /home/zythom/.ssh/id_rsa.pub.

Vous disposez désormais d’une clé publique et privée (sur votre machine cliente) que vous allez pouvoir utiliser pour vous authentifier. Je vous recommande de conserver précieusement une copie de ces deux fichiers dans votre Keepass.

L’action suivante consiste à placer la clé publique sur votre serveur afin que vous puissiez utiliser l’authentification par clé pour vous connecter :

zythom@Client:~$ cat ~/.ssh/id_rsa.pub | \
 ssh pi@ip-serveur "mkdir -p ~/.ssh && cat >> \
 ~/.ssh/authorized_keys"

Vous devriez pouvoir ensuite vous connecter au serveur en ssh, comme à l’étape 2, sans avoir à entrer de mot de passe lié au compte, mais une phrase de passe liée aux clés.

Étape 4 : Installer Tor sur le serveur et configurer un Hidden Service pour ssh

Sur le serveur, exécutez la commande suivante pour rejoindre le réseau Tor :

pi@Serveur:~$ sudo apt install tor

Toujours sur le serveur, modifiez /etc/tor/torrc en ajoutant les lignes suivantes (j’ai choisi le port 6001 pour éviter le port 22, plus par superstition que pour une raison valable) :

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 6001 127.0.0.1:22

Redémarrez Tor :

pi@Serveur:~$ sudo service tor restart

Vérifiez la création du répertoire /var/lib/tor/ssh
et récupérez le contenu du fichier /var/lib/tor/ssh/hostname

pi@Serveur:~$ sudo cat /var/lib/tor/ssh/hostname
3bjgocu36yuyggl...utbofs7us27gd6gvopwuvlywaodabzsad.onion

pi@Serveur:~$

La longue ligne se terminant par .onion est le petit nom de votre serveur sur Tor : je l’appellerai « nom-tor-etape4.onion » dans la suite du billet. Il est d’ores et déjà joignable depuis toute la planète depuis le réseau Tor (voir étape suivante), sans avoir à intervenir sur sa box pour rediriger des ports…

Étape 5 : utiliser Tor pour se connecter en ssh sur votre serveur

Vous avez deux manières de faire :

Soit en utilisant torsocks

zythom@Client:~$ sudo apt install torsocks

zythom@Client:~$ torsocks ssh -p 6001 [email protected]

pi@Serveur:~$

Soit en utilisant ncat et les options de ssh (source https://debian-facile.org/doc:reseau:tor)

zythom@Client:~$ sudo apt install ncat

zythom@Client:~$ ssh -o VerifyHostKeyDNS=no -o CheckHostIP=no -o IdentitiesOnly=yes -o ProxyCommand="ncat --proxy 127.0.0.1:9050 --proxy-type socks5 %h %p" -p 6001 [email protected]

pi@Serveur:~$

Étape 6 : transformer votre Hidden Service en Hidden Service Stealth

C’est l’étape la plus intéressante. Elle permet d’interdire à toute machine non autorisée d’essayer de se connecter au service ssh de votre serveur caché. Pour cela, vous allez avoir besoin de générer des clés que vous associerez à vos deux machines.

S1) Sur la machine cliente, générez une paire de clés en utilisant l’algorithme x25519 :

zythom@Client:~$ openssl genpkey -algorithm x25519 \
 -out toto.prv.pem

S2) Transformez les clés en format base32 :

zythom@Client:~$ sudo apt install basez

zythom@Client:~$ cat toto.prv.pem | \
 grep -v " PRIVATE KEY" | \
 base64pem -d | \
 tail --bytes=32 | \
 base32 | \
 sed 's/=//g' > toto.prv.key

zythom@Client:~$ openssl pkey -in toto.prv.pem -pubout | \
 grep -v " PUBLIC KEY" | \
 base64pem -d | \
 tail --bytes=32 | \
 base32 | \
 sed 's/=//g' > toto.pub.key

S3) affichez la clé publique :

zythom@Client:~$ cat toto.pub.key WWRQ37XF6U6FNWH...VHFK7CH4OX4THEUHC5N75IHA

S4) affichez la clé privée :

zythom@Client:~$ cat toto.prv.key GACZ2JCBS4CBKTPYX...4A6PMQANRDK66NBKGYTFAA

S5) Côté serveur :
Créez un fichier zythom.auth dans le répertoire /var/lib/tor/ssh/authorized_clients
contenant la clé publique du S3) formaté comme suit : descriptor:x25519:clé-du-S3

pi@Serveur:~$ sudo su
pi@Serveur:# echo "descriptor:x25519:WWRQ37XF6U6FNWH...VHFK7CH4OX4THEUHC5N75IHA" > /var/lib/tor/ssh/authorized_clients/zythom.auth

pi@Serveur:# cd /var/lib/tor/ssh/authorized_clients
pi@Serveur:# chown debian-tor.debian-tor zythom.auth
pi@Serveur:# chmod 600 zythom.auth
pi@Serveur:# service tor restart

S6) Côté client :
Modifiez le fichier /etc/tor/torrc pour y ajouter la ligne suivante :

ClientOnionAuthDir /var/lib/tor/onion_auth

Puis créez le répertoire /var/lib/tor/onion_auth

zythom@Client:~$ sudo su
zythom@Client:# cd /var/lib/tor
zythom@Client:# mkdir onion_auth
zythom@Client:# chown debian-tor.debian-tor onion_auth
zythom@Client:# chmod 700 onion_auth

Créez dans ce répertoire onion_auth un fichier zythom.auth_private contenant 
adresse-en-onion-sans-le-onion:descriptor:x25519:la-clef-privée-affichée-en-S4

zythom@Client:# cd onion_auth/
zythom@Client:# echo "nom-tor-etape4:descriptor:x25519:GACZ2JCBS4CBKTPYX...4A6PMQANRDK66NBKGYTFAA" > zythom.auth_private

zythom@Client:# chown debian-tor.debian-tor zythom.auth_private
zythom@Client:# chmod 600 zythom.auth_private
zythom@Client:# service tor restart

Étape 7 : utiliser Tor pour se connecter en ssh sur votre serveur

Ce sont les mêmes commandes qu’à l’étape 5, mais qui ne peuvent être exécutées que depuis votre machine cliente :

zythom@Client:~$ torsocks ssh -p 6001 [email protected]

Ou : 

zythom@Client:~$ ssh -o VerifyHostKeyDNS=no -o CheckHostIP=no -o IdentitiesOnly=yes -o ProxyCommand="ncat --proxy 127.0.0.1:9050  --proxy-type socks5 %h %p" -p 6001 [email protected]

Et voilà. Vous pouvez bien sûr créer des alias pour ces commandes afin de vous faciliter la vie. Amusez-vous bien.

12 réflexions sur « Créer une porte dérobée chez soi »

  1. Bonjour, super pédagogique comme d’habitude. J’ai une petite question. En cas de perte de la machine cliente, vous avez une copie des clés permettant de changer de machine cliente à distance ou il faut tout refaire en local ?

    • Tous mes mots de passe, toutes mes phrases de passe, toutes mes paires de clés cryptographiques, tous mes scripts importants et tous mes secrets sont stockés dans une base de données Keepass. Celle-ci est sauvegardée dans les règles de l’art.

  2. Effectivement, problématique à laquelle beaucoup pensent… mais peu implémentent s’ils n’ont pas vécu le fait d’être « fermé dehors »…
    Personnellement j’ai pensé au port knocking (https://fr.wikipedia.org/wiki/Port_knocking), mais je ne suis pas passé à l’action.
    Mais je pense que la solution décrite dans le billet doit avoir l’avantage de permettre une connexion même en cas de bannissement de l’adresse IP, ce qui m’arrive de temps en temps (erreur de mot de passe, IP cliente grillée : fermé dehors).
    Je vais y regarder de plus près : merci pour les pistes de réflexion et le tuto !

    • Merci pour l’idée.
      Et je ne connaissais pas le port knocking, merci aussi.

      > Je ne veux pas faire de redirection de ports sur ma box.
      Je n’ai peut-être pas tout saisi mais le port pour Tor ?

  3. Et moi j’aime bien le « autossh » ( https://linux.die.net/man/1/autossh ) avec l’option -Rxxxx:127.0.0.1:22
    Cela permet d’obtenir un « tunnel dans l’autre sens » par port-forwarding, depuis une machine de confiance (un VPS). Ce dernier « attaché » à localhost ne peut pas être utilisé depuis ailleurs que le VPS lui-même.
    Mais belle démonstration ! on en apprend tous les jours sur Tor grâce à vous.

    • Oh ! Merci pour autossh. Ça me plaît beaucoup.
      Évidement, grand merci à l’auteur de de blog pour ses effort continus d’édification des masses de sysadmin distraits.

  4. Je hais les portes dérobées. Vous avez un beau PC Windows, vous y créez des comptes différents avec des droits différents. Vous ajoutez un mot de passe sur le boot pour éviter qu’un hacker ne le démarre sur un clef Linux. Et tout cela ne sert à rien. Car le fabricant a installé une porte dérobée pour accéder au boot. Et que très souvent, le mot de passe de cette porte dérobée est simplement le nom du fabricant (authentique!).
    En même temps j’ai connu pire. Sur un PC certifié médical, il ne servait strictement à rien de protéger le boot. Car le mot de passe vide y donnait accès. Peut-on encore parler de bug à ce niveau?

  5. Tout cela vous prémunit-il contre les portes dérobées (fortement) susceptibles d’être présentes dans Tor ?
    J’ai comme un vieux doute.

    • Il n’est pas possible de répondre autre chose que le risque zéro n’existe pas. Mais le but est de le minimiser : à la redirection classique de ports, je préfère cette méthode, où outre le réseau Tor, le chiffrement ssh s’applique avec des autorisations gérées à 2 niveaux (clés pour la machine, clés pour le compte).

  6. Sympa l’article, comme toujours.

    L’avantage de la connexion par SSH, c’est qu’on peut la configurer pour la rendre plus simple. Au lieu de définir un alias, il suffit de définir l’hôte et ses options dans le fichier ~/.ssh/config en ajoutant:

    Host maison
    HostName nom-tor-etape4.onion
    Port 6001
    User pi
    VerifyHostKeyDNS no
    ProxyCommand « ncat –proxy 127.0.0.1:9050 –proxy-type socks5 %h %p »
    CheckHostIP no
    IdentitiesOnly yes

    Il suffira ensuite de se connecter avec la commande

    ssh maison

    Avantage par rapport à l’alias, les paramètres s’appliquent également à scp et sftp.

Les commentaires sont fermés.