L'angle de conformité d'entreprise "Sans-Racine" : sécuriser les tunnels développeurs en 2026

Les tunnels développeurs ont commencé comme une commodité : une commande, et un service tournant sur localhost obtient une URL HTTPS publique pour tester un webhook ou montrer un aperçu à un collègue. Dans une organisation zéro-trust, cette même commodité devient une voie non gérée du laptop vers Internet public, et les équipes de sécurité l’ont remarquée.

Cet article explique ce que le “sans-racine” apporte réellement, ce qu’il ne fait pas, quels outils fonctionnent vraiment sans privilèges élevés, et comment déployer une politique de tunneling que les développeurs suivront plutôt que de contourner.

Pourquoi le modèle de menace est important (et où l’histoire habituelle est erronée)

Un tunnel inverse est une connexion qu’une machine privée ouvre vers l’extérieur vers un serveur public. Le serveur public relaie ensuite le trafic entrant par cette connexion. Parce que rien d’entrant n’est jamais accepté par la machine privée, cela fonctionne derrière un routeur domestique, un pare-feu d’entreprise ou un NAT de niveau opérateur sans redirection de ports.

Ce design à sens unique sortant explique pourquoi les tunnels sont si faciles à adopter, et pourquoi ils posent un problème de gouvernance. Les règles de pare-feu conçues pour bloquer l’accès entrant ne les voient pas.

Où intervient le privilège ? À deux endroits :

• L’agent lui-même. La plupart des clients de tunnel n’ont besoin que d’établir une connexion sortante et de parler à un port local, ce qui ne nécessite pas de droits spéciaux. Les privilèges élevés apparaissent généralement lorsque quelqu’un installe l’agent en tant que service système persistant, ou utilise un mode qui manipule la pile réseau. Par exemple, le mode backend VPN de zrok est documenté avec sudo, tandis que ses partages proxy ordinaires ne le sont pas.
• L’application exposée. C’est la partie que les gens oublient. Si un attaquant trouve votre URL de tunnel et exploite une faille dans l’application derrière, il obtient les privilèges de ce processus d’application, pas du client tunnel. Un serveur de développement tournant en tant qu’administrateur, avec accès aux sockets Docker ou aux identifiants cloud, représente le vrai problème de rayon d’impact. Exécuter le client tunnel sans privilèges est une bonne pratique, mais il est tout aussi important que l’application exposée ne le soit pas.

Sous Linux, l’association à des ports inférieurs à 1024 nécessite traditionnellement des droits élevés, c’est pourquoi les serveurs de tunnels auto-hébergés écoutent généralement sur des ports élevés ou derrière un reverse proxy. bore, par exemple, par défaut, accepte ses ports de tunnel à partir de 1024.

Rootless est nécessaire, pas suffisant

Il est tentant de dire que supprimer root rend un tunnel conforme, ou même invisible pour la détection en endpoint. Ce n’est pas vrai, et le second n’est pas l’objectif principal d’un programme de conformité.

Les utilitaires de tunneling sont une technique d’attaque bien documentée, répertoriée dans MITRE ATT&CK comme Protocol Tunneling (T1572). Quelques points concrets :

• L’avis conjoint de CISA sur le groupe de ransomware Akira décrit des acteurs utilisant des utilitaires de tunneling comme ngrok pour établir des sessions chiffrées de commande et contrôle qui contournent la surveillance périmétrique, et liste également Cloudflare Tunnel parmi les outils utilisés pour C2.
• L’analyse de Cofense de mars 2026 documente des acteurs malveillants abusant de Cloudflare Tunnels, notamment la fonctionnalité gratuite TryCloudflare, pour établir des connexions temporaires et obfusquées dissimulant leur infrastructure.
• La recherche SERPENTINE#CLOUD de Securonix décrit une campagne hébergeant des charges utiles sur des sous-domaines trycloudflare.com.
• L’équipe de réponse aux incidents de GuidePoint a documenté l’utilisation de cloudflared dans des intrusions dès 2023, notant que des outils légitimes et couramment utilisés réduisent la détection.

Les défenseurs ont répondu par des détections basées sur le comportement, pas sur le privilège. La règle analytique “Windows Potential Cloudflared Network Connection” de Splunk (mise à jour mai 2026) repose sur la télémétrie EDR : noms de processus, processus parent et lignes de commande complètes. Elastic fournit une règle préconstruite “Potential Protocol Tunneling via Cloudflared” mappée à T1572.

La conclusion pour un programme de conformité : un tunnel approuvé, rootless, inventorié avec journalisation est défendable. Un tunnel non approuvé ressemblera à celui d’un attaquant, qu’il fonctionne avec ou sans privilèges root, car du point de vue du réseau, il fait la même chose. Considérer “l’évasion de détection” comme l’anti-objectif. L’objectif est de rendre les tunnels sanctionnés faciles à reconnaître et à mettre sur la liste blanche.

La boîte à outils sans-racine

Outils basés sur SSH : rien à installer

Le forwarding SSH à distance est le tunnel inverse original, utilisant le client OpenSSH fourni avec les versions actuelles de Windows, macOS et presque toutes les distributions Linux. Cela signifie pas de nouveau binaire à vérifier.

localhost.run fonctionne avec une seule commande et sans inscription :

ssh -R 80:localhost:8080 nokey@localhost.run

Les domaines gratuits restent gratuits, mais la FAQ indique que les tunnels gratuits changent de nom de domaine après quelques heures, ce qui les rend peu adaptés aux enregistrements webhook nécessitant une URL stable. Utiliser une clé SSH plutôt que le nom d’utilisateur nokey maintient le domaine entre les connexions, et un domaine stable comme lhr.rocks ou un domaine personnalisé est une option payante à 9 $ par mois, facturée annuellement.

Pinggy adopte la même approche :

ssh -p 443 -R0:localhost:3000 free.pinggy.io

Selon la page d’aide de Pinggy, le plan gratuit a un délai d’expiration de tunnel de 60 minutes, et démarrer un nouveau tunnel donne une nouvelle URL. Un domaine ou URL persistante nécessite un plan Pro. Les tunnels TCP et TLS sont gratuits. À noter pour la sécurité : Pinggy indique qu’il lit le trafic du tunnel pour alimenter sa fonctionnalité Web Debugger, et recommande les tunnels TLS pour son mode “zéro confiance”, où il ne peut pas lire vos données. Fonctionner sur le port 443 signifie que cela ressemble à un egress HTTPS ordinaire, pratique pour les développeurs et la raison pour laquelle vous souhaitez qu’il soit sur une liste approuvée plutôt que découvert par accident.

Binaires auto-hébergés : pas de tiers dans le chemin de données

frp (Fast Reverse Proxy) est la norme pour l’auto-hébergement. Vous exécutez frps sur un VPS que vous contrôlez et frpc sur les machines des développeurs, avec forwarding TCP, UDP, HTTP et HTTPS. Il est en développement actif, avec la version v0.70 actuellement sur la page de release du projet. Deux détails importants pour la conformité : TLS entre client et serveur activé par défaut depuis v0.50.0, et vous pouvez définir transport.tls.force = true sur le serveur pour rejeter les clients non-TLS. Depuis v0.69.0, le projet documente aussi une fenêtre de support : chaque version mineure est supportée jusqu’à ce que neuf versions mineures plus récentes soient publiées, avec une compatibilité garantie à l’intérieur de cette fenêtre.

bore est l’option minimaliste. Son README le décrit comme environ 400 lignes de Rust sécurisé et asynchrone, un seul binaire pour client et serveur, sans fichier de configuration :

bore local 8000 --to bore.pub

Il est uniquement TCP, et les précautions de sécurité sont à mentionner clairement. L’optionnel --secret est utilisé pour un défi HMAC lors de la poignée de main initiale, mais le README indique qu’aucun autre trafic n’est chiffré par défaut. Tout ce qui est sensible doit porter son propre TLS. Le serveur utilise un port de contrôle (7835) et, par défaut, ne distribue que des ports de tunnel à partir de 1024. Cela facilite la compréhension, mais c’est un outil pour un serveur déjà contrôlé, pas une plateforme d’entreprise gouvernée.

zrok (basé sur OpenZiti) adopte un modèle mental différent : partage privé. Un partage privé n’est exposé qu’à l’intérieur du réseau OpenZiti et accessible via zrok access, plutôt que par un frontend public. Des partages publics pour HTTP/HTTPS existent aussi, et il y a un mode “drive” de partage de fichiers via WebDAV. Notez que zrok 2.0 (sorti début 2026) a renommé le binaire en zrok2, déplacé son répertoire d’environnement vers ~/.zrok2, et remplacé les partages réservés par des espaces de noms et noms réservés. Les tutoriels plus anciens utilisant zrok reserve ne correspondront plus aux versions actuelles.

Options réseau et identité

Cloudflare Tunnel (cloudflared) établit une connexion sortante vers l’edge de Cloudflare. La forme quick-tunnel ne nécessite pas de compte :

cloudflared tunnel --url http://localhost:8080

La documentation de Cloudflare précise que les quick tunnels sont uniquement pour les tests : ils ont une limite de 200 requêtes simultanées et ne supportent pas les Server-Sent Events. L’utilisation en production nécessite un tunnel nommé, qui requiert un compte Cloudflare et un domaine sur DNS Cloudflare, mais offre un hostname stable et des politiques d’accès devant l’application. Étant donné la fréquence d’apparition de TryCloudflare dans les rapports de menace, de nombreuses équipes de sécurité bloquent *.trycloudflare.com directement et n’autorisent que les tunnels nommés liés au compte d’entreprise.

Microsoft Dev Tunnels est l’option la plus clairement conçue pour des environnements gérés. Héberger un tunnel nécessite de se connecter avec un Microsoft Entra ID, un compte Microsoft ou GitHub ; les utilisateurs anonymes ne peuvent pas créer de tunnels. Par défaut, seul le compte créateur peut héberger ou se connecter. L’accès anonyme est une option explicite (--allow-anonymous), et la documentation de Microsoft avertit que cela permet à quiconque devinant l’ID du tunnel d’atteindre votre serveur local. L’accès peut être étendu à votre tenant Entra (--tenant) ou à une organisation GitHub. Crucial pour les admins : il existe des politiques de groupe pour désactiver totalement l’accès anonyme et limiter les utilisateurs à une liste blanche d’ID de tenant Entra. Microsoft publie aussi les domaines sortants impliqués (par exemple *.devtunnels.ms), pour permettre ou bloquer au niveau réseau.

ngrok reste l’option commerciale la plus connue. Son agent ouvre une connexion TLS sortante sur le port 443, et le plan gratuit inclut un agent, un domaine statique, inspection et replay du trafic, et des endpoints HTTP, HTTPS et TCP. L’authentification via OAuth ou basic auth est appliquée via Traffic Policy. L’agent n’est pas un outil réservé à root, mais notez que ngrok a été mentionné avec Cloudflare Tunnel dans l’avis CISA ci-dessus, il doit donc être dans votre inventaire comme tout autre tunnel.

Gestion d’entreprise : Packetriot Spokes

Pour les équipes nécessitant un contrôle centralisé, Packetriot propose Spokes, une version auto-hébergée (ou gérée par le fournisseur) de son serveur edge. La documentation indique que le client Packetriot standard fonctionne de manière identique contre Spokes, avec des administrateurs gérant l’enregistrement des clients et les jetons d’authentification.

Ce que la page d’entreprise du fournisseur indique réellement :

• Spokes fournit des tunnels HTTP/S et TCP pour des équipes ou flottes de dispositifs, avec plus de contrôle sur le trafic, la sécurité et l’audit. Une instance unique est conçue pour évoluer jusqu’à des milliers de tunnels.
• Déploiement via un conteneur Docker officiel, Kubernetes ou paquets RPM et DEB. SQLite est la base de données par défaut, avec options MariaDB et Postgres pour de plus grandes déploiements.
• La licence est annuelle et basée sur le nombre de tunnels : 1000 $ pour jusqu’à 100 tunnels, 2000 $ pour 250, 3500 $ pour 500, et prix personnalisé pour 1000 ou plus. Une licence d’essai de 30 jours est proposée.
• Le fournisseur argue que l’hébergement sur site permet de réutiliser les contrôles existants pour des régimes comme HIPAA, GDPR, SOX et PCI. C’est une position du fournisseur, pas une certification : Spokes en fonctionnement dans votre environnement hérite de votre posture de conformité, et vous devrez toujours valider la journalisation, la rétention et les contrôles d’accès selon vos propres exigences d’audit.

Côté client, le démarrage rapide de Packetriot distingue une configuration utilisateur, adaptée à un hébergement intermittent et des tests, d’une configuration système pour un hébergement persistant ²⁴⁄₇. Cela correspond bien à une politique : utilisateur unique pour les laptops de développeurs, réservé au niveau système pour les dispositifs gérés.

Les alternatives légitimes à ce niveau incluent un déploiement auto-hébergé de frp et les plans payants de Cloudflare ou ngrok avec SSO et fonctionnalités d’audit. Le choix dépend de l’endroit où vous souhaitez que le chemin de données et le journal d’audit résident.

Tunnels intégrés : une tendance réelle, avec un compromis de détection

Certaines équipes s’éloignent des binaires de tunnel autonomes vers des tunnels créés à l’intérieur du processus applicatif. C’est réel et supporté par les fournisseurs :

• ngrok Agent SDKs pour Go, JavaScript, Python et Rust permettent à une application de créer ses propres endpoints de manière programmatique, et la documentation ngrok indique que le trafic depuis le cloud ngrok est traité comme si l’application avait ouvert une socket d’écoute. Elle recommande ces SDKs si vous ne souhaitez pas gérer un processus agent séparé.
• OpenZiti et zrok fournissent des SDK pour intégrer la connectivité zero-trust directement dans une application.
• Pinggy liste un SDK Python pour la création de tunnels programmatiques.

L’avantage sécurité est réel : le tunnel hérite de l’utilisateur, des limites de ressources et de la politique réseau de l’application, et disparaît lorsque le processus se termine, évitant un service de fond permanent.

L’inconvénient est la visibilité. Un tunnel créé dans votre application ne sera pas visible comme un processus ngrok ou cloudflared reconnaissable, donc les détections basées sur le nom de processus ou la ligne de commande le manqueront. Pour les tunnels intégrés, votre détection doit se baser sur le DNS, le proxy et la télémétrie firewall : quels hôtes parlent à vos agents de build et machines de développement, et ces domaines de fournisseurs de tunnels sont-ils sur votre liste approuvée ?

Une note sur “TunnelAPI 2.0.” Vous pouvez voir cela décrit comme une norme émergente pour l’intégration du tunneling dans les runtimes d’application. Ce n’en est pas une. TunnelAPI est une plateforme hébergée par un seul fournisseur (docs.tunnelapi.in) qui combine des tunnels HTTPS avec une passerelle API, un contrôleur d’entrée Kubernetes, et une authentification SAML/OAuth/OIDC pour les tunnels. Elle est listée dans les répertoires communautaires “awesome-tunneling” à côté d’un outil 1.0 plus ancien, et est pilotée par une CLI arm. C’est peut-être un bon produit à évaluer, mais il n’existe pas de spécification neutre de fournisseur “TunnelAPI 2.0” pour construire une politique. Pour les tunnels intégrés aujourd’hui, regardez les SDK mentionnés ci-dessus.

Un plan de déploiement que les développeurs suivront réellement

1. Inventaire en premier. Utilisez la télémétrie EDR, DNS et proxy pour repérer les agents de tunnel et domaines déjà en usage, y compris ceux basés sur SSH (sessions SSH sortantes longues vers des hôtes inconnus, et flags -R dans les lignes de commande). Signalez tout en privilège élevé ou installé en tant que service système.
2. Rédigez la norme d’utilisation acceptable. Exigez que les tunnels tournent en utilisateur standard, n’exposent qu’un port intentionnel, soient protégés par authentification pour tout ce qui dépasse une démo jetable, et ne frontent jamais une application tournant en administrateur ou avec des identifiants de production dans l’environnement.
3. Proposez une voie sanctionnée. Bloquer sans remplacement pousse les développeurs vers des comptes personnels et outils grand public. Choisissez une ou deux options approuvées : par exemple Dev Tunnels avec accès anonyme désactivé par politique et restriction de tenant, plus une instance auto-hébergée frp ou Packetriot Spokes pour des besoins partagés et durables.
4. Appliquez au niveau réseau. Liste blanche des domaines des fournisseurs sanctionnés et bloquez ou alertez pour les autres, y compris trycloudflare.com si vous n’utilisez pas quick tunnels. Parce que les tunnels SSH et port 443 se fondent dans le trafic normal, ce sont les logs DNS et proxy qui sont votre principal point d’application.
5. Ajoutez la détection, pas seulement l’interdiction. Utilisez des règles fournisseur pour les outils de tunneling (comme celles de Splunk et Elastic pour cloudflared, et équivalents pour d’autres outils) avec une liste d’exception pour les déploiements approuvés, pour que les alertes restent pertinentes.
6. Gérez les tunnels intégrés avec soin. Si des frameworks internes créent des tunnels au démarrage, enregistrez les endpoints qu’ils utilisent et assurez-vous qu’ils soient authentifiés et limités dans le temps.
7. Révisez périodiquement. Les termes de l’offre gratuite et le comportement des produits changent souvent (le renommage de zrok 2.0 et les règles de timeout de Pinggy en sont des exemples récents), donc revérifiez votre liste approuvée selon la documentation fournisseur à intervalles réguliers.

En résumé

Exécuter des clients de tunnel sans root est une ligne de base raisonnable. Cela réduit ce qu’un agent compromis peut faire, et maintient les tunnels hors du niveau privilégié, toujours actif. Mais cela ne rend pas un tunnel sûr, ni invisible, et cela ne doit pas. La position de conformité la plus forte est une liste courte d’options de tunneling approuvées, authentifiées, journalisées, une politique réseau appliquée qui considère tout le reste comme suspect, et une détection qui comprend à la fois les tunnels autonomes et intégrés.

---

Sources

• Packetriot pour Entreprise : https://packetriot.com/enterprise
• Documentation Packetriot Spokes : https://docs.packetriot.com/spokes/
• Démarrage rapide Packetriot : https://docs.packetriot.com/quickstart/
• Aide Pinggy : https://pinggy.io/help/
• FAQ localhost.run : https://localhost.run/docs/faq/
• Accueil / Tarification localhost.run : https://localhost.run/
• Dépôt frp : https://github.com/fatedier/frp
• Releases frp : https://github.com/fatedier/frp/releases
• Dépôt bore : https://github.com/ekzhang/bore
• Releases zrok : https://github.com/openziti/zrok/releases
• Introduction à zrok v2.0 : https://blog.openziti.io/introducing-zrok-v2-0
• Documentation partage public zrok : https://docs.zrok.io/docs/concepts/sharing-public
• Configuration Cloudflare Tunnel (limites quick tunnel) : https://developers.cloudflare.com/tunnel/get-started/
• Sécurité Microsoft Dev Tunnels : https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/security
• Politiques de groupe Microsoft Dev Tunnels : https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/policies
• Référence CLI Microsoft Dev Tunnels : https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/cli-commands
• ngrok SDKs : https://ngrok.com/docs/agent-sdks
• Vue d’ensemble partage local ngrok : https://ngrok.com/use-cases/share-localhost
• CISA #StopRansomware : Akira : https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-109a
• Cofense, abus de Cloudflare : https://cofense.com/blog/how-cloudflare-services-are-abused-for-credential-theft-and-malware-distribution
• Securonix, SERPENTINE#CLOUD : https://www.securonix.com/blog/analyzing_serpentinecloud-threat-actors-abuse-cloudflare-tunnels-threat-research/
• GuidePoint, Cloudflared en utilisation : https://www.guidepointsecurity.com/blog/tunnel-vision-cloudflared-abused-in-the-wild/
• Splunk, Connexion réseau potentielle cloudflared : https://research.splunk.com/endpoint/29798d45-c9c7-4240-a5ef-d7648c016024/
• Elastic, Tunneling de protocole potentiel via cloudflared : https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/windows/command_and_control_tunnel_cloudflared
• MITRE ATT&CK T1572, Protocol Tunneling : https://attack.mitre.org/techniques/T1572/
• docs.tunnelapi.in : https://docs.tunnelapi.in/
• Directory awesome-tunneling : https://github.com/anderspitman/awesome-tunneling