Problema

En entornos homelab avanzados es frecuente querer unificar la monitorización, la correlación de eventos y la respuesta automática sin depender de SaaS externos. La dificultad radica en combinar fuentes de logs dispares (servidores Linux, Windows, dispositivos de red) con una capa de IA que pueda actuar en tiempo real, manteniendo la seguridad de los canales de comunicación y evitando falsos positivos que saturen al operador.

Causa

  1. Fragmentación de logs – Cada servicio escribe en su propio formato (syslog, journald, Windows Event Log). Sin un colector central, la correlación se vuelve manual y propensa a errores.
  2. Falta de orquestación – Los scripts de mitigación suelen estar aislados; no hay un motor que reciba eventos, evalúe reglas y ejecute acciones de forma consistente.
  3. Ausencia de contexto persistente – Los sistemas tradicionales pierden el historial de incidentes, lo que impide que una IA recuerde patrones previos.
  4. Seguridad del transporte – En un homelab con acceso externo, los canales de datos a menudo usan TLS tradicional, vulnerable a futuros ataques cuánticos.
  5. Sobrecarga de falsos positivos – Reglas genéricas disparan alertas sin filtrado, generando ruido y reduciendo la confianza en la solución.

Solución

Una arquitectura modular basada en componentes de código abierto permite abordar los puntos anteriores sin depender de licencias propietarias.

1. Colector y normalizador de logs

  • Filebeat / Winlogbeat para capturar logs locales y enviarlos a Logstash.
  • En Logstash, usar filtros Grok y la salida Elasticsearch para indexar eventos estructurados.
  • Configurar TLS mutual (mTLS) con certificados cliente para cada agente; usar X25519‑MLKEM768 para resistencia post‑cuántica.

2. Motor de correlación y reglas SOAR

  • Implementar un backend Node.js que suscriba a los índices de Elasticsearch mediante la API de scroll o el Watcher de Elastic.
  • Definir reglas en formato JSON siguiendo la taxonomía MITRE ATT&CK. Cada regla incluye:
    • Condición (p.ej. event.type == "ssh_login" && event.outcome == "failure" && event.source.ip in blacklist)
    • Acción (p.ej. block_ip, restart_service, notify_slack).
  • El motor evalúa eventos en tiempo real y publica acciones en una cola Redis.

3. Agente de respuesta en cada host

Desplegar un daemon escrito en Go o Rust que escuche la cola Redis y ejecute comandos seguros. El daemon debe:

  • Verificar la firma del mensaje (HMAC con clave rotativa).
  • Ejecutar acciones limitadas a un whitelist (p.ej. systemctl restart nginx).
  • Registrar la ejecución en un log local que vuelve al colector.

4. Capa de IA para enriquecimiento y decisiones

  • Instalar vLLM sobre una GPU (DGX Spark o similar) y cargar modelos como Qwen3‑Coder‑30B.
  • Exponer la inferencia mediante una API REST protegida por mTLS.
  • En el backend Node.js, enviar eventos críticos a la API y recibir una respuesta estructurada: {"action":"block_ip","confidence":0.92}.
  • Almacenar contexto de conversación en Qdrant, lo que permite que la IA mantenga memoria a largo plazo entre sesiones.

5. Interfaz de visualización

  • Utilizar GridStack para crear un dashboard dinámico en el monitor.
  • Incluir widgets de métricas (Prometheus + Grafana), flujos de logs (Kibana), y un web terminal que se conecte al agente de respuesta mediante WebSockets seguros.

6. Automatización de despliegue

  • Definir todo con Docker Compose o Kubernetes (k3s) para reproducibilidad.
  • Cada componente (Filebeat, Logstash, Elasticsearch, Node.js, vLLM, Qdrant) se describe en su propio docker-compose.yml con volúmenes persistentes y variables de entorno para certificados.

Cuándo aplicar esta solución

  • Entornos mixtos con servidores Linux y Windows que requieren correlación de eventos.
  • Necesidad de respuesta automática sin intervención humana constante.
  • Requerimiento de seguridad de extremo a extremo (mTLS, post‑quantum TLS).
  • Disponibilidad de GPU para inferencia local de modelos LLM.

No es adecuada cuando:

  • La infraestructura es demasiado pequeña (menos de 3 nodos) y la complejidad supera los beneficios.
  • No se dispone de GPU compatible con vLLM; la IA se vuelve un cuello de botella.
  • Se prefiere una solución SaaS con SLA garantizado.

Código

# docker-compose.yml fragmento para el motor SOAR
services:
  soar-backend:
    image: node:20-alpine
    working_dir: /app
    volumes:
      - ./soar:/app
    environment:
      - REDIS_HOST=redis
      - ELASTIC_HOST=https://elastic:9200
      - TLS_CERT=/certs/client.crt
      - TLS_KEY=/certs/client.key
    command: ["node", "index.js"]
    depends_on:
      - redis
      - elastic
  redis:
    image: redis:7-alpine
    command: ["redis-server", "--requirepass", "${REDIS_PASSWORD}"]
  elastic:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.12.0
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=true
      - ELASTIC_PASSWORD=${ELASTIC_PASSWORD}
    volumes:
      - esdata:/usr/share/elasticsearch/data
volumes:
  esdata:

Verificación

  1. Generar un evento de prueba: falló un login SSH desde una IP no autorizada.
  2. Confirmar que el evento aparece en Kibana y que el backend Node.js lo procesa.
  3. Verificar que la cola Redis contiene una tarea block_ip.
  4. Revisar el log del agente en el host origen; debe haber ejecutado iptables -A INPUT -s <IP> -j DROP.
  5. Consultar el dashboard; el widget de “Bloqueos activos” debe reflejar la nueva regla.

Notas adicionales

  • Mantener los certificados en un Vault interno y rotarlos cada 90 días evita la exposición accidental.
  • Cuando se usa mTLS con X25519‑MLKEM768, asegúrese de que la biblioteca OpenSSL está compilada con soporte post‑quantum; de lo contrario la negociación caerá a TLS 1.2.
  • La mayoría de falsos positivos provienen de reglas demasiado genéricas; empiece con un conjunto reducido y ajuste umbrales de confianza después de la fase de observación.
  • Qdrant permite crear índices por vector y por metadato; almacenar tanto el embedding del mensaje como etiquetas de ATT&CK facilita búsquedas contextuales posteriores.
  • En entornos con tráfico externo, colocar un WAF (ModSecurity) delante del dashboard y habilitar fail2ban para bloquear intentos de fuerza bruta en la UI reduce la superficie de ataque.