Renforcer la sécurité d’un LLM auto-hébergé : une liste de vérification

Lancer un modèle local via Ollama, llama.cpp, vLLM ou LM Studio est simple. Permettre à un collègue, un agent ou un autre appareil d’accéder à cet endpoint sans en faire une porte ouverte est souvent problématique. Cette liste de vérification décrit les points essentiels, dans l’ordre où ils posent problème, et indique ceux qui ne constituent plus un souci dès qu’un connecteur sortant tel que Tokios est mis en place. Il s’agit d’une liste de vérification, non d’une garantie. La suivre réduit les risques, mais n’élimine pas totalement les dangers ; rien ici ne prétend qu’une configuration donnée — y compris Tokios — soit inviolable.

​

1. Adresse de liaison : privilégiez l’adresse de boucle locale

Chaque environnement d’exécution dans ce domaine utilise par défaut 127.0.0.1 (boucle locale) pour une raison précise : c’est le seul mécanisme empêchant tout accès à l’API en dehors de la machine où elle tourne.

• Ollama écoute sur 127.0.0.1:11434 par défaut. En définissant OLLAMA_HOST=0.0.0.0, il écoute sur toutes les interfaces réseau, devenant ainsi accessible depuis votre réseau local et, si le port est redirigé, depuis Internet.
• llama.cpp server, vLLM et LM Studio fonctionnent de même : adresse de boucle locale par défaut, avec une option permettant de lier l’écoute à 0.0.0.0 ou à une interface LAN spécifique.

Point de la liste : si aucune raison particulière ne justifie d’élargir la portée de la liaison, ne le faites pas. Si un accès LAN ou distant est nécessaire, c’est là que s’appliquent les autres éléments de cette liste ou l’usage d’un connecteur sortant uniquement.

​

2. Authentification : la plupart des environnements n’en proposent pas, ou la rendent optionnelle

Utiliser une adresse de liaison plus large que la boucle locale sans authentification permet à quiconque atteignant le port d’appeler l’API sans aucune identité — lister les modèles, effectuer des inférences ou en télécharger de nouveaux. Point de vérification : si plusieurs personnes ou services sollicitent votre point de terminaison, une seule clé API statique partagée (ou l’absence de clé) ne permet pas d’identifier chaque appelant ni de la révoquer pour un seul d’entre eux. Consultez Ajouter des clés API à un modèle local sans clé pour en savoir plus sur les compromis possibles.

​

3. Pare-feu et ports d’entrée

Lorsque vous autorisez des connexions en dehors du bouclier local, le pare-feu constitue le contrôle suivant :

• Limitez autant que possible le port d’entrée (11434 pour Ollama, 8080 pour llama.cpp, 8000 pour vLLM, 1234 pour LM Studio) aux adresses IP connues, plutôt que de le laisser accessible à toutes les adresses.
• Gardez à l’esprit qu’il faut disposer d’une adresse IP publique stable pour rediriger un port via votre routeur. De nombreuses connexions résidentielles ou mobiles sont soumises à un CGNAT, ce qui empêche d’obtenir une adresse IP publique utilisable — voir Accéder à un modèle derrière un CGNAT.
• Les scanners d’Internet (Shodan, Censys) indexent les services nouvellement ouverts en quelques heures ou jours. Un port ouvert et non protégé ne reste pas longtemps indétecté.

Point de vérification : considérez qu’un port ouvert temporairement reste tout de même repérable. Si un port est accessible, il sera découvert.

​

4. Pièges liés aux proxys inverses

Placer nginx ou Caddy en amont d’un environnement d’exécution sans authentification constitue la solution DIY la plus courante pour pallier ce manque d’authentification, mais cela implique de bien gérer plusieurs éléments critiques :

• Terminaison TLS. Le proxy requiert un certificat valide ; un certificat auto-signé fera échouer les vérifications de confiance par défaut de la plupart des clients HTTP.
• Réponses en streaming. Les API de modèles linguistiques diffusent les jetons via des événements envoyés par le serveur (SSE). Un proxy inverse ou un CDN amont qui met en mémoire tampon les réponses au lieu de les transmettre immédiatement peut transformer un échange supposé diffuser les jetons un par un en une opération bloquée jusqu’à la réception complète de la réponse, voire entraîner un délai d’attente dépassé.
• La logique d’authentification se trouve dans la configuration du proxy, non sur le serveur de modèle. Vous devez désormais veiller à ce que les règles d’authentification du proxy soient correctes, synchronisées et testées ; le moteur d’exécution lui-même ignore totalement l’existence de clés API propres à chaque utilisateur.
• Délais d’attente. Des générations de texte longues peuvent dépasser les délais d’attente par défaut du proxy ou du réseau périphérique, provoquant ainsi une interruption prématurée de la réponse en cours de diffusion.

Point de vérification : si vous mettez en place un proxy inverse, testez impérativement un scénario de réponse en streaming lente sur l’ensemble du parcours — et non uniquement un scénario rapide et bref — avant de l’utiliser en production.

​

5. Veillez à maintenir le moteur d’exécution à jour.

Les serveurs d’inférence locaux sont des logiciels soumis à un cycle normal de vulnérabilités, et les identifiants CVE publiés dans ce domaine sont effectivement exploités dès leur divulgation. Ollama, par exemple, a connu plusieurs avis de sécurité dans son historique de versions ; consultez les avis de sécurité publiés sur GitHub ou la base de données NVD afin de connaître les identifiants CVE ou les versions corrigées avant de vous fier à un identifiant ou à une version précise. Point de vérification : abonnez-vous aux notes de version et aux avis de sécurité du moteur d’exécution, et ne laissez jamais une version en fonctionnement indéfiniment sous prétexte qu’elle fonctionne correctement. Cette règle s’applique que le serveur soit accessible localement ou publiquement ; un hôte compromis demeure un risque même si le reste du réseau est sain.

​

Ce que le mode sortant élimine complètement de cette liste.

Chaque élément précédent repose sur le fait qu’un composant doit écouter les connexions entrantes pour être joignable. Le connecteur en mode sortant — le connecteur Tokios en est un exemple — fonctionne différemment : il s’exécute à côté du modèle et établit une connexion sortante vers https://api.tokios.com, de sorte qu’aucun processus sur votre machine ou votre réseau ne doit écouter sur un port pour le trafic du modèle. Cette approche supprime certains points de vérification, tandis que d’autres demeurent inchangés.

• Aucun port entrant à lier ou à rediriger. Le modèle reste sur 127.0.0.1 ; le connecteur initie la connexion, il n’est donc pas nécessaire de procéder à un bind sur 0.0.0.0, ni de définir de règle de redirection de port, ni de résoudre de problème lié au CGNAT pour assurer la connectivité.
• Aucune règle de pare-feu pour le port du modèle. Il n’existe aucune requête entrante que le pare-feu devrait autoriser ou bloquer au nom du modèle.
• Aucun proxy inverse nécessaire pour le chiffrement TLS ou le routage. La connexion vers https://api.tokios.com est déjà sécurisée par TLS ; il n’est pas nécessaire de configurer ni de maintenir nginx ou Caddy.
• Des clés API ciblées et révocables plutôt qu’une seule clé statique partagée. Chaque requête s’authentifie via une clé sk-tok-… Tokios pouvant être attribuée à des déploiements de modèles spécifiques (liste de motifs séparés par des virgules comme gemma*, gpt-4*) et révoquée individuellement. Ainsi, il n’est pas nécessaire de modifier une clé utilisée par tous lorsqu’on retire l’accès d’un membre d’équipe ou d’un service. Consultez Ajouter des clés API à un modèle local sans clé.
• Ce qui ne change pas : la mise à jour. Tokios se place en amont de votre environnement d’exécution sans le modifier. Il vous revient donc de maintenir à jour Ollama, llama.cpp, vLLM ou LM Studio, que vous utilisiez un connecteur ou non.

En cas d’erreur lors d’une requête, consultez Dépannage pour identifier les causes fréquentes avant de conclure à une faille de sécurité ; la plupart des problèmes de connexion proviennent d’une mauvaise configuration et non d’une intrusion.

​

Passez à une configuration autorisant uniquement les connexions sortantes.