703 lines
89 KiB
Markdown
703 lines
89 KiB
Markdown
# Articulos de seguridad - Lecciones aprendidas de un incidente real
|
|
|
|
> Basado en el analisis forense de un servidor Proxmox Backup Server comprometido con un credential stealer via PAM, exfiltracion de contraseñas a un C2 externo, y persistencia mediante multiples artefactos en el sistema.
|
|
|
|
---
|
|
|
|
## Bloque 1: El incidente - Que paso y como se detecto
|
|
|
|
### 1. Como un backdoor PAM puede robar todas tus contraseñas SSH sin que lo notes
|
|
- No olvidar: explicar como `pam_exec.so` con `expose_authtok` permite capturar contraseñas en texto plano y enviarlas a un servidor externo con un simple curl. Mostrar el flujo completo: usuario hace login -> PAM ejecuta script -> contraseña capturada -> enviada por HTTP al atacante.
|
|
|
|
### 2. Anatomia de un credential stealer: del curl al C2 en 5 lineas de bash
|
|
- No olvidar: desglosar linea a linea el script `login.sh` real encontrado. Explicar el base64, el exfil via HTTP con `--max-time`, el `nohup` para no bloquear el login, y la descarga y ejecucion remota de comandos (`/run | bash`). Incluir el script completo como ejemplo.
|
|
|
|
### 3. Cronica de una intrusion: timeline de un servidor PBS comprometido
|
|
- No olvidar: reconstruir la linea temporal completa del ataque. Fecha de instalacion de los artefactos (9 de marzo), primera captura de credenciales, ficheros creados progresivamente (`ld.so.preload`, `login.sh`, `daemon`, `command-port`), y momento de deteccion (13 de marzo). Resaltar los 4 dias de ventana.
|
|
|
|
---
|
|
|
|
## Bloque 2: Vectores de ataque y persistencia
|
|
|
|
### 4. ld.so.preload: la linea mas peligrosa de tu sistema Linux
|
|
- No olvidar: explicar como un atacante puede inyectar librerias maliciosas en todos los procesos del sistema mediante este fichero. Diferencia entre un rootkit de userland y uno de kernel. Como monitorizar este fichero con auditd/inotify. Que aunque este vacio, su mera existencia reciente es un indicador de compromiso.
|
|
|
|
### 5. Ficheros fantasma en /usr/bin: como detectar binarios anomalos en directorios de sistema
|
|
- No olvidar: explicar la tecnica de buscar ficheros recientes en directorios de sistema (`find /usr/bin -mtime -7`). Cubrir los distintos artefactos encontrados: ficheros de 0 bytes como marcadores (`daemon`), scripts maliciosos con nombres inocuos (`login.sh`), directorios de configuracion del malware (`/usr/local/sbin/env/`). Un binario legitimo en /usr/bin rara vez cambia fuera de actualizaciones de paquetes.
|
|
|
|
### 6. Persistencia sin cron ni systemd: tecnicas de backdoor via PAM
|
|
- No olvidar: explicar por que PAM es un vector de persistencia tan efectivo: se ejecuta en cada autenticacion, no aparece en `crontab -l`, no crea servicios visibles, y es transparente para el usuario. Comparar con otros metodos de persistencia (cron, systemd timers, rc.local, authorized_keys) y por que PAM es mas sigiloso.
|
|
|
|
### 7. El fichero de 27 bytes que anulo toda tu seguridad SSH: cloud-init y sshd_config.d
|
|
- No olvidar: mostrar como `sshd_config.d/50-cloud-init.conf` con `PasswordAuthentication yes` sobreescribe silenciosamente el `PasswordAuthentication no` del config principal. Explicar el orden de precedencia de `Include` en sshd. Recalcar que despues de cada despliegue hay que auditar los drop-ins.
|
|
|
|
### 8. Cuando el atacante ya tiene tu contraseña: por que cambiarla ANTES de limpiar
|
|
- No olvidar: recalcar que las credenciales ya estan en manos del atacante desde el momento de la captura. Limpiar el backdoor sin rotar credenciales deja la puerta abierta. Incluir checklist de rotacion: contraseña root, usuarios PBS, API tokens, claves SSH del servidor.
|
|
|
|
---
|
|
|
|
## Bloque 3: Deteccion y respuesta
|
|
|
|
### 9. Checklist forense rapido: como saber si tu servidor Linux esta comprometido en 10 minutos
|
|
- No olvidar: incluir la checklist completa usada en esta investigacion, en orden de prioridad:
|
|
1. `grep pam_exec /etc/pam.d/*`
|
|
2. `cat /etc/ld.so.preload`
|
|
3. `find /usr/bin /usr/sbin -mtime -30`
|
|
4. `awk -F: '$3==0' /etc/passwd`
|
|
5. `cat /root/.ssh/authorized_keys`
|
|
6. `crontab -l` y `/etc/cron.d/`
|
|
7. `ss -tulnp` y `ss -tnp state established`
|
|
8. `ls -la /tmp /dev/shm`
|
|
9. `ps auxf` comparado con `/proc/[0-9]*`
|
|
10. `systemctl list-unit-files --state=enabled`
|
|
|
|
### 10. Auditoria post-incidente en Proxmox: del host a las VMs
|
|
- No olvidar: explicar como extender la investigacion del host a las VMs usando `qm guest exec`. Mostrar que el guest agent de QEMU permite ejecutar comandos de auditoria dentro de las VMs sin necesidad de SSH. Verificar que la infeccion no se propago lateralmente.
|
|
|
|
### 11. Señales de alerta que no debes ignorar: IOCs de un credential stealer
|
|
- No olvidar: listar los indicadores de compromiso (IOCs) concretos encontrados: fichero `ssh_auth.log` con credenciales en base64, conexiones salientes a IPs no esperadas en puertos altos (10480), ficheros recientes en `/usr/bin` que no corresponden a ningun paquete (`dpkg -S`), directorio `env` dentro de `/usr/local/sbin/`.
|
|
|
|
### 12. Como usar dpkg --verify para detectar binarios del sistema modificados
|
|
- No olvidar: explicar que `dpkg --verify` compara los ficheros instalados con los checksums del paquete original. Si un binario de sistema fue reemplazado por el atacante, aparecera como modificado. Limitaciones: no detecta ficheros nuevos añadidos, solo modificaciones a ficheros existentes.
|
|
|
|
---
|
|
|
|
## Bloque 4: Prevencion y hardening
|
|
|
|
### 13. Firewall estricto pero comprometido: cuando la amenaza ya esta dentro
|
|
- No olvidar: mostrar que este servidor tenia un firewall bien configurado (SSH limitado por IP, politica DROP, bloqueo de puertos de mineria) y aun asi fue comprometido. El firewall perimetral no protege contra amenazas que ya lograron acceso. Capas adicionales necesarias: auditd, file integrity monitoring, deteccion de anomalias.
|
|
|
|
### 14. Hardening SSH mas alla de cambiar el puerto: guia completa para Proxmox
|
|
- No olvidar: cubrir todos los aspectos: deshabilitar password auth (y verificar que cloud-init no lo reactive), usar solo claves SSH, configurar `AllowUsers`/`AllowGroups`, limitar por IP en firewall Y en sshd_config, habilitar fail2ban, configurar auditd para cambios en sshd_config y PAM.
|
|
|
|
### 15. Monitorizar /etc/pam.d con auditd: detectar manipulaciones antes de que sea tarde
|
|
- No olvidar: proporcionar reglas de auditd concretas para vigilar cambios en `/etc/pam.d/`, `/etc/ld.so.preload`, `/usr/bin/`, `/usr/sbin/`. Incluir configuracion de alertas y como integrar con un SIEM o envio de correo.
|
|
|
|
### 16. Bloqueo de C2 y mineria: reglas de salida que todo servidor deberia tener
|
|
- No olvidar: documentar el patron de reglas OUT DROP por puertos de stratum (3333, 5555, 7777, 14433, 14444) y por IPsets de pools/C2. Explicar como añadir nuevos IOCs al firewall de Proxmox. Recalcar la importancia de politica `policy_out: DROP` con whitelist explicita.
|
|
|
|
### 17. Segmentacion de backups: por que tu PBS no deberia tener acceso general a internet
|
|
- No olvidar: un servidor de backups solo necesita trafico entrante de los clientes de backup y salida para DNS, NTP y repositorios de actualizaciones. Cualquier otra conexion saliente es sospechosa. Diseñar reglas de salida minimas para un PBS.
|
|
|
|
---
|
|
|
|
## Bloque 5: Infraestructura y operaciones
|
|
|
|
### 18. Tu servidor DNS esta caido y no lo sabes: monitorizacion de servicios criticos en Docker
|
|
- No olvidar: el caso real de disco lleno al 100% en la VM del DNS que tumbo PowerDNS sin que nadie se enterase. Configurar alertas de espacio en disco, healthchecks funcionales (el healthcheck de este PowerDNS usaba `pdns_control ping` que no funcionaba), y monitorizacion externa de resolucion DNS.
|
|
|
|
### 19. Healthchecks de Docker que mienten: cuando "unhealthy" no significa lo que crees
|
|
- No olvidar: el caso concreto donde `pdns_control ping` devolvia "Unknown command: PING" pero el servicio DNS funcionaba perfectamente. Diferencia entre healthcheck del contenedor y salud real del servicio. Como diseñar healthchecks que realmente validen la funcionalidad.
|
|
|
|
### 20. Gestion de espacio en disco para VMs con Docker: lecciones de un DNS caido
|
|
- No olvidar: calcular correctamente el espacio necesario para imagenes Docker, volumenes de datos (MariaDB), logs y espacio temporal. La VM tenia 13GB para un stack completo de DNS con base de datos. Alertas proactivas antes de llegar al 100%.
|
|
|
|
### 21. PowerDNS como secundario: errores comunes en la sincronizacion de zonas
|
|
- No olvidar: explicar los errores de SOA "Query Refused" encontrados en 3 dominios (actioestudio.com, leristextil.com, oxigendc.com). Causas comunes: ACLs en el primario, dominios eliminados sin limpiar el secundario, problemas de red. Como monitorizar la sincronizacion de zonas.
|
|
|
|
---
|
|
|
|
## Bloque 6: Cultura y procesos
|
|
|
|
### 22. Respuesta a incidentes sin panico: guia paso a paso para sysadmins
|
|
- No olvidar: documentar el proceso seguido en este incidente como ejemplo: primero investigar sin tocar nada, recopilar evidencias, identificar el alcance (host + VMs), verificar propagacion lateral, limpiar, y rotar credenciales. Enfatizar que no se debe apagar ni reinstalar antes de recopilar evidencias.
|
|
|
|
### 23. El factor tiempo: 4 dias con un backdoor activo y que hacer para reducir la ventana
|
|
- No olvidar: desde la instalacion del backdoor (9 marzo) hasta la deteccion (13 marzo) pasaron 4 dias. Cada login en ese periodo fue capturado. Herramientas y practicas para reducir el tiempo de deteccion: file integrity monitoring, auditd, revision periodica de logs, honeypots internos.
|
|
|
|
### 24. Documentar para sobrevivir: como un CLAUDE.md bien hecho acelero la respuesta al incidente
|
|
- No olvidar: el fichero CLAUDE.md del servidor contenia toda la arquitectura, comandos, y configuracion documentada, lo que permitio una investigacion rapida y contextualizada. Argumentar a favor de mantener documentacion operativa actualizada como herramienta de seguridad.
|
|
|
|
### 25. Post-mortem sin culpables: como convertir un incidente de seguridad en mejora continua
|
|
- No olvidar: estructura de un post-mortem efectivo: que paso, timeline, como se detecto, como se resolvio, que salio bien, que salio mal, acciones correctivas con responsable y fecha. El objetivo es mejorar procesos, no buscar culpables.
|
|
|
|
---
|
|
|
|
## Bloque 7: Investigacion forense avanzada
|
|
|
|
### 26. Forense en caliente vs en frio: cuando NO apagar el servidor comprometido
|
|
- No olvidar: en este caso la investigacion se hizo con el sistema en ejecucion, lo que permitio ver conexiones activas, procesos en memoria y ficheros abiertos. Si se hubiera apagado, se habria perdido evidencia volatil. Explicar cuando si conviene apagar (ransomware activo, exfiltracion masiva en curso) y cuando no.
|
|
|
|
### 27. El arte de leer /proc: detectar procesos ocultos y binarios eliminados
|
|
- No olvidar: la tecnica de comparar el conteo de `ps aux` con `ls /proc/[0-9]*` para detectar procesos ocultos. Buscar `/proc/*/exe` con "(deleted)" para encontrar malware que se borro del disco pero sigue ejecutandose en memoria. En este caso salio limpio, pero explicar que habria significado si no.
|
|
|
|
### 28. Reconstruir la actividad del atacante a traves de timestamps de ficheros
|
|
- No olvidar: usar `stat` para ver Birth/Modify/Change/Access de los artefactos. En este incidente los timestamps revelaron el orden de instalacion: primero `command-port` y `ld.so.preload` (9 mar 18:58), luego `login.sh` (9 mar 19:00), luego `daemon` (13 mar 08:55). Explicar MAC times y como interpretarlos.
|
|
|
|
### 29. Buscar al atacante: OSINT basico sobre IPs de C2 y como reportar
|
|
- No olvidar: que hacer con la IP del C2 (91.208.162.132): whois, geolocalizar, comprobar en bases de datos de amenazas (AbuseIPDB, VirusTotal, Shodan), reportar al ISP/CERT. Explicar que el puerto 10480 y el path `/run` son firma del malware que pueden usarse para buscar variantes.
|
|
|
|
### 30. Analisis de trafico de red post-incidente: que buscar en los logs del firewall
|
|
- No olvidar: revisar los logs de salida del firewall de Proxmox (log_level_out: info) para encontrar conexiones al C2 que pasaron desapercibidas. Buscar patrones: conexiones a puertos altos, transferencias pequeñas periodicas (beaconing), conexiones desde procesos inesperados.
|
|
|
|
---
|
|
|
|
## Bloque 8: Seguridad en entornos de backup
|
|
|
|
### 31. Tu servidor de backups es el objetivo mas valioso: por que los atacantes lo buscan primero
|
|
- No olvidar: un PBS comprometido da acceso a los backups de TODOS los clientes. El atacante puede robar datos historicos, inyectar ransomware en los backups, o destruirlos. Explicar por que el servidor de backup necesita el maximo nivel de hardening.
|
|
|
|
### 32. El modelo de multiplicador 6x en PBS: cuando las quotas ZFS te salvan de un desastre
|
|
- No olvidar: explicar el modelo de provisionamiento encontrado (commercial x6 quota, x5 reservation) y como las quotas ZFS limitan el impacto si un atacante intenta llenar el almacenamiento. Sin quotas, un solo datastore comprometido podria consumir todo pool9.
|
|
|
|
### 33. Aislamiento de datastores en PBS: un cliente comprometido no debe afectar a otros
|
|
- No olvidar: cada cliente tiene su propio usuario PBS con permisos DatastorePowerUser limitados a su datastore. Revisar que las ACLs estan bien configuradas. Un atacante con credenciales de un cliente no deberia poder acceder a otros datastores.
|
|
|
|
### 34. Verificacion y garbage collection: mantenimiento de PBS como herramienta de seguridad
|
|
- No olvidar: los verify jobs detectan backups corruptos que podrian indicar manipulacion. El GC recurrente libera espacio y elimina chunks huerfanos. Sin mantenimiento, un backup comprometido podria pasar desapercibido meses. Relacionar con los cron jobs encontrados en el servidor.
|
|
|
|
### 35. Sync jobs y la cadena de confianza: cuando sincronizas malware sin saberlo
|
|
- No olvidar: los sync jobs copian backups de servidores remotos. Si el servidor origen esta comprometido, los backups sincronizados pueden contener malware. Explicar como validar la integridad post-sync y la importancia de verificar los origenes.
|
|
|
|
---
|
|
|
|
## Bloque 9: Docker y contenedores en produccion
|
|
|
|
### 36. Docker en produccion sin monitoring es como conducir sin retrovisores
|
|
- No olvidar: el stack de DNS completo (PowerDNS + MariaDB + Traefik + admin panels) estaba caido sin alertas. Herramientas de monitoring para Docker: Uptime Kuma, Prometheus + cAdvisor, Watchtower para actualizaciones, y alertas por correo/Telegram.
|
|
|
|
### 37. Dimensionar discos para VMs con Docker: la regla del triple
|
|
- No olvidar: calcular espacio real necesario: imagenes base + capas overlay + volumenes de datos + logs + espacio temporal de Docker + margen del 30%. En este caso 13GB era insuficiente para el stack, 23GB resolvio el problema pero deberia planificarse desde el inicio.
|
|
|
|
### 38. Traefik como puerta de entrada: hardening del reverse proxy en tu stack Docker
|
|
- No olvidar: el stack usaba Traefik con Let's Encrypt para multiples servicios (admin DNS, phpMyAdmin, dashboard). Revisar que los paneles de administracion tengan autenticacion, que los certificados se renueven, y que las cabeceras de seguridad esten configuradas.
|
|
|
|
### 39. Secretos en docker-compose.yml: el peligro de las contraseñas en texto plano
|
|
- No olvidar: en los compose encontrados habia contraseñas en claro (`MYSQL_ROOT_PASSWORD`, `PDNS_API_KEY=secret`, etc.). Alternativas: Docker secrets, ficheros .env con permisos restrictivos, HashiCorp Vault. Nunca commitear contraseñas en repositorios.
|
|
|
|
---
|
|
|
|
## Bloque 10: Automatizacion y herramientas
|
|
|
|
### 40. Construir tu propio scanner de rootkits con bash en 100 lineas
|
|
- No olvidar: basandose en los comandos usados en esta investigacion, crear un script que automatice la deteccion de: PAM modifications, ld.so.preload, ficheros recientes en /usr/bin, usuarios UID 0 extra, authorized_keys sospechosas, conexiones a IPs externas, procesos ocultos. Publicar en GitHub.
|
|
|
|
### 41. Usar qm guest exec para auditar todas tus VMs desde el host Proxmox
|
|
- No olvidar: script que itere sobre todas las VMs con guest agent activo y ejecute el checklist de seguridad. Generar un informe por VM. Requisitos: guest agent instalado y corriendo, VMs encendidas. Limitaciones de timeout y tamaño de output.
|
|
|
|
### 42. Alertas automaticas de cambios en ficheros criticos con inotifywait
|
|
- No olvidar: configurar inotifywait para vigilar en tiempo real cambios en `/etc/pam.d/`, `/etc/ssh/sshd_config*`, `/etc/ld.so.preload`, `/usr/bin/`, `/usr/sbin/`. Enviar alerta inmediata por correo o webhook. Mas ligero que auditd para servidores pequeños.
|
|
|
|
### 43. Integrar la seguridad en tus scripts de provisionamiento: lecciones de modificar.sh
|
|
- No olvidar: el script `modificar.sh` crea datastores, usuarios y sync jobs. Deberia tambien verificar la integridad del sistema antes de operar, comprobar que PAM no esta modificado, y registrar un hash de los ficheros criticos tras cada cambio. Seguridad como parte del workflow, no como algo separado.
|
|
|
|
---
|
|
|
|
## Bloque 11: Monitoring e inventario - Decisiones de arquitectura
|
|
|
|
### 44. Por que Netbox y no GLPI: elegir CMDB para infraestructura Proxmox
|
|
- No olvidar: comparar ambas herramientas en el contexto real de gestionar 100-500 PBS/PVE. Netbox gana en IPAM, modelo de tenants/clientes, integracion nativa con Ansible y Prometheus. GLPI gana en autodiscovery con agente y ticketing integrado. Para un modelo de negocio donde ICSManager alimenta el inventario via API, Netbox es la eleccion porque su API REST es superior.
|
|
|
|
### 45. Inventario que se rellena solo: como ICSManager alimenta Netbox en el proceso comercial
|
|
- No olvidar: el flujo cliente pide recursos -> ICSManager procesa -> Netbox recibe via API -> Ansible provisiona -> Prometheus monitoriza. El inventario se genera como subproducto del proceso de venta, no como tarea manual. Incluir los custom fields especificos para PBS: commercial_size_gb, quota_gb, reservation_gb, sync_server, pbs_status. Reconciliacion con la API de Proxmox para detectar recursos no inventariados.
|
|
|
|
### 46. Checkmk nos arruino el rendimiento: lecciones de elegir herramientas de monitoring
|
|
- No olvidar: la experiencia real con Checkmk (version opensource con Nagios por debajo, consumo desmesurado de recursos). Criterios para evaluar herramientas de monitoring antes de comprometerse: consumo de recursos por agente/target, escalabilidad real probada, ecosistema de integraciones, curva de aprendizaje, coste oculto de la version enterprise. No fiarse de demos con 10 servidores cuando vas a tener 500.
|
|
|
|
### 47. VictoriaMetrics vs Prometheus: por que elegimos Victoria para 500 servidores
|
|
- No olvidar: comparativa detallada de consumo de RAM (5-10x menos), disco (7-10x menos con compresion), retencion nativa sin Thanos/Cortex, compatibilidad 100% con PromQL y todos los exporters. A 100+ servidores un Prometheus single empieza a sufrir. VictoriaMetrics single-node gestiona miles de targets sin despeinarse. MetricsQL es superset de PromQL (compatible hacia atras).
|
|
|
|
### 48. El stack de monitoring que realmente necesitas: VictoriaMetrics + Grafana + vmagent
|
|
- No olvidar: arquitectura completa con diagrama de 4 capas (exporters -> vmagent -> VictoriaMetrics -> Grafana). Explicar cada componente y por que existe. node_exporter en todos los servidores (5MB RAM), pve_exporter por cluster, pbs-exporter centralizado en multi-target. Dimensionamiento: VM de 4 vCPU, 8GB RAM, 200GB disco para 500 servidores con retencion de 1 año.
|
|
|
|
### 49. Uptime Kuma no es monitoring: donde encaja el check binario en tu stack
|
|
- No olvidar: Uptime Kuma es complementario, no sustituto. Es "vivo o muerto", no metricas. Usarlo para: checks externos de disponibilidad (PBS:8007, DNS:53, paneles web), certificados SSL a punto de expirar, pagina de status para clientes. NO usarlo para: metricas de rendimiento, alertas de disco/ZFS, estado de jobs. Evitar la trampa de pensar que con Kuma ya tienes monitoring.
|
|
|
|
### 50. pbs-exporter de natrontech: monitoring de PBS sin reinventar la rueda
|
|
- No olvidar: el exporter comunitario cubre datastores, snapshots por VM, ultimo backup por VM, host metrics, suscripcion. Modo multi-target: una instancia para N servidores PBS. Complementar con script de 40 lineas para GC/verify/sync jobs via textfile collector. Configuracion completa: usuario monitoring@pbs con Audit, API token, despliegue Docker o systemd.
|
|
|
|
### 51. Las 10 alertas que habrian evitado este desastre
|
|
- No olvidar: alertas concretas en PromQL que, de haber estado configuradas, habrian detectado los problemas encontrados:
|
|
1. Disco > 80% (habria alertado del DNS caido por disco lleno)
|
|
2. ZFS pool no ONLINE
|
|
3. PBS sin backup > 48h por datastore
|
|
4. GC no ejecutado en 3 dias
|
|
5. Verify con errores
|
|
6. Sync fallido
|
|
7. Cambio en ficheros PAM (seguridad)
|
|
8. Nuevo fichero en /usr/bin (seguridad)
|
|
9. Conexion saliente a IP no whitelisted
|
|
10. Certificado SSL expira en < 14 dias
|
|
|
|
### 52. Dashboard de capacity planning: predecir cuando se llena tu pool ZFS
|
|
- No olvidar: usar `predict_linear()` de PromQL para proyectar crecimiento. Dashboard con tendencia 12 meses, prediccion de llenado por pool y por datastore, deteccion de clientes con quotas sobredimensionadas (oportunidad de reclamar espacio), y resumen comercial (GB vendidos vs GB reales usados vs quota asignada con ratio 6x).
|
|
|
|
### 53. Tres dashboards de Grafana que todo equipo PBS necesita
|
|
- No olvidar: diseño concreto de cada dashboard con mockups ASCII:
|
|
1. **NOC/pantalla grande**: estado global, datastores con problemas, jobs del dia
|
|
2. **Operaciones por datastore**: espacio, quota, dedup ratio, estado de cada job, snapshots recientes
|
|
3. **Management/capacity**: tendencias, prediccion, oportunidades de optimizacion, resumen comercial
|
|
|
|
---
|
|
|
|
## Bloque 12: Tecnicas de respuesta y contencion
|
|
|
|
### 54. chattr +i como trampa: usar ficheros inmutables para bloquear la reinstalacion de malware
|
|
- No olvidar: la tecnica real usada por el equipo en este incidente. Crear `/usr/bin/daemon` vacio con `chattr +i` (inmutable) para que el malware no pueda recrear el binario. El fichero actua como trampa: si alguien intenta escribirlo, falla, y si se intenta borrar, tambien falla. Util como medida de contencion mientras se investiga. Limitaciones: el atacante con root puede hacer `chattr -i`.
|
|
|
|
### 55. Verificar la limpieza: checklist post-remediacion para confirmar que no queda nada
|
|
- No olvidar: el proceso completo de re-auditoria tras la limpieza. No basta con borrar los ficheros conocidos: hay que reverificar PAM, SSH config, authorized_keys, crontabs, systemd units, procesos, conexiones, kernel modules. Comparar con la auditoria original. Incluir la tabla de estado (eliminado/limpio/pendiente) usada en este incidente.
|
|
|
|
### 56. Cuando dpkg --verify te miente: falsos positivos y como interpretarlos
|
|
- No olvidar: en este incidente, `/usr/bin/gzip` aparecia como modificado en `dpkg --verify`. La investigacion revelo que era un wrapper legitimo hacia `pigz` (compresion paralela). Explicar como distinguir modificaciones maliciosas de personalizaciones legitimas: revisar el contenido, comprobar timestamps, verificar si hay razon operativa. No entrar en panico, investigar.
|
|
|
|
### 57. El PBS:8007 abierto al mundo: cuando un puerto de backup se convierte en superficie de ataque
|
|
- No olvidar: en el firewall del servidor, el puerto 8007 de PBS estaba abierto a todas las IPs (`IN ACCEPT -p tcp -dport 8007`) para recibir backups de clientes. Esto expone la API de PBS a internet. Aunque requiere autenticacion, es un vector para fuerza bruta, CVEs futuros, o credenciales robadas (como en este caso). Alternativa: VPN o whitelist de IPs de clientes.
|
|
|
|
---
|
|
|
|
## Bloque 13: Gestion de DNS e infraestructura auxiliar
|
|
|
|
### 58. Tu servidor DNS es una VM de 13GB: dimensionamiento real de servicios criticos
|
|
- No olvidar: la VM del DNS (ns1.docloud.com) tenia 13GB de disco para un stack Docker completo (PowerDNS + MariaDB + Traefik + phpMyAdmin + admin panels + Homepage). Se lleno al 100% y todo cayo. Regla practica para Docker: imagenes + datos + logs + overlay + 30% margen. Para un stack de DNS con BBDD: minimo 25-30GB. Alertar al 80%.
|
|
|
|
### 59. PowerDNS en Docker: arquitectura de un DNS autoritativo secundario
|
|
- No olvidar: documentar la arquitectura real encontrada: MariaDB como backend, PowerDNS auth como secundario sincronizando zonas desde primario (51.254.111.145), Traefik como reverse proxy para paneles admin con Let's Encrypt, PowerDNS Admin para gestion web. Red Docker `pdns_network` compartida. Lecciones: separar datos (volumenes) de servicios, no exponer phpMyAdmin sin autenticacion fuerte.
|
|
|
|
### 60. Investigar dentro de VMs sin SSH: qm guest exec como herramienta forense
|
|
- No olvidar: en este incidente se uso `qm guest exec` para auditar la VM del DNS sin necesidad de SSH (que podria estar comprometido). El guest agent de QEMU permite ejecutar comandos arbitrarios dentro de la VM desde el host. Requisitos: qemu-guest-agent instalado y corriendo, VM encendida. Limitaciones: timeout de comandos, tamaño de output, no interactivo. Ideal para: verificar infeccion, comprobar servicios, diagnosticar problemas de disco.
|
|
|
|
---
|
|
|
|
## Bloque 14: De scripts artesanales a infraestructura como codigo
|
|
|
|
### 61. De modificar.sh a Ansible: evolucion natural de la automatizacion en PBS
|
|
- No olvidar: el script `modificar.sh` encontrado hace todo lo necesario (ZFS, datastore, usuario, password, ACL, sync job, verify job) pero es un script bash monolitico en /root. A 100+ servidores, esto deberia ser un playbook Ansible idempotente versionado en git. Mostrar la transformacion paso a paso, manteniendo la logica de negocio (multiplicador 6x, scheduling aleatorio de sync).
|
|
|
|
### 62. El peligro de los scripts en /root: por que versionar tu automatizacion
|
|
- No olvidar: todos los scripts operativos (modificar.sh, lista.sh, gc_jobs.sh, verify_jobs.sh, status_disk.sh) estaban en /root sin control de versiones. Si el servidor se pierde, se pierde toda la operativa. Si un tecnico modifica un script y rompe algo, no hay rollback. Solucion: Gitea/Forgejo + Ansible + CI/CD. El coste de no versionar es mayor que el de configurar git.
|
|
|
|
### 63. Netbox como fuente de verdad para Ansible: inventario dinamico para PBS
|
|
- No olvidar: con el plugin `netbox.netbox.nb_inventory`, Ansible genera su inventario directamente desde Netbox. Cuando ICSManager crea un cliente en Netbox, Ansible lo ve automaticamente en el proximo run. Custom fields de Netbox (quota, sync_server, pve_host) se convierten en variables de Ansible. Elimina ficheros de inventario manuales y el riesgo de desincronizacion.
|
|
|
|
---
|
|
|
|
## Bloque 15: Logs centralizados - Decisiones de arquitectura
|
|
|
|
### 64. Tus logs locales no valen nada si el atacante tiene root
|
|
- No olvidar: en este incidente, el backdoor escribia credenciales robadas en `/var/log/ssh_auth.log`. Ese fichero estaba solo en el servidor comprometido. Si el atacante lo hubiera borrado (trivial con root), no habria quedado evidencia. Los logs deben salir del servidor en tiempo real a un destino que el atacante no controle. Esta es la razon numero uno para centralizar logs.
|
|
|
|
### 65. Grafana Loki vs Graylog vs ELK: por que elegimos Loki para 500 servidores
|
|
- No olvidar: la decision se basa en que ya tenemos Grafana y VictoriaMetrics. Loki se integra nativamente en el mismo panel. Graylog requiere Elasticsearch + MongoDB (7GB RAM minimo) y es otra UI separada. ELK necesita 16GB+ de RAM y es matar moscas a cañonazos a esta escala. Loki no indexa contenido (solo labels), lo que lo hace 5-10x mas ligero. LogQL es similar a PromQL, misma curva de aprendizaje.
|
|
|
|
### 66. Grafana Alloy: un solo agente para logs y metricas en cada servidor
|
|
- No olvidar: Alloy reemplaza a Promtail (solo logs) y puede reemplazar tambien a node_exporter y vmagent. Un unico agente que consume 30-50MB de RAM por servidor. Comparar con Checkmk agent (200-500MB). Configuracion en formato River. Estrategia: empezar con Alloy solo para logs, expandir a metricas cuando el equipo este comodo.
|
|
|
|
### 67. Que logs centralizar primero: la piramide de prioridades
|
|
- No olvidar: no centralizar todo el dia 1. Prioridad 1 (dia 1): auth.log y syslog (seguridad basica). Prioridad 2 (semana 1): firewall PVE, PBS logs, dpkg.log. Prioridad 3 (mes 1): Docker logs de VMs, cron logs, Proxmox cluster logs. Empezar con lo que habria detectado el incidente y expandir.
|
|
|
|
### 68. LogQL para sysadmins: las 10 consultas que usaras todos los dias
|
|
- No olvidar: consultas practicas reales:
|
|
1. Logins SSH exitosos con IP de origen
|
|
2. Intentos fallidos con top IPs
|
|
3. Paquetes instalados/eliminados
|
|
4. Conexiones bloqueadas por firewall
|
|
5. Errores en PBS jobs
|
|
6. Busqueda libre en un servidor en ventana de tiempo
|
|
7. Correlacion temporal con metricas
|
|
8. Conteo de eventos por label (rate)
|
|
9. Parseo de campos con pattern matching
|
|
10. Alertas sobre patrones en logs
|
|
|
|
### 69. Alertas sobre logs: las reglas que habrian pillado el backdoor en minutos
|
|
- No olvidar: alertas concretas en LogQL que habrian detectado este incidente:
|
|
- Login desde IP fuera de la whitelist de `red_tecnicos`
|
|
- Aparicion de `pam_exec` en syslog (el backdoor se registro en PAM)
|
|
- Instalacion de paquetes fuera de ventana de mantenimiento
|
|
- Mas de 10 intentos fallidos de SSH en 5 minutos
|
|
- Cualquier referencia a IPs del C2 en logs de firewall
|
|
Incluir las reglas YAML completas listas para copiar y pegar.
|
|
|
|
### 70. Dimensionar Loki: cuanto disco necesitas para 500 servidores durante un año
|
|
- No olvidar: Loki comprime agresivamente (5-10x). 500 servidores generan ~25GB/dia de logs raw, que Loki comprime a ~3-5GB/dia. 30 dias de retencion = ~150GB. 90 dias = ~450GB. 1 año = ~1.5TB. Backend recomendado: filesystem local para empezar, migrar a Minio/S3 para retencion larga. Retencion diferenciada: auth.log 90 dias, syslog 30 dias, dpkg.log 180 dias.
|
|
|
|
### 71. El diagrama completo: como encajan Netbox, VictoriaMetrics, Loki y Grafana
|
|
- No olvidar: diagrama de arquitectura del stack completo decidido. Netbox (SSOT) alimentado por ICSManager. VictoriaMetrics (metricas) con vmagent, node_exporter, pbs-exporter, pve_exporter. Loki (logs) con Alloy en cada servidor. Grafana como UI unica para todo. Alertas a Telegram/email. VM de monitoring: 4 vCPU, 8GB RAM, 400GB disco. Impacto por servidor de produccion: ~50MB RAM.
|
|
|
|
---
|
|
|
|
## Anexos sugeridos
|
|
|
|
### A. Script de auditoria rapida para servidores Linux
|
|
- No olvidar: compilar todos los comandos de deteccion usados en este incidente en un script ejecutable que genere un informe automatico.
|
|
|
|
### B. Plantilla de reglas de firewall para Proxmox Backup Server
|
|
- No olvidar: incluir la configuracion de firewall completa recomendada con politica DROP, whitelist de servicios necesarios, y bloqueo de puertos de mineria/C2.
|
|
|
|
### C. Playbook de respuesta a incidentes para infraestructura Proxmox
|
|
- No olvidar: checklist imprimible con los pasos de investigacion, contencion, erradicacion y recuperacion adaptados a entornos Proxmox con PBS.
|
|
|
|
---
|
|
|
|
## Bloque 16: Seguridad como capa de infraestructura - Decisiones de arquitectura
|
|
|
|
### 72. Wazuh: el guardaespaldas que habria cortado el incidente en minutos
|
|
- No olvidar: desglosar exactamente que habria detectado Wazuh y en cuanto tiempo: creacion de `login.sh` (FIM, segundos), modificacion de PAM (FIM, segundos), `ld.so.preload` (rootkit check, segundos), conexion saliente al C2 (log analysis, minutos). El incidente duro 4 dias. Con Wazuh habria durado minutos. Incluir la configuracion FIM concreta para paths de PBS/Proxmox con realtime=yes y report_changes=yes.
|
|
|
|
### 73. Reglas custom de Wazuh para detectar backdoors PAM en Proxmox
|
|
- No olvidar: las 4 reglas XML creadas especificamente para este tipo de ataque: deteccion de pam_exec en ficheros PAM (level 15), deteccion de ld.so.preload (level 15), fichero nuevo en /usr/bin (level 12), curl sospechoso con nohup (level 10). Explicar los niveles de severidad, como se encadenan con sids, y como probarlas antes de ponerlas en produccion.
|
|
|
|
### 74. auditd como caja negra: el registro que el atacante no puede borrar (si lo envias fuera)
|
|
- No olvidar: las reglas de auditd concretas para PBS: monitorizar PAM (-w /etc/pam.d/ -p wa -k pam_changes), SSH config, authorized_keys, crontabs, binarios de sistema, ejecucion de curl/wget/base64. auditd registra pero NO alerta: por eso es complemento de Wazuh, no sustituto. Si los logs de auditd se envian a Loki en tiempo real, el atacante no puede borrar la evidencia.
|
|
|
|
### 75. Wazuh + Grafana vs Wazuh Dashboard: por que la seguridad merece su propio panel
|
|
- No olvidar: dos opciones de visualizacion. Opcion 1: Wazuh Dashboard (OpenSearch) con modulos especializados de seguridad, requiere 4GB RAM extra pero ofrece la mejor experiencia de analisis. Opcion 2: enviar alertas a Loki y verlas en Grafana junto con metricas y logs, ahorra RAM pero pierde dashboards especializados. Recomendacion: empezar con Dashboard propio. Las alertas criticas van a Telegram igualmente.
|
|
|
|
### 76. Escaneo de vulnerabilidades en 4 capas: de Wazuh a OpenVAS
|
|
- No olvidar: piramide de escaneo con herramienta y frecuencia para cada capa: Wazuh vuln detection (paquetes, continuo), Trivy (imagenes Docker, tras cada pull), Nuclei (servicios web como PBS:8007/PVE:8006/PowerDNS Admin, semanal), OpenVAS (red completa, mensual). No empezar por OpenVAS: es lo mas pesado y lo menos urgente. Wazuh ya cubre el 70% del dia 1.
|
|
|
|
### 77. Vaultwarden en 30 minutos: eliminar contraseñas compartidas por chat
|
|
- No olvidar: despliegue real con docker-compose (un contenedor, 256MB RAM). Configuracion con SIGNUPS_ALLOWED=false tras crear las cuentas iniciales. Que meter primero: contraseñas de root de PBS, usuarios PBS de clientes, API tokens, accesos a paneles PVE, credenciales de Netbox/Grafana. Audit log: quien accedio a que secreto y cuando. Comparar con la alternativa de "el password esta en un .txt en el Telegram del equipo".
|
|
|
|
### 78. De .env a HashiCorp Vault: la ruta evolutiva de gestion de secretos
|
|
- No olvidar: tres fases de madurez. Fase 0 (actual): contraseñas en docker-compose y scripts. Fase 1 (inmediata): ficheros .env con chmod 600 fuera del repo git. Fase 2 (cuando Ansible este en produccion): HashiCorp Vault con secretos que Ansible lee dinamicamente, rotacion automatica de API tokens, PKI interna para certificados. No saltar a Vault antes de tener Ansible funcionando.
|
|
|
|
### 79. SSH hardening como playbook de Ansible: lo que se aplica el dia 1 en todos los servidores
|
|
- No olvidar: el playbook concreto con las 8 directivas criticas: PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin prohibit-password, MaxAuthTries 3, LoginGraceTime 30, AllowUsers, neutralizacion de cloud-init (99-ssh-hardening.cfg con ssh_pwauth: false), instalacion de Fail2ban. Este playbook es lo primero que se ejecuta contra cada servidor nuevo. Incluir el gotcha de cloud-init que reactiva password auth.
|
|
|
|
### 80. CrowdSec vs Fail2ban: inteligencia colaborativa contra ataques
|
|
- No olvidar: Fail2ban es reactivo y local (solo tu ves tus ataques). CrowdSec es proactivo y colaborativo (bloqueas IPs que atacan a otros antes de que te ataquen a ti). No se excluyen: Fail2ban como primera linea inmediata, CrowdSec como segunda linea con threat intelligence. Despliegue con 3 comandos. Collections especificas: crowdsecurity/sshd, crowdsecurity/linux. Metricas exportables a Prometheus.
|
|
|
|
### 81. TOTP en Proxmox y PBS: MFA que ya tienes y no usas
|
|
- No olvidar: tanto PVE como PBS tienen TOTP integrado de serie. Solo hay que habilitarlo por usuario en la GUI. No requiere instalar nada. Protege contra el escenario exacto de este incidente: contraseña robada pero el atacante no puede usarla sin el segundo factor. Incluir paso a paso de activacion y que hacer si pierdes el dispositivo TOTP (recovery keys).
|
|
|
|
### 82. Teleport: cuando el equipo crece y SSH directo ya no escala
|
|
- No olvidar: a 3 tecnicos con acceso SSH directo funciona. A 10+ tecnicos necesitas saber quien hizo que, en que servidor, y cuando. Teleport centraliza todo el acceso SSH con grabacion de sesiones (puedes "reproducir" lo que hizo cada tecnico), MFA obligatorio, RBAC (junior solo ve, senior modifica), y audit completo. Evaluar a partir de 5+ personas o si hay requisitos de compliance (ISO 27001).
|
|
|
|
### 83. Dimensionar la seguridad: cuanto cuesta en recursos proteger 500 servidores
|
|
- No olvidar: desglose completo de recursos. VM Wazuh: 4 vCPU, 8GB RAM, 100GB disco (separada de monitoring). Wazuh agent por servidor: 50-100MB RAM. Vaultwarden: contenedor Docker, 256MB RAM. CrowdSec por servidor: 50MB RAM. Fail2ban: 30MB RAM. auditd: ya instalado, 0 extra. Total overhead por servidor de produccion: ~200MB RAM. VM adicional de seguridad: 4 vCPU, 8GB RAM. Comparar con el coste de otro incidente (4 dias de backdoor activo).
|
|
|
|
---
|
|
|
|
## Bloque 17: Vulnerabilidades, secretos y SSO - Decisiones de arquitectura
|
|
|
|
### 84. Wazuh vulnerability detection: el escaner de CVEs que ya tienes y no sabias
|
|
- No olvidar: si ya tienes Wazuh desplegado (2.1), el modulo de vulnerability detection viene incluido. Escanea paquetes instalados contra NVD y Debian Security de forma continua. Cuando sale un CVE nuevo que afecta a un paquete en tus servidores, te avisa automaticamente. Cubre el 70% del escaneo de vulnerabilidades sin esfuerzo adicional. Mostrar ejemplo real de alerta: "CVE-2024-XXXX afecta a openssh-server 9.2p1 en ns31787946".
|
|
|
|
### 85. Trivy para Docker: escanear antes de desplegar, no despues de llorar
|
|
- No olvidar: cada imagen Docker es un sistema operativo en miniatura con sus propias vulnerabilidades. `trivy image mariadb:latest` te dice en 5 segundos que CVEs tiene. El caso real del stack de DNS: PowerDNS + MariaDB + Traefik, cada imagen con su set de vulnerabilidades. Integrar en el workflow: antes de `docker compose up`, ejecutar `trivy`. En CI/CD (Forgejo Actions): bloquear despliegue si hay CVEs criticos.
|
|
|
|
### 86. Nuclei: auditar tus paneles web antes de que lo haga otro
|
|
- No olvidar: PBS:8007, PVE:8006, PowerDNS Admin, phpMyAdmin, Grafana, Netbox... todos son paneles web accesibles por red. Nuclei tiene miles de templates que prueban cabeceras de seguridad, endpoints expuestos, configuraciones por defecto, CVEs conocidos de cada software. Ejemplo real: escanear PBS:8007 abierto a internet y ver que encuentra. Programar semanal con Semaphore y alertar solo en criticos/altos.
|
|
|
|
### 87. VMs Windows de clientes: monitoring sin gestion, responsabilidad sin culpa
|
|
- No olvidar: modelo de responsabilidad en hosting Proxmox. Las VMs Linux las gestionais vosotros (Wazuh agent, hardening, parches). Las VMs Windows las administra el cliente. Pero cuando el Windows "se desmadra" (mineria, ransomware, DDoS), vienen a vosotros. Que monitorizar desde fuera sin tocar dentro: trafico anomalo desde el host, consumo de recursos, disponibilidad (Uptime Kuma). Como detectar mineria desde una VM sin agente: patron de trafico a puertos stratum, CPU sostenido al 100% visto desde el hipervisor.
|
|
|
|
### 88. Custodiar secretos vs reducir secretos: por que necesitas ambas estrategias
|
|
- No olvidar: custodiar (Vaultwarden) protege los secretos que existen. Reducir (SSO con Authentik) elimina secretos innecesarios. Con 50 contraseñas distintas, aunque esten en Vaultwarden, cada una es un vector de ataque. Con SSO, pasas a 1 credencial + MFA que abre todo. Las dos estrategias son complementarias: SSO para el dia a dia, Vaultwarden para los secretos residuales (API tokens, root de emergencia, credenciales de clientes).
|
|
|
|
### 89. Authentik: SSO y MFA centralizado para toda tu infraestructura Proxmox
|
|
- No olvidar: Authentik como Identity Provider que unifica el acceso a PVE (OpenID nativo desde PVE 7), PBS (OpenID nativo), Grafana (OAuth2), Netbox (OAuth2), Forgejo (OAuth2), Semaphore (OIDC), Wazuh Dashboard (SAML), Vaultwarden (SSO nativo). Para apps sin SSO nativo (Uptime Kuma, phpMyAdmin), Authentik actua como proxy de autenticacion. Un tecnico, una cuenta, un MFA, acceso a todo. Baja de la empresa = desactivar una cuenta, no 50.
|
|
|
|
### 90. Authentik primero: por que el Identity Provider se despliega antes que todo lo demas
|
|
- No olvidar: leccion aprendida en la planificacion. Si despliegas Grafana, Netbox, Forgejo con contraseñas locales y luego añades Authentik, tienes que reconfigurar cada servicio. Si despliegas Authentik primero (dia 1 del servidor nuevo), cada servicio nace ya con SSO. El orden correcto para infraestructura desde cero: Forgejo (git) -> Authentik (identidad) -> todo lo demas ya con SSO. Aplicable a cualquier migracion de infra.
|
|
|
|
### 91. Proxmox VE y PBS con OpenID Connect: eliminar contraseñas locales de los paneles
|
|
- No olvidar: tanto PVE como PBS soportan OpenID Connect de serie. Configurar Authentik como proveedor, crear realm OIDC en PVE/PBS, y los tecnicos entran con su cuenta centralizada + MFA. Las cuentas locales (`root@pam`) se mantienen solo para emergencias (password en Vaultwarden). Paso a paso completo de la integracion con capturas.
|
|
|
|
### 92. La ruta de .env a HashiCorp Vault pasando por Authentik
|
|
- No olvidar: evolucion completa de gestion de secretos en 4 fases. Fase 0 (actual): passwords en docker-compose y scripts. Fase 1 (dia 1): ficheros .env con chmod 600 + Vaultwarden para el equipo. Fase 2 (mes 1): Authentik SSO reduce de 50 a ~10 secretos residuales. Fase 3 (mes 6+): HashiCorp Vault para secretos de maquinas (Ansible, CI/CD, rotacion automatica). Cada fase es independiente y aporta valor sin necesitar la siguiente.
|
|
|
|
### 93. Infraestructura desde cero: el orden optimo para desplegar 15 servicios en una semana
|
|
- No olvidar: documentar el orden real de despliegue decidido para el servidor nuevo, basado en dependencias. Dia 1: Forgejo + Authentik + Vaultwarden (fundacion). Dia 2: Wazuh + VictoriaMetrics + Grafana (visibilidad). Dia 3: Loki + Alloy + Netbox (observabilidad). Dia 4: Semaphore + playbooks base (automatizacion). Cada servicio nace con SSO, logs centralizados, y monitoring desde el minuto 0. Comparar con el enfoque clasico de "primero funcionar, luego securizar".
|
|
|
|
---
|
|
|
|
## Bloque 18: Acceso SSH y bastion - Decisiones de arquitectura
|
|
|
|
### 94. Por que descartamos Teleport: cuando el open source no es tan open
|
|
- No olvidar: Teleport Community es AGPL-3.0, que no es lo mismo que Apache o MIT. Sigue el patron de empresas que empiezan open y migran features a enterprise (HashiCorp/Terraform, Redis, MongoDB). Ademas requiere un cliente propietario (`tsh`) en vez de SSH estandar, lo que complica Ansible y el workflow diario. Alternativa: bastion SSH puro con grabacion, usando herramientas estandar que llevan 20 años funcionando y no cambian de licencia.
|
|
|
|
### 95. Bastion SSH con grabacion: toda sesion registrada con SSH estandar
|
|
- No olvidar: el bastion es una VM minima (1 vCPU, 1GB RAM) que actua como punto unico de entrada SSH. Usa `ForceCommand` con `script`/`asciinema` para grabar cada sesion completa (teclas, output, timing). Las grabaciones van a Loki para busqueda centralizada. Los servidores destino solo aceptan SSH desde la IP del bastion (iptables DROP al resto). No hay forma de saltarse el bastion. Todo con OpenSSH estandar, sin clientes especiales.
|
|
|
|
### 96. ProxyJump (-J): la feature de SSH que cambia las reglas del juego
|
|
- No olvidar: OpenSSH `ProxyJump` (flag `-J`) permite usar un bastion de forma totalmente transparente. Disponible desde OpenSSH 7.3 (2016), funciona en Linux, macOS, Windows 10/11, iTerm, MobaXterm, WinSCP. Configurando `~/.ssh/config` con `ProxyJump bastion` una sola vez, el tecnico escribe `ssh servidor.infra` y el salto es invisible. Ansible funciona sin cambios. SCP funciona sin cambios. Es SSH normal al 100%.
|
|
|
|
### 97. SSH solo desde el bastion: como blindar el acceso con una regla de firewall
|
|
- No olvidar: la regla mas simple y mas efectiva: `iptables -A INPUT -p tcp --dport 22 -s IP_BASTION -j ACCEPT` + `iptables -A INPUT -p tcp --dport 22 -j DROP`. Se aplica via Ansible a cada servidor nuevo. Resultado: aunque un atacante tenga la clave SSH, no puede conectar directamente a ningun servidor. Tiene que pasar por el bastion, que graba todo. Combinar con Fail2ban y CrowdSec en el propio bastion.
|
|
|
|
### 98. Fail2ban + CrowdSec: defensa reactiva y proactiva combinadas
|
|
- No olvidar: Fail2ban es reactivo y local (banea IPs que fallan contra TU servidor). CrowdSec es proactivo y colaborativo (banea IPs que atacan a OTROS antes de que te ataquen a ti). No se excluyen, se complementan. Fail2ban como primera linea inmediata (dia 1), CrowdSec como segunda linea con threat intelligence (semana 2). CrowdSec exporta metricas a Prometheus, asi que aparece en vuestros dashboards de Grafana.
|
|
|
|
### 99. El flujo completo de acceso de un tecnico: de Authentik al servidor pasando por el bastion
|
|
- No olvidar: documentar el flujo completo end-to-end. Paneles web: tecnico → Authentik SSO → MFA → acceso a PVE/PBS/Grafana/Netbox. SSH: tecnico → ssh servidor.infra → transparente via bastion → sesion grabada → auditd registra dentro → Wazuh vigila. Secretos: tecnico → Vaultwarden (SSO via Authentik) → buscar credencial de cliente. Un solo tecnico, una cuenta, visibilidad total de todo lo que hace.
|
|
|
|
### 100. Windows de clientes en tu infraestructura: responsabilidad sin culpa
|
|
- No olvidar: modelo de responsabilidad claro. VMs Linux: gestionadas por nosotros (Wazuh, hardening, parches). VMs Windows: administradas por el cliente. Pero cuando "se desmadran" vienen a nosotros. Que podemos ver sin tocar dentro: trafico anomalo desde el hipervisor (mineria, C2, DDoS), consumo de recursos, disponibilidad (Uptime Kuma). Detectar mineria desde fuera: patron de trafico a puertos stratum, CPU al 100% sostenido visto desde PVE. Documentar limites de responsabilidad en contrato.
|
|
|
|
---
|
|
|
|
## Bloque 19: Automatizacion - De scripts en /root a infraestructura como codigo
|
|
|
|
### 101. Por que Ansible y no Terraform cuando tus servidores son permanentes
|
|
- No olvidar: Terraform/OpenTofu/Pulumi brillan cuando creas y destruyes infraestructura continuamente (cloud, entornos efimeros, CI/CD). Si tus servidores son fisicos dedicados con VMs que viven meses o años, Ansible cubre el 100%: configura lo que ya existe, no necesita crear y destruir. Descartar Terraform no es ignorancia, es saber cuando NO usarlo. Si algun dia necesitais crear 50 VMs identicas de golpe, reevaluar.
|
|
|
|
### 102. Ansible sin experiencia: la ruta de aprendizaje para sysadmins que ya saben SSH
|
|
- No olvidar: si ya sabes hacer `ssh servidor apt upgrade`, ya sabes el 30% de Ansible. Ruta realista: semana 1 (inventario estatico + primer playbook apt upgrade), semana 2 (copiar playbook de hardening SSH ya preparado + aprender roles), semana 3 (Semaphore para ejecutar desde navegador), semana 4 (inventario dinamico Netbox). No intentar automatizar todo el dia 1. Empezar con lo que ya se sabe y crecer.
|
|
|
|
### 103. El playbook bootstrap-server: un comando para que un servidor nazca seguro
|
|
- No olvidar: el primer playbook real no es para servidores existentes, es para preparar cada servidor nuevo antes de recibir VMs. Un solo `ansible-playbook bootstrap-server.yml` ejecuta en secuencia: hardening SSH + Fail2ban + CrowdSec + Wazuh agent + auditd + node_exporter + Alloy + firewall SSH-solo-bastion + Lynis baseline. El servidor nace seguro, monitorizado, con logs centralizados. Comprar con el enfoque manual: 2 horas de checklist vs 5 minutos de playbook.
|
|
|
|
### 104. Semaphore: Ansible con boton para el equipo que no quiere terminal
|
|
- No olvidar: Semaphore es una UI web para Ansible. El junior pulsa "Ejecutar hardening", Semaphore lanza el playbook, muestra el resultado, y queda en el audit log. Sin necesidad de saber sintaxis de ansible-playbook. Con SSO de Authentik (misma cuenta que todo). Scheduling integrado (reemplaza cron jobs). Notificaciones por webhook a Telegram si un playbook falla. 512MB RAM, un contenedor Docker. La API REST permite integracion con ICSManager para provisionamiento automatico.
|
|
|
|
### 105. Semaphore API + ICSManager: cuando el comercial vende y el servidor se provisiona solo
|
|
- No olvidar: flujo completo end-to-end: comercial vende 100GB de backup → ICSManager llama API Netbox (crea device + custom fields) → ICSManager llama API Semaphore (lanza playbook pbs-customer.yml con variables) → Ansible crea dataset ZFS, datastore PBS, usuario, ACL, sync job, verify job → Semaphore reporta OK → facturacion activa el servicio. Ningun tecnico interviene. Todo con audit log. El script `modificar.sh` de /root transformado en un flujo automatico empresarial.
|
|
|
|
### 106. Forgejo que ya tienes: ampliar el git de desarrollo a infraestructura
|
|
- No olvidar: si ya teneis Forgejo para proyectos de desarrollo, no hay que desplegar nada nuevo para infraestructura. Solo crear repos nuevos: `infra/ansible-playbooks`, `infra/pbs-scripts` (migrar de /root), `infra/monitoring-config`, `infra/docker-stacks`. Si el servidor se pierde, toda la operativa se recupera con `git clone`. Activar branch protection en main + review obligatorio para repos de infra: nadie modifica un playbook de hardening sin que otro lo revise.
|
|
|
|
### 107. Forgejo Actions: CI/CD para infraestructura sin salir del ecosistema
|
|
- No olvidar: Forgejo Actions es compatible con GitHub Actions. Con un runner self-hosted, cada push a un playbook ejecuta ansible-lint automaticamente (valida sintaxis antes de aplicar). Evita el "lance el playbook y rompio 50 servidores por un typo en YAML". No hace falta Jenkins ni GitLab CI. Empezar con lint automatico, evaluar deploy automatico cuando el equipo tenga confianza.
|
|
|
|
### 108. Branch protection: el code review que habria evitado romper produccion
|
|
- No olvidar: un playbook de Ansible con un error puede dejar 500 servidores sin SSH. Branch protection en Forgejo (gratis, ya integrado): nadie hace push directo a main, todo va por pull request, al menos 1 persona revisa antes de mergear. Combinado con ansible-lint en CI, los errores se pillan antes de tocar produccion. Coste: 0 euros, 5 minutos de configuracion. Beneficio: no romper 500 servidores a la vez.
|
|
|
|
### 109. Git como backup de tu operativa: si pierdes el servidor no pierdes los scripts
|
|
- No olvidar: todos los scripts de /root (modificar.sh, lista.sh, gc_jobs.sh, verify_jobs.sh, status_disk.sh, enable-maintenance.sh, disable-maintenance.sh) existen solo en un servidor sin control de versiones. Si ese servidor muere, se pierde toda la operativa. Moverlos a Forgejo es un backup inmediato. Si un tecnico modifica un script y rompe algo, `git revert` en 5 segundos. Si quieres saber que cambio y cuando, `git log`. Coste: 1 hora de trabajo. No hay excusa.
|
|
|
|
---
|
|
|
|
## Bloque 20: Orquestacion de jobs y cierre de Capa 3
|
|
|
|
### 110. Cuando los cron jobs de PBS colapsan el servidor: controlar concurrencia sin reinventar la rueda
|
|
- No olvidar: los GC y verify jobs programados con el scheduling nativo de PBS pueden provocar picos de IO que congestionan el servidor. Solucion: no usar el scheduling nativo, sino scripts que comprueban si hay otro proceso corriendo antes de lanzar uno nuevo. La logica es simple: consulta API → si hay tarea activa, no lances otra → si no hay ninguna, lanza la mas antigua. Semaphore traduce esto directamente: un playbook con esa logica ejecutado cada 15 minutos, con la opcion de "no ejecutar si la ejecucion anterior no ha terminado". Misma logica, con UI y notificaciones.
|
|
|
|
### 111. Semaphore como reemplazo de cron: visibilidad sin complejidad
|
|
- No olvidar: el salto de cron a Semaphore no es un cambio de herramienta, es un cambio de visibilidad. Con cron: si un job falla, queda en un log local que nadie lee. Con Semaphore: fallo visible en la UI + webhook a Telegram + historial completo de ejecuciones. La logica del playbook es identica a la del script bash, solo cambia donde se ejecuta (Semaphore) y donde se ve el resultado (UI web en vez de /var/log). Migracion progresiva: no cambiar todos los cron de golpe, ir migrando uno a uno y validar.
|
|
|
|
### 112. n8n y workflows reactivos: el pegamento entre sistemas que no se hablan
|
|
- No olvidar: n8n no es una herramienta de dia 1, es de mes 3-6. Su valor es conectar sistemas: Grafana detecta disco al 90% → n8n busca el cliente en Netbox → envia email al comercial. Wazuh detecta actividad sospechosa → n8n pasa el evento a un LLM local → el LLM analiza si es falso positivo → si es real, alerta con explicacion en lenguaje claro a Telegram. Todo sin escribir scripts. Pero requiere que Ansible, Semaphore, Wazuh y Grafana ya esten funcionando. No poner n8n antes de tener los bloques basicos.
|
|
|
|
### 113. n8n con IA: analisis automatizado de eventos de seguridad
|
|
- No olvidar: n8n tiene nodos nativos para OpenAI, Ollama (LLM local), y otros modelos. Caso de uso real: Wazuh genera 50 alertas al dia, el 95% son falsos positivos. n8n recoge cada alerta → la pasa a un LLM → el modelo analiza contexto (hora, servidor, tipo de evento, historial) → clasifica como falso positivo o real → solo las reales llegan a Telegram con una explicacion en lenguaje humano. Reduce la fatiga de alertas dramaticamente. Pero esto es avanzado (mes 6+), requiere que el equipo ya tenga criterio para validar las clasificaciones del LLM.
|
|
|
|
### 114. Resumen de Capa 3: de scripts en /root a infraestructura gestionada
|
|
- No olvidar: la Capa 3 completa transforma la operativa actual de "scripts bash sin versionar ejecutados por cron en un servidor" a "playbooks idempotentes en git, ejecutados desde una UI web con SSO, scheduling centralizado, notificaciones de fallo, audit log, y API para integracion con facturacion". Las herramientas: Ansible (sin agente, solo SSH), Semaphore (UI + scheduling + API), Forgejo existente (git + CI/CD), n8n futuro (workflows reactivos). Terraform descartado (servidores permanentes). Recursos nuevos: Semaphore 512MB + n8n 512MB futuro. Forgejo ya desplegado.
|
|
|
|
---
|
|
|
|
## Bloque 21: VPN y red - WireGuard como columna vertebral
|
|
|
|
### 115. Por que WireGuard y no Tailscale/Headscale cuando controlas toda la infra
|
|
- No olvidar: Tailscale es fantastico para equipos distribuidos que necesitan zero-config. Pero si controlas los servidores, el vRack, y el firewall, WireGuard puro te da control total sin dependencia de coordination servers externos (Tailscale SaaS) ni capas de abstraccion (Headscale). Un fichero de texto por servidor, modulo de kernel, overhead ~0. Con Ansible para distribuir configs, la "complejidad" de WireGuard desaparece. Si algun dia la escala lo justifica (+500 peers, mesh dinamico), Headscale es la evolucion natural sin cambiar los clientes.
|
|
|
|
### 116. Tres redes WireGuard: backups, clientes y gestion - cada una con su rol
|
|
- No olvidar: no mezclar todo en una sola VPN. Separar en tres redes con propositos distintos: (1) Backup: PBS como WG server, peers solo los PVE que le envian backups, sin forwarding entre peers. (2) Clientes/tecnicos: WG Hub con forwarding controlado por nftables, aislamiento por cliente. (3) Gestion: mesh cifrado sobre vRack para servicios internos (Grafana, Wazuh, Netbox). Cada red tiene su rango IPv6 ULA independiente. Un compromiso en la red de clientes no afecta a la red de gestion.
|
|
|
|
### 117. IPv6 ULA para redes internas: sin NAT, sin colisiones, infinitas IPs
|
|
- No olvidar: todo el direccionamiento WireGuard en IPv6 ULA (fd00::/8). Ventajas: sin NAT (cada peer tiene IP unica directa), espacio ilimitado (un /64 por red = 2^64 direcciones), organizacion clara por funcion (fdab:1234:bkp::/48 backups, fdab:1234:vpn::/48 clientes, fdab:1234:mgmt::/48 gestion). Los PVE remotos con solo IPv4 se conectan al endpoint WG por IPv4, pero dentro del tunel todo es IPv6. WireGuard separa transporte del payload sin problemas.
|
|
|
|
### 118. PBS como servidor WireGuard: cerrar el 8007 a internet de una vez
|
|
- No olvidar: el puerto 8007 de PBS sirve tanto para el dashboard web como para recibir backups (no se pueden separar). Hoy esta abierto a internet. Solucion: cada PBS levanta un WG server cuyos unicos peers son los PVE que le envian backups. PVE configura el storage como [fdab::X]:8007 (IP WG). PBS:8007 deja de escuchar en IP publica. Solo queda expuesto el puerto UDP de WireGuard. Reduccion dramatica de superficie de ataque. Trafico entre fisicos del mismo DC va por vRack a 25Gbps con WG encima (overhead ~3-5%).
|
|
|
|
### 119. WG Hub con keepalived: alta disponibilidad sin routing dinamico
|
|
- No olvidar: el punto debil del hub-spoke es que si el hub cae, todo para. Solucion simple: par de VMs Debian minimal con la misma config WG y keepalived gestionando una VIP (IP flotante). Failover en <2 segundos. Los peers ni se enteran: su endpoint es la VIP que no cambia. No hace falta BGP ni OSPF: a <200 peers, keepalived es mas simple, mas rapido en failover (2 seg vs 5-30 seg OSPF), y no requiere conocimiento de routing dinamico. Evaluar FRRouting solo si se llega a multiples DCs con hubs distribuidos.
|
|
|
|
### 120. De un gateway por cliente a gateways compartidos: menos VMs, mas control
|
|
- No olvidar: el modelo actual (1 VM gateway por cliente con NAT + WG) significa 50 clientes = 50 VMs que mantener, sin HA, cada una consumiendo recursos. Modelo nuevo: 2 VMs WG Hub (par HA) compartidas por todos los clientes, aislamiento con nftables por subnet IPv6 (/64 por cliente). Ventajas: de 50 VMs a 2, HA centralizada, sin NAT (IPv6 directo), gestion centralizada. Riesgo: error en nftables podria exponer trafico entre clientes. Mitigacion: tests automatizados de aislamiento con Ansible (playbook que verifica que cada cliente solo alcanza sus recursos).
|
|
|
|
### 121. Aislamiento de clientes con nftables: cada /64 es una isla
|
|
- No olvidar: en el WG Hub, el ip forwarding esta activado (los peers deben verse entre ellos dentro del mismo cliente). El aislamiento se hace con nftables: regla por subnet que permite forward solo dentro del mismo /64, y DROP por defecto para todo lo demas. Cada cliente tiene su /64 (fdab:1234:vpn:acme::/64). Las VMs, usuarios remotos y mikrotiks del mismo cliente estan en el mismo /64 y se ven. Los de otro cliente: DROP. Panel futuro para que el cliente defina granularidad peer-a-peer dentro de su /64.
|
|
|
|
### 122. vRack de OVH: privada no significa segura
|
|
- No olvidar: el vRack de OVH es una red L2 privada, pero "privada" solo significa que no sale a internet. Dentro del vRack: sin cifrado, sin autenticacion, cualquier servidor puede ver trafico de los demas (ARP spoofing trivial). Si un servidor es comprometido (como ya paso), tiene acceso directo L2 a todos los demas servidores del vRack. Solucion: WireGuard sobre vRack. Mismo cable de 25Gbps, pero con cifrado y autenticacion encima. Overhead minimo (~3-5% CPU). Un servidor comprometido ya no puede esnifar ni alcanzar servicios de otros sin la clave WG.
|
|
|
|
### 123. wgdashboard: UI y API para WireGuard sin perder el control
|
|
- No olvidar: WireGuard puro no tiene UI ni API. wgdashboard es un contenedor Docker que lee y escribe /etc/wireguard/*.conf y recarga WG (wg syncconf). Aporta: dashboard web (peers conectados, trafico, ultimo handshake), API REST (crear/eliminar peers programaticamente), generacion de configs. Integrable con Authentik (proxy de autenticacion delante). La API permite: ICSManager vende backup → API crea peer WG automaticamente. Corre en la VM del WG Hub, no necesita nada mas.
|
|
|
|
### 124. Fase de arranque VPN: primero tecnicos, luego clientes
|
|
- No olvidar: no abrir la VPN a clientes el dia 1. Fase inicial solo con tecnicos internos: montar par HA de WG Hub, crear peers para el equipo, validar acceso a paneles (:8007, :8006, Grafana, etc.), probar aislamiento nftables, verificar failover keepalived. Cuando el modelo este pulido y estable, abrir progresivamente: primero un cliente piloto, luego el resto. Evita exponer un modelo sin probar a clientes de produccion.
|
|
|
|
---
|
|
|
|
## Bloque 22: DNS - Cuatro problematicas, una arquitectura
|
|
|
|
### 125. PowerDNS autoritativo + Technitium resolver: cada uno en lo suyo
|
|
- No olvidar: no mezclar roles. PowerDNS Authoritative se queda como autoritativo de zonas de clientes (primario o secundario) y de las zonas nuevas (vpn6.com.es, PTR IPv6). Technitium DNS entra como resolver: resuelve consultas de navegacion de VMs y usuarios WG, con bloqueo configurable por cliente. Technitium reenvia a PowerDNS las consultas de zonas internas (*.vpn6.com.es, zonas de clientes), y al upstream DoH (Cloudflare/Google) para el resto. Dos herramientas, dos roles, sin solapamiento.
|
|
|
|
### 126. Technitium DNS: resolver multi-tenant con panel por cliente incluido
|
|
- No olvidar: la clave de Technitium frente a AdGuard Home o Pi-hole es el multi-tenancy nativo. Cada cliente (identificado por su rango IP WG) tiene su perfil de bloqueo (malware, ads, adult, custom) y puede ver su propio dashboard de queries. Panel web multi-usuario incluido, sin desarrollo custom. API REST completa para automatizacion. Soporta DNSSEC validation y upstream DoH/DoT. Un contenedor Docker, 512MB-1GB RAM.
|
|
|
|
### 127. Naming automatico: toda IP tiene nombre desde el momento 0
|
|
- No olvidar: cada IP que se asigna (WG peer, VM, servidor) debe tener AAAA + PTR operativos inmediatamente. Esquema sobre vpn6.com.es: laptop.david.vpn6.com.es (tecnico), vm-web.acme.vpn6.com.es (VM cliente), oficina.acme.vpn6.com.es (mikrotik). Automatizacion: wgdashboard crea peer → API PowerDNS crea registros. Netbox sincroniza VM desde PVE → netbox-dns crea registros en PowerDNS. Ningun registro DNS manual. El cliente puede pedir usar su dominio propio (vpn.acme-empresa.com → CNAME a acme.vpn6.com.es).
|
|
|
|
### 128. PVE a DNS sin hookscripts: el camino limpio via Netbox
|
|
- No olvidar: PVE no tiene registro DNS nativo. Se puede hacer con hookscripts (vzdump hooks) que llaman a PowerDNS API, pero es fragil (depende del guest-agent, del script, etc.). El camino limpio: netbox-proxmox sincroniza VMs automaticamente desde la API de PVE a Netbox. netbox-dns en Netbox sincroniza los registros a PowerDNS. Si la VM existe en Netbox con IP, tiene DNS. Sin hookscripts, sin fragilidad, Netbox como SSOT.
|
|
|
|
### 129. DNS como servicio: bloqueo de malware como valor anadido para clientes
|
|
- No olvidar: ofrecer DNS resolver con bloqueo de malware/phishing no es solo seguridad, es un servicio diferenciador. El cliente conecta su VM o su oficina por WG y automaticamente navega con proteccion contra dominios maliciosos. Niveles de servicio: basico (solo malware), medio (malware + ads), premium (configurable por el cliente desde su panel Technitium). Puede ser incluido en el servicio base o como upsell. Coste para nosotros: un contenedor Docker de 512MB.
|
|
|
|
### 130. Pagina de diagnostico self-service: que el cliente compruebe antes de llamar
|
|
- No olvidar: desarrollo propio ligero (Flask/FastAPI, un contenedor). El cliente entra (SSO Authentik), la app detecta su IP WG, identifica quien es, y ejecuta checks en tiempo real: WG conectado (handshake reciente), DNS resolviendo, certificado PBS no caducado, PBS:8007 accesible, latencia. Genera informe copiable. Si hay problema, el cliente ya sabe que falla antes de abrir ticket. Reduce tickets de soporte y mejora la experiencia. Prioridad: mes 3+, no es critico para arrancar.
|
|
|
|
---
|
|
|
|
## Bloque 23: Proxy inverso y eliminacion de IPv4
|
|
|
|
### 131. Traefik como punto unico de publicacion: el cliente no necesita IP publica
|
|
- No olvidar: las VMs de clientes tienden a no tener IPv4 publica propia. Traefik actua como proxy inverso centralizado: escucha en IPv4+IPv6 publica, y reenvia a la VM del cliente por su IPv6 WG interna. El cliente declara "quiero publicar portal.acme.com", se crea una ruta en Traefik + un AAAA en PowerDNS, y el servicio esta online con SSL en segundos. La VM solo necesita WG IPv6. Menos IPs publicas, menos superficie de ataque, menos coste.
|
|
|
|
### 132. SSL automatico centralizado: Let's Encrypt sin que el cliente lo toque
|
|
- No olvidar: con Traefik, el SSL es automatico via Let's Encrypt (ACME). El cliente no necesita saber que es un certificado ni como renovarlo. Traefik lo pide, lo renueva, y lo sirve. Centralizado: un solo punto donde gestionar certificados, no uno por VM. Si un certificado falla, Grafana alerta (no el cliente). Elimina la categoria completa de tickets "mi certificado ha caducado".
|
|
|
|
### 133. De IPv4 publica por VM a IPv6-only con proxy: la transicion
|
|
- No olvidar: la transicion no es de golpe. Fase 1: servicios nuevos nacen sin IPv4, solo WG IPv6 + Traefik. Fase 2: servicios existentes se migran progresivamente (cambiar DNS del dominio al Traefik, quitar IP publica de la VM). Fase 3: solo Traefik tiene IPv4 publica, las VMs son IPv6-only. Para clientes legacy que necesiten IPv4 entrante por razones tecnicas, Traefik hace el bridge IPv4→IPv6 de forma transparente. No hay flag day.
|
|
|
|
### 134. Traefik config dinamica con Ansible: alta automatica de servicios
|
|
- No olvidar: Traefik lee ficheros YAML de configuracion de un directorio y recarga automaticamente (file watcher). Ansible genera el YAML al dar de alta un servicio de cliente. Flujo: ICSManager → API Semaphore → playbook que crea fichero YAML en Traefik + AAAA en PowerDNS → servicio publicado. Sin reiniciar Traefik, sin tocar la config a mano. Un fichero YAML por servicio de cliente, versionado en Forgejo.
|
|
|
|
### 135. Resumen de Capa 4: la red como servicio integrado
|
|
- No olvidar: la Capa 4 completa transforma la red de "puertos abiertos a internet con IPs publicas por VM" a "todo por WG cifrado, DNS automatico con nombres desde el momento 0, resolver con bloqueo por cliente, y publicacion de servicios sin IPv4 via Traefik". Herramientas: WireGuard + wgdashboard (VPN), PowerDNS (autoritativo existente), Technitium DNS (resolver multi-tenant), Traefik (proxy inverso, ya existente). IPv6 ULA para todo lo interno. Recursos nuevos: 2 VMs WG Hub (1GB total) + Technitium (512MB-1GB). Todo lo demas ya existe o es kernel module.
|
|
|
|
---
|
|
|
|
## Bloque 24: Gestion de incidentes y documentacion
|
|
|
|
### 136. Zammad como centro: integrar el ticketing con el stack de monitoring
|
|
- No olvidar: Zammad ya esta en produccion y funciona. No reinventar. Lo que falta es conectarlo con el stack nuevo: SSO Authentik (misma cuenta), webhook desde Alertmanager (alerta no atendida en 15min → crea ticket automaticamente), webhook desde Wazuh (incidente seguridad → ticket critico), integracion con panel diagnostico (cliente adjunta informe), contexto de Netbox visible en el ticket. Zammad tiene API REST completa, todo esto es viable sin desarrollo complejo.
|
|
|
|
### 137. Telegram como canal de alertas: simple, al movil, funciona
|
|
- No olvidar: no complicarse con herramientas nuevas el dia 1. Alertmanager y Wazuh envian a un bot de Telegram. Llega al movil, se ve, se actua. Es lo minimo que funciona. Cuando el equipo necesite historial buscable, contexto compartido, y canales tematicos, se añade Mattermost. Cuando necesite gestion de guardias y escalado, se añade Grafana OnCall. Pero el dia 1, Telegram y Zammad cubren el 90%.
|
|
|
|
### 138. Mattermost como futuro panel de notificaciones del equipo
|
|
- No olvidar: Mattermost no es para chatear (para eso ya hay canales). Es un panel de notificaciones centralizado donde todo el stack vuelca sus eventos: #alertas-criticas (Alertmanager), #seguridad (Wazuh), #backups (Semaphore), #tickets (Zammad). El equipo tiene visibilidad compartida e historial buscable. Un tecnico nuevo lee los canales y tiene contexto inmediato. Pero requiere que el stack este rodando primero. No antes del mes 3.
|
|
|
|
### 139. Grafana OnCall: gestion de alertas con ciclo de vida real
|
|
- No olvidar: la diferencia entre Telegram/Mattermost y Grafana OnCall es el ciclo de vida. En Telegram los mensajes se acumulan y no sabes si alguien lo esta atendiendo. En OnCall: la alerta aparece activa, alguien se la asigna, cuando se resuelve desaparece. Si nadie responde en X minutos, escala al siguiente. Rotacion de guardias automatica. Integrado en Grafana (mismo panel). Open source. Pero requiere guardias formales. No antes del mes 6.
|
|
|
|
### 140. Outline como wiki del equipo: Notion pero tuyo
|
|
- No olvidar: Outline es una wiki moderna self-hosted con interfaz tipo Notion. Edicion colaborativa en tiempo real (dos tecnicos editando el mismo runbook a la vez), busqueda full-text, permisos por coleccion, SSO nativo con Authentik. Estructura: Runbooks (que hacer cuando X pasa), Arquitectura (diagramas, decisiones), Onboarding (primer dia del tecnico), Clientes (info restringida). Convive con Forgejo: Outline para conocimiento operativo, Forgejo para docs que van con el codigo (README, configs, playbooks). ~1GB RAM en Docker.
|
|
|
|
### 141. Runbooks: la documentacion que salva a las 3am
|
|
- No olvidar: un runbook es "que hacer cuando X pasa", paso a paso, escrito para alguien que esta medio dormido a las 3am. Runbooks criticos minimos: servidor nuevo (checklist bootstrap), incidente de seguridad (protocolo de respuesta), disco lleno (limpiar, ampliar, alertar), restore de backup (como, donde, cuanto tarda), failover WG Hub (pasos manuales si keepalived falla). Si no esta escrito, no existe. Si esta en la cabeza de David y David esta de vacaciones, no existe.
|
|
|
|
### 142. Resumen de Capa 5: gestionar incidentes sin reinventar
|
|
- No olvidar: la Capa 5 no añade casi nada nuevo. Zammad ya funciona (solo integrar con SSO y webhooks). Telegram ya funciona (solo conectar Alertmanager y Wazuh). Lo unico nuevo es Outline para documentacion (~1GB RAM). Mattermost y Grafana OnCall quedan como evoluciones futuras cuando el equipo y los procesos lo justifiquen. Prioridad: no cargar de herramientas nuevas, solo conectar las que ya hay y documentar lo critico.
|
|
|
|
---
|
|
|
|
## Bloque 25: Almacenamiento y backup: tres capas geograficas
|
|
|
|
### 143. ZFS en PBS: un dataset por cliente como unidad de gestion
|
|
- No olvidar: ZFS no se usa por sus snapshots (PBS gestiona eso nativamente). Se usa porque permite crear un dataset por cliente con quota y reservation independientes, modelo multiplicador 6x (100GB comerciales = 600GB quota). Esto aisla a los clientes entre si: si un cliente llena su quota no afecta a otros. Propiedades optimizadas: recordsize=1M (alineado con chunk size de PBS), compression=lz4 (rapido, buena ratio), atime=off (reduce escrituras parasitas). No se necesitan Sanoid/Syncoid/zrepl: PBS gestiona snapshots y replicacion con sus propios mecanismos.
|
|
|
|
### 144. Backup de 3 capas geograficas: PVE → PBS1 → PBS2
|
|
- No olvidar: una sola capa de backup es insuficiente (OVH Estrasburgo ardio en 2021). Modelo: PVE (Francia, produccion) → PBS1 (Alemania, transito, retencion corta: keep-last:5, keep-daily:3) ← PBS2 (Polonia, archivo, retencion larga: keep-daily:7, keep-weekly:4, keep-monthly:5). Nota: PBS2 TIRA de PBS1, no al reves. Cada capa aplica su politica de retencion independientemente. 3 paises, 3 jurisdicciones, 3 datacenters separados. Si uno cae, los otros siguen intactos.
|
|
|
|
### 145. PVE no puede borrar: permisos minimos como defensa anti-ransomware
|
|
- No olvidar: el usuario PVE en PBS1 tiene solo DatastoreBackup (crear backups) y DatastoreReader (restaurar). NO tiene DatastoreAdmin ni DatastorePowerUser. Si ransomware compromete un PVE, puede crear backups (inofensivo) y restaurar, pero no puede borrar ni podar los existentes. Principio: el servidor que produce los datos nunca tiene permiso para destruirlos en el servidor de backup. Simple, efectivo, sin herramientas adicionales.
|
|
|
|
### 146. PBS2 invisible: el bunker que nadie puede alcanzar
|
|
- No olvidar: PBS2 es el ultimo recurso. Debe ser inalcanzable. Firewall: INPUT solo acepta SSH desde bastion de emergencia + WG desde peer de gestion. OUTPUT solo hacia PBS1:8007 por WG + DNS/NTP. No tiene puertos abiertos a internet. PBS1 no tiene credenciales de PBS2 ni ruta de red hacia el. PVE no sabe que PBS2 existe. Solo PBS2 decide cuando hablar con PBS1 (sync jobs pull). Verify semanal sobre los backups recibidos: si algo llega corrupto se detecta antes de necesitarlo.
|
|
|
|
### 147. Cuando PBS1 se pierde: procedimiento de recuperacion con hueco de ~1 dia
|
|
- No olvidar: si PBS1 (transito) se pierde por fallo de hardware, el procedimiento es: provisionar PBS1 nuevo → PVE empieza a hacer backups frescos al nuevo PBS1 → PBS2 empieza a tirar cuando hay datos. Hueco de ~1 dia sin capa de transito. Durante ese hueco las VMs funcionan normalmente pero no hay backup reciente. PBS2 conserva todas las copias historicas intactas. El riesgo real es que un PVE falle DURANTE ese hueco. Runbook critico: documentar en Outline el paso a paso de reconstruccion de PBS1.
|
|
|
|
### 148. Cuando PBS2 se pierde: definicion de producto y opcion PBS3
|
|
- No olvidar: si PBS2 (archivo) se pierde, se pierden las copias historicas (semanas, meses). PBS1 sigue con retencion corta. PVE sigue haciendo backups. Pero si PBS1 tambien falla → datos perdidos. Esto no es un fallo tecnico a resolver, es una decision de producto: el producto base incluye 2 capas (PBS1+PBS2), clientes criticos que no quieran asumir ese riesgo pueden contratar PBS3 (otra ubicacion, otro proveedor). Documentar claramente en la definicion del producto los riesgos de cada nivel de servicio. El cliente decide segun su criticidad y presupuesto.
|
|
|
|
### 149. Monitorizar el backup del backup: alertas que no puedes ignorar
|
|
- No olvidar: todo este modelo es inutil si nadie se entera de que fallo. Alertas criticas (todas a Telegram + ticket Zammad si no se atiende en 15min): PBSBackupOld48h (VM sin backup en 48h), PBSSyncFailed (sync PBS2←PBS1 fallo), PBSSyncOld48h (PBS2 no sincroniza en 48h), PBSVerifyErrors (verify en PBS2 detecta corrupcion). Alertas warning: DatastoreSpace90 (PBS1 o PBS2 > 90% espacio). La alerta de sync es especialmente critica: si PBS2 deja de sincronizar y nadie lo nota, cuando se necesite la copia estara desactualizada.
|
|
|
|
### 150. Configs de PVE/PBS a git: saber exactamente que habia cuando algo se pierde
|
|
- No olvidar: los datos de VMs estan en PBS (backup). Pero la configuracion del propio nodo (que VMs habia, con que config, que datastores, que usuarios, que red) esta solo en el nodo. Si se pierde, ICSManager sabe que clientes hay pero no el detalle de cada .conf de VM, cada regla de firewall, cada ZFS property. Solucion simple: playbook Ansible que diariamente recoge /etc/pve/ y /etc/proxmox-backup/ de cada nodo y hace commit a un repo de Forgejo. Son ficheros de texto (KB), el diff de cada commit muestra exactamente que cambio. Coste cero: Forgejo ya existe, son KB de texto. Valor enorme: reconstruir un nodo pasa de horas/dias adivinando a minutos leyendo configs exactas. Bonus: si alguien cambia algo manualmente, el diff lo delata.
|
|
|
|
### 151. Replica ZFS de VMs de gestion a oficina: plan de contingencia fuera de OVH
|
|
- No olvidar: toda la infra de gestion (monitoring, Wazuh, Netbox, Authentik) vive en OVH. Si OVH pierde ese servidor, te quedas ciego. Solucion: replicar las VMs criticas por ZFS send/recv incremental cada 4h al servidor Xeon 96GB que ya existe en la oficina. Las VMs estan apagadas, solo se encienden en contingencia. Transporte por WG cifrado. Sync incremental ~1-5 GB cada 4h (factible con fibra). Plan de contingencia: detectar caida → encender VMs en oficina → actualizar DNS/WG → ~10 minutos operativo. No es HA automatico, es plan B manual con runbook en Outline. Coste: cero (hardware existente). Solo replica gestion, no datos de clientes (esos estan en las 3 capas PBS).
|
|
|
|
### 152. Resumen de Capa 6: almacenamiento y backup sin herramientas extra
|
|
- No olvidar: la Capa 6 no introduce herramientas nuevas de software. ZFS ya esta (solo monitorizar con node_exporter existente). PBS gestiona snapshots y replicacion nativamente (Sanoid/Syncoid/zrepl descartados). 4 subcapas: 6.1 ZFS monitoring, 6.2 backup 3 capas geograficas (PVE→PBS1→PBS2, con opcion PBS3 premium), 6.3 configs PVE/PBS a git diariamente (Forgejo, coste 0), 6.4 replica ZFS de VMs de gestion a oficina (servidor existente, coste 0). La seguridad viene de la arquitectura (permisos, aislamiento, pull-not-push, invisibilidad, diversificacion geografica) no de software adicional. Recursos nuevos: PBS2 fisico (Polonia) y las alertas en el stack existente. Todo lo demas ya existe o es coste cero.
|
|
|
|
---
|
|
|
|
## Bloque 26: Observabilidad avanzada - de datos a decisiones
|
|
|
|
### 153. Dashboard por cliente en Grafana: una vista, todo un cliente
|
|
- No olvidar: hoy para ver el estado de un cliente el tecnico salta entre 4 herramientas. Con un dashboard Grafana con variable dropdown por cliente, seleccionas "ACME" y ves todo: VMs (UP/DOWN, CPU, RAM, disco), backups (ultimo, estado, verify), storage PBS (uso, tendencia), sync PBS2, eventos Wazuh, conectividad WG. Un solo dashboard, todos los clientes. La variable viene de Netbox (plugin grafana-netbox-datasource) asi que al dar de alta un cliente en Netbox aparece automaticamente en el dropdown. No es un dashboard por cliente, es un dashboard con filtro.
|
|
|
|
### 154. SLOs/SLIs: medir lo que prometes al cliente
|
|
- No olvidar: sin SLIs no sabes si cumples lo que prometes. Definir metricas claras: backup freshness (< 24h), backup success rate (> 99%), verify pass rate (> 99.5%), sync freshness (< 48h), storage headroom (> 15%), VM availability (> 99.5%). Trackear en panel Grafana con semaforo verde/rojo. Alertas cuando un SLO se incumple (diferente de alertas de infra: las de infra dicen "algo falla ahora", las de SLO dicen "estas incumpliendo lo que prometiste"). Cuando el cliente pregunta "como ha ido este mes", tienes datos, no opiniones.
|
|
|
|
### 155. Capacity planning: anticipar en vez de reaccionar
|
|
- No olvidar: VictoriaMetrics tiene predict_linear nativo (Prometheus tambien pero MetricsQL es mas potente). Aplicar a storage PBS: ¿cuantos dias quedan para que ACME llene su quota? Si la respuesta es < 30 dias, alerta warning. Si < 7 dias, alerta critica. Mismo para pool ZFS global. Dashboard con tabla de todos los clientes ordenados por "dias para llenarse". El comercial puede contactar al cliente ANTES de que se llene, no despues. Diferenciador de servicio: "te avisamos cuando necesitas mas espacio, no cuando ya no tienes".
|
|
|
|
### 156. Informes mensuales automaticos: el cliente recibe datos, no silencio
|
|
- No olvidar: un informe mensual automatico por cliente (backups OK, uptime, storage, seguridad) generado con playbook Ansible + template Jinja2 → PDF/HTML. Enviado por email o disponible en Zammad/Outline. El cliente ve que el servicio funciona. El comercial tiene argumento para renovar. El tecnico tiene evidencia si hay disputa. Implementar cuando el stack este maduro (mes 4+). No urgente pero diferenciador enorme: la mayoria de proveedores no envian informes proactivos.
|
|
|
|
### 157. Grafana org per-client: que el cliente vea sus datos en tiempo real
|
|
- No olvidar: Grafana soporta Organizations con RBAC. Cada cliente puede tener acceso de solo lectura a un dashboard con sus metricas. SSO con Authentik (misma cuenta). El cliente ve sus VMs, sus backups, su storage. No ve nada de otros clientes ni de la infra interna. Es un upsell o diferenciador: "te damos acceso a tu panel de monitoring". Implementar mes 3+ cuando los dashboards esten pulidos.
|
|
|
|
### 158. Correlacion metricas + logs + seguridad: investigar incidentes sin saltar entre herramientas
|
|
- No olvidar: Grafana soporta multiples data sources en la misma vista temporal. Dashboard de investigacion: arriba metricas (VictoriaMetrics), centro logs (Loki), abajo eventos de seguridad (Wazuh via Loki). Seleccionas un rango temporal y ves todo sincronizado. Annotations: eventos de Wazuh aparecen como lineas verticales sobre las graficas de metricas. Para que funcione: enviar Wazuh alerts.json a Loki via Alloy (un fichero JSON, Alloy lo recoge como cualquier otro log). La correlacion es visual, no automatica, pero ahorra el 80% del tiempo de investigacion.
|
|
|
|
### 159. Resumen de Capa 7: observabilidad avanzada sin herramientas nuevas
|
|
- No olvidar: la Capa 7 no introduce ninguna herramienta nueva. Todo se construye sobre Grafana + VictoriaMetrics + Loki + Wazuh + Netbox ya desplegados en Capas 1-2. Coste: cero. Son dashboards, queries, recording rules, templates. 5 subcapas: dashboards por cliente (mes 1-2), SLOs/SLIs (mes 2-3), capacity planning con prediccion (mes 2-3), status page + informes (mes 3-4), correlacion avanzada (mes 2-3). Transforma datos crudos (metricas, logs, eventos) en inteligencia operativa (¿como esta el cliente? ¿cumplimos lo prometido? ¿cuando necesitaremos mas disco? ¿que paso exactamente a las 03:15?). La diferencia entre tener datos y usarlos.
|
|
|
|
---
|
|
|
|
## Bloque 27: Modelo de VMs, salida a internet y decisiones de producto
|
|
|
|
### 160. Una VM = un servicio: el patron de caja negra que simplifica todo
|
|
- No olvidar: cada servicio con BBDD vive en su propia VM con todo dentro (app + PostgreSQL/MongoDB + Redis, todo Docker). Zammad en una VM, Authentik en otra, Netbox en otra, ICSManager en otra, WildDuck en otra. Un tecnico trabaja en la VM de Zammad con libertad total sin miedo a romper Netbox. Si Zammad falla, reinicias su VM. Para migrar: mueves la VM entera. Para backup: PBS backupea la VM entera (datos incluidos). Para diagnosticar: "la VM Zammad consume IO" → es Zammad. Mas VMs pero operativamente mucho mas simple que una VM con 6 servicios mezclados.
|
|
|
|
### 161. WildDuck y MongoDB: correo del equipo como servicio dockerizado
|
|
- No olvidar: WildDuck (correo del equipo tecnico) corre en su propia VM con MongoDB y Redis dockerizados dentro. Funcionalidad critica: tokens SMTP que usan los PVE para enviar notificaciones de avisos. Si se pierde WildDuck, los PVE dejan de notificar. MongoDB dockerizado es suficiente para correo interno (bajo volumen). Si crece (mas departamentos, clientes con correo), reevaluar si MongoDB necesita VM dedicada. De momento: caja negra, todo dentro, backupeado por PBS.
|
|
|
|
### 162. CGNAT para IPv4 de VMs: el rango que no colisiona con nadie
|
|
- No olvidar: las VMs de clientes necesitan IPv4 para salir a internet (apt, APIs, navegacion). Usar rango CGNAT 100.64.0.0/10 (RFC 6598) en vez de RFC1918 (10.x, 192.168.x). Ventaja: si el cliente conecta su oficina (192.168.1.0/24) por WG, no hay conflicto con la IP de sus VMs. Asignacion: un /24 por cliente (100.64.1.0/24 para ACME, 100.64.2.0/24 para BETA). 64.000 /24 disponibles, sobra. Registro en Netbox IPAM como cualquier otro prefijo.
|
|
|
|
### 163. Politica de salida restrictiva: puerto 25 bloqueado sin excepciones
|
|
- No olvidar: con NAT compartido, un cliente que envia spam blacklistea la IP para todos. Solucion: politica nftables restrictiva en el WG Hub. Permitido: 80, 443 (web), 53 (DNS), 123 (NTP). Puerto 25 (SMTP sin autenticar): BLOQUEADO SIEMPRE, sin excepciones. Puertos 465, 587 (SMTP autenticado): solo a whitelist de servidores conocidos (WildDuck propio, Gmail, etc.). Todo lo demas: bloqueado por defecto, el cliente pide y se evalua. Logs de intentos bloqueados a Loki para detectar abusos.
|
|
|
|
### 164. IP compartida base vs IP dedicada premium: decision de producto
|
|
- No olvidar: el servicio base incluye NAT compartido con IP que puede cambiar sin preaviso y sin garantia de reputacion. Si un cliente necesita IP fija con PTR propio (para enviar email desde sus VMs, por ejemplo), contrata el servicio premium: IP dedicada, si se blacklistea solo le afecta a el. Implementacion trivial: una regla nftables SNAT por cliente premium. Coste de IP adicional en OVH: centimos. Se repercute como servicio premium. Documentar claramente en la definicion de producto.
|
|
|
|
### 165. Dual-stack por VM: IPv4 sale, IPv6 entra, Traefik publica
|
|
- No olvidar: cada VM de cliente tiene dual-stack. IPv4 CGNAT (100.64.x.x) solo para salir (NAT en WG Hub, nunca abierto entrante). IPv6 WG (fdab:...) para acceso entrante controlado (RDP, SSH, lo que el cliente autorice via nftables per-peer). Servicios web publicados via Traefik (sin IP publica en la VM). Tres canales claros, tres propositos distintos. El cliente nunca necesita una IP publica propia.
|
|
|
|
### 166. Dimensionamiento revisado: de 64 GB a 128 GB RAM
|
|
- No olvidar: con el modelo de una VM por servicio, las VMs de gestion pasan de 30-36 GB (servicios compartidos) a 40-52 GB (cada uno en su VM). Con PVE host overhead (~4 GB) y margen de crecimiento (Mattermost, n8n, Grafana OnCall futuro), 64 GB queda justo. 128 GB da margen para 3-5 años sin preocuparse. CPU: 8-12 cores / 16-24 threads sobra (las VMs son IO-bound, no CPU-bound). Disco: 2x2TB NVMe en ZFS mirror para IO de Loki + VictoriaMetrics + OpenSearch.
|
|
|
|
---
|
|
|
|
## Bloque 28: Gestion multi-cluster y filtrado de correo
|
|
|
|
### 167. Proxmox Datacenter Manager (PDM): gestion multi-cluster desde un solo panel
|
|
- No olvidar: con multiples PVE en distintos datacenters, gestionar cada uno por separado es tedioso y propenso a errores. PDM centraliza la vista de todos los clusters PVE en una sola interfaz web. Funcionalidad clave: migracion cross-cluster (mover VMs de un PVE en Francia a otro en Alemania sin downtime manual). Tambien: inventario centralizado de recursos, alertas globales, y busqueda de VMs en cualquier cluster. Se despliega como VM ligera (1 vCPU, 1-2 GB RAM). Complementa a Netbox (PDM es operacion en tiempo real, Netbox es inventario planificado). No sustituye a Ansible para configuracion.
|
|
|
|
### 168. Migracion cross-cluster con PDM: mover VMs entre datacenters
|
|
- No olvidar: escenario real: un cliente tiene VMs en PVE-Francia y queremos moverlas a PVE-Alemania (mantenimiento, mejor latencia, o descomision). Sin PDM: export OVA + import manual + reconfigurar red. Con PDM: seleccionar VM → migrar a cluster destino → PDM orquesta la copia de discos y reconfiguracion. Requisitos: WireGuard entre clusters (ya tenemos), storage compatible en destino, mappings de red configurados. No es instantaneo (depende del tamaño del disco), pero es automatizado y sin errores manuales.
|
|
|
|
### 169. Proxmox Mail Gateway (PMG): anti-spam y anti-virus delante de WildDuck
|
|
- No olvidar: WildDuck acepta correo pero no tiene filtrado anti-spam/anti-virus nativo robusto. PMG se coloca delante como MX relay: MX → PMG → WildDuck. PMG incluye SpamAssassin (anti-spam con scoring), ClamAV (anti-virus), greylisting, SPF/DKIM/DMARC checks, y una interfaz de quarantine donde los usuarios ven sus correos retenidos. Para correo saliente: PMG verifica que el correo saliente no sea spam (protege la reputacion de nuestra IP). Recurso modesto: 1-2 vCPU, 2-3 GB RAM. Solo tiene sentido cuando WildDuck se abra a mas usuarios/departamentos.
|
|
|
|
### 170. PMG como capa de defensa del correo: reglas, quarantine y reporting
|
|
- No olvidar: PMG permite crear reglas por dominio, remitente, destinatario. Ejemplo: correo de dominios .ru → spam score +5. Correo con adjuntos .exe → quarantine directa. La interfaz de quarantine es self-service: el usuario revisa sus correos retenidos sin molestar al admin. Reports diarios/semanales por email. Integracion con Grafana: metricas de correos procesados, spam rate, virus detectados → dashboard de salud del correo. Greylist reduce spam en ~80% sin false positives. Configuracion via API para automatizar con Ansible.
|
|
|
|
---
|
|
|
|
## Bloque 29: IA y agentes para operaciones
|
|
|
|
### 171. Claude Code en el bastion: copiloto de infraestructura para tecnicos
|
|
- No olvidar: instalar Claude Code (CLI) en la VM Bastion. El tecnico hace SSH al bastion y usa Claude Code como copiloto conversacional. Tiene acceso a los repos de playbooks, CLIs de PBS/ZFS, APIs de Netbox/PVE. Casos de uso: diagnosticar GC lentos, generar playbooks, analizar alertas Wazuh, documentar scripts heredados, construir timelines de incidentes. No es un demonio ni un servicio: se ejecuta solo cuando el tecnico lo lanza. Coste: solo API key (~$20-50/mes segun uso). Recurso: despreciable (va en Bastion existente).
|
|
|
|
### 172. Agentes de IA especializados: n8n + Claude API en vez de un agente general
|
|
- No olvidar: no desplegar un agente general con acceso al sistema (tipo OpenClaw). En su lugar: workflows de n8n que se disparan por triggers (alerta, cron, webhook), recopilan contexto de APIs (VictoriaMetrics, Loki, Netbox), llaman a Claude API con prompt especializado, y generan outputs (tickets Zammad, informes Outline, MRs en Forgejo). Ventajas: scope minimo, read-only, auditable, sin acceso shell, humano aprueba antes de actuar. Cada agente es un workflow con 5-6 nodos, no un servicio nuevo.
|
|
|
|
### 173. Agente de triaje de alertas: de "disco lleno" a diagnostico con contexto
|
|
- No olvidar: el agente con mayor ROI. Alertmanager dispara webhook → n8n recopila metricas (VictoriaMetrics, 2h), logs (Loki, 30min), inventario (Netbox: cliente, SLA) → Claude API analiza con prompt que incluye arboles de decision para problemas comunes → crea ticket Zammad con severidad, diagnostico y acciones recomendadas. Ejemplo: "GC de ACME lleva 26h. 340 snapshots, ultimo exitoso hace 12 dias. Verificar sync job concurrente." Un tecnico junior recibe un ticket ya triado en vez de una alerta cruda.
|
|
|
|
### 174. Agente de capacity planning: prediccion semanal de espacio
|
|
- No olvidar: cron semanal, consulta todas las metricas de disco, calcula tendencias 30/60/90 dias, genera tabla priorizada en Outline: cliente, usado%, quota, tendencia, dias hasta lleno, accion. El tecnico lee un informe de 1 pagina los lunes en vez de revisar 100 datastores manualmente. Detecta crecimiento anomalo ("GAMMA crecio un 15% esta semana, normal es 2%"). Usa predict_linear de VictoriaMetrics como input.
|
|
|
|
### 175. Agente de seguridad: analisis automatizado de alertas Wazuh
|
|
- No olvidar: Wazuh genera muchas alertas, la mayoria son ruido. El agente recibe alertas nivel ≥10, recopila contexto (logs, eventos correlacionados, baseline del servidor), y clasifica: falso positivo (con justificacion), incidente real (con pasos de respuesta del playbook), o indeterminado (que verificar manualmente). Reduce la fatiga de alertas del equipo. Usa Opus (maximo razonamiento) en vez de Sonnet por la criticidad.
|
|
|
|
### 176. Por que descartamos OpenClaw para infraestructura
|
|
- No olvidar: OpenClaw (145k+ estrellas GitHub, agente IA open-source) fue evaluado y descartado. Razones: (1) Vulnerabilidades de seguridad documentadas - prompt injection via skills (demostrado por Cisco), ClawJacked (control remoto via WebSocket). Nosotros acabamos de sufrir un credential stealer con acceso shell; poner un agente IA con acceso shell y vulnerabilidades conocidas seria repetir el error. (2) Modelo inadecuado: es un demonio general con acceso amplio, nosotros necesitamos agentes especializados bajo demanda con scope minimo. (3) Complejidad innecesaria: requiere MongoDB, gateway, canales; nosotros ya tenemos n8n + Zammad + Mattermost. (4) Gobernanza incierta: creador se unio a OpenAI, China restringio su uso. Reevaluar si madura en seguridad.
|
|
|
|
### 177. Principios de seguridad para agentes de IA en produccion
|
|
- No olvidar: cinco reglas inquebrantables. (1) Read-only por defecto: agentes consultan APIs pero nunca ejecutan comandos en produccion. (2) Humano en el bucle: las acciones son recomendaciones, un humano aprueba. (3) Scope minimo: cada agente solo accede a las APIs que necesita, no "acceso a todo". (4) Auditabilidad total: ejecuciones en n8n + logs en Loki. (5) Coste controlado: Sonnet para rutina, Opus solo para seguridad. Si un agente necesita acceso de escritura a produccion, no es un agente: es un playbook de Ansible con aprobacion en Semaphore.
|