La porte qui ne répond pas

Mettre son serveur dans sa poche, sans l'ouvrir à Internet

Je voulais piloter depuis mon téléphone un agent qui tourne sur mon serveur. La solution évidente — un sous-domaine, un mot de passe — était la mauvaise, et pour une raison qui n'a rien à voir avec la cryptographie. Voici le raisonnement, et les trois pièges bêtes qui m'ont coûté un après-midi.

Ce qu'on expose vraiment

Un agent qui tourne en serveur, ce n'est pas une page web. C'est un interpréteur de commandes. Il lit des fichiers, il en écrit, il lance des programmes. Mettre ça derrière un sous-domaine avec un mot de passe, c'est mettre un shell sur Internet et espérer que le mot de passe tienne.

La bonne question n'est pas « est-ce que mon mot de passe est solide ». C'est : qu'est-ce que quelqu'un obtient s'il franchit cette porte ? Sur un serveur d'agent, la réponse est presque toujours : tout. Le compte qui fait tourner l'agent est celui qui a le droit de déployer, de redémarrer, de lire les configurations. Supposez que qui l'atteint devient administrateur, et vous raisonnerez juste.

La règle que j'en tire. Ce qui est public, c'est ce qui doit l'être : un site, une API. Un outil de pilotage n'a aucune raison d'être joignable par un inconnu — même protégé. On ne durcit pas une porte inutile : on la supprime.

Pourquoi pas un service tout fait

Il existe des services qui montent ce genre de tunnel en trois clics. Ils reposent tous sur la même mécanique de chiffrement, éprouvée, et je n'ai rien à leur reprocher là-dessus.

Le point faible est ailleurs. Ces services ont un serveur de coordination : une machine, chez eux, qui sait quels appareils existent et qui distribue les autorisations. Ce n'est pas le tunnel qu'un attaquant vise, c'est cet annuaire. Et quand il tombe, il tombe pour tout le monde à la fois.

En montant le tunnel soi-même, cet annuaire n'existe pas. Les machines se reconnaissent par leur clé, échangée une fois, à la main. Il n'y a personne à compromettre, parce qu'il n'y a personne.

Une porte qui ne répond pas

Voilà la propriété qui décide de tout, et elle est mal connue.

Un serveur SSH ouvert sur Internet répond. On lui envoie n'importe quoi, il annonce son nom et sa version. C'est ainsi qu'on se fait recenser : des robots balaient l'Internet en permanence, notent ce qui répond, et reviennent plus tard.

Le tunnel, lui, ne répond pas. Un paquet qui n'est pas signé par une clé qu'il connaît déjà est jeté sans un mot : pas de refus, pas d'erreur, rien. Pour un robot qui balaie, ce port n'existe pas.

Ne confondez pas avec « cacher ». Déplacer un service sur un port inhabituel, c'est le cacher : celui qui regarde bien le trouve. Ne pas répondre, c'est autre chose — même en sachant exactement où frapper, on n'obtient rien sans la clé. La discrétion n'est pas la sécurité ; ici elle en est la conséquence, pas le moyen.

Conséquence agréable : une fois le tunnel en place, on peut refermer l'accès d'administration habituel. On ne rajoute pas une porte, on en remplace une bavarde par une muette.

Les trois pièges

Le tunnel a marché du premier coup. C'est le reste qui a résisté, et aucun des trois problèmes n'était intéressant. Les voici pour qu'ils ne vous coûtent pas le même après-midi.

1. La taille des paquets

Symptôme : les petites réponses passent, les grosses disparaissent. Une page qui « charge » indéfiniment, aucune erreur, aucun journal. C'est ce qu'il y a de pire à diagnostiquer, parce que quelque chose marche.

Un tunnel ajoute une enveloppe autour de chaque paquet. Si la valeur configurée ne tient pas compte de cette enveloppe, les paquets pleins sont jetés en silence quelque part sur le chemin — et un aller-retour court, lui, passe très bien. J'ai soupçonné l'authentification, la configuration du serveur, un défaut du logiciel. C'était une histoire de taille.

Le test qui tranche. Comparez une réponse vide et une réponse avec du contenu. Si la vide passe et l'autre non, arrêtez de chercher côté logiciel : c'est la taille. Descendez la valeur à 1280, la plus sûre, y compris en 4G.

2. L'espace invisible

Une clé refusée, un message d'erreur qui parle de longueur. La clé était juste — vérifiée des deux côtés, même empreinte. Le clavier du téléphone avait ajouté une espace à la fin du collage.

Une heure perdue à soupçonner une clé correcte. Quand un secret collé est refusé, la première hypothèse n'est pas qu'il est faux : c'est qu'il a été abîmé en route.

3. L'adresse au mauvais endroit

Le formulaire demande deux adresses qui n'ont rien à voir : la vôtre dans le tunnel, et celle du serveur à joindre. Mettez la seconde à la place de la première, et le tunnel s'établit quand même — la poignée de main n'en dépend pas — mais rien ne circule ensuite. Ça marche à moitié, ce qui est la pire façon de ne pas marcher.

Le garde-fou qui efface

Dernier épisode, et le plus instructif. Deux fois, le tunnel s'est tu tout seul après avoir fonctionné.

Mon pare-feu n'est pas configuré à la main : il est déclaré dans un fichier, et un programme le réapplique tout seul à intervalle régulier. Toute règle ajoutée à côté disparaît au passage suivant. Sans message, évidemment : il ne corrige pas une erreur, il remet l'état voulu.

Ce qui rend le symptôme trompeur, c'est que la connexion en cours survit. Tout semble marcher — jusqu'à la première coupure, où plus rien ne revient.

Ce n'est pas un bug, c'est la fonctionnalité. Un pare-feu qu'on modifie à la main dérive, et personne ne sait plus pourquoi tel port est ouvert. Déclaré, il se relit. La bonne réaction n'était pas de remettre ma règle : c'était de l'écrire dans le fichier, avec le commentaire qui explique pourquoi elle existe. Une règle sans sa raison sera supprimée par le prochain qui fait le ménage — et il aura raison.

Ce que je n'écris pas ici

Un article sur sa propre infrastructure demande de décider ce qu'on tait. Ma règle : aucune valeur. Pas de clé, pas de mot de passe, pas d'adresse de machine, pas de numéro de port. Non parce que ce serait dangereux de les connaître — la solidité d'un système ne doit jamais reposer sur le secret de sa mécanique — mais parce qu'ils ne servent à rien au lecteur. Ce qui l'aide, c'est le raisonnement ; ce qui ne l'aide pas mais aiderait quelqu'un d'autre, on le garde.

Il y a aussi ce que je tais parce que ce n'est pas encore réglé. Un serveur d'agent joignable par le tunnel donne accès à un compte puissant, et c'est le vrai sujet — plus important que tout le débat sur le tunnel. Le tunnel est la moitié facile.

Ce que je retiens. La sécurité ne s'est pas jouée sur le choix du chiffrement — il était acquis. Elle s'est jouée sur trois décisions ennuyeuses : ne pas exposer ce qui n'a pas besoin de l'être, ne dépendre de personne pour distribuer la confiance, et écrire ses règles là où un programme les relit. Le reste, ce sont des espaces en fin de ligne.