Plan2026/00-herramientas-ecosistema-administradores.md

# Ecosistema de herramientas para administradores de infraestructura Proxmox/PBS

> Guia de herramientas recomendadas para equipos que gestionan entre 100 y 500 servidores Proxmox VE, Proxmox Backup Server, y servicios asociados. Organizado por capas funcionales, de lo mas urgente a lo mas estrategico.

---

## Capa 1: Visibilidad - Si no lo ves, no existe

### 1.1 Inventario y CMDB

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Netbox** | Inventario de servidores, IPs, racks, cableado, VMs, datastores. SSOT (Single Source of Truth) de toda la infra. | 100-5000+ |
| **GLPI** | Inventario + ticketing + gestion de activos. Mas orientado a ITIL. | 100-1000 |
| **Snipe-IT** | Gestion de activos hardware (servidores fisicos, discos, tarjetas de red). Complementa a Netbox. | 100-500 |

- No olvidar: sin un inventario centralizado, a 100+ servidores no sabes que tienes, donde esta, ni que version corre. En este incidente, la documentacion en CLAUDE.md era el unico inventario, y eso no escala.

### 1.2 Monitoring de infraestructura

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Prometheus + Grafana** | Metricas de CPU, RAM, disco, red, ZFS, PBS jobs. Alertas basadas en umbrales. Stack estandar de la industria. | 100-10000+ |
| **Victoria Metrics** | Alternativa a Prometheus con menor consumo de recursos y mejor retencion a largo plazo. Drop-in compatible. | 500-10000+ |
| **pve-exporter** | Exportador Prometheus especifico para Proxmox VE. Extrae metricas de VMs, nodos, storage. | Cualquiera |
| **Zabbix** | Monitoring todo-en-uno con autodiscovery, templates para Proxmox y ZFS, alertas, mapas de red. Mas pesado pero muy completo. | 100-5000+ |
| **Uptime Kuma** | Monitoring ligero de disponibilidad (HTTP, TCP, DNS, ping). Ideal para servicios criticos. Alertas por Telegram/email. | 10-500 |
| **Checkmk** | Monitoring con agente, autodiscovery agresivo, templates de ZFS y Linux. Buena alternativa a Zabbix. | 100-5000+ |

- No olvidar: el DNS en la VM 135241 estuvo caido por disco lleno sin que nadie se enterase. A 100 servidores, esto pasa constantemente si no hay monitoring. Metricas minimas obligatorias: espacio en disco (alerta al 80%), estado de ZFS pools, estado de jobs PBS (GC, verify, sync), disponibilidad de servicios.

### 1.3 Monitoring de backups (PBS especifico)

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Proxmox Backup Metrics (influxdb)** | PBS puede enviar metricas nativas a InfluxDB. Verificar que todos los PBS estan reportando. | Cualquiera |
| **Script personalizado + Prometheus pushgateway** | Exportar estado de GC jobs, verify jobs, sync jobs, espacio por datastore, ultimo backup exitoso por VM. | 100-500 |
| **Grafana dashboards para PBS** | Dashboards dedicados: ultimo backup por cliente, jobs fallidos, ocupacion por datastore vs quota, tendencia de crecimiento. | Cualquiera |
| **Alerta "ultimo backup > 48h"** | Si una VM no tiene backup en 48h, algo esta mal. Esta alerta sola previene el 80% de los problemas de backup. | Cualquiera |

- No olvidar: gestionar 100+ PBS sin un dashboard centralizado de estado de backups es volar a ciegas. El mayor riesgo no es perder un backup, es no darte cuenta de que lo has perdido.

### 1.4 Logs centralizados

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Grafana Loki + Promtail** | Agregacion de logs ligera. Misma interfaz que Grafana para metricas. Barato en recursos. | 100-1000 |
| **Graylog** | Logs centralizados con busqueda, alertas, dashboards. Buena relacion potencia/complejidad. | 100-5000 |
| **ELK Stack (Elasticsearch + Logstash + Kibana)** | El estandar para logs a gran escala. Potente pero costoso en recursos. | 500-10000+ |
| **Vector (de Datadog)** | Recolector y router de logs ultraligero. Reemplaza a Logstash/Promtail con menor overhead. | Cualquiera |

- No olvidar: en este incidente, los logs de auth estaban solo en el servidor comprometido. Un atacante puede borrar logs locales. Con logs centralizados, aunque comprometa el servidor, la evidencia ya esta en otro sitio. Minimo centralizar: auth.log, syslog, logs de PBS, logs de firewall.

---

## Capa 2: Seguridad - Lo que nos habria salvado

### 2.1 Deteccion de intrusiones y file integrity

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **OSSEC / Wazuh** | HIDS (Host Intrusion Detection). Monitoriza cambios en ficheros, analiza logs, detecta rootkits, alerta en tiempo real. Wazuh es el fork activo con dashboard. | 100-10000+ |
| **AIDE** | File integrity monitoring. Genera una base de datos de checksums y alerta si algo cambia en /usr/bin, /etc/pam.d, etc. Ligero. | 10-500 |
| **Tripwire** | Similar a AIDE pero comercial. Version open source disponible. | 100-1000 |
| **auditd + aureport** | Auditoria del kernel de Linux. Registra quien cambio que fichero, que proceso abrio que socket. Ya viene instalado, solo hay que configurarlo. | Cualquiera |
| **Lynis** | Auditoria de seguridad y hardening. Escanea el sistema y da puntuacion con recomendaciones. Ideal para linea base. | Cualquiera |

- No olvidar: **Wazuh habria detectado este incidente en minutos**, no en 4 dias. Habria alertado al detectar: creacion de `/usr/bin/login.sh`, modificacion de `/etc/pam.d/common-auth`, creacion de `/etc/ld.so.preload`, y conexion saliente a una IP desconocida. Es la herramienta de mayor impacto para este escenario.

### 2.2 Escaneo de vulnerabilidades

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **OpenVAS / Greenbone** | Escaner de vulnerabilidades de red. Detecta servicios expuestos, CVEs, configuraciones debiles. | 100-1000 |
| **Trivy** | Escaner de vulnerabilidades para contenedores Docker, imagenes, y ficheros de configuracion. Rapido y ligero. | Cualquiera |
| **Nuclei** | Escaner de vulnerabilidades basado en templates. Miles de checks para servicios web, APIs, paneles de admin. | Cualquiera |

- No olvidar: escanear regularmente desde fuera (que ve un atacante) y desde dentro (que tiene cada servidor). Automatizar con cron semanal y alertar solo en criticos/altos.

### 2.3 Gestion de secretos y credenciales

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **HashiCorp Vault** | Gestion centralizada de secretos: contraseñas, API keys, certificados. Rotacion automatica. Audit log. | 100-10000+ |
| **Bitwarden / Vaultwarden** | Gestor de contraseñas para el equipo. Para credenciales que necesitan acceso humano (paneles web, etc). | Cualquiera |
| **SOPS (Mozilla)** | Cifrado de secretos en ficheros (YAML, JSON). Ideal para secretos en repos git. | Cualquiera |

- No olvidar: en los docker-compose encontrados habia contraseñas en texto plano (`PDNS_API_KEY=secret`, `MYSQL_ROOT_PASSWORD`). A 100+ servidores con multiples equipos, los secretos en texto plano son una bomba de relojeria.

### 2.4 Acceso y autenticacion

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Teleport** | Acceso SSH centralizado con grabacion de sesiones, MFA, RBAC, y audit log. Reemplaza SSH directo. | 50-5000+ |
| **Boundary (HashiCorp)** | Acceso seguro a servicios sin exponer la red. Session recording. Complementa Vault. | 100-5000+ |
| **FreeIPA / Keycloak** | Directorio central de usuarios, SSO, MFA. Elimina usuarios locales en cada servidor. | 100-5000+ |
| **Fail2ban** | Bloqueo automatico de IPs con intentos fallidos. Basico pero efectivo. Deberia estar en todos los servidores. | Cualquiera |
| **Yubikey / MFA hardware** | Segundo factor fisico para SSH y paneles web. Elimina el riesgo de contraseñas robadas. | Cualquiera |

- No olvidar: en este incidente, aunque la contraseña fue robada, el firewall limitaba SSH por IP. Pero si el atacante hubiera estado en una IP permitida (o si hubiera usado la contraseña en el panel web PBS:8007 que estaba abierto a todos), habria entrado. MFA habria bloqueado el acceso incluso con la contraseña robada.

---

## Capa 3: Automatizacion - Lo que mantiene la cordura a escala

### 3.1 Gestion de configuracion

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Ansible** | Automatizacion sin agente. Ideal para Proxmox: provisionar VMs, configurar PBS, desplegar reglas de firewall, aplicar hardening. Ya se usa en este entorno (clave SSH de `david@ansible`). | 10-5000+ |
| **Ansible Semaphore** | UI web para Ansible. Permite al equipo ejecutar playbooks sin acceso SSH directo. Audit log de quien ejecuto que. | 50-500 |
| **Terraform + provider Proxmox** | Infraestructura como codigo. Definir VMs, redes, storage en ficheros versionados. Reproducibilidad total. | 50-5000+ |
| **Pulumi** | Alternativa a Terraform usando lenguajes reales (Python, Go, TypeScript). Mas flexible para logica compleja. | 50-5000+ |

- No olvidar: el script `modificar.sh` es el embrion de automatizacion. A 100+ servidores, eso deberia ser un playbook de Ansible idempotente que garantice que la configuracion de cada PBS es consistente. Si un atacante modifica PAM en un servidor, el proximo run de Ansible lo revierte.

### 3.2 CI/CD para infraestructura

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Gitea / Forgejo** | Repositorio git auto-alojado para scripts, playbooks, configuraciones. No depender de GitHub para infra critica. | Cualquiera |
| **Woodpecker CI** | CI/CD ligero, auto-alojado. Ejecuta playbooks de Ansible automaticamente al hacer push. | 10-500 |
| **GitLab CE** | Repositorio + CI/CD + registry + wiki. Todo en uno. Mas pesado pero muy completo. | 50-5000+ |

- No olvidar: todos los scripts de `/root/` (modificar.sh, lista.sh, gc_jobs.sh, etc.) deberian estar en un repositorio git con versionado, code review, y despliegue automatico. Si el servidor se reinstala, se recupera toda la automatizacion.

### 3.3 Orquestacion y scheduling

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Rundeck** | Ejecucion de jobs en multiples servidores con UI, RBAC, scheduling, y audit log. Ideal para operaciones como GC masivo. | 50-1000 |
| **AWX (Ansible Tower open source)** | Interfaz web para Ansible con inventario dinamico, scheduling, RBAC. Mas completo que Semaphore. | 100-5000+ |
| **n8n** | Automatizacion de workflows (si pasa X, haz Y). Conectar alertas con acciones: si Wazuh detecta intrusion, bloquear IP en firewall. | Cualquiera |

- No olvidar: los cron jobs actuales (`pbs-gc-oldest.sh` cada 30min, `pbs-verify-oldest.sh` cada 2h) funcionan en un solo servidor. A 100+ servidores, necesitas orquestacion centralizada que distribuya los jobs, evite colisiones, y reporte resultados.

---

## Capa 4: Red y conectividad

### 4.1 VPN y acceso seguro

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **WireGuard** | VPN punto a punto ultraligera. Ideal para conectar PBS con servidores remotos por vRack o internet. Reemplaza las IPs publicas expuestas. | Cualquiera |
| **Tailscale / Headscale** | VPN mesh basada en WireGuard con zero-config. Cada servidor se une a la red. Headscale es la version self-hosted. | 10-1000 |
| **Nebula (Slack/Defined)** | Overlay network con certificados. Cada nodo tiene identidad criptografica. Muy escalable. | 100-10000+ |
| **Netbird** | VPN mesh self-hosted con SSO integration. Alternativa a Tailscale. | 50-1000 |

- No olvidar: el PBS actual tiene el puerto 8007 abierto a todo internet para recibir backups. A 100+ servidores, cada servicio de backup deberia ir por VPN privada. Reduce la superficie de ataque drasticamente.

### 4.2 DNS y service discovery

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **PowerDNS** (ya en uso) | DNS autoritativo para dominios propios. Ya desplegado en la VM 135241 como secundario. | Cualquiera |
| **CoreDNS** | DNS ligero, ideal para service discovery interno. Se integra con Consul y Kubernetes. | 50-5000+ |
| **Consul (HashiCorp)** | Service discovery + health checking + KV store. Los servicios se registran y se encuentran automaticamente. | 100-5000+ |

- No olvidar: con 100+ servidores, mantener `/etc/hosts` o DNS manual no escala. Service discovery automatico elimina errores de configuracion y permite failover automatico.

### 4.3 Proxy y balanceo

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Traefik** (ya en uso en VM) | Reverse proxy con autodiscovery Docker y Let's Encrypt automatico. Ya desplegado para los paneles DNS. | Cualquiera |
| **Nginx Proxy Manager** | Reverse proxy con UI simple. Ideal para equipos que no quieren YAML. | 10-100 |
| **HAProxy** | Balanceador de carga de alto rendimiento. Para distribuir trafico de backup entre multiples PBS. | 50-5000+ |

---

## Capa 5: Gestion de incidentes y comunicacion

### 5.1 Ticketing y alertas

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **PagerDuty / Opsgenie** | Escalado de alertas, on-call rotation, integracion con monitoring. Cuando Prometheus alerta, alguien se entera. | 50-5000+ |
| **Alertmanager (Prometheus)** | Routing de alertas: agrupar, silenciar, deduplicar. Enviar a Telegram, email, webhook, PagerDuty. | Cualquiera |
| **Zammad** | Ticketing open-source. Para que los clientes reporten problemas y el equipo los gestione con trazabilidad. | 50-1000 |
| **Mattermost** | Chat interno (alternativa a Slack). Canal de alertas, war rooms para incidentes, integracion con bots. | Cualquiera |
| **Gotify / ntfy** | Push notifications self-hosted. Para alertas criticas al movil sin depender de servicios externos. | Cualquiera |

- No olvidar: las alertas que nadie ve no sirven. El canal de alertas debe tener: niveles de severidad, escalado automatico si nadie responde en X minutos, y silenciado inteligente para evitar fatiga de alertas.

### 5.2 Documentacion operativa

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Bookstack** | Wiki self-hosted para documentacion operativa. Playbooks, runbooks, topologias de red, procedimientos. | Cualquiera |
| **Outline** | Wiki moderna con busqueda, permisos, y markdown. Alternativa a Notion self-hosted. | Cualquiera |
| **MkDocs + Material** | Documentacion como codigo. Ficheros markdown en git que generan un sitio web estatico. | Cualquiera |

- No olvidar: el CLAUDE.md de este servidor es excelente documentacion operativa. A 100+ servidores, eso deberia estar en una wiki centralizada con busqueda, no en ficheros individuales en cada servidor.

---

## Capa 6: Almacenamiento y datos

### 6.1 Gestion de ZFS a escala

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **ZFS Exporter (Prometheus)** | Metricas de pools ZFS: espacio, salud, IO, scrub status, errores. Dashboard de todos los pools en un vistazo. | Cualquiera |
| **zfswatcher** | Monitoring dedicado de ZFS con alertas por email. Detecta discos degradados, errores de checksum, scrubs fallidos. | 10-500 |
| **Sanoid / Syncoid** | Gestion automatica de snapshots ZFS y replicacion. Politicas de retencion declarativas. | Cualquiera |
| **zrepl** | Replicacion ZFS continua con push/pull. Alternativa moderna a Syncoid para replicacion entre sitios. | 10-500 |

- No olvidar: con pool9 gestionando todos los datastores de clientes, un fallo de ZFS es catastrofico. Minimo: alerta inmediata si el pool deja de estar ONLINE, alerta si un scrub encuentra errores, dashboard de ocupacion con proyeccion de cuando se llena.

### 6.2 Backup del backup

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **PBS replication (sync jobs)** | Ya en uso. Sync entre PBS servers. Pero necesita monitoring de que los syncs funcionan. | Cualquiera |
| **Restic + Minio/S3** | Backup offsite de datos criticos (configuraciones, BBDD) a object storage. Cifrado, deduplicado, barato. | Cualquiera |
| **Rclone** | Sincronizacion a cualquier cloud (S3, B2, Google, Azure). Ideal para copia offsite de backups criticos. | Cualquiera |
| **BorgBackup** | Backup deduplicado y cifrado. Alternativa a Restic. Muy maduro y fiable. | Cualquiera |

- No olvidar: el PBS tiene sync jobs mensuales desde servidores remotos. Pero quien hace backup del PBS? Si el host se pierde (ransomware, fallo hardware), se pierden todos los backups. La regla 3-2-1 aplica tambien al servidor de backups.

---

## Capa 7: Observabilidad avanzada (para +500 servidores)

### 7.1 Stack de observabilidad completo

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Grafana LGTM Stack** | Loki (logs) + Grafana (dashboards) + Tempo (traces) + Mimir (metricas). Stack unificado. | 500-10000+ |
| **Netdata** | Monitoring en tiempo real con dashboard por servidor. Muy visual, zero-config. Bueno para troubleshooting rapido. | 10-1000 |
| **Datadog / New Relic** | SaaS de observabilidad completa. Caro pero potente. Para equipos que no quieren mantener infra de monitoring. | 100-10000+ |

### 7.2 SIEM y correlacion de eventos

| Herramienta | Que resuelve | Escala |
|-------------|-------------|--------|
| **Wazuh** (repite por importancia) | SIEM + HIDS + compliance. Correlaciona eventos de multiples servidores. Detecta patrones de ataque. | 100-10000+ |
| **Security Onion** | Plataforma completa de seguridad: IDS, analisis de red, SIEM, caza de amenazas. | 100-5000 |
| **CrowdSec** | IDS colaborativo. Comparte listas de IPs maliciosas con la comunidad. Complementa Fail2ban. | Cualquiera |

---

## Priorizacion: que implementar primero

### Fase 1 - Inmediata (semana 1-2) - Supervivencia
> Detener la hemorragia y ver lo basico

1. **Wazuh** en todos los servidores (detecta intrusiones como la que encontramos)
2. **Fail2ban** en todos los servidores (ya deberia estar)
3. **Uptime Kuma** para servicios criticos (PBS, DNS, paneles)
4. **Alertas de disco** al 80% en todas las VMs y hosts
5. **Bitwarden/Vaultwarden** para el equipo (no mas contraseñas en texto plano)

### Fase 2 - Corto plazo (mes 1-2) - Fundamentos
> Visibilidad y automatizacion basica

6. **Prometheus + Grafana** con pve-exporter y ZFS exporter
7. **Grafana Loki** para logs centralizados (al menos auth.log y syslog)
8. **Netbox** para inventario de toda la infra
9. **Ansible** playbooks para hardening base (SSH, firewall, auditd)
10. **Gitea** para versionar toda la automatizacion

### Fase 3 - Medio plazo (mes 3-6) - Madurez
> Procesos y escalabilidad

11. **WireGuard/Tailscale** para trafico de backup privado
12. **Vault** para gestion de secretos
13. **Terraform** para provisionar VMs de forma reproducible
14. **Bookstack** para documentacion operativa centralizada
15. **Rundeck/AWX** para orquestacion de jobs de mantenimiento

### Fase 4 - Largo plazo (mes 6-12) - Excelencia
> Observabilidad avanzada y zero-trust

16. **Teleport** para acceso SSH centralizado con audit
17. **FreeIPA/Keycloak** para directorio central de usuarios
18. **OpenVAS** para escaneo de vulnerabilidades periodico
19. **LGTM Stack** completo si se supera los 500 servidores
20. **Security Onion** para analisis de red

---

## Resumen por necesidad

| Necesidad | Herramienta clave | Alternativa |
|-----------|------------------|-------------|
| "Me han hackeado y no me entere" | **Wazuh** | OSSEC + AIDE |
| "No se que servidores tengo" | **Netbox** | GLPI |
| "Un servicio cayo y nadie lo vio" | **Prometheus + Grafana** | Zabbix |
| "Los logs estaban solo en el servidor comprometido" | **Grafana Loki** | Graylog |
| "Contraseñas en texto plano por todos lados" | **Vault + Bitwarden** | SOPS |
| "Configuro servidores a mano y cada uno es distinto" | **Ansible** | Terraform |
| "Los backups fallan y no me entero" | **Dashboard PBS + alertas** | Script custom |
| "SSH con password abierto a internet" | **Teleport + MFA** | Fail2ban + WireGuard |
| "El disco se llena y todo cae" | **Alertas Prometheus al 80%** | Netdata |
| "No tengo documentacion de nada" | **Bookstack** | MkDocs |