Variables d'environnement du proxy : auditer le trafic API d'un agent

Les variables d'environnement du proxy sont des instructions de routage exécutables, pas de simples préférences inoffensives du shell. Si un agent de programmation IA hérite de HTTP_PROXY, HTTPS_PROXY, ALL_PROXY ou NO_PROXY, une requête qui semblait devoir atteindre directement une API interne peut emprunter un autre chemin réseau avant même que l'agent ait commencé son travail.

J'ai vu des équipes passer des jours à examiner la portée des jetons et les listes d'autorisation des points de terminaison, avant de découvrir que l'exécuteur de l'agent avait hérité d'un proxy de débogage local depuis le shell d'un développeur. Les identifiants étaient valides, le client API fonctionnait exactement comme prévu, mais le trafic allait tout de même quelque part où personne ne l'avait voulu. Auditez l'environnement du processus avant d'autoriser un agent à accéder à des services internes.

Les variables de proxy modifient la route, pas seulement les paramètres de connexion

Une variable de proxy indique à un client compatible de remettre sa requête à un intermédiaire. Pour HTTP ordinaire, le client envoie généralement l'URL complète de destination à cet intermédiaire. Pour HTTPS, il lui demande habituellement d'ouvrir un tunnel CONNECT vers l'hôte cible, puis établit TLS dans ce tunnel.

Cette différence compte, car un proxy peut agir sur la disponibilité, le contrôle de la destination, le comportement DNS et la visibilité du trafic, même s'il ne peut pas déchiffrer HTTPS. Il peut refuser une connexion, la rediriger au niveau TCP, enregistrer l'hôte et le port demandés, ou devenir le seul chemin permettant à un agent d'atteindre un service.

Considérez ces variables comme une partie de l'autorité de sortie de l'agent :

• HTTP_PROXY et http_proxy concernent généralement les URL http://.
• HTTPS_PROXY et https_proxy concernent généralement les URL https://.
• ALL_PROXY et all_proxy servent de solution de repli dans les clients qui les prennent en charge.
• NO_PROXY et no_proxy excluent généralement certaines destinations du passage par le proxy.

Le mot « généralement » est important. Les variables d'environnement sont une convention, pas une norme réseau que tous les environnements implémentent de la même manière. Un agent peut appeler un client en ligne de commande, utiliser une bibliothèque HTTP, lancer un gestionnaire de paquets ou démarrer un processus auxiliaire. Chaque couche peut prendre une décision différente concernant le proxy.

Une variable absente ne prouve pas non plus qu'une route directe est utilisée. Un client peut lire un fichier de configuration, utiliser un paramètre de proxy système, respecter un fichier PAC ou appeler explicitement un relais local. Cet article se concentre sur les variables d'environnement parce qu'elles sont faciles à hériter, difficiles à repérer dans un environnement de processus chargé et souvent considérées comme temporaires alors qu'elles sont devenues permanentes.

Le lanceur détermine ce que l'agent hérite

Un agent ne reçoit que les variables présentes dans son propre environnement de processus ou transmises par un parent. Le terminal dans lequel vous avez vérifié env n'a peut-être aucun rapport avec le processus qui exécute réellement l'agent.

Sur macOS, l'erreur est particulièrement facile. Un processus lancé depuis un shell interactif hérite des variables exportées par ce shell. Une app graphique lancée depuis Finder ou un service lancé par launchd suit un autre chemin d'héritage. Un IDE peut démarrer son terminal intégré avec un environnement et son hôte d'extensions avec un autre. Un agent lancé en arrière-plan hier peut conserver une ancienne valeur de proxy longtemps après la disparition de la variable du shell.

Cartographiez la chaîne d'exécution avant de modifier les paramètres. Posez quatre questions concrètes :

1. Quel processus démarre l'agent ?
2. L'agent démarre-t-il des shells, des outils de paquets, des exécuteurs de tests ou des assistants distants ?
3. Lesquels de ces processus effectuent-ils des appels HTTP ?
4. Quel point de lancement fournit chaque variable d'environnement ?

N'acceptez pas « l'agent s'exécute dans mon terminal » comme réponse tant que vous n'avez pas identifié le processus parent et reproduit l'exécution depuis ce terminal. L'agent peut être un enfant de l'éditeur, d'un exécuteur de tâches ou d'un service d'automatisation qui utilise un environnement enregistré.

Une variable de proxy injectée par un processus parent atteint tous ses enfants, sauf si l'un d'eux la supprime. C'est pourquoi un simple export dans le shell peut modifier discrètement les appels effectués par l'installation de paquets, les assistants de contrôle de version, les CLI cloud, l'automatisation de navigateur et les fixtures de test. La requête concernée n'est peut-être pas celle à laquelle vous pensiez en lançant l'agent.

La sémantique des variables de proxy varie selon les clients

Il n'existe pas une interprétation unique de HTTP_PROXY, HTTPS_PROXY et NO_PROXY. Une revue de sécurité qui applique le comportement d'un client à un autre est incomplète.

La documentation de curl décrit une exception importante que beaucoup ignorent : curl n'accepte que http_proxy en minuscules pour configurer un proxy HTTP. La documentation explique que cela évite un problème CGI, dans lequel un en-tête entrant Proxy: peut devenir une variable d'environnement HTTP_PROXY. curl accepte les variantes en majuscules pour plusieurs autres variables de proxy, mais cette exception HTTP est intentionnelle.

Go documente http.ProxyFromEnvironment comme une fonction qui lit HTTP_PROXY, HTTPS_PROXY et NO_PROXY, ainsi que leurs variantes en minuscules. Son comportement comprend aussi une protection CGI : lorsqu'un environnement CGI contient REQUEST_METHOD, Go refuse d'utiliser HTTP_PROXY, car un en-tête de requête a pu le fournir. Cette protection ne rend pas un processus Go sûr. HTTPS_PROXY, les formes en minuscules, les paramètres de transport explicites et les contextes non CGI doivent encore être examinés.

De nombreuses applications JavaScript compliquent la situation. Le runtime Node.js n'a historiquement pas imposé de politique universelle concernant les proxys d'environnement dans ses API HTTP intégrées. Les applications et leurs dépendances ajoutent souvent elles-mêmes la prise en charge des proxys. Une commande peut respecter HTTPS_PROXY, une autre du même lancement peut l'ignorer et une troisième peut lire une option personnalisée.

Ne tranchez pas cette question avec un tableau de croyances sur les runtimes. Identifiez chaque exécutable capable de communiquer sur le réseau et testez-le. Notez sa version, son invocation, l'URL cible, les variables concernées et le fait qu'il se soit connecté directement ou via le proxy prévu. Conservez le résultat avec les notes de déploiement de l'agent, car une mise à jour de dépendance peut modifier le comportement.

On confond souvent deux notions : la prise en compte du proxy et son application. Un client qui respecte une variable de proxy peut être routé lorsque celle-ci existe. Il peut toujours se connecter directement si la variable est absente, mal formée, contournée par NO_PROXY ou ignorée par un processus auxiliaire. Si vous devez empêcher toute sortie directe, imposez cette règle à la frontière réseau au lieu d'espérer que chaque bibliothèque lise une variable d'environnement.

NO_PROXY exige des tests explicites pour les noms internes

NO_PROXY est une liste de contournement. Une mauvaise liste peut envoyer du trafic interne vers un proxy ou laisser passer directement du trafic que vous pensiez devoir inspecter. Aucun de ces résultats ne doit être supposé sûr.

La plupart des implémentations acceptent des entrées séparées par des virgules. Au-delà, les détails divergent. Les clients peuvent traiter différemment registry.corp.example, .corp.example, corp.example, 10.20.0.0/16, 10.20.30.40, localhost et *. Une correspondance par suffixe qui fonctionne dans un client peut être trop large ou échouer complètement dans un autre. Les entrées incluant un port ne se comportent pas non plus de façon uniforme.

Évitez les entrées trop larges tant qu'un test n'a pas confirmé leur signification. Un suffixe de domaine nu peut exclure des hôtes que vous ne vouliez pas inclure. Un astérisque peut désactiver le proxy bien plus largement que ne le prévoit le réviseur. La prise en charge de CIDR est utile lorsqu'elle existe, mais ne constitue pas une hypothèse portable. Les noms d'hôtes internes exacts sont peu sophistiqués, et c'est précisément ce qui les rend utiles ici.

Commencez par une courte liste de services nommés qui doivent se connecter directement, comme un hôte de code source interne, un registre d'artefacts et un point de terminaison de découverte de services. N'ajoutez un suffixe de domaine qu'après avoir vérifié que le client le met en correspondance comme prévu et que tous les hôtes situés sous ce suffixe doivent emprunter la même route.

Séparez aussi la correspondance des noms de la résolution de noms. Un client décide souvent si NO_PROXY s'applique avant de se connecter. Si votre liste contient un nom d'hôte, la correspondance peut réussir même si ce nom se résout vers une adresse extérieure à la plage attendue. Si votre liste contient une plage IP, le client doit parfois résoudre le nom avant de pouvoir décider. L'implémentation contrôle cette séquence.

Un test de contournement nécessite une destination que vous contrôlez et que vous pouvez identifier dans les journaux. N'utilisez pas une API de production en déduisant le succès d'une réponse 200. Un point de terminaison de test interne doit signaler l'adresse distante ou émettre un identifiant de requête dans son journal d'accès. Comparez ensuite une requête effectuée avec l'entrée de contournement et une autre sans cette entrée. Vous voulez des preuves du chemin de connexion, pas une supposition fondée sur la sortie de l'application.

HTTPS masque le contenu, mais un proxy reçoit tout de même des informations utiles

Un tunnel HTTPS CONNECT protège généralement les en-têtes et les corps de requête d'un proxy direct classique. Il ne rend pas le proxy sans importance. Celui-ci voit l'hôte et le port indiqués dans la requête CONNECT, le moment de la connexion, les volumes d'octets et souvent l'adresse source. Selon le client et le réseau, le trafic DNS associé peut révéler davantage.

Le proxy peut lire des identifiants API déchiffrés si le client fait confiance à une autorité de certification utilisée par le proxy pour intercepter TLS. Cela arrive dans certains réseaux d'entreprise administrés et dans des configurations de débogage. La présence d'un certificat racine local approuvé est une décision de sécurité, pas un simple réglage pratique. Si un processus d'agent fait confiance à cette racine, l'opérateur du proxy peut inspecter le trafic vers tout hôte couvert par la politique d'interception.

HTTP en clair est plus grave encore. Un proxy direct peut recevoir l'URL complète et les en-têtes de requête, y compris des jetons bearer ou une authentification basique. N'autorisez pas un agent à utiliser HTTP en clair pour des API internes authentifiées sous prétexte que « le réseau est privé ». Les variables de proxy sont l'un des moyens par lesquels cette hypothèse devient fausse.

Un problème moins évident concerne une URL de proxy contenant des identifiants, par exemple http://user:[email protected]:8080. Cette valeur peut apparaître dans une sortie de diagnostic, un rapport d'incident, l'historique du shell, une inspection de processus ou des journaux qui enregistrent l'environnement. L'authentification du proxy doit utiliser un mécanisme administré adapté à votre environnement, et une revue de sécurité doit traiter ces identifiants comme des secrets à part entière.

Si vous ne pouvez pas identifier l'opérateur du proxy, l'adresse de son écouteur et la possibilité d'une interception TLS, ne faites pas passer par lui le trafic privilégié de l'agent. Ce n'est pas de la paranoïa. Le proxy fait déjà partie du chemin entre un processus automatisé et un service sensible.

Auditez le processus en cours sans révéler ses secrets

Commencez par un inventaire qui indique les noms des variables et les points de terminaison des proxys, sans produire une copie complète de l'environnement. Dans un shell susceptible de lancer l'agent, exécutez :

env | grep -Ei '(^|_)(http|https|all|no)_proxy='

La sortie devrait ressembler à ceci :

HTTPS_PROXY=http://127.0.0.1:8888
NO_PROXY=localhost,127.0.0.1,registry.corp.example

Si l'URL du proxy contient des informations utilisateur, ne copiez pas la sortie brute dans un ticket. Notez le schéma, l'hôte et le port après suppression des identifiants. Une adresse de bouclage n'est pas automatiquement sûre. Les proxys locaux servent souvent à des outils de débogage légitimes, mais des logiciels malveillants ou indésirables peuvent aussi écouter sur le bouclage. Vérifiez quel processus possède le port d'écoute.

Sur macOS, inspectez un écouteur avec :

lsof -nP -iTCP:8888 -sTCP:LISTEN

Un résultat normal indique une commande et un identifiant de processus. Si aucun processus attendu ne possède le port, arrêtez-vous et enquêtez. Ne laissez pas un agent envoyer des identifiants à un écouteur simplement parce que l'adresse commence par 127.0.0.1.

Inspectez ensuite le processus réel de l'agent. ps peut afficher l'environnement d'un processus sur macOS, mais il peut aussi révéler d'autres secrets. Limitez l'accès au propriétaire de la machine ou à un administrateur, ne collectez que le nécessaire et ne copiez pas le résultat dans une conversation ou un journal partagé.

ps eww -p "$AGENT_PID" | tr ' ' '\n' | grep -Ei '(^|_)(http|https|all|no)_proxy='

Définissez AGENT_PID avec l'identifiant du processus de l'agent en cours. Cette commande peut encore afficher des identifiants de proxy sensibles. Utilisez-la dans un terminal fiable et expurgez les résultats avant de conserver les preuves. Si la sortie diffère de l'inventaire du shell, le processus parent a injecté ou supprimé des variables.

Pour les processus lancés par launchd, examinez la définition du job et le lanceur plutôt que de vous fier au terminal. launchctl getenv HTTPS_PROXY peut révéler une variable dans le domaine launchd actuel, mais son absence ne suffit pas à innocenter un job particulier. Un job peut définir son propre environnement et un script enveloppe peut exporter des variables juste avant de démarrer l'agent.

Prouvez la route avec une requête sans danger

Une revue de configuration indique ce qui devrait arriver. Une requête contrôlée montre ce qui s'est réellement passé. Il faut les deux.

Créez ou utilisez un point de terminaison sans données sensibles qui journalise l'adresse du pair et le chemin de la requête. Effectuez ensuite une requête avec une sortie détaillée. curl est utile, car il indique s'il se connecte au proxy et s'il envoie une requête CONNECT.

HTTPS_PROXY=http://127.0.0.1:8888 \
NO_PROXY= \
curl -v --connect-timeout 5 https://probe.corp.example/agent-proxy-check

Lorsque curl utilise le proxy pour HTTPS, sa sortie détaillée contient généralement des lignes de cette forme :

* Uses proxy env variable HTTPS_PROXY == 'http://127.0.0.1:8888'
* Establish HTTP proxy tunnel to probe.corp.example:443
> CONNECT probe.corp.example:443 HTTP/1.1

Effectuez ensuite volontairement la comparaison directe :

HTTPS_PROXY=http://127.0.0.1:8888 \
NO_PROXY=probe.corp.example \
curl -v --connect-timeout 5 https://probe.corp.example/agent-proxy-check

Une exécution directe doit montrer une connexion vers la cible plutôt qu'une requête CONNECT vers le proxy. Confirmez le résultat dans les journaux du serveur de test. Si curl indique qu'il a contourné le proxy mais que le serveur voit une source inattendue ou que la requête échoue, examinez séparément le DNS, le routage et tout proxy réseau transparent.

Cela prouve le comportement de curl, pas celui de votre agent. Répétez le test en passant par le chemin d'exécution exact de l'agent. S'il appelle un script, exécutez ce script. S'il utilise une dépendance pour appeler une API, ajoutez temporairement une URL de test dans cette même configuration. S'il lance un processus auxiliaire, recueillez les preuves de routage de ce processus. Le test d'un autre client n'est qu'un indice.

N'utilisez pas un service public de type « quelle est mon adresse IP ? ». Vous transformeriez une revue de routage interne en divulgation externe inutile, sans savoir quelle politique de proxy interne s'est appliquée.

Les environnements de lancement propres valent mieux que les exports permanents du shell

Ne placez pas les exports de proxy d'entreprise dans un profil shell universel en espérant que les outils autonomes sauront créer des exceptions sûres. Les exports globaux sont populaires parce qu'ils permettent à une commande bloquée de fonctionner une fois. Ils se propagent aussi à tous les processus enfants que vous oublierez ensuite.

Utilisez un lanceur explicite pour l'agent. Commencez avec un environnement connu, transmettez uniquement les variables nécessaires et rendez l'utilisation du proxy visible dans la commande de lancement ou le script enveloppe. Dans un shell Unix, env -i efface les variables héritées. Vous devez donc restaurer les éléments de base requis par le programme :

env -i \
PATH="$PATH" \
HOME="$HOME" \
LANG="${LANG:-en_US.UTF-8}" \
NO_PROXY="localhost,127.0.0.1,registry.corp.example" \
agent-command

Cet exemple ne définit volontairement aucun proxy. Si l'agent en a besoin, ajoutez la variable dans le lanceur après avoir identifié le propriétaire du proxy et testé son comportement. Ne copiez pas une valeur depuis un profil shell vers un script sans vérifier si elle contient des identifiants ou pointe vers un service local obsolète.

Un environnement propre peut casser des outils qui dépendaient de variables telles que les emplacements de certificats, les profils cloud, les sockets d'agent SSH ou les caches de paquets. Cette panne fournit une information utile. Rajoutez seulement les variables nécessaires à l'agent, une par une, et documentez la raison de chacune. Le lanceur doit être assez limité pour qu'un autre ingénieur comprenne où partiront les requêtes.

Les contrôles réseau doivent compléter cette approche. Si un agent ne doit atteindre que quelques services internes, utilisez des règles de pare-feu, un proxy de sortie à politique imposée ou un segment réseau dédié adapté à votre environnement. Les variables d'environnement choisissent une route pour les clients coopératifs. Elles n'empêchent pas un processus compromis ou une bibliothèque non conforme d'ouvrir directement un socket.

Gardez les identifiants hors du processus qui choisit la route

Une bonne hygiène de proxy réduit les changements de route accidentels, mais ne rend pas judicieux le fait de remettre des jetons API à un agent autonome. Si l'environnement de l'agent contient un jeton bearer, chaque processus qui peut accéder à cet environnement fait partie du chemin d'exposition du secret.

Sallyport place cette frontière ailleurs : l'agent demande une action HTTP ou SSH via son shim MCP, tandis que les identifiants restent dans le coffre chiffré de l'app et que l'app exécute l'action. Ainsi, une fuite de variable de proxy dans le processus de l'agent expose moins de choses, puisque l'agent ne reçoit jamais l'identifiant API ou SSH en clair.

Ne surestimez pas cette séparation. Une passerelle d'identifiants ne définit pas automatiquement un comportement de proxy sûr pour chaque commande exécutée par l'agent et ne rend pas inoffensive une destination dangereuse. Vous devez toujours contrôler les destinations et les actions autorisées, examiner le processus applicatif qui effectue l'appel réseau et conserver la preuve du chemin de la requête.

La séparation utile est celle entre la garde du secret et le routage réseau. La garde du secret répond à la question de savoir qui peut lire l'identifiant. Le routage répond à celle de savoir quel intermédiaire traite la requête. Les équipes résolvent souvent l'un des deux problèmes en pensant avoir résolu les deux. Ce n'est pas le cas.

Traitez toute utilisation inexpliquée d'un proxy comme un incident à contenir

Si un agent privilégié a envoyé des requêtes via un proxy inconnu, arrêtez l'exécution avant d'enquêter depuis le même environnement contaminé. Notez l'identifiant du processus de l'agent, son processus parent, l'adresse du proxy, les noms des destinations concernées et la période. Conservez les journaux pertinents de l'agent et du proxy conformément à votre procédure d'incident.

Supprimez ensuite la variable à sa source. La supprimer dans votre terminal actuel ne corrige que les futurs enfants de ce terminal. Vérifiez les profils shell, les paramètres de tâches de l'IDE, les agents de lancement, la configuration CI, les scripts enveloppes et tout système de gestion de configuration qui écrit des paramètres d'environnement. Redémarrez le processus concerné après avoir corrigé le point de lancement.

Évaluez les identifiants selon le protocole. Si le trafic concerné était du HTTP en clair avec authentification, faites tourner l'identifiant exposé. S'il s'agissait de HTTPS via un proxy, déterminez si le point de terminaison a validé TLS normalement et si l'agent faisait confiance à un certificat d'interception. Ne supposez pas que HTTPS dispense d'un examen, et ne faites pas tourner les identifiants sans corriger le mécanisme d'injection.

Enfin, ajoutez une vérification préalable au démarrage de l'agent. Faites échouer l'exécution ou demandez une revue explicite lorsqu'une variable de proxy inattendue apparaît. La vérification doit signaler le nom de la variable et un point de terminaison expurgé, le comparer à la route approuvée pour ce job et laisser une trace de son exécution. Le premier proxy inexpliqué est un avertissement. Le deuxième est un défaut de déploiement que vous avez choisi de conserver.