Face à Tailworm : renforcer notre réseau Tailscale sans interrompre la production

Comment nous avons vérifié notre réseau Tailscale au regard des résultats de Tailworm, supprimé l’exposition de Tailscale SSH et gardé toutes les tâches de production actives.

Résumé

Le 25 octobre 2026, un chercheur en sécurité a publié « Tailworm » : 11 constats concernant Tailscale et headscale, rendus publics sans divulgation coordonnée (coordinated disclosure). Au moment de la rédaction, Tailscale n’a publié aucun correctif. Le soir même, nous avons vérifié notre propre réseau Tailscale au regard de chaque constat. Nous avons supprimé la seule exposition qui nous concernait, restreint les accès et maintenu toutes les tâches de production en fonctionnement tout au long de l’opération.

Cet article décrit ce que nous avons vérifié, ce que nous avons modifié, comment nous avons évité une interruption de service et ce que nous en avons retenu. Il ne s’agit pas d’une vérification indépendante du rapport.

Ce que Tailworm a signalé, en bref

Les 11 constats se répartissent en quelques groupes :

• Tailscale SSH (le plus grave). Une session SSH autorisée pouvait être élevée au niveau root sur la machine cible. Dans le laboratoire du chercheur, l’attaque s’est ensuite propagée de machine en machine.
• App connectors. Les destinations ne sont pas validées.
• Épuisement de la mémoire, sur le serveur de contrôle et sur les clients.
• Cas limites de Serve et Funnel.

Chaque constat suppose que l’attaquant dispose déjà d’un point d’appui. Aucun ne constitue une attaque à distance depuis internet. Certains spécialistes de la sécurité estiment que la présentation exagère le risque, mais l’exposition principale, Tailscale SSH, est réelle et facile à supprimer.

Étape 1 : vérifier avant de modifier

Nous avons commencé par des vérifications en lecture seule et consigné les résultats avant de toucher à quoi que ce soit :

• les versions du client Tailscale utilisées
• les fonctionnalités réellement activées
• 60 jours de journaux de sessions SSH, pour savoir qui s’était connecté et d’où, et si quelqu’un avait utilisé la redirection de ports ou de sockets
• la liste des appareils, y compris ceux qui n’avaient pas été vus depuis des mois

Constats :

• Tailscale SSH était activé sur une partie de notre environnement ; les constats F1–F3 et F5 nous concernaient donc.
• Les fonctionnalités dont dépendent les autres constats n’étaient pas utilisées ; la plupart ne s’appliquaient donc pas.
• Les journaux SSH ne montraient aucune source inattendue ni aucune demande de redirection.

Étape 2 : supprimer l’exposition sans interruption

La solution évidente consistait à désactiver Tailscale SSH et à utiliser à la place l’authentification standard par clé d’OpenSSH. Notre vérification préalable a révélé un piège.

Tailscale SSH authentifie par l’identité dans la tailnet, et non par la clé SSH. Nos scripts d’automatisation passaient une clé SSH en ligne de commande, mais cette clé était protégée par une phrase secrète et n’aurait jamais pu fonctionner sans intervention humaine. Les tâches ne tournaient que parce que Tailscale SSH ne regardait jamais la clé. Si nous avions simplement désactivé Tailscale SSH, toutes les tâches automatisées se seraient arrêtées.

Nous avons donc procédé à la bascule dans cet ordre :

1. Création d’une clé dédiée à l’automatisation, limitée à une seule machine source, avec la redirection désactivée.
2. Test du nouveau chemin avant la bascule. Nous avons ouvert un port OpenSSH temporaire, accessible uniquement depuis la tailnet, et nous nous sommes connectés depuis un environnement identique à celui de nos tâches (sans agent SSH, sans terminal), de toutes les manières dont nos scripts appellent SSH.
3. Tests négatifs. La nouvelle clé était refusée en dehors de sa source autorisée, et les demandes de redirection étaient rejetées.
4. Mise en place préalable d’un retour arrière automatique. Avant de désactiver Tailscale SSH, nous avons programmé un minuteur qui le réactiverait de lui-même. Ce chemin de reprise ne dépendait pas du bon fonctionnement de SSH.
5. Bascule, puis vérification de chaque tâche automatisée avec de nouvelles connexions. Chaque tâche a mené à bien une exécution réelle. Nous n’avons pas considéré une session déjà ouverte comme une preuve.
6. Suppression des éléments temporaires — le port supplémentaire, la règle de pare-feu et le minuteur de retour arrière — puis nouvelle vérification.

Étape 3 : resserrer le reste

• Vidage de la politique Tailscale SSH. La politique par défaut permettait à n’importe quel appareil d’un utilisateur d’ouvrir des sessions SSH vers ses autres appareils, y compris en root, moyennant une nouvelle approbation hebdomadaire dans le navigateur. Nous l’avons vidée : réactiver Tailscale SSH par erreur n’accorde plus aucun accès.
• Fermeture de SSH vers internet. Avant de le fermer, nous avons vérifié que la connexion via une console hors bande (out-of-band) fonctionnait, afin de ne pas nous retrouver bloqués dehors. Ensuite, nous avons vérifié depuis un réseau externe que SSH ne répondait plus.
• Approbation obligatoire des appareils. Tout nouvel appareil doit être approuvé par un administrateur avant de pouvoir rejoindre le réseau.
• Vérification des clés d’enrôlement. Il n’y en avait aucune à révoquer.
• Confirmation de la MFA sur le compte administrateur. Quiconque s’empare de l’identifiant administrateur peut annuler les contrôles au niveau du réseau.
• Début de l’observation du trafic réel entre appareils, afin que l’étape suivante — limiter quels appareils peuvent communiquer avec quels services — repose sur des faits et non sur des suppositions.

Tailnet Lock et l’approbation des appareils protègent tous deux contre l’arrivée d’un appareil indésirable, mais ils ne peuvent pas être utilisés ensemble : choisissez l’un des deux en connaissance de cause.

Étape 4 : corriger le runbook, pas seulement le serveur

Notre ancienne procédure de reprise demandait de reconnecter le serveur avec Tailscale SSH activé. Appliquée après ce changement, elle aurait discrètement réintroduit la fonctionnalité à risque. Nous l’avons réécrite :

• Diagnostiquer d’abord. La connexion réseau est-elle coupée, ou le problème vient-il de SSH lui-même (clés, configuration, pare-feu) ? Les deux cas ne se règlent pas de la même façon.
• Se reconnecter sans modifier les paramètres. N’ajoutez aucune option, enregistrez les paramètres du nœud avant la reconnexion et comparez-les ensuite.
• N’ouvrir un accès d’urgence qu’avec un minuteur. Obtenez d’abord une approbation, programmez une fermeture automatique avant d’ouvrir, limitez la source et vérifiez IPv4 et IPv6.
• Ne pas réactiver Tailscale SSH, même en cas d’urgence. La modification de la politique d’accès qu’il nécessite ne peut pas être annulée automatiquement.

Ce que nous avons appris

1. Sachez ce qu’une fonction de sécurité authentifie réellement avant de la retirer. La clé indiquée par nos scripts n’avait jamais servi.
2. Testez exactement le chemin vers lequel vous migrez, dans le même environnement que celui où tournent vos tâches, avant la bascule.
3. Prévoyez un retour arrière qui ne dépend pas de ce que vous modifiez. Un minuteur, pas « on se reconnectera en SSH pour réparer ».
4. Vérifiez l’accès de secours avant de fermer une porte. Nous avons confirmé l’accès console avant de fermer SSH vers internet.
5. Mettez à jour le runbook dans le même changement. Une ancienne étape de reprise peut annuler un correctif de sécurité des mois plus tard.
6. Lisez les politiques par défaut. « Autoriser ses propres appareils, y compris en root » était la configuration par défaut de départ.
7. Distinguez « le changement a fonctionné » de « la vulnérabilité est corrigée ». Nous ne sommes plus exposés aux constats liés à Tailscale SSH, mais Tailworm dans son ensemble ne sera pas clos tant que les correctifs upstream ne seront pas publiés. Nous mettrons nos clients à jour dès leur sortie.
8. Mesurer, puis restreindre. Le trafic observé et une liste des dépendances réelles passent avant des règles d’accès plus strictes, afin que le renforcement ne pénalise pas l’activité.

Prochaines étapes

Nous restreignons l’accès réseau entre appareils au strict minimum dont chaque service a besoin, sur la base du trafic observé. Nous installerons les correctifs de Tailscale dès leur publication.

Références : le rapport Tailworm (tailworm.com) et la documentation de Tailscale sur Tailnet Lock.