L’adoption rapide des technologies d’IA générative « on-premise » ou en local réintroduit des vecteurs d’attaque classiques que l’on pensait maîtrisés. La facilité de déploiement d’outils comme Ollama, qui permet d’exécuter des LLM (Large Language Models) localement, se heurte souvent à une négligence des bonnes pratiques de sécurité infrastructure.
SentinelOne Labs a récemment mis en lumière un phénomène inquiétant baptisé « Silent Brothers ». Des acteurs malveillants exploitent activement des instances Ollama mal configurées et exposées sur Internet pour constituer un réseau d’inférence distribué et anonyme. Cette analyse détaille la mécanique technique de cette menace et les mesures impératives pour sécuriser vos infrastructures de Compute IA.
1. Analyse Technique du Phénomène
Ollama est devenu un standard de facto pour l’exécution locale de modèles GGUF, apprécié pour sa simplicité (une seule commande pour lancer un modèle). Par défaut, le démon Ollama écoute sur 127.0.0.1:11434, une configuration sécurisée limitant l’accès à la machine hôte.
Le problème survient lorsque les utilisateurs ou les administrateurs souhaitent rendre ce service accessible sur le réseau local ou distant. La modification de la variable d’environnement OLLAMA_HOST vers 0.0.0.0 expose le service sur toutes les interfaces réseau.
La faille critique : Ollama, dans sa conception actuelle, n’intègre aucun mécanisme natif d’authentification ou d’autorisation.
Les attaquants ont industrialisé la détection de ces instances. SentinelOne rapporte une augmentation massive des scans sur le port TCP 11434. Une fois une instance ouverte détectée, le mode opératoire est simple et scriptable via l’API REST d’Ollama :
- Reconnaissance : Appel à
/api/tagspour lister les modèles déjà présents sur l’hôte. - Armement : Si aucun modèle utile n’est présent, appel à
/api/pullpour forcer le téléchargement de modèles performants (ex: llama2, mistral). - Exploitation : Appel à
/api/generatepour soumettre des prompts et récupérer les inférences.
Ces instances compromises forment un réseau « Silent Brothers », permettant aux attaquants de générer du contenu sans censure (contournant les garde-fous des API commerciales comme OpenAI) et sans frais d’infrastructure.
2. Impacts sur l’Infrastructure
L’exposition de ces services n’est pas anodine et présente des risques tangibles pour les environnements d’entreprise.
A. Vol de Ressources Compute (GPU/CPU)
L’impact le plus direct est le parasitage des ressources. L’inférence LLM est extrêmement gourmande en GPU (ou CPU en fallback). Une instance compromise verra ses ressources Compute détournées pour des tâches tierces, entraînant une dégradation immédiate des performances pour les charges de travail légitimes (VDI graphiques, calculs scientifiques, rendus 3D ou services d’IA internes). Cela se traduit par une augmentation directe des coûts énergétiques ou cloud.
B. Risque de « Shadow AI » et Exfiltration
Si l’organisation utilise Ollama pour faire tourner des modèles affinés (finetuned) sur des données propriétaires, l’exposition de l’API /api/tags révèle l’existence de ces modèles, et l’API de génération pourrait potentiellement être utilisée pour tenter d’extraire des informations confidentielles contenues dans les poids du modèle.
C. Réputation de l’IP
L’adresse IP publique de l’infrastructure compromise est utilisée pour générer du contenu potentiellement illégal, du phishing ou des campagnes de désinformation. Cela peut entraîner le blacklistage de l’IP de l’entreprise par les services de sécurité tiers.
3. Recommandations Pragmatiques
La sécurisation d’Ollama repose sur le principe fondamental que l’outil lui-même ne gère pas la sécurité. C’est à la couche infrastructure de le faire.
A. Configuration par Défaut et Segmentation
La règle absolue est de maintenir le binding sur localhost (OLLAMA_HOST=127.0.0.1) si l’accès distant n’est pas strictement nécessaire. Si l’accès réseau est requis, il ne doit jamais être direct. Utilisez des règles de pare-feu strictes (allow-listing d’IPs spécifiques) ou, idéalement, n’autorisez l’accès qu’au travers d’un VPN d’entreprise. Le port 11434 ne doit jamais être ouvert sur l’Internet public.
B. Implémentation d’un Reverse Proxy Authentifiant (Obligatoire pour accès distant)
Puisqu’Ollama ne gère pas l’auth, il est impératif de placer un reverse proxy (Nginx, Traefik, Caddy) devant l’instance pour gérer TLS et l’authentification (Basic Auth, OAuth2, etc.).
Voici un exemple minimaliste de configuration Nginx pour sécuriser une instance Ollama :
# Exemple de configuration Nginx pour sécuriser Ollama
server {
listen 80;
server_name ollama.votre-infra.local;
location / {
# Redirection vers l'instance Ollama locale
proxy_pass http://127.0.0.1:11434;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# Activation obligatoire de l'authentification Basic
auth_basic "Accès Restreint Infrastructure IA";
auth_basic_user_file /etc/nginx/.htpasswd;
}
}C. Surveillance
Intégrez la surveillance du port 11434 et des processus ollama dans vos outils de monitoring (SIEM, Prometheus/Grafana). Des pics d’utilisation GPU inexpliqués ou des connexions entrantes sur ce port doivent déclencher des alertes immédiates.
Conclusion
L’émergence de « Silent Brothers » démontre que la nouvelle vague d’outils GenAI ne doit pas échapper aux politiques de sécurité infrastructure établies. L’absence de sécurité native (« secure by design ») dans des outils comme Ollama impose aux équipes Ops et SecOps de compenser par une architecture réseau rigoureuse. Traitez vos instances d’IA avec la même rigueur que vos bases de données critiques : jamais exposées directement sur le Net.