Mapa operativo del servidor

Fecha: 2026-04-12
Host: silvio-server
Propósito: clasificación funcional del software y servicios instalados, con foco en utilidad operativa, criticidad y sensibilidad

1. Objetivo del documento

Este documento sirve para dos cosas a la vez:

1. dar una visión clara de qué hay en el servidor y cómo se puede agrupar
2. dejar una referencia operativa para saber qué herramientas y plataformas están disponibles para uso futuro

No es solo inventario. Es un mapa mental de uso.

2. Resumen ejecutivo

Este servidor no es una máquina de propósito único. Es una plataforma mixta que agrupa:

• automatización y asistentes
• servicios web
• IA local y proxys LLM
• bases de datos
• observabilidad
• aplicaciones de identidad y documentación
• laboratorio de seguridad ofensiva
• utilidades de administración y scripting

La consecuencia práctica es esta:

• tienes mucha capacidad instalada
• puedes reutilizar bastante de lo que ya existe
• también tienes mucha superficie que conviene entender antes de seguir creciendo

3. Clasificación principal

3.1 Producción o núcleo operativo

Estas piezas parecen formar parte del núcleo útil o persistentemente activo del servidor.

OpenClaw

Qué es: tu plataforma principal de asistente y automatización.
Estado: activo y funcional.
Utilidad: muy alta.

Incluye alrededor:

• gateway
• sidecar
• integración Telegram
• TTS/STT configurados

Nginx

Qué es: frontal web / reverse proxy.
Estado: activo.
Utilidad: alta.

Docker + containerd

Qué es: base de despliegue de gran parte del resto del stack.
Estado: activo.
Utilidad: crítica.

LiteLLM y LiteLLM bridge

Qué es: proxy y capa de integración para modelos.
Estado: activo.
Utilidad: alta para IA y orquestación.

Ollama

Qué es: runtime local para modelos.
Estado: activo.
Utilidad: alta si se usan modelos locales.

Open WebUI

Qué es: interfaz para LLMs / conversación.
Estado: contenedor activo.
Utilidad: alta o media, según tu flujo real.

Authentik

Qué es: gestión de identidad y acceso.
Estado: activo.
Utilidad: alta si protege servicios internos.

Uptime Kuma

Qué es: monitorización de disponibilidad.
Estado: activo.
Utilidad: alta como visibilidad operativa.

Netdata

Qué es: monitorización del host.
Estado: activo.
Utilidad: alta.

SSH

Qué es: acceso remoto administrativo.
Estado: activo.
Utilidad: crítica.

3.2 Servicios importantes pero auxiliares

Son piezas útiles, probablemente activas, pero no necesariamente el corazón del sistema.

Coolify

Qué es: plataforma de despliegue/self-hosting.
Estado: activa.
Utilidad: media-alta.

CRM stack

Detectado:

• crm_backend
• crm_frontend
• crm_redis
• crm_db
• worker y n8n relacionados

Qué es: stack de aplicación de negocio o experimento serio.
Utilidad: media-alta, depende de si está en uso real.

PwnDoc

Qué es: documentación de auditorías / pentesting.
Estado: activo.
Utilidad: alta si haces seguridad técnica.

Neo4j

Qué es: base de grafos.
Estado: activo como servicio.
Utilidad: media-alta, especialmente si se liga a BloodHound o analítica.

MongoDB

Qué es: backend de PwnDoc u otros servicios.
Estado: contenedor activo.
Utilidad: auxiliar.

PostgreSQL / pgvector

Qué es: base de datos relacional y vectorial.
Estado: activa vía contenedores.
Utilidad: alta para apps modernas e IA.

Redis

Qué es: cache / cola / soporte para apps.
Estado: activo.
Utilidad: alta como componente auxiliar.

Tailscale

Qué es: conectividad privada overlay.
Estado: servicio activo.
Utilidad: alta, incluso si OpenClaw reportó tailscale off a nivel de su propia vista.

3.3 Herramientas de IA, automatización y procesamiento

Estas no son solo software instalado. Son capacidades disponibles que se pueden aprovechar.

IA y LLM

Dispones de:

• OpenClaw
• LiteLLM
• Open WebUI
• Ollama
• OpenAI CLI
• tiny-agents
• MCP tooling

Capacidades derivadas:

• orquestación de modelos
• uso de modelos locales
• integración con herramientas externas
• proxies y capas de compatibilidad

Audio y voz

Dispones de:

• edge-tts
• edge-playback
• ffmpeg
• stack de faster-whisper / ct2-*

Capacidades derivadas:

• TTS en español
• STT local
• conversión/transcodificación de audio y vídeo
• automatización multimedia

Visión / multimedia / ML

Dispones de:

• ffmpeg
• imagemagick
• easyocr
• insightface-cli
• ultralytics
• yolo
• torchrun
• rembg

Capacidades derivadas:

• OCR
• detección de objetos
• recorte de fondos
• análisis de imagen
• procesamiento de vídeo

Automatización Python / APIs

Dispones de:

• fastapi
• flask
• uvicorn
• gunicorn
• watchfiles
• uv
• uvx

Capacidades derivadas:

• levantar APIs rápidamente
• prototipos de servicios
• automatización web y backend local

3.4 Herramientas ofensivas y sensibles

Esta categoría requiere especial conciencia, porque amplía mucho lo que el servidor puede hacer.

Se detectan múltiples herramientas de:

• Active Directory
• SMB
• NTLM relay
• Kerberos
• enumeración LDAP
• dumping de secretos
• pivoting
• phishing infra
• cracking
• radio/wifi y red ofensiva

Ejemplos detectados

• metasploit-framework
• bettercap
• aircrack-ng
• gobuster
• hashcat
• hydra
• john
• evilginx2
• bloodhound-python
• gran cantidad de scripts de impacket

Qué significa esto operativamente

Este servidor tiene capacidad real para:

• auditoría ofensiva
• enumeración de infraestructuras AD
• credential attacks
• relay y movimiento lateral simulado
• documentación técnica de hallazgos

Qué significa desde seguridad

Esto exige disciplina:

• control de acceso muy estricto
• claridad sobre qué canales pueden disparar acciones
• no tratar el host como un simple servidor doméstico

3.5 Servicios probablemente de laboratorio, legado o residuales

Hay piezas que parecen haber sido usadas o probadas, pero no está claro si siguen aportando valor constante.

Candidatos claros a revisión

• contenedores detenidos de n8n
• minio
• BloodHound CE antiguo
• workspace-supervisor-1
• crm_worker detenido
• componentes antiguos de grafos o apps descartadas

Criterio

No necesariamente sobran, pero sí conviene clasificarlos como:

• activos en producción
• mantenidos pero inactivos
• legado
• pendientes de retirada

4. Qué puedo utilizar en este servidor

Aquí está la parte importante para “tomar conciencia”.

4.1 Como asistente, tengo disponibles de forma potencial

Para automatización y backends

• Python moderno
• FastAPI / Flask / Uvicorn / Gunicorn
• Node.js moderno
• Docker y contenedores

Para IA

• OpenClaw
• LiteLLM
• Ollama
• Open WebUI
• herramientas OpenAI / agentes

Para voz y multimedia

• TTS con Edge/Microsoft
• STT local con Whisper stack
• ffmpeg
• herramientas de procesamiento de imagen y vídeo

Para observabilidad y operación

• Netdata
• Uptime Kuma
• systemd
• Docker
• Nginx

Para identidad y acceso

• Authentik
• SSH
• Tailscale
• OpenVPN presente a nivel de servicio

Para seguridad técnica

• PwnDoc
• Neo4j
• BloodHound tooling
• Metasploit
• Bettercap
• tooling de impacket y AD

4.2 Lo que esto me permite hacer contigo

Prácticamente, esta máquina me permite ayudarte en:

1. automatización y scripting
2. desarrollo de APIs o herramientas internas
3. voz, TTS, STT y procesamiento multimedia
4. integración con modelos locales o proxys LLM
5. análisis de infraestructura y servicios
6. documentación técnica y auditoría
7. tareas de seguridad defensiva y ofensiva controlada
8. despliegue o soporte de apps autocontenidas

5. Riesgo y sensibilidad por categorías

Muy sensible

• OpenClaw con permisos altos
• SSH
• Docker
• LiteLLM / Open WebUI si exponen modelos o claves
• Authentik
• PostgreSQL / Redis / MongoDB
• tooling ofensivo

Sensible

• PwnDoc
• Neo4j
• Uptime Kuma
• paneles auxiliares web
• n8n si vuelve a activarse

Menos sensible, pero útil

• ffmpeg
• edge-tts
• utilidades Python locales
• OCR y visión

6. Recomendación estructural

La mejor forma de mantener este servidor bajo control es pensar en cuatro bloques:

1. Core de asistente y AI
2. OpenClaw
3. LiteLLM
4. Ollama

5. Open WebUI

6. Core de infraestructura

7. Nginx
8. Docker
9. SSH
10. Tailscale

11. monitorización

12. Apps auxiliares

13. CRM
14. Authentik
15. PwnDoc

16. Uptime Kuma

17. Laboratorio y seguridad

18. Metasploit
19. Bettercap
20. BloodHound tooling
21. impacket y demás

Ese modelo ayuda a decidir qué proteger más, qué restringir, qué documentar mejor y qué podría moverse a otro host si el servidor crece demasiado.

7. Acciones recomendadas después de este mapa

1. etiquetar cada servicio como:
2. producción
3. auxiliar
4. laboratorio

5. legado

6. documentar propietario o motivo de existencia de cada stack

7. decidir qué software ofensivo debe permanecer aquí y qué no

8. separar exposición pública y privada por servicio

9. usar este documento como base para una futura limpieza o endurecimiento

8. Conclusión

Sí, ya tengo una imagen mucho más clara de lo que hay instalado y de lo que puedo aprovechar en esta máquina.

La idea importante no es solo “hay muchas cosas”, sino esta:

• hay capacidad real ya desplegada
• mucha de esa capacidad es reutilizable
• varias piezas son delicadas y exigen más control
• este servidor ya es más una plataforma que una simple máquina de apoyo

Eso cambia cómo conviene operarlo.

9. Estado del documento

Documento generado en solo lectura, sin cambios en la configuración del host.