Tactical RMM para sysadmins: arquitectura, hardening, despliegue reproducible y operación diaria (sin cuotas por endpoint)

X (Twitter) Facebook Pinterest LinkedIn Email WhatsApp

Tactical RMM (TRMM) es un RMM self-hosted que integra inventario, monitorización, parcheo, ejecución de scripts y acceso remoto (vía MeshCentral) con agentes para Windows, Linux y macOS (estos dos últimos como parte de su programa de patrocinio). Corre sobre Django + Vue, NATS, PostgreSQL y Redis, y se orquesta bien vía Docker Compose. Para entornos small/medium que viven hoy con AnyDesk/TeamViewer + scripts + GPO, TRMM reduce tool sprawl y, sobre todo, corta OPEX: 0 € por endpoint y control total de datos y superficie de ataque.

A continuación, una guía orientada a operación (no marketing): arquitectura, requisitos, IaC y hardening, runbook de actualización, backup/DR, gotchas y dimensiones realistas.

1) Arquitectura de referencia

Componentes (contenedorizados):

Panel/UI: Vue + API Django
NATS: mensajería/colas para tareas/telemetría
PostgreSQL: base de datos de estado
Redis: broker/caché (colas cortas, counters)
MeshCentral: escritorio remoto, shell y transferencia de archivos
Proxy TLS: Traefik/Caddy/nginx con Let’s Encrypt

FQDN recomendados (dos planos):

rmm.example.com → UI
api.example.com → API/Agentes

Puertos externos: 80/443.
Puertos internos (no expuestos): 4222 (NATS), 5432 (Postgres), 6379 (Redis), 443xx (Mesh sub-servicios si aplica).

Nota de HA: TRMM está diseñado para single-node. Se puede stretch a HA light (PG en HA, backups calientes, reverse en activo/pasivo), pero no es Kubernetes.

2) Requisitos y sizing

SO host: Ubuntu 22.04 LTS (recomendado) o 24.04
HW mínimo: 4 vCPU, 8 GB RAM, 80–120 GB SSD
HW recomendado (≈ 1.000 endpoints, checks moderados): 8 vCPU, 16–24 GB RAM, SSD NVMe
Tiempo de despliegue: 60–120 min (con DNS y TLS propagados)

Reglas de pulgar de sizing (depende de checks, intervalos y patch windows):

300–500 endpoints: 4 vCPU/8 GB → OK
500–1.500 endpoints: 8 vCPU/16–24 GB → ajustar NATS/PG (work_mem, autovacuum)
1.500 endpoints: verticalizar y auditar checks/intervalos; PG aparte o managed; considerar split por tenant.

3) Red, DNS y PKI

DNS: A/AAAA de rmm. y api. a la IP del host.
PKI: Let’s Encrypt HTTP-01 (o DNS-01 si wildcard).
Firewall: abrir 22/80/443; bloquear todo lo demás en host (UFW/nftables).
Zero Trust (opcional): Cloud proxy (Cloudflare, Zscaler) delante de api. con WAF y rate limiting.

4) Despliegue reproducible (IaC)

4.1 Bootstrap del host (Ansible, idempotente)

Instalar Docker/Compose, git, jq, unzip
Configurar TZ, sysctl (fs.inotify, vm.), journald (rotación)
Crear usuario sin contraseña, sudoers mínimos, SSH por clave
UFW con perfil deny by default

4.2 Compose stack

Estructura de carpetas:

/opt/tacticalrmm/
  docker-compose.yml
  .env
  traefik/ (o caddy/)
  postgres/data
  redis/data
  meshcentral/data
  backup/

Variables clave (.env):

RMM_FQDN=rmm.example.com
API_FQDN=api.example.com
TZ=Europe/Madrid
[email protected]

POSTGRES_PASSWORD=XXXXXXXX
REDIS_PASSWORD=XXXXXXXX
NATS_PASSWORD=XXXXXXXX
DJANGO_SECRET_KEY=XXXXXXXX (>= 50 chars)

Compose (alto nivel):

traefik/caddy con entrypoints 80/443 y certificados automáticos
Servicios rmm, api, nats, postgres, redis, meshcentral en red interna
Healthchecks y restart policies

Lanzar:

docker compose pull
docker compose up -d
docker compose ps

Post-install:

Acceder a https://rmm.example.com → crear admin
Validar https://api.example.com/api/ → 200
Configurar SMTP/alertas, políticas y MeshCentral (2FA y certificados)

5) Hardening (checklist)

TLS obligatorio, cipher suites modernas (TLS1.2/1.3)
UI: 2FA obligatorio para admins; RBAC mínimo; auditar cambios
API: rate limiting (traefik/caddy), headers de seguridad (CSP, HSTS, X-Frame)
MeshCentral: 2FA, session expiry corto, auto-update y consent UAC configurado
Serv. internos (PG/Redis/NATS): bind a redes internas; sin puertos expuestos
Logs: forwarding a syslog/ELK/Vector con retención y RGPD
Backups: ver §7; encrypt-at-rest (rclone/Restic a S3/Backblaze)
Parches del host: unattended-upgrades + ventana mensual de compose pull
Secretos: .env y credenciales en Vault/sops; no en git

6) Modelo operativo: políticas, checks, parcheo, scripts

Estructura

Tenants (Organizaciones) → Sitios → Grupos → Equipos
Políticas heredables (Baseline, AV/EDR, Parches, Alert routing)

Checks base

CPU > 85% (5 min), RAM > 85%, disco < 15%, S.M.A.R.T., services up, event logs (IDs críticos), Windows Update status, AV/EDR activo, last reboot, RDP state (según política)

Parcheo

Ventana Patch Tuesday + X días por ring (crit-high → low)
Reboots escalonados; pre/post scripts (DISM/SFC reset WU cuando proceda)
Excluir drivers salvo casos de soporte

Scripts

Win: PowerShell (limpieza %TEMP%, DISM /RestoreHealth, sfc /scannow, reset WU, choco installs)
Linux: apt/yum updates, chequeos de systemd, journald rotación
macOS: brew, profiles (si patrocinio)
Runner programado (semanal/mensual)

Remoto

Escritorio (consent/UAC), shell en tiempo real, ficheros; recording opcional según cumplimiento

7) Copias de seguridad y DR

Qué respaldar

PostgreSQL: pg_dump (diario) + base semanal (pg_basebackup si el tamaño crece)
Redis: snapshot RDB (horario); incluir en off-site
MeshCentral: meshcentral-data/ y config
Configs: docker-compose.yml, .env, secrets (en Vault), trabajos cron

Dónde

S3 compatible (AWS/Wasabi/Backblaze) con bucket privado, encryption-at-rest y lifecycle (7/30/90 días)
Snapshots de VM semanales (cloud provider)

Restauración ensayada (trimestral)

VM limpia → compose → importar PG/Redis → validar agents check-in
Objetivo: < 60 min RTO para panel, < 15 min RPO en PG

8) Actualizaciones (runbook)

Staging idéntico (subconjunto de endpoints)
Ventana: snapshot + backups OK
docker compose pull && docker compose up -d
Validar migrations de Django, Mesh y UI
Fumigar contenedores antiguos, dangling images y volcar compose version en changelog interno
Abrir change ticket con diff de versión y periodo de observación (24–48 h)

9) Observabilidad (SRE-light)

Métricas host: node_exporter → Prometheus → Grafana (CPU, RAM, FS, net)
Métricas PG: postgres_exporter (TPS, bloat, locks, vacuums)
Métricas NATS: endpoint de varz → exporter
Aplicación: healthchecks de /api/, tiempos de respuesta, colas de tareas, tasa de errores
Alertas: alta latencia en API, HTTP 5xx, PG conexiones, disco < 15%, cert expiry LE

10) Seguridad del endpoint

Windows: agente MSI vía GPO/Intune con despliegue /qn y transform si aplica; firma de código (si patrocinio)
Linux: paquete .deb/systemd; whitelisting egress hacia api.:443
macOS: agente (patrocinio); profiles MDM para permissions y daemon
EDR/AV coexistencia: excluir rutas de agente/Mesh si el EDR lo exige

11) Comparativa con AnyDesk/TV (resumen)

Función	AnyDesk/TV	Tactical RMM (+ MeshCentral)
Control remoto	Sí (SaaS)	Sí (self-hosted)
Inventario/monitoring	No/Limitado	Sí (integrado)
Parcheo	No	Sí (políticas)
Scripts/automatización	Limitado	Sí (PS/BAT/Python/NuShell/Deno)
Alertas	No	Sí (email/SMS/Webhook)
Coste por endpoint	Sí	No
Datos/compliance	SaaS del vendor	En tu infraestructura

Estrategia de migración: convivencia 2–4 semanas, validación de remoto y UAC, script de desinstalación legado.

12) Problemas conocidos y soluciones rápidas

Let’s Encrypt rate-limit: usa wildcard DNS-01 o staging para pruebas masivas
UAC rompe remoto: ajustar MeshCentral (elevación), habilitar consent prompt
Build de agente bloqueado por AV: firmar MSI/exe; excepciones temporales
PG crece rápido: activar autovacuum agresivo en tablas events/logs; particionado por fecha si volumen alto
Alta latencia de agentes: revisar DNS/Anycast del proveedor; keepalive de NATS; latencias de red (MTR)

13) FAQ para operación

¿Se puede usar PG gestionado (RDS/Aurora/Citus)?
Sí. Reduce blast radius del host, pero añade latencia y coste. Asegura SSL, parameter group y backups.

¿Cómo limito superficie de api.?
Rate limit, WAF, mTLS opcional, IP access lists para panel (no para agentes), y origin rules en proxy.

¿Puedo multi-tenant en un solo TRMM?
Sí, por Organizaciones/Sitios. Si requieres aislamiento duro (datos/reglas), separa instancias y/o PG.

¿Cómo integro SSO?
Disponible en patrocinio (SAML/OIDC). Alternativa: SSO en MeshCentral y 2FA obligatorio en TRMM.

14) TL;DR de despliegue (comandos clave)

# Host prep
apt update && apt -y upgrade
apt -y install git curl jq ufw
curl -fsSL https://get.docker.com | sh
usermod -aG docker $USER

# Clone stack (según doc oficial) y rellenar .env
docker compose pull
docker compose up -d

# TLS y acceso
# -> https://rmm.example.com (crear admin)
# -> https://api.example.com/api/ (200)

# Backups (ejemplo PG)
pg_dump -Fc -U trmm_user trmm_db > /opt/tacticalrmm/backup/trmm_$(date +%F).dump

# Updates
docker compose pull && docker compose up -d
Lenguaje del código: PHP (php)

Cierre

Tactical RMM no sustituye a un orquestador ni a una plataforma ITSM completa; sí sustituye con solvencia el “colchón de retales” habitual (AnyDesk/TV + scripts dispersos + inventarios ad-hoc + parches manuales). Para un equipo de sistemas con cientos o pocos miles de endpoints, la combinación TRMM + MeshCentral + buenas prácticas de operación entrega control, auditoría y coste predecible. El resto —hardening, runbooks, backups y cultura de mejora continua— depende de nosotros.

vía: Revista Cloud

X (Twitter) Facebook Pinterest LinkedIn Email WhatsApp

Suscríbete al boletín SysAdmin

Este es tu recurso para las últimas noticias y consejos sobre administración de sistemas, Linux, Windows, cloud computing, seguridad de la nube, etc. Lo enviamos 2 días a la semana.

¡Apúntate a nuestro newsletter!

– patrocinadores –

Noticias destacadas