Incidente s52 PM — Exposición pública de la Web UI de llama-server (llama-help.crearack.com)

Resumen ejecutivo

Al cierre de la sesión 52 (2026-05-07), Edu detectó que el subdominio https://llama-help.crearack.com/ — un Cloudflare Tunnel apuntando al llama-server self-hosted en el LXC 100 del nodo pve-epyc-02 — exponía la web UI built-in de llama.cpp al público general sin ninguna autenticación.

Estado de riesgo al detectar el incidente

Vector	Estado
Rutas de inferencia (`/v1/*`, `/completion`, `/props`)	✅ Protegidas con `LLAMA_API_KEY` — devuelven 401 sin auth
Web UI estática (`GET /`)	❌ Respondía 200 al mundo — footprinting trivial
Modelo explotable sin key	No — la inferencia requiere auth header
Datos de usuarios expuestos	No — la UI carga pero no funciona sin la key
Violación de política del equipo	Sí — “nada abierto al público sin autenticar”

Severidad: Media-Baja (riesgo de explotación inmediata bajo, pero violación de política clara de seguridad).

Línea de tiempo

Momento	Evento
s52 PM — cierre	Edu detecta la exposición al revisar subdominios activos
s52 PM — minutos después	Se borra la fila `llama-help (público)` del D1 remote en vivo directamente
s52 PM — commit `38aaa0a`	Se registra el plan de mitigación en `briefings/NEXT.md`; el seed `migrations/0018_seed_quick_links.sql` se actualiza para eliminar la fila del subdominio público y evitar que resucite con una re-aplicación
s53 AM (próxima sesión)	Ejecución del plan B: eliminar CF Tunnel + migrar Help via Tailscale en `crearack-prod`

Causa raíz

El llama-server (llama.cpp) expone una web UI integrada en GET / que no está sujeta a la misma autenticación que las rutas de API. Al crear el Cloudflare Tunnel llama-help para dar acceso al Help Widget de CreaRack, se publicó inadvertidamente esta UI sin considerar que el flag --api-key solo protege las rutas de inferencia, no la ruta raíz.

Impacto

Footprint visible: cualquier persona podía ver la interfaz de llama.cpp, identificar el modelo cargado y la versión del servidor.
No se explotó el modelo: sin la LLAMA_API_KEY las llamadas de inferencia fallan con 401.
Sin fuga de datos de usuarios: el llama-server no tiene acceso a la base de datos de CreaRack Pro.
Duración de exposición: indeterminada — el tunnel llevaba activo desde la implementación inicial del Help Widget.

Mitigación inmediata (s52 PM)

Eliminada la fila ('llama-help (público)', 'https://llama-help.crearack.com/', ...) del D1 remote directamente.
Actualizado migrations/0018_seed_quick_links.sql para reflejar el estado correcto y prevenir resurrección.
Las referencias en el seed de Quick Links ahora apuntan exclusivamente a las IPs tailnet (http://100.80.142.60:8081/), solo accesibles internamente.

Plan de resolución completa (s53 AM)

Ver [[decision—20260507—help-migrar-tailscale-django]] para el plan técnico detallado de 10 pasos.

En síntesis:

Instalar Tailscale en crearack-prod (Hetzner CCX).
Refactorizar core/api_help.py de CreaRack-Pro para llamar directamente al llama-server via tailnet.
Eliminar el Cloudflare Tunnel llama-help y el CNAME DNS llama-help.crearack.com.
Cambiar el bind del llama-server-e2b a 0.0.0.0:8081 (protegido por UFW en tailscale0).

Estado actual

DRAFT — En resolución. El plan B está aprobado pero pendiente de ejecución en s53 AM. Actualizar este incidente a resolved una vez confirmado el end-to-end con Tailscale.

Véase también

[[decision—20260507—help-migrar-tailscale-django]]