Proteger Ollama

Qué abarca este artículo sobre seguridad en Ollama

• Por qué Ollama no es seguro en la red por defecto.
• Cómo limitar el acceso a la red local.
• Cómo usar un Reverse Proxy con autenticación.
• Cómo Tailscale o una VPN proporcionan acceso remoto seguro.
• Reglas importantes de firewall y sistema.

Introducción: proteger Ollama

Ollama escucha por defecto en 127.0.0.1:11434 y no ofrece autenticación propia. Una vez que haces el servicio accesible en la red, cualquiera en la misma red puede acceder al modelo, enviar prompts y potencialmente consultar datos del entorno en ejecución. Una configuración de seguridad adecuada es obligatoria si Ollama se va a usar en más de un dispositivo.

Este artículo muestra cómo ejecutar Ollama de forma segura con aislamiento de red, firewall, Reverse Proxy y VPN.

Términos clave

• Bind: Interfaz de red en la que Ollama escucha.
• Firewall: Seguridad de red basada en reglas.
• Reverse Proxy: Intermediario entre el cliente y Ollama.
• Autenticación: Verificación de quién puede acceder.
• Tailscale: VPN mesh para acceso remoto seguro.
• mTLS: Autenticación TLS mutua.
• API-Key: Clave secreta para el acceso.

Comportamiento por defecto de Ollama

Sin configuración, Ollama solo es accesible desde localhost. Esto es seguro mientras todo se ejecute en una máquina. Si quieres conectar otro host en la red, debes vincular Ollama a una interfaz externa. Esto hace que el servicio sea potencialmente accesible para cualquiera en la red.

Restringir la vinculación de red

Para acceso desde la red local:

export OLLAMA_HOST=0.0.0.0:11434

Es mejor usar una interfaz específica:

export OLLAMA_HOST=192.168.1.50:11434

De esta forma, Ollama escucha solo en la dirección interna, no en todas las interfaces.

Reglas de firewall

En un host Proxmox o servidor Linux, el puerto de Ollama no debería estar abierto a Internet. Ejemplo con iptables:

iptables -A INPUT -p tcp --dport 11434 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 11434 -j DROP

En Proxmox, el firewall integrado en el Datacenter y en el nivel LXC/VM puede contener reglas correspondientes.

Reverse Proxy con autenticación

Un Reverse Proxy como Nginx o Traefik puede publicar el puerto de Ollama y, al mismo tiempo, forzar la autenticación. Ejemplo con Nginx:

server {
    listen 443 ssl;
    server_name ollama.home.local;

    auth_basic "Ollama";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

De esta forma, Ollama solo es accesible con usuario y contraseña.

Tailscale para acceso remoto

En lugar de hacer Ollama públicamente accesible, puedes usar Tailscale:

• Ollama permanece vinculado a 127.0.0.1.
• El cliente se conecta al host a través de Tailscale.
• La comunicación está cifrada.
• No se necesitan puertos públicos.

Ollama detrás de Open WebUI

Open WebUI puede actuar como punto central. Ollama en sí permanece inalcanzable desde la red, y Open WebUI lo contacta localmente. Los usuarios se autentican en Open WebUI. Esto simplifica considerablemente la seguridad.

-e OLLAMA_BASE_URL=http://localhost:11434
-p 8080:8080

Open WebUI obtiene entonces el puerto 8080, y Ollama permanece local.

API-Keys a través de un Proxy

Ollama no admite API-Keys nativamente. Si aun así necesitas autenticación basada en claves, puedes usar un proxy como oauth2-proxy, Traefik o Caddy con Forward-Auth. Alternativamente, existen middlewares que verifican API-Keys antes de reenviar las solicitudes a Ollama.

mTLS

Para máxima seguridad, puedes usar mTLS entre el cliente y el Reverse Proxy. Ambos lados se verifican mutuamente con certificados. Esto es apropiado para agentes automatizados y servicios internos.

Seguridad en Docker y contenedores

Si Ollama se ejecuta en Docker:

• Vincula el puerto 11434 solo a 127.0.0.1: -p 127.0.0.1:11434:11434.
• No ejecutes como root.
• Verifica --read-only y --security-opt no-new-privileges.
• Minimiza las capabilities.

Logs y monitoreo

Los logs de acceso ayudan a detectar actividades inusuales. El Reverse Proxy registra logs HTTP. Ollama en sí registra poco, por lo que el proxy o una puerta de enlace anterior es importante.

Errores comunes

• Ollama vinculado a 0.0.0.0: El puerto es entonces accesible desde cualquier lugar.
• Sin autenticación: Cualquiera en la red puede usar los modelos.
• Puerto abierto a Internet: Puede ser explotado rápidamente.
• Open WebUI sin protección: También aquí debe estar activa la autenticación.
• Reglas de firewall olvidadas: Aísla la red donde sea posible.

Enlaces e información adicional

• BotServ.de Fundamentos de Tailscale
• BotServ.de Proxmox LXC vs. VM
• BotServ.de Proxmox Storage
• BotServ.de Administración de Open WebUI

FAQ: Proteger Ollama

¿Necesito autenticación para Ollama? Sí, una vez que más de un dispositivo accede.

¿Ollama admite API-Keys nativamente? No, debe hacerlo un Reverse Proxy u otra herramienta.

¿Es Tailscale suficientemente seguro? Sí, para acceso remoto, Tailscale es una solución muy buena.

¿Debería hacer Ollama accesible desde Internet? No. Si es absolutamente necesario, solo con Reverse Proxy, autenticación, TLS y Rate-Limiting.

¿Cuál es la forma más segura de ofrecer Ollama en la red? Mantén Ollama en 127.0.0.1 y hazlo accesible a través de Open WebUI o un Reverse Proxy protegido.

Fuentes y lecturas adicionales

• Ollama Docs: https://github.com/ollama/ollama/blob/main/docs/
• Nginx Reverse Proxy: https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• Tailscale: https://tailscale.com/

Resumen: Proteger Ollama

Ollama no está diseñado para acceso de red sin medidas adicionales. Si quieres usar Ollama en la red local o de forma remota, debes restringir la dirección de vinculación, establecer reglas de firewall, configurar autenticación a través de un Reverse Proxy y proteger el acceso remoto con Tailscale. Open WebUI puede actuar como punto de control protegido, mientras que Ollama en sí permanece accesible solo localmente. Al combinar estas capas, logras acceso seguro a modelos de IA locales.