#Pourquoi sécuriser Ollama est urgent

Ollama n'a aucune authentification native. Le daemon écoute, sert les requêtes, point final : il part du principe que seul un client de confiance sur la machine locale lui parle. Ce modèle tient tant qu'on reste sur http://localhost:11434. Le problème apparaît dès qu'on change une variable d'environnement pour rendre le service accessible depuis le réseau — un geste courant pour brancher une interface distante ou une autre machine.

En positionnant OLLAMA_HOST sur 0.0.0.0, on demande au daemon d'écouter sur toutes les interfaces réseau. Si le port 11434 n'est pas filtré par un pare-feu, l'API se retrouve ouverte à tout le réseau local, voire à internet entier si la machine a une IP publique ou une redirection de port sur la box. Aucun mot de passe, aucun jeton : n'importe qui peut envoyer des requêtes, télécharger ou supprimer vos modèles, et consommer votre GPU.

Le risque concret

Une instance Ollama ouverte, c'est du calcul GPU offert à des inconnus (minage de réponses, contenus abusifs générés sous votre IP) et une fuite potentielle : les prompts envoyés et les modèles fine-tunés que vous hébergez deviennent lisibles et manipulables par des tiers.

#Ce que l'API Ollama expose vraiment

Avant de protéger quoi que ce soit, il faut comprendre l'étendue de la surface d'attaque. L'API Ollama n'est pas qu'un endpoint de chat : c'est une API d'administration complète, sans distinction de privilèges. Un client anonyme dispose exactement des mêmes droits que vous.

/api/generate et /api/chat: Génération de texte. Consomme votre GPU à volonté et voit passer tous les prompts — donc potentiellement des données sensibles injectées par vos propres applications.
/api/tags: Liste tous les modèles installés. Un attaquant sait immédiatement ce que vous hébergez, y compris vos éventuels fine-tunes internes.
/api/pull: Télécharge n'importe quel modèle depuis un registre. Un tiers peut saturer votre disque ou installer un modèle piégé.
/api/delete: Supprime des modèles. Destruction de données possible sans aucune authentification.
/api/create et /api/push: Création de modèles à partir d'un Modelfile et envoi vers un registre. Détournement complet de l'instance.
/v1/*: Couche OpenAI-compatible sur le même port. Même absence de contrôle d'accès, exploitable par n'importe quel client OpenAI standard.

Aucune granularité de droits

Ollama ne connaît pas la notion d'utilisateur ni de rôle. Il n'existe pas de mode « lecture seule ». La seule frontière de sécurité est le réseau : soit on peut joindre le port, soit non. Toute la stratégie repose donc sur qui a le droit d'atteindre le port 11434.

#Vérifier si votre Ollama est exposé

Commencez par un diagnostic honnête. L'objectif : savoir sur quelles interfaces le daemon écoute et si le port est joignable depuis l'extérieur. Trois vérifications, de la plus locale à la plus externe.

D'abord, regardez sur quelles adresses le processus est en écoute. Une écoute sur 127.0.0.1 est saine ; une écoute sur 0.0.0.0 ou une IP de réseau signifie que le service accepte des connexions distantes.

Terminal — inspecter les sockets en écoute

# Voir sur quelle interface Ollama écoute (Linux)
ss -tlnp | grep 11434

# Alternative si ss n'est pas disponible
sudo lsof -i :11434

# Vérifier la variable qui contrôle l'écoute
systemctl show ollama --property=Environment 2>/dev/null | grep -i host
echo $OLLAMA_HOST

Ensuite, testez depuis une autre machine du réseau. Remplacez IP_DU_SERVEUR par l'adresse locale de la machine Ollama. Si la commande renvoie la liste des modèles, l'instance est joignable sur le réseau — ce qui est acceptable en LAN de confiance, mais jamais sans filtrage vers internet.

Terminal — tester depuis une autre machine

# Depuis un autre poste du réseau local
curl http://IP_DU_SERVEUR:11434/api/tags

# Réponse = liste JSON des modèles => l'instance répond aux tiers

Enfin, contrôlez l'exposition publique. Si votre machine a une IP publique ou une redirection de port active, cherchez-la sur un moteur de recensement comme Shodan ou Censys. Une requête simple sur le port 11434 et la bannière Ollama révèle si votre instance est déjà indexée. Vous pouvez aussi tester votre IP publique directement.

Terminal — vérifier l'exposition publique

# Récupérer votre IP publique
curl -s https://api.ipify.org; echo

# Tester si le port 11434 répond depuis internet (depuis un réseau externe,
# ex. partage 4G du téléphone, pas depuis le LAN)
curl http://VOTRE_IP_PUBLIQUE:11434/api/tags

→

Recherche Shodan

Sur shodan.io, la requête product:"Ollama" ou port:11434 "Ollama is running" liste les instances exposées publiquement. Cherchez votre IP pour confirmer que vous n'y figurez pas. C'est ainsi que les instances vulnérables sont trouvées en masse.

#Étape 1 — Revenir à une écoute localhost

La première mesure, et souvent la seule nécessaire, consiste à ramener Ollama à son comportement par défaut : n'écouter que sur la boucle locale. Aucune raison d'exposer le port brut si vous placez ensuite un reverse proxy devant. Le proxy parlera à Ollama en local, et le monde extérieur ne parlera qu'au proxy.

Sur Linux, Ollama tourne en service systemd. La variable OLLAMA_HOST se configure via une surcharge de service, ce qui survit aux mises à jour du paquet.

01
Éditer la surcharge du service
Ouvrez l'éditeur de surcharge systemd pour le service ollama. Cela crée un fichier drop-in propre sans toucher au service d'origine.
02
Forcer l'écoute locale
Déclarez OLLAMA_HOST sur 127.0.0.1:11434. Le daemon refusera alors toute connexion venant du réseau.
03
Recharger et redémarrer
Rechargez la configuration systemd puis redémarrez le service pour appliquer la variable.
04
Confirmer
Revérifiez avec ss -tlnp | grep 11434 : l'adresse doit être 127.0.0.1 et non 0.0.0.0.

Terminal — forcer l'écoute locale (systemd)

# Ouvre un éditeur pour un drop-in override
sudo systemctl edit ollama

Fichier — override.conf

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

Terminal — appliquer et vérifier

sudo systemctl daemon-reload
sudo systemctl restart ollama

# L'écoute doit revenir sur 127.0.0.1
ss -tlnp | grep 11434

Docker et macOS

En conteneur, ne publiez pas le port avec -p 11434:11434 (qui l'ouvre sur toutes les interfaces) : utilisez -p 127.0.0.1:11434:11434, ou mieux, laissez le port interne au réseau Docker et ne l'exposez que via le conteneur reverse proxy. Sur macOS, réglez OLLAMA_HOST dans l'environnement via launchctl setenv puis relancez l'app.

#Étape 2 — Ajouter une authentification via reverse proxy

Puisque Ollama ne sait pas authentifier, on délègue cette responsabilité à un reverse proxy placé devant lui. Le proxy exige un identifiant, vérifie le trafic, puis relaie vers Ollama en local. Deux options éprouvées : Caddy (configuration minimale, TLS automatique) et nginx (omniprésent, très documenté).

#Option A — Caddy (recommandé pour la simplicité)

Caddy gère le TLS automatiquement via Let's Encrypt et propose une authentification basique en quelques lignes. Générez d'abord un hash du mot de passe, puis référencez-le dans le Caddyfile. Ne stockez jamais le mot de passe en clair.

Terminal — générer le hash du mot de passe

# Génère un hash bcrypt à coller dans le Caddyfile
caddy hash-password --plaintext 'VotreMotDePasseFort'

Fichier — Caddyfile

ollama.mondomaine.fr {
    # Authentification basique (utilisateur : admin)
    basic_auth {
        admin $2a$14$le_hash_genere_ci_dessus
    }

    # Relais vers Ollama en local
    reverse_proxy 127.0.0.1:11434
}

Avec un nom de domaine pointant sur votre IP publique et les ports 80/443 ouverts, Caddy obtient et renouvelle seul le certificat TLS. Le client devra fournir l'identifiant à chaque requête via l'en-tête Authorization.

Terminal — appeler l'API protégée

# L'accès nécessite désormais des identifiants
curl -u admin:VotreMotDePasseFort https://ollama.mondomaine.fr/api/tags

#Option B — nginx

nginx demande un fichier de mots de passe séparé, généré avec htpasswd, puis un bloc server qui applique l'authentification et relaie vers Ollama. C'est plus verbeux mais très répandu, notamment quand nginx sert déjà d'autres services.

Terminal — créer le fichier d'identifiants

# Paquet apache2-utils (Debian/Ubuntu) ou httpd-tools (Fedora)
sudo htpasswd -c /etc/nginx/.ollama_htpasswd admin

Fichier — /etc/nginx/sites-available/ollama

server {
    listen 443 ssl;
    server_name ollama.mondomaine.fr;

    ssl_certificate     /etc/letsencrypt/live/ollama.mondomaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ollama.mondomaine.fr/privkey.pem;

    location / {
        auth_basic           "Ollama";
        auth_basic_user_file /etc/nginx/.ollama_htpasswd;

        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;

        # Le streaming des tokens ne doit pas être bufferisé
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

En-tête Host obligatoire

Ollama refuse par défaut les requêtes dont l'en-tête Host n'est pas localhost (protection anti-DNS-rebinding). Depuis un reverse proxy, forcez proxy_set_header Host localhost:11434 (nginx) ou l'équivalent, sinon vous obtiendrez des erreurs 403.

#Étape 3 — Chiffrer le trafic (TLS)

L'authentification basique transmet l'identifiant encodé en base64 : sans TLS, il circule quasiment en clair et se capture trivialement. Le chiffrement du transport n'est donc pas optionnel dès qu'on sort du localhost. Deux cas de figure selon que vous avez un nom de domaine public ou non.

Domaine public + ports 80/443: Let's Encrypt via Caddy (automatique) ou certbot pour nginx. Certificat reconnu, aucun avertissement navigateur, renouvellement automatique.
Réseau interne sans domaine public: Certificat auto-signé ou autorité interne (mkcert). Les clients devront faire confiance au certificat, mais le trafic reste chiffré sur le LAN.
Derrière un VPN: Le tunnel VPN chiffre déjà tout. TLS reste recommandé en défense en profondeur, mais moins critique puisque personne d'externe n'atteint le proxy.

Terminal — certificat Let's Encrypt pour nginx

# Obtenir et installer le certificat, avec renouvellement automatique
sudo certbot --nginx -d ollama.mondomaine.fr

# Tester le renouvellement à blanc
sudo certbot renew --dry-run

→

Rien à configurer avec Caddy

Si vous utilisez Caddy avec un domaine public et les ports ouverts, le TLS est déjà en place : Caddy provisionne et renouvelle le certificat sans intervention. C'est la raison principale de le préférer pour un déploiement rapide et sûr.

#Étape 4 — Accès distant propre : VPN et Tailscale

La question la plus importante : avez-vous vraiment besoin d'exposer Ollama sur internet ? Dans la grande majorité des cas, non. Vous voulez y accéder depuis vos propres appareils, pas depuis le web ouvert. Un réseau privé (VPN) répond exactement à ce besoin sans jamais exposer le port publiquement.

Tailscale est l'option la plus simple : il crée un réseau maillé chiffré (WireGuard) entre vos machines, avec des IP privées stables. Ollama n'écoute alors que sur l'interface Tailscale, et seuls vos appareils authentifiés dans votre tailnet peuvent le joindre. Aucune redirection de port, aucune IP publique exposée.

01
Installer Tailscale sur le serveur
Installez le client et connectez la machine à votre tailnet. Elle reçoit une IP privée en 100.x.y.z accessible uniquement depuis vos autres appareils authentifiés.
02
Lier Ollama à l'interface Tailscale
Réglez OLLAMA_HOST sur l'IP Tailscale de la machine (ou gardez 127.0.0.1 et exposez via Tailscale Serve). Le port n'est joignable que dans le tailnet.
03
Installer Tailscale sur vos clients
Vos autres machines rejoignent le même tailnet et atteignent Ollama via son IP 100.x.y.z, où que vous soyez, sans ouvrir le moindre port sur la box.
04
Vérifier l'isolement
Depuis un réseau externe hors tailnet, le port doit être totalement injoignable. C'est le comportement attendu.

Terminal — Tailscale sur le serveur

# Installation (Linux)
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

# Récupérer l'IP Tailscale de la machine
tailscale ip -4

# Exposer Ollama proprement dans le tailnet (HTTPS + identité tailnet)
tailscale serve --bg 11434

Tailscale Serve gère aussi le TLS

tailscale serve place un proxy TLS devant Ollama avec un certificat valide pour votre domaine tailnet, et restreint l'accès aux membres du réseau. C'est souvent la solution la plus propre : chiffrement + contrôle d'accès sans reverse proxy manuel ni port ouvert sur internet.

Si vous tenez à un VPN classique, WireGuard auto-hébergé offre le même résultat avec plus de contrôle : vous montez le tunnel, vous liez Ollama à l'interface wg0, et le port reste invisible depuis internet. Le choix entre Tailscale et WireGuard nu tient surtout à l'arbitrage entre simplicité et souveraineté totale de l'infrastructure.

#Durcissement réseau complémentaire

Au-delà du proxy et du VPN, quelques mesures de défense en profondeur limitent les dégâts en cas de mauvaise configuration. Le principe directeur : ne jamais dépendre d'une seule couche.

Pare-feu strict: Bloquez le port 11434 en entrée sur toutes les interfaces sauf loopback et VPN. Avec ufw : refuser 11434 par défaut, autoriser uniquement depuis le sous-réseau Tailscale/WireGuard.
Pas de redirection de port: Ne créez jamais de port forwarding 11434 sur la box/routeur. Si vous en avez un « pour tester », supprimez-le : c'est la cause n°1 des instances exposées.
Limitation de débit: Sur le reverse proxy, appliquez un rate limiting pour amortir un éventuel abus même après authentification (nginx limit_req, Caddy rate_limit).
Mots de passe forts et rotation: L'authentification basique ne résiste qu'à la force du secret. Utilisez des mots de passe longs et changez-les si un poste client est compromis.
Journalisation: Activez les logs d'accès du proxy pour repérer les tentatives anormales. Une instance saine ne reçoit que vos requêtes.

Terminal — pare-feu ufw (n'autoriser que le VPN)

# Refuser l'accès direct au port depuis le réseau
sudo ufw deny 11434

# N'autoriser que le sous-réseau Tailscale (exemple)
sudo ufw allow from 100.64.0.0/10 to any port 11434

sudo ufw status verbose

#Dépannage

403 Forbidden derrière le proxy: Ollama rejette l'en-tête Host. Forcez Host à localhost:11434 côté proxy, ou définissez OLLAMA_ORIGINS pour autoriser votre domaine.
Le streaming se fige ou arrive en bloc: Le proxy bufferise la réponse. Désactivez le buffering (proxy_buffering off sur nginx) et augmentez le timeout de lecture pour les longues générations.
curl fonctionne mais pas depuis une autre machine: Ollama écoute encore sur 127.0.0.1 alors que le proxy est ailleurs, ou le pare-feu bloque le port 443 du proxy. Vérifiez ss -tlnp et les règles ufw.
Certificat Let's Encrypt échoue: Le port 80 doit être joignable depuis internet pour la validation HTTP-01, et le domaine doit pointer sur la bonne IP. Vérifiez le DNS et l'ouverture du port 80.
Tailscale : Ollama injoignable dans le tailnet: Ollama écoute sur 127.0.0.1 sans tailscale serve. Soit liez OLLAMA_HOST à l'IP 100.x, soit exposez via tailscale serve 11434.
Toujours visible sur Shodan après correction: L'index met du temps à se rafraîchir. Confirmez d'abord vous-même depuis un réseau externe que le port est fermé ; l'indexation se mettra à jour ensuite.

#Pour aller plus loin

Sécuriser l'accès n'est qu'une partie du tableau. Ces guides prolongent celui-ci sur le déploiement et la conformité :

Déployer un chatbot IA pour son équipe sur intranet: Le cas d'usage typique où ce durcissement s'applique : Ollama + Open WebUI multi-utilisateurs derrière un reverse proxy authentifié.
Déployer un LLM en production avec Docker Compose: Stack complète Ollama + Traefik où le reverse proxy et l'isolation réseau sont gérés dès la conception.
LLM local et RGPD : la conformité données privées en entreprise: Le pendant réglementaire : une exposition non maîtrisée est aussi un risque de fuite de données personnelles à documenter.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Entreprise · 20 min