Matriz de decisión de servicios del servidor

Fecha: 2026-04-12
Host: silvio-server
Objetivo: proponer una decisión operativa para cada bloque relevante del servidor

1. Cómo leer este documento

Cada servicio o stack se clasifica en una de estas acciones recomendadas:

• SE QUEDA: debe permanecer como parte del entorno actual
• SE RESTRINGE: sigue siendo útil, pero necesita menos exposición o más control
• SE MUEVE: convendría llevarlo a otra máquina, red o segmento
• SE ELIMINA: parece prescindible, residual o innecesariamente riesgoso

La matriz no ejecuta nada. Es una propuesta para revisión humana.

2. Criterios de decisión

He usado estos criterios:

1. utilidad actual o esperable
2. criticidad para tu flujo
3. exposición en red
4. sensibilidad de seguridad
5. coste operativo de mantenerlo aquí
6. si encaja o no con el rol principal del servidor

3. Decisiones recomendadas

3.1 Núcleo de asistente, IA y operación

OpenClaw

• Decisión: SE QUEDA
• Motivo: es pieza central del sistema
• Condición: necesita endurecimiento de configuración y reducción de exposición
• Prioridad: muy alta

OpenClaw sidecar

• Decisión: SE QUEDA
• Motivo: soporte directo del stack OpenClaw
• Condición: revisar permisos y superficie de acceso
• Prioridad: alta

LiteLLM

• Decisión: SE QUEDA
• Motivo: útil como proxy de modelos y capa de integración
• Condición: idealmente restringido a red confiable o loopback/reverse proxy controlado
• Prioridad: alta

LiteLLM bridge

• Decisión: SE QUEDA
• Motivo: complementa integración con OpenClaw
• Condición: restringir exposición directa
• Prioridad: alta

Ollama

• Decisión: SE QUEDA
• Motivo: capacidad local de modelos, muy valiosa
• Condición: exponer solo si realmente hace falta
• Prioridad: alta

Open WebUI

• Decisión: SE RESTRINGE
• Motivo: útil, pero no imprescindible como servicio abierto
• Condición: mantenerlo solo detrás de autenticación o red confiable
• Prioridad: alta

Nginx

• Decisión: SE QUEDA
• Motivo: es pieza estructural del frontend/reverse proxy
• Condición: revisar rutas expuestas y proxies publicados
• Prioridad: muy alta

SSH

• Decisión: SE QUEDA
• Motivo: acceso administrativo crítico
• Condición: endurecer y revisar política de acceso
• Prioridad: muy alta

Tailscale

• Decisión: SE QUEDA
• Motivo: es de las mejores formas de acceso privado seguro
• Condición: usarlo más como canal preferente y menos exposición pública directa
• Prioridad: alta

OpenVPN

• Decisión: SE RESTRINGE
• Motivo: útil si realmente lo usas, pero duplica función con Tailscale
• Condición: confirmar si sigue siendo necesario
• Prioridad: media

3.2 Observabilidad y monitorización

Netdata

• Decisión: SE QUEDA
• Motivo: buena visibilidad del host
• Condición: no debería quedar abierto libremente sin protección
• Prioridad: alta

Uptime Kuma

• Decisión: SE QUEDA
• Motivo: útil para control operativo
• Condición: limitar acceso por autenticación o red confiable
• Prioridad: media-alta

3.3 Identidad y acceso

Authentik

• Decisión: SE QUEDA
• Motivo: muy útil si centraliza autenticación de servicios web
• Condición: revisar bien exposición y puertos 9000/9443
• Prioridad: alta

Control UI insegura de OpenClaw

• Decisión: SE RESTRINGE
• Motivo: útil para operar, pero actualmente demasiado permisiva
• Condición: quitar flags peligrosos, cerrar wildcard origins, restaurar device auth
• Prioridad: crítica

3.4 Bases de datos y almacenamiento

PostgreSQL / pgvector

• Decisión: SE RESTRINGE
• Motivo: seguramente necesario para apps activas, pero no debería estar expuesto ampliamente
• Condición: idealmente loopback, red interna Docker o acceso muy controlado
• Prioridad: crítica

Redis

• Decisión: SE RESTRINGE
• Motivo: útil para apps, pero expuesto es una mala idea
• Condición: restringir a red interna o loopback
• Prioridad: crítica

MongoDB de PwnDoc

• Decisión: SE RESTRINGE
• Motivo: backend auxiliar, no servicio para exposición general
• Condición: mantener solo interno
• Prioridad: alta

Neo4j

• Decisión: SE RESTRINGE
• Motivo: valioso si usas BloodHound o grafos, pero sensible
• Condición: confirmar uso real y cerrar acceso si no se usa continuamente
• Prioridad: alta

MinIO

• Decisión: SE ELIMINA o SE MUEVE
• Motivo: aparece detenido y no parece parte clara del core actual
• Condición: primero confirmar si hay datos o dependencia pendiente
• Prioridad: media

3.5 Apps y stacks auxiliares

CRM stack (crm_backend, crm_frontend, crm_db, crm_redis)

• Decisión: SE QUEDA o SE MUEVE
• Motivo: parece un stack funcional separado del núcleo OpenClaw
• Condición: si es importante de negocio, merece más aislamiento
• Recomendación concreta: si va a crecer, moverlo a host o segmento propio
• Prioridad: alta

crm_worker

• Decisión: SE ELIMINA o SE REACTIVA conscientemente
• Motivo: aparece parado, así que ahora mismo es deuda técnica
• Condición: decidir si es necesario o residual
• Prioridad: media

crm_n8n

• Decisión: SE ELIMINA o SE REACTIVA conscientemente
• Motivo: estado creado/parado, no claramente operativo
• Prioridad: media

n8n antiguo

• Decisión: SE ELIMINA o SE MUEVE
• Motivo: contenedor parado, parece intento previo o legado
• Prioridad: media

PwnDoc

• Decisión: SE QUEDA
• Motivo: útil si documentas auditorías
• Condición: revisar si debe estar expuesto o solo accesible por red privada
• Prioridad: media-alta

Coolify

• Decisión: SE RESTRINGE o SE MUEVE
• Motivo: es muy potente, pero añade mucha superficie si no es pieza central de tu operación diaria
• Condición: decidir si este servidor debe ser también host de orquestación general
• Prioridad: alta

3.6 Laboratorio, seguridad y herramientas ofensivas

Metasploit

• Decisión: SE MUEVE o SE RESTRINGE
• Motivo: herramienta potente, sensible y no necesaria para la operación base del asistente
• Condición: mejor en laboratorio separado o al menos con perímetro más controlado
• Prioridad: alta

Bettercap

• Decisión: SE MUEVE o SE RESTRINGE
• Motivo: tooling ofensivo delicado
• Condición: no ideal en el mismo host multipropósito si no hay control estricto
• Prioridad: alta

BloodHound tooling / impacket / scripts AD ofensivos

• Decisión: SE MUEVE
• Motivo: capacidades de seguridad ofensiva muy sensibles
• Condición: idealmente en laboratorio o VM específica
• Prioridad: alta

Evilginx2

• Decisión: SE MUEVE o SE ELIMINA
• Motivo: extremadamente sensible desde perspectiva de riesgo y reputación
• Condición: mantenerlo aquí solo si existe un motivo muy consciente y controlado
• Prioridad: muy alta

Hashcat / John / Hydra / Aircrack-ng / Gobuster

• Decisión: SE RESTRINGE o SE MUEVE
• Motivo: útiles para seguridad, pero no forman parte del núcleo del servidor
• Condición: mejor en entorno de laboratorio si no se usan frecuentemente aquí
• Prioridad: media-alta

3.7 Utilidades locales y scripts personalizados

backup_openclaw.sh y restore_openclaw.sh

• Decisión: SE QUEDAN
• Motivo: muy valiosos para continuidad operativa
• Condición: revisar y documentar su ubicación/uso
• Prioridad: alta

duckdns-update.sh

• Decisión: SE QUEDA o SE ELIMINA
• Motivo: depende de si DuckDNS sigue formando parte del acceso real
• Condición: confirmar uso actual
• Prioridad: baja-media

scripts de test y utilidades locales (check-model, check-node, etc.)

• Decisión: SE QUEDAN
• Motivo: útiles para operación y diagnóstico
• Condición: conviene documentarlos mejor
• Prioridad: media

4. Matriz resumida

5. Decisiones transversales importantes

Más allá del software individual, hay cuatro decisiones de arquitectura que convendría tomar:

1. Este servidor, ¿es core productivo o también laboratorio?

Ahora mismo es ambas cosas. Eso aumenta mucho la complejidad y el riesgo.

2. ¿Qué debe estar accesible públicamente?

Hay demasiadas piezas candidatas a exposición. Eso debería reducirse y centralizarse detrás de pocos puntos muy controlados.

3. ¿Qué debe vivir solo en red privada?

Bases de datos, paneles internos, proxies LLM y tooling sensible deberían tender a red privada o loopback.

4. ¿Qué tooling ofensivo merece seguir en este host?

No todo lo instalado debería convivir con OpenClaw, Authentik, CRM y servicios web.

6. Propuesta de siguiente fase

Mi propuesta práctica sería esta, por orden:

Fase 1

• restringir OpenClaw
• restringir Control UI
• cerrar DBs y Redis
• confirmar exposición real de paneles

Fase 2

• decidir futuro de CRM, Coolify, Open WebUI y Authentik en esta máquina
• separar lo que sea claramente una plataforma distinta

Fase 3

• sacar o aislar tooling ofensivo y de laboratorio
• limpiar contenedores y restos detenidos

7. Conclusión

Mi lectura operativa es esta:

• se queda el núcleo de asistente, acceso, monitorización y componentes que claramente te aportan valor diario
• se restringe casi todo lo que hoy está más expuesto de lo necesario
• se mueve buena parte del laboratorio ofensivo y, posiblemente, algunos stacks paralelos si van a crecer
• se elimina lo parado, residual o sin función actual clara

La clave no es borrar por borrar. La clave es que el servidor deje de ser una acumulación de cosas y pase a ser una plataforma con roles claros.

8. Estado del documento

Documento generado en modo solo lectura, sin aplicar cambios.