Sécuriser les instances Ollama auto-hébergées contre l'accès non authentifié

Les serveurs auto-hébergés de grands modèles de langage (LLM) sont de plus en plus courants dans les environnements de développement, mais leurs configurations par défaut manquent souvent de contrôles de sécurité élémentaires. Une analyse récente souligne qu'Ollama, un outil populaire pour exécuter des modèles localement, ne dispose d'aucun mécanisme d'authentification intégré, exposant ainsi des milliers d'instances sur Internet public. Les équipes partageant des ressources GPU doivent mettre en œuvre des protections externes pour empêcher tout accès non autorisé et toute fuite de données.

Ce qui s'est passé

Par défaut, Ollama écoute sur localhost, ce qui est sécurisé pour les ordinateurs portables mono-utilisateur. Des problèmes surviennent lorsque les administrateurs modifient le paramètre hôte sur 0.0.0.0 pour permettre à leurs collègues d'accéder à un serveur GPU centralisé. Cette configuration ouvre tous les points d'accès API à quiconque peut atteindre l'adresse réseau, y compris les fonctions permettant de télécharger, supprimer, créer et pousser des modèles. Sans authentification, tout utilisateur connecté dispose d'un contrôle total sur les ressources du serveur et les données stockées.

Des chercheurs en sécurité ont documenté l'ampleur de cette exposition. En janvier, des scans effectués par SentinelOne et Censys ont identifié environ 175 000 serveurs Ollama ouverts sur Internet dans 130 pays. Près de la moitié de ces instances hébergeaient des modèles dotés de capacités d'appel d'outils (tool-calling), augmentant le risque d'abus automatisés. La situation s'est aggravée en mai lorsque Cyera a divulgué CVE-2026-7482, connu sous le nom de Bleeding Llama. Cette vulnérabilité permettait aux attaquants de fuiter la mémoire du serveur, y compris les variables d'environnement et les clés API, via deux requêtes non authentifiées.

Bien qu'un correctif ait été publié dans la version 0.17.1 en février, de nombreux serveurs restent non patchés car les notes de version n'ont pas explicitement qualifié cette mise à jour de correction de sécurité. À partir de la version 0.40.3 en octobre 2026, Ollama ne propose toujours pas de système de clés API côté serveur. Les mainteneurs ont déclaré qu'ils n'avaient pas l'intention d'ajouter une authentification native, recommandant plutôt aux utilisateurs de compter sur des réseaux privés virtuels (VPN) ou des proxys inverses pour leur protection.

Détails clés

• Ollama ne dispose pas d'authentification par clé API native, reposant sur l'isolation réseau pour la sécurité.
• Environ 175 000 serveurs ont été trouvés exposés sur Internet début 2026.
• CVE-2026-7482 permettait une fuite de mémoire via des requêtes non authentifiées de création et de poussée de modèles.
• La vulnérabilité a été corrigée dans la version 0.17.1, mais son adoption reste inégale.
• Le paramétrage OLLAMA_HOST=0.0.0.0 expose tous les points d'accès API, y compris les opérations destructives.
• Les règles de publication de ports Docker peuvent contourner les configurations de pare-feu locales comme ufw.

Contexte

Comprendre le risque nécessite de savoir comment Ollama gère les connexions réseau. Par défaut, il se lie à 127.0.0.1, ce qui signifie que seuls les processus sur la même machine peuvent communiquer avec lui. Lorsqu'il est changé en 0.0.0.0, il accepte les connexions depuis n'importe quelle interface réseau. Dans les environnements conteneurisés, Docker gère ses propres règles iptables, qui peuvent supplanter les paramètres de pare-feu au niveau de l'hôte. Cela signifie qu'une règle refusant le trafic sur le port 11434 pourrait ne pas bloquer l'accès si le conteneur publie globalement ce port.

La vulnérabilité Bleeding Llama exploitait des points d'accès API spécifiques gérant les fichiers de modèles. En envoyant un fichier GGUF conçu spécifiquement vers le point d'accès de création, puis en le poussant vers un registre externe, les attaquants pouvaient déclencher des lectures de mémoire exposant des données sensibles. Ce type d'attaque est possible parce que le serveur fait confiance à toute requête entrante sans vérifier l'identité ni l'intention de l'expéditeur. Sécuriser ces points d'accès est crucial pour toute configuration multi-utilisateurs.

Pourquoi c'est important

Pour les équipes développant leurs propres logiciels, l'absence d'authentification native crée des risques opérationnels significatifs. Sans contrôles d'accès au niveau utilisateur, les administrateurs ne peuvent pas suivre qui utilise les ressources GPU ni limiter la consommation. Un seul script hors de contrôle ou acteur malveillant peut monopoliser le matériel, perturbant le travail de tous les autres. De plus, l'impossibilité de révoquer l'accès pour des utilisateurs individuels signifie que la compromission d'un seul identifiant ou appareil potentiellement compromet l'ensemble du serveur.

La confidentialité des données est une autre préoccupation majeure. Les serveurs exposés peuvent fuiter du code propriétaire, des prompts internes et des clés API stockées dans les variables d'environnement. Pour les entreprises traitant des données clients sensibles ou de la propriété intellectuelle, cette exposition viole les principes fondamentaux de sécurité. La mise en œuvre de contrôles d'accès appropriés garantit que seul le personnel autorisé peut interagir avec les modèles et que leurs actions sont auditées.

Que pouvez-vous faire ?

• Vérifiez que votre serveur n'est pas exposé en exécutant une commande curl depuis un réseau externe pour consulter les listes de modèles.
• Mettez à jour Ollama vers la version 0.17.1 ou ultérieure pour corriger les vulnérabilités connues de fuite de mémoire.
• Utilisez des tunnels SSH ou Tailscale pour les petites équipes afin de garder Ollama lié à localhost tout en permettant l'accès distant.
• Déployez un proxy inverse comme Caddy ou Nginx pour appliquer une authentification basée sur des jetons et bloquer les points d'accès administratifs.
• Envisagez d'utiliser Open WebUI comme interface frontale pour gérer les comptes utilisateurs et générer des clés API par utilisateur.
• Évaluez des solutions de proxy dédiées comme LoLLMs Hub ou LiteLLM pour une limitation avancée du débit et un suivi de l'utilisation.

"À court terme, nous n'avons pas l'intention d'ajouter un système de clés API au serveur Ollama lui-même."

Section de clôture :