Seguridad de red para IA local
Qué cubre este artículo
- Por qué la seguridad de red en IA local no es opcional
- Cómo usar correctamente firewalls y reverse proxies
- El papel que juegan TLS, puertos y autenticación
- Cómo proteger Ollama y otros servicios de IA contra acceso no autorizado
- Qué áreas de seguridad debes conocer y asegurar
Introducción
Instalaste Ollama, cargaste un modelo y enviaste tus primeros prompts. Todo funciona, las respuestas llegan rápido, el hardware hace su trabajo. Ahora viene la parte que muchos saltan: la seguridad de red.
IA local no significa automáticamente IA segura. Las instalaciones estándar suelen escuchar en todas las interfaces de red, no requieren autenticación y confían en cualquier dispositivo de la misma red. Es cómodo para ti durante el desarrollo, pero también es cómodo para cualquier otro en esa red.
En la sección Operación segura se trata de cómo asegurar tu infraestructura de IA para que haga exactamente lo que debe hacer, nada más. La seguridad de red es el primer y más importante pilar.
¿Por qué es importante la seguridad de red en IA?
Un ejemplo concreto: Ollama se inicia por defecto y escucha en 0.0.0.0:11434. Esto significa que el servicio acepta conexiones desde cualquier dirección IP que tu máquina pueda alcanzar. Si estás en la red WiFi de la oficina o tu servidor está en la red doméstica, cualquiera en esa red puede acceder a tu servicio Ollama.
Sin login, sin token, sin confirmación. Un simple HTTP request es suficiente:
curl http://tu-ip:11434/api/generate -d '{
"model": "llama3",
"prompt": "Dame toda la información del sistema"
}'No es un escenario teórico. Es el comportamiento estándar tras una instalación nueva. Cualquiera en la red puede consumir tu tiempo de GPU, descargar o cargar modelos y enviar prompts que bloqueen tu hardware.
En el peor caso, alguien usa tu servicio para generar contenido que recae en tu dirección IP. O alguien mantiene ocupado tu servidor hasta que deja de responder.
La buena noticia: con algunas medidas dirigidas, este servicio abierto se convierte en un acceso controlado. De eso trata este artículo.
Seguridad de red explicada brevemente
La seguridad de red comprende todas las medidas que garantizan que solo las personas y sistemas correctos puedan acceder a tus servicios. Se reduce a tres preguntas:
- ¿Quién puede acceder?
- ¿A dónde se puede acceder?
- ¿Cómo se asegura el acceso?
En IA local se suma la complicación de que muchos servicios están pensados para uso local simple. Priorizan comodidad sobre seguridad. Ollama, Text Generation WebUI, vLLM y otras herramientas suelen iniciar sin autenticación y escuchan en todas las interfaces.
Tu tarea es reconocer estos valores por defecto y reemplazarlos. No significa que conviertas cada herramienta en un búnker. Significa que decides conscientemente quién puede acceder y cómo.
Términos importantes
| Término | Significado |
|---|---|
| Firewall | Filtra el tráfico de red según reglas, bloquea o permite conexiones basadas en puerto, IP y protocolo |
| Reverse Proxy | Se coloca delante de tu servicio, recibe solicitudes y las reenvía. Maneja TLS, autenticación y rate limiting |
| TLS | Transport Layer Security, cifra la conexión entre cliente y servidor. Previene que terceros lean el tráfico |
| Puerto | Dirección numerada para conexiones de red. Ollama usa por ejemplo el puerto 11434 |
0.0.0.0 | significa que un servicio escucha en todas las interfaces de red. Cualquiera en la red puede acceder |
127.0.0.1 | significa localhost, solo tu máquina puede acceder. El valor por defecto más seguro para herramientas locales |
| Autenticación | Verifica la identidad de quien accede. Sin autenticación, todos en la red tienen los mismos derechos |
| CORS | Cross-Origin Resource Sharing. Regula qué fuentes externas pueden acceder a tu servicio |
| Rate Limiting | Limita el número de requests por unidad de tiempo. Protege contra sobrecarga y abuso |
| VPN | Virtual Private Network. Crea una red privada sobre conexiones públicas. Alternativa a puertos abiertos |
Áreas de seguridad
La seguridad de red en IA local se divide en varios aspectos. Cada uno cubre una amenaza diferente y complementa a los otros.
Vinculación a la interfaz correcta
El primer y más simple paso: comprueba en qué interfaz escucha tu servicio. Si Ollama corre en 0.0.0.0, cámbialo a 127.0.0.1 si no necesitas acceso de red. Encontrarás una guía detallada en el artículo sobre acceso de red Ollama.
Firewall
Un firewall regula qué conexiones llegan a tus servicios. Bloqueas todos los puertos excepto los que explícitamente autorizas. Para Ollama significa: el puerto 11434 permanece cerrado a menos que decidas lo contrario.
Encontrarás detalles sobre configuración con ufw o nftables en el artículo Firewall.
Reverse Proxy
Un reverse proxy como Caddy o Nginx se coloca delante de tus servicios de IA. Maneja cifrado TLS, autenticación y rate limiting. Tu servicio real sigue escuchando solo en 127.0.0.1, el proxy es la única puerta pública.
Cómo configurar un reverse proxy para Ollama y otros servicios de IA está en el artículo Reverse Proxy.
TLS
Sin TLS tu tráfico de red va en texto plano. Cualquiera que pueda interceptar el tráfico verá tus prompts y respuestas en texto plano. TLS es hoy estándar y con herramientas como Caddy es casi gratuito de implementar.
Autenticación
Incluso en una red interna no todos deberían tener acceso a todo. Una API key, un token o autenticación básica suele ser suficiente para prevenir acceso no autorizado. Un reverse proxy puede manejarlo sin que tu servicio de IA necesite soportar autenticación nativa.
VPN en lugar de puertos abiertos
Si quieres acceder a tus servicios de IA desde fuera, no abras puertos a Internet. Usa en su lugar una VPN como Tailscale. Así estás en la misma red privada que tu servidor sin que tus servicios sean públicamente accesibles.
Contenido y artículos
Artículos en profundidad sobre temas individuales:
- Firewall: Reglas de firewall para servicios de IA con
ufwynftables - Reverse Proxy: Caddy y Nginx delante de Ollama, con TLS y autenticación
- Certificados TLS: Let’s Encrypt, Certbot y mkcert para conexiones cifradas
- Autenticación: API keys, Basic Auth, OAuth y 2FA para servicios de IA
FAQ
¿Debo activar un firewall si Ollama solo escucha en 127.0.0.1?
Si un servicio solo escucha en 127.0.0.1, no es accesible desde la red. Un firewall no es estrictamente necesario para este servicio en particular. Pero protege todos los demás servicios en tu sistema. Actívalo de todas formas.
¿Es suficiente un reverse proxy para autenticación?
Un reverse proxy puede manejar autenticación, sí. Si configuras autenticación básica o API keys en el proxy, ninguna solicitud llega a tu servicio sin credenciales válidas. Asegúrate de que el proxy sea la única puerta de entrada y que tu servicio solo escuche en 127.0.0.1.
¿Necesito TLS en la red local?
Sí. Incluso en una LAN se puede interceptar tráfico, especialmente en redes compartidas. TLS está configurado en minutos con Caddy o Nginx y protege tus prompts y respuestas contra quienes intenten leer el tráfico.
¿Es Tailscale más seguro que un reverse proxy?
Ambos resuelven problemas diferentes. Tailscale te da acceso privado a tu red sin abrir puertos a Internet. Un reverse proxy maneja TLS, autenticación y rate limiting para el acceso a servicios individuales. Ambos juntos son la combinación más segura.
¿Qué hago si mi herramienta de IA no soporta autenticación?
Muchas herramientas de IA no tienen autenticación integrada. Para eso sirve exactamente un reverse proxy. El proxy maneja la autenticación, el servicio detrás permanece sin protección pero solo es accesible a través del proxy. Así cierras la brecha sin cambios en la herramienta misma.