Proteger tu servidor Ollama: autenticación, proxy inverso, exposition

#Por qué es urgente proteger Ollama

Ollama no tiene ninguna autenticación nativa. El daemon escucha y atiende las peticiones, y punto: parte de la premisa de que solo se comunica con él un cliente de confianza en la máquina local. Este modelo funciona mientras el acceso se limite a http://localhost:11434. El problema aparece en cuanto se cambia una variable de entorno para hacer que el servicio sea accesible desde la red —algo habitual para conectar una interfaz remota u otra máquina.

Al configurar OLLAMA_HOST como 0.0.0.0, se indica al demonio que escuche en todas las interfaces de red. Si el puerto 11434 no está filtrado por un cortafuegos, la API queda abierta a toda la red local, e incluso a todo internet si el equipo tiene una IP pública o una redirección de puertos configurada en el router. Sin contraseña ni token: cualquiera puede enviar solicitudes, descargar o eliminar tus modelos y consumir los recursos de tu GPU.

#Lo que realmente expone la API Ollama

Antes de proteger cualquier cosa, es necesario entender el alcance de la superficie de ataque. La API Ollama no es solo un endpoint de chat: es una API de administración completa, sin distinción de privilegios. Un cliente anónimo tiene exactamente los mismos derechos que tú.

/api/generate et /api/chat

Generación de texto. Consume recursos de tu GPU a voluntad y ve pasar todos los prompts, por lo que puede acceder a datos sensibles introducidos por tus propias aplicaciones.

/api/tags

Lista todos los modelos instalados. Un atacante sabe inmediatamente qué estás alojando, incluyendo tus posibles fine-tunes internos.

/api/pull

Descarga cualquier modelo desde un registro. Un tercero puede saturar tu disco o instalar un modelo dañino.

/api/delete

Elimina modelos. Posible pérdida de datos sin autenticación.

/api/create et /api/push

Creación de modelos a partir de un Modelfile y envío a un registro. Toma de control completa de la instancia.

/v1/*

Capa compatible con OpenAI en el mismo puerto. La misma falta de control de acceso; cualquier cliente estándar de OpenAI puede utilizarla.

#Verificar si tu Ollama está expuesto

Comienza con un diagnóstico honesto. El objetivo: saber en qué interfaces el daemon escucha y si el puerto es accesible desde fuera. Tres comprobaciones, de la más local a la más externa.

Primero, revisa en qué direcciones está escuchando el proceso. Que escuche en 127.0.0.1 es una buena señal; que escuche en 0.0.0.0 o en una IP de red significa que el servicio acepta conexiones remotas.

# 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

Luego, prueba desde otra máquina de la red. Sustituye IP_DU_SERVEUR por la dirección local de la máquina Ollama. Si el comando devuelve la lista de modelos, la instancia es accesible en red — lo cual es aceptable en una LAN de confianza, pero nunca sin filtrado hacia internet.

# 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

Por último, comprueba la exposición pública. Si tu máquina tiene una IP pública o una redirección de puerto activa, búscala en un buscador de dispositivos como Shodan o Censys. Una consulta sencilla por el puerto 11434 y el banner de Ollama revela si tu instancia ya está indexada. También puedes probar tu IP pública directamente.

# 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

#Paso 1 — Volver a escuchar en localhost

La primera medida, y a menudo la única necesaria, consiste en devolver Ollama a su comportamiento predeterminado: escuchar solo en la interfaz de bucle local. No hay razón para exponer directamente el puerto si después colocas un proxy inverso delante. El proxy se comunicará con Ollama en local, y el mundo exterior solo se comunicará con el proxy.

En Linux, Ollama se ejecuta como servicio de systemd. La variable OLLAMA_HOST se configura mediante un archivo de configuración que sobrescribe la del servicio y se conserva tras las actualizaciones del paquete.

1. 01
   Editar la configuración de anulación del servicio

   Abre el editor de configuración de systemd para sobrescribir los ajustes del servicio ollama. Esto crea un archivo drop-in limpio sin modificar el servicio original.
2. 02
   Forzar la escucha local

   Establece OLLAMA_HOST en 127.0.0.1:11434. El demonio entonces rechazará cualquier conexión proveniente de la red.
3. 03
   Recargar y reiniciar

   Recarga la configuración systemd y vuelve a arrancar el servicio para aplicar la variable.
4. 04
   Confirmar

   Vuelve a comprobarlo con ss -tlnp | grep 11434: la dirección debe ser 127.0.0.1 y no 0.0.0.0.

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

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

sudo systemctl daemon-reload
sudo systemctl restart ollama

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

#Paso 2 — Añadir autenticación mediante un proxy inverso

Como Ollama no puede autenticar a los usuarios, se delega esta responsabilidad en un proxy inverso situado delante de él. El proxy exige un identificador, verifica el tráfico y luego lo reenvía a Ollama en local. Dos opciones probadas: Caddy (configuración mínima, TLS automático) y nginx (omnipresente, muy documentado).

#Opción A — Caddy (recomendado por su sencillez)

Caddy gestiona el TLS automáticamente mediante Let's Encrypt y ofrece autenticación básica en unas pocas líneas. Genera primero un hash de la contraseña y luego haz referencia a ese hash en el Caddyfile. Nunca almacenes la contraseña en texto plano.

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

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
}

Con un nombre de dominio que apunta a tu IP pública y los puertos 80/443 abiertos, Caddy obtiene y renueva solo el certificado TLS. El cliente deberá proporcionar el identificador en cada solicitud a través de la cabecera Authorization.

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

#Opción B — nginx

nginx requiere un archivo de contraseñas separado, generado con htpasswd, y luego un bloque server que aplique la autenticación y reenvíe las solicitudes a Ollama. La configuración es más extensa, pero está muy extendida, especialmente cuando nginx ya presta otros servicios.

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

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;
    }
}

#Paso 3 — Encriptar el tráfico (TLS)

La autenticación básica transmite el identificador codificado en base64: sin TLS, circula casi en texto plano y se captura fácilmente. Por tanto, el cifrado del transporte no es opcional en cuanto sales de localhost. Hay dos casos, según tengas o no un nombre de dominio público.

Dominio público + puertos 80/443

Let's Encrypt a través de Caddy (automático) o certbot para nginx. Certificado reconocido, sin advertencias del navegador, renovación automática.

Red interna sin dominio público

Certificado autofirmado o autoridad interna (mkcert). Los clientes deberán confiar en el certificado, pero el tráfico permanece cifrado en la red local.

Detrás de una VPN

El túnel VPN ya cifra todo. TLS sigue siendo recomendable como medida de defensa en profundidad, pero es menos crítico porque nadie externo puede acceder al proxy.

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

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

#Paso 4 — Acceso remoto bien configurado: VPN y Tailscale

La pregunta más importante: ¿realmente necesitas exponer Ollama a internet? En la gran mayoría de los casos, no. Quieres acceder a él desde tus propios dispositivos, no desde la web abierta. Una red privada (VPN) responde exactamente a esta necesidad sin exponer nunca el puerto públicamente.

Tailscale es la opción más sencilla: crea una red en malla cifrada (WireGuard) entre tus máquinas, con direcciones IP privadas estables. Ollama solo escucha en la interfaz Tailscale y solo los dispositivos autenticados en tu tailnet pueden acceder a él. No hay redirección de puertos, ninguna IP pública expuesta.

1. 01
   Instalar Tailscale en el servidor

   Instala el cliente y conecta la máquina a tu tailnet. La máquina recibe una IP privada del tipo 100.x.y.z, accesible únicamente desde tus otros dispositivos autenticados.
2. 02
   Asociar Ollama a la interfaz Tailscale

   Configura OLLAMA_HOST con la IP de Tailscale de la máquina (o mantén 127.0.0.1 y expón mediante Tailscale Serve). El puerto solo es accesible dentro de la red tailnet.
3. 03
   Instalar Tailscale en tus clientes

   Tus otras máquinas se conectan al mismo tailnet y acceden a Ollama a través de su IP 100.x.y.z, dondequiera que estés, sin abrir ningún puerto en el router.
4. 04
   Verificar el aislamiento

   Desde una red externa fuera del tailnet, el puerto debe ser completamente inaccesible. Es el comportamiento esperado.

# 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

Si prefieres una VPN clásica, WireGuard autoalojado ofrece el mismo resultado con más control: estableces el túnel, vinculas Ollama a la interfaz wg0 y el puerto permanece invisible desde internet. La elección entre Tailscale y WireGuard sin más depende principalmente del equilibrio entre simplicidad y soberanía total de la infraestructura.

#Medidas adicionales de refuerzo de la seguridad de la red

Más allá del proxy y de la VPN, algunas medidas de defensa en profundidad limitan los daños en caso de una configuración incorrecta. El principio rector: nunca depender de una sola capa.

Cortafuegos estricto

Bloquea el tráfico entrante al puerto 11434 en todas las interfaces excepto loopback y VPN. Con ufw: denegar el acceso al puerto 11434 por defecto y permitirlo únicamente desde la subred de Tailscale/WireGuard.

Sin redirección de puerto

Nunca configures una redirección del puerto 11434 en el módem/router. Si tienes una «para probar», elimínala: es la causa número 1 de las instancias expuestas.

Limitación de la tasa de solicitudes

En el proxy inverso, aplica una limitación de la tasa de solicitudes para mitigar un posible abuso incluso después de la autenticación (nginx limit_req, Caddy rate_limit).

Contraseñas seguras y rotación

La seguridad de la autenticación básica depende únicamente de la fortaleza del secreto. Usa contraseñas largas y cámbialas si un equipo cliente se ve comprometido.

Registro

Activa los logs de acceso del proxy para detectar intentos anómalos. Una instancia sana solo recibe tus solicitudes.

# 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

#Solución de problemas

403 Forbidden detrás del proxy

Ollama rechaza el encabezado Host. Fuerza el valor de Host a localhost:11434 en el proxy, o configura OLLAMA_ORIGINS para permitir tu dominio.

El streaming se congela o llega en bloque

El proxy almacena la respuesta en un búfer. Desactiva ese almacenamiento en búfer (proxy_buffering off en nginx) y aumenta el tiempo de espera de lectura para las generaciones largas.

curl fonctionne mais pas depuis une autre machine

Ollama sigue escuchando en 127.0.0.1 mientras el proxy está en otro lugar, o el firewall bloquea el puerto 443 del proxy. Comprueba ss -tlnp y las reglas ufw.

El certificado Let's Encrypt falla

El puerto 80 debe ser accesible desde internet para la validación HTTP-01, y el dominio debe apuntar a la IP correcta. Comprueba el DNS y que el puerto 80 esté abierto.

Tailscale: Ollama inaccesible en el tailnet

Ollama escucha en 127.0.0.1 sin tailscale serve. Configura OLLAMA_HOST con la IP 100.x o expón el servicio mediante tailscale serve 11434.

Sigue visible en Shodan después de la corrección

El índice tarda en actualizarse. Confirma primero tú mismo desde una red externa que el puerto está cerrado; luego el índice se actualizará.

#Para ir más allá

Proteger el acceso es solo una parte del panorama. Estas guías complementan la presente en materia de despliegue y cumplimiento normativo:

Desplegar un chatbot de IA para tu equipo en una intranet

El caso de uso típico al que se aplica este refuerzo de seguridad: Ollama + Open WebUI multiusuario detrás de un proxy inverso con autenticación.

Desplegar un LLM en producción con Docker Compose

Pila completa de Ollama + Traefik en la que el proxy inverso y el aislamiento de red se gestionan desde el diseño.

LLM local y RGPD: cumplimiento normativo para los datos privados en la empresa

La vertiente regulatoria: una exposición no controlada también supone un riesgo de filtración de datos personales que debe documentarse.