Les chercheurs de Talos, l’équipe cybersécurité de Cisco, ont cartographié des instances Ollama non authentifiées accessibles sur Internet: 1 139 serveurs détectés et 214 hébergeant activement des modèles vulnérables.
Leur approche combine le scan de Shodan et un outil Python interne. La majorité des expositions se concentre aux États‑Unis (36,6 %), en Chine (22,5 %) et en Allemagne (8,9 %).
En toile de fond, un défaut de configuration récurrent: pas d’authentification par défaut et le port 11434 ouvert à tout vent. Parallèlement, des observations de terrain font état de plus de 14 000 instances publiquement accessibles, un chiffre en forte hausse depuis fin 2024.
Que montre exactement la cartographie des serveurs exposés ?
Le panorama est on ne peut plus inquiétant: des déploiements d’Ollama non authentifiés restent accessibles sur Internet.
Le constat agrège des données issues de scans automatisés et met en évidence des configurations par défaut laissées telles quelles, parfois en production.
Les chiffres annoncent 1 139 serveurs identifiés, 214 hébergeant des modèles vulnérables. Les foyers d’exposition les plus visibles sont localisés aux États‑Unis, Chine, Allemagne.
En filigrane, un angle mort opérationnel: la mise en ligne hâtive de services IA sans garde‑fous.
Quelles failles et attaques pèsent sur ces instances ?
La faille CVE-2024-37032, alias « Probllama », permet une exécution de code à distance avec une simple requête HTTP. Concrètement, un attaquant peut prendre le contrôle du serveur, pivoter dans le réseau, et persister.
S’ajoutent des vecteurs bien connus: extraction de modèles, jailbreaking des garde‑fous, injection de backdoors, épuisement des ressources et déni de service. Les déploiements Docker mal renforcés aggravent l’exposition: API parfois lancée avec des privilèges root et liée à toutes les interfaces. Et trop d’instances tournent encore sur des versions obsolètes.
Comment sécuriser rapidement un serveur sans tout casser ?
L'objectif immédiat des utilisateurs et gestionnaires est de tarir l’exposition. Un reverse proxy avec authentification coupe l’accès direct et ajoute de la journalisation utile. Ensuite, corriger, cloisonner, et vérifier que les services ne sortent pas de leur périmètre. Cisco dresse un protocole clair et précis pour limiter les risques :
- Mise à jour: passer à la version corrigeant Probllama (par exemple 0.1.34 ou plus récent).
- Restreindre l'écoute réseau : configurer OLLAMA_HOST=127.0.0.1 et ne publier qu'à travers le proxy.
- Gestion de l'accès : mettre en place une authentification forte (SAML/OIDC, MFA) au niveau de la façade.
- Filtrage : Limiter l'accès au port 11434 uniquement au réseau interne par le biais de règles de sécurité ou d'un pare-feu.
- Durcissement conteneurs: exécuter sans privilèges, profils seccomp/AppArmor, volumes et permissions minimaux.
- Hygiène: surveiller logs, limiter les quotas pour éviter l’épuisement, supprimer les images et modèles obsolètes.
Foire Aux Questions (FAQ)
Comment savoir si mon instance est exposée sur Internet ?
Vérifier si le service répond depuis l’extérieur et si le port 11434 est accessible publiquement. Un scan du périmètre (interne/externe) et un audit des règles de pare‑feu suffisent souvent. Idéalement, l’API ne doit écouter que sur localhost et être publiée via un frontal authentifié.
Quelle version corrige Probllama et que faut‑il tester après mise à jour ?
La correction est disponible à partir de 0.1.34. Après mise à jour, tester l’authentification, l’isolation réseau et le blocage des requêtes non authentifiées. Confirmer que l’API n’est plus accessible directement depuis Internet et que les journaux tracent correctement les accès.
Ollama est‑il sûr en usage local ?
Oui, si le service reste local (écoute sur 127.0.0.1) et que les accès sont filtrés. Les risques surviennent principalement quand l’instance est exposée en clair sur le web, sans authentification ni durcissement. En local bien configuré, l’attaque devient nettement plus difficile.
