Ollama no pide usuario ni contraseña para usar su API. Si el puerto 11434 de tu servidor se ve desde internet, cualquiera que lo encuentre puede usar tu tarjeta gráfica, ver qué modelos tienes y descargar o borrar modelos. Esta guía es para quien ya tiene Ollama (u otro servidor de modelos) funcionando y quiere salir de dudas: cómo comprobar si el tuyo está abierto, con dos comandos, y cómo cerrarlo en orden de preferencia. Todo está pensado para revisar tu propio servidor. Si todavía no has instalado Ollama, empieza por cómo instalar Ollama en un servidor, que ya explica lo básico de su seguridad. Aquí vamos un paso más allá: comprobar y cerrar.
Revisado en septiembre de 2026.
Cuántos Ollama hay abiertos a internet
No es un caso raro. En enero de 2026, SentinelOne SentinelLABS y Censys publicaron que habían encontrado unas 175.000 máquinas con Ollama accesibles desde internet en 130 países. El 48 % tenía modelos con llamada a herramientas, la función que permite que una aplicación deje al modelo actuar sobre otros sistemas. Los investigadores consideran esa combinación (herramientas, sin autenticación y abierto a la red) el caso de mayor gravedad. El mismo artículo describe lo que llaman "LLMjacking": alguien usa la infraestructura de IA de otro para sus fines y el dueño paga la factura, y habla ya de un mercado donde se revende ese acceso.
Meses antes, el 1 de septiembre de 2025, Cisco había publicado un estudio más pequeño: 1.139 servidores Ollama expuestos, de los que 214 (el 18,8 %) estaban sirviendo modelos en ese momento.
La causa de fondo es sencilla y está en la propia documentación. La página de autenticación de la API dice que la API local no necesita autenticación. Es razonable mientras escucha solo dentro del servidor. Deja de serlo en cuanto el puerto sale fuera.
Qué puede hacer alguien con un Ollama abierto
Sin entrar en recetas, basta con leer la referencia de la API de Ollama para ver qué queda a mano de quien llegue al puerto. Todas estas funciones existen para que tú administres tu servidor, y sin autenticación las tiene cualquiera:
| Lo que ofrece la API | Qué supone si está abierta |
|---|---|
| Generar respuestas y chat | Usan tu GPU gratis. Tus usuarios notan lentitud, y si pagas por consumo, lo pagas tú |
Listar modelos (/api/tags) y los cargados (/api/ps) | Saben qué tienes instalado, incluidos modelos personalizados con nombres internos |
Descargar modelos (/api/pull) | Pueden llenar tu disco con decenas de gigas |
Borrar modelos (/api/delete) | Pueden dejar sin modelo a tu equipo o a tus automatizaciones |
| Crear y copiar modelos | Pueden alterar lo que tu equipo cree estar usando |
Y hay un efecto menos visible: la máquina es tuya, así que el tráfico y lo que se genere con ella salen de tu IP.
Las dos formas típicas de acabar expuesto
Casi nadie abre Ollama a internet a propósito. Pasa por uno de estos dos caminos, y los dos aparecen en tutoriales y en la documentación oficial como forma de "acceder desde otra máquina".
El primero es OLLAMA_HOST=0.0.0.0. Según la FAQ de Ollama, por defecto escucha en 127.0.0.1, es decir, solo acepta conexiones del propio servidor. Para usarlo desde otro equipo, la misma FAQ explica cómo cambiar esa variable a 0.0.0.0, que significa "escucha en todas las direcciones". En un servidor con IP pública y sin cortafuegos, eso llega a todo internet.
El segundo es Docker. La guía de Ollama para Docker lo arranca con -p 11434:11434. La documentación de Docker lo avisa: publicar puertos es inseguro por defecto, porque el puerto queda disponible no solo para el servidor sino para el exterior. Y hay una segunda trampa. Según Docker, el tráfico hacia los puertos que publica se desvía antes de pasar por las reglas de ufw, el cortafuegos más habitual en Ubuntu. Dicho en llano: puedes tener ufw activado, sin ninguna regla que permita el 11434, y el puerto seguir abierto.
Cómo comprobar si el tuyo está abierto
Hay que mirar desde dos sitios: dentro del servidor, para saber en qué dirección escucha, y desde fuera, para saber qué llega de verdad. La primera prueba te dice por qué; la segunda es la que manda.
Dentro del servidor: en qué dirección escucha
Entra por SSH y ejecuta:
sudo ss -tlnp | grep 11434ss lista los puertos en los que hay algún programa escuchando. Fíjate en la columna de la dirección local:
127.0.0.1:11434: escucha solo dentro del servidor. Es lo que quieres si nadie de fuera tiene que usarlo.*:11434,0.0.0.0:11434o[::]:11434: escucha en todas las direcciones. Si no hay un cortafuegos delante, está abierto.- Una IP privada, por ejemplo
10.8.0.1:11434: escucha solo en esa red. Es lo normal si lo has puesto detrás de una VPN.
Si el proceso que aparece es docker-proxy en lugar de ollama, el puerto lo está publicando Docker. Para verlo con más claridad:
docker ps --format '{{.Names}}\t{{.Ports}}'0.0.0.0:11434->11434/tcp significa publicado en todas las direcciones. 127.0.0.1:11434->11434/tcp, solo en local.
Desde fuera: la prueba que no miente
Ahora, desde otra máquina que no esté en la misma red (tu portátil con los datos del móvil, por ejemplo), pregunta a la IP pública de tu servidor:
curl -m 5 http://TU_IP:11434/api/tags-m 5 corta la prueba a los cinco segundos. Cómo leer la respuesta:
| Respuesta | Qué significa |
|---|---|
Un JSON que empieza por {"models": | Abierto. Cualquiera puede ver tus modelos y usar la API |
Connection refused | Nada acepta conexiones en esa dirección y puerto. Cerrado desde ahí |
Se agota el tiempo (timed out) | Un cortafuegos descarta el tráfico. Cerrado desde ahí |
401 o Unauthorized | Hay un proxy delante pidiendo contraseña. Bien, si es lo que montaste |
Si tu servidor tiene también dirección IPv6, repite la prueba con ella: es frecuente cerrar IPv4 y olvidar la otra. Con curl va entre corchetes:
curl -g -m 5 "http://[TU_IPV6]:11434/api/tags"Si la prueba sale cerrada pero ss dice que escucha en todas las direcciones, te protege solo el cortafuegos: una capa. El día que alguien lo desactive para probar otra cosa, vuelve a quedar abierto.
Cómo cerrarlo, en orden de preferencia
La regla es exponer lo mínimo: empieza por la primera opción y baja solo si tu caso lo pide. Se pueden combinar, y conviene hacerlo.
1. Que escuche solo en local
Si Ollama lo usan programas del mismo servidor (Open WebUI, un flujo de automatización, tu propia aplicación), no necesita escuchar fuera. Primero mira dónde está fijada la variable:
systemctl cat ollamaEse comando enseña el servicio y los ajustes añadidos. Si ves una línea con OLLAMA_HOST=0.0.0.0, ábrela con sudo systemctl edit ollama.service, como indica la FAQ, y bórrala o déjala así:
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"Aplica los cambios y vuelve a comprobar:
sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -tlnp | grep 11434Si arrancaste Ollama a mano con ollama serve, la variable puede estar en tu sesión o en un guion de arranque, no en el servicio. Búscala ahí también.
En Docker, un contenedor no cambia sus puertos una vez creado: hay que borrarlo y crearlo de nuevo. Los modelos no se pierden si están en el volumen ollama, como en la guía oficial:
docker rm -f ollama
docker run -d --gpus=all -v ollama:/root/.ollama -p 127.0.0.1:11434:11434 --name ollama ollama/ollamaSi usas Docker Compose, la línea equivalente es "127.0.0.1:11434:11434" dentro de ports.
2. Cortafuegos (y el caso Docker)
Si otra máquina concreta tiene que hablar con Ollama, el cortafuegos del servidor debe dejar pasar solo a esa IP. Con ufw:
sudo ufw status numbered
sudo ufw allow from 203.0.113.10 to any port 11434 proto tcpCambia 203.0.113.10 por la IP real de esa máquina. En la lista numerada busca reglas antiguas que abran el 11434 a todo el mundo y bórralas con sudo ufw delete seguido del número. Si vas a activar ufw por primera vez en un servidor al que entras por SSH, permite antes el SSH (sudo ufw allow OpenSSH) o te quedarás fuera. Lo tienes con calma en nuestra guía de UFW e iptables.
Recuerda la trampa de antes: con Docker, ufw no filtra los puertos publicados. La solución no es pelearse con las reglas, sino publicar el puerto en 127.0.0.1 como en el paso anterior y dejar que el acceso externo entre por una de las opciones siguientes.
3. Red privada o VPN
Para un equipo que trabaja desde varios sitios, lo más limpio es una VPN: una red privada cifrada entre tus equipos y el servidor. WireGuard es una opción sencilla y muy extendida; su guía rápida explica cómo generar las claves y levantar la interfaz. Una vez montada, el servidor tiene una IP dentro de esa red (por ejemplo 10.8.0.1) y hay dos formas de usarla:
- Ollama escucha solo en la IP de la VPN:
Environment="OLLAMA_HOST=10.8.0.1:11434". Ojo: si Ollama arranca antes que la VPN, esa dirección todavía no existe en la máquina, y un programa no puede escuchar en una dirección que la máquina no tiene. Después del primer reinicio, comprueba que el servicio arrancó conjournalctl -u ollama. - Ollama en todas las direcciones y el cortafuegos filtra por interfaz: solo entra lo que llega por la VPN.
sudo ufw allow in on wg0 to any port 11434 proto tcpLa ventaja de la VPN es que no hay que inventar contraseñas para la API: quien no está dentro de la red, no llega al puerto.
4. Proxy inverso con contraseña y HTTPS
Si Ollama tiene que ser accesible desde internet (un servicio externo que no puede entrar en tu VPN, por ejemplo), no se abre el 11434. Ollama sigue en 127.0.0.1 y delante pones un proxy inverso: un servidor web que recibe las peticiones, pide contraseña, cifra la conexión con HTTPS y solo entonces las pasa a Ollama. La FAQ incluye el bloque básico de nginx; la contraseña la añade el módulo de autenticación básica de nginx. Primero crea el usuario (en Debian y Ubuntu, htpasswd viene en el paquete apache2-utils):
sudo apt install apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd-ollama equipoY el bloque, con el certificado ya emitido (por ejemplo con Let's Encrypt):
server {
listen 443 ssl;
server_name ia.tuempresa.es;
ssl_certificate /etc/letsencrypt/live/ia.tuempresa.es/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ia.tuempresa.es/privkey.pem;
location / {
auth_basic "Ollama";
auth_basic_user_file /etc/nginx/.htpasswd-ollama;
proxy_pass http://127.0.0.1:11434;
proxy_set_header Host localhost:11434;
proxy_read_timeout 300s;
}
}Comprueba la sintaxis con sudo nginx -t y recarga con sudo systemctl reload nginx. proxy_read_timeout da margen a las respuestas largas, que con un modelo grande pueden pasar del minuto. Si prefieres Caddy, que gestiona el certificado solo, la directiva es basic_auth (se llamaba basicauth antes de la versión 2.8) y la contraseña cifrada se genera con caddy hash-password:
ia.tuempresa.es {
basic_auth {
equipo PEGA_AQUI_EL_HASH
}
reverse_proxy 127.0.0.1:11434 {
header_up Host localhost:11434
}
}Desde fuera, prueba ahora sin y con contraseña: la primera debe dar 401 y la segunda la lista de modelos.
curl -m 5 https://ia.tuempresa.es/api/tags
curl -m 5 -u equipo https://ia.tuempresa.es/api/tagsUna limitación honesta: muchos programas pensados para la API de OpenAI solo saben mandar una clave del tipo Authorization: Bearer, no usuario y contraseña. Para esos, la contraseña básica no encaja, y suele ser mejor la VPN o que el programa viva en el mismo servidor.
5. Una interfaz con usuarios delante
Si lo que tu equipo necesita es chatear con el modelo, lo más sencillo es que Ollama no salga a ningún sitio. Open WebUI, instalado en el mismo servidor, habla con Ollama por dentro y es lo único que se publica, con su dominio, su HTTPS y una cuenta por persona. Lo montamos paso a paso en Open WebUI: un ChatGPT privado para tu equipo, incluido cómo cerrar el registro para que no entre quien no debe. Así la puerta que da a internet tiene usuarios y permisos, y la API sin contraseña se queda dentro.
vLLM y llama.cpp: la clave no lo cubre todo
Los otros servidores de modelos tienen una opción --api-key, pero protegen menos de lo que parece. En vLLM, según su página de seguridad, la clave solo se exige en las rutas que empiezan por /v1, /v2, /inference y /cohere, y otras rutas del mismo servidor (algunas de inferencia y otras de control, como pausar o actualizar pesos) siguen sin autenticación; la propia documentación pide no fiarse solo de ella. En llama.cpp, según el README de su servidor, escucha por defecto en 127.0.0.1 y /health queda público aunque pongas clave. Y en los dos, sin HTTPS delante, la clave viaja sin cifrar. La receta es la misma que con Ollama: local, cortafuegos o VPN, y proxy con HTTPS si tiene que salir.
Lista de comprobación
ss -tlnp | grep 11434dice127.0.0.1o una IP privada, no todas las direcciones.systemctl cat ollamano tieneOLLAMA_HOST=0.0.0.0salvo que haya un motivo y un cortafuegos detrás.- En Docker, el puerto se publica como
127.0.0.1:11434:11434. - El cortafuegos está activo y no hay reglas que abran el 11434 a todo el mundo.
- La prueba con
curldesde fuera no devuelve la lista de modelos, ni por IPv4 ni por IPv6. - Si tu equipo accede desde fuera, entra por VPN o por un proxy con contraseña y HTTPS.
- Si hay interfaz de chat, es lo único publicado y el registro de cuentas está cerrado.
- vLLM o llama.cpp, si los usas, siguen las mismas reglas: la
--api-keyno basta sola. - Repites la prueba desde fuera después de cada actualización o cambio en Docker.
Lo que esta guía no te cuenta
Cerrar el puerto es una tarde. Mantenerlo cerrado es cada semana, y ahí es donde falla casi todo:
- Un cambio lo vuelve a abrir sin avisar. Un compañero recrea el contenedor copiando el comando de la documentación, con
-p 11434:11434. Alguien pone0.0.0.0"un momento" para una prueba. Ninguna de las dos cosas da error: el servicio funciona igual, solo que abierto. - Vigilar desde fuera, de forma periódica. La prueba con
curlde esta guía vale el día que la haces. Lo útil es repetirla de forma automática desde otra máquina y que salte un aviso si un día devuelve la lista de modelos. - Actualizar sin romper. Actualizar Ollama, Docker o el sistema es parte de la seguridad, pero tiene su trampa. Si se actualizan los controladores de NVIDIA y no reinicias, el controlador cargado y el instalado dejan de coincidir:
nvidia-smida "Failed to initialize NVML: Driver/library version mismatch" y NVIDIA lo documenta. Ollama sigue respondiendo, pero con el procesador y mucho más lento. - Revisar el resto del servidor. El mismo
ss -tlnpsin filtrar te enseña todo lo que escucha, no solo Ollama.
Todo esto se puede hacer con tiempo y constancia. Si prefieres no encargarte tú, lo dejamos cerrado y lo vigilamos nosotros en un servidor con GPU, o en tu propio servidor con nuestra administración de servidores. Hablas con personas, no con un panel.
Preguntas frecuentes
¿Ollama tiene contraseña o clave de API?
La API local no. Según la documentación de autenticación, la API en localhost:11434 no requiere autenticación. La clave de API de Ollama sirve para sus modelos en la nube, no para proteger tu servidor. La protección la pones tú delante: cortafuegos, VPN o proxy con contraseña.
¿Basta con cambiar el puerto 11434 por otro?
No. Cambiar el puerto solo retrasa que lo encuentren: la API responde igual en cualquier puerto. Lo que protege es que no se pueda llegar.
Tengo ufw activado. ¿Estoy protegido?
Si Ollama está instalado directamente en el sistema y no hay reglas que abran el 11434, sí. Si lo ejecutas con Docker y publicaste el puerto con -p 11434:11434, no: Docker desvía ese tráfico antes de que llegue a ufw. Publica en 127.0.0.1 y compruébalo desde fuera.
¿Cómo sé si alguien ya ha usado mi Ollama?
Mira los registros del servicio con journalctl -u ollama por si aparecen peticiones que no reconozcas (según la versión y el nivel de registro, puede que no las veas todas), y revisa con ollama ls si hay modelos que no descargaste tú. Si lo tenías abierto, ciérralo primero y revisa después: lo urgente es cortar el acceso.
Artículos relacionados
- Cómo instalar Ollama en un servidor y cerrarlo a internet
- Open WebUI: un ChatGPT privado para tu equipo
- Firewall en VPS: guía de UFW e iptables
¿Prefieres no encargarte tú?
Montamos tu IA en un servidor con GPU, la dejamos funcionando y la mantenemos nosotros.
