Saltar a contenido

Detección — ver y demostrar que aún se detecta

Traducción automática del original francés.

La prevención responde a la pregunta "¿se puede entrar?". La detección responde a la siguiente pregunta, que es crucial cuando la primera falla: "¿alguien ha entrado y qué está haciendo?".

Esta página describe los motores de detección del parque, la pregunta a la que cada uno responde, y, sobre todo, cómo se asegura de que siguen detectando — porque un detector averiado no produce un error: produce silencio, y el silencio es exactamente lo mismo que "nada que señalar".

Los términos técnicos se refieren al glosario.

Una pregunta, un motor

El peligro de un conjunto de herramientas de seguridad es tomarlas como una solución completa. Diez herramientas que responden a la misma pregunta dejan sin respuesta las nueve restantes. Por lo tanto, el parque parte de las preguntas y asigna a cada una un motor — uno solo.

La pregunta El motor Fuera de su ámbito
¿Esta imagen contiene una CVE conocida? Trivy Lo que hace el contenedor una vez que se inicia
¿Este código tiene algún defecto, dependencia vulnerable o secreto? Semgrep, Trivy (dependencias), trufflehog El comportamiento del programa durante la ejecución
¿Este host está protegido, integrado y actualizado? Wazuh — SCA, FIM, rootcheck, vulnerabilidades Un comportamiento anómalo, en tiempo real
¿Qué se ejecuta solo en esta máquina? osquery (en Wazuh), KnockKnock en el sistema macOS —
¿Este proceso hace algo anómalo? Falco (eBPF) El tráfico de red
¿Qué pasa a través de la red? Suricata (IDS) El contenido de un flujo cifrado de extremo a extremo
¿Este archivo es un malware conocido? ClamAV Un malware inédito
¿Qué hay en este archivo, a todos los niveles? Strelka + YARA Lo que haría el archivo si se ejecutara
¿Quién ataca el perímetro? CrowdSec + bloqueo comunitario Lo que no es HTTP
¿Qué ha pasado en esta máquina? Velociraptor — ver Respuesta —

La columna de la derecha no es una confesión: es lo que delimita cada herramienta. Indica dónde termina su respuesta, por lo que comienza la de otra.

La regla de autoridad

Trivy tiene autoridad sobre lo que se construye y se versiona. Wazuh tiene autoridad sobre el estado de un host en funcionamiento. Falco, Suricata y Velociraptor tienen autoridad sobre el comportamiento y los flujos. Ninguno repite el trabajo de otro; cuando dos motores detectan la misma anomalía, se filtra mediante un identificador de regla, sin apagar ninguno de los dos.

flowchart LR
    classDef src fill:#3f3f46,stroke:#3f3f46,color:#fff
    classDef det fill:#7c2d12,stroke:#7c2d12,color:#fff
    classDef hub fill:#0f766e,stroke:#0f766e,color:#fff

    subgraph sources["Ce qu'on observe"]
        img["Images et dépôts"]:::src
        host["Hôtes<br/>fichiers · configuration · paquets"]:::src
        proc["Processus et conteneurs"]:::src
        net["Trafic réseau"]:::src
        file["Fichiers déposés"]:::src
        logs["Journaux du proxy"]:::src
    end

    subgraph moteurs["Les moteurs"]
        trivy["Trivy · Semgrep · trufflehog<br/>scanner de vulnérabilités"]:::det
        wazuh["Wazuh<br/>SIEM · osquery · listes d'IOC"]:::det
        falco["Falco<br/>appels système"]:::det
        suri["Suricata<br/>signatures réseau"]:::det
        av["ClamAV + Strelka<br/>verdict · analyse profonde"]:::det
        cs["CrowdSec<br/>comportement HTTP"]:::det
    end

    tri["Tableau de triage<br/>score · exposition · journal"]:::hub
    hub["Répartiteur d'alertes"]:::hub

    img --> trivy --> tri
    host --> wazuh
    proc --> falco
    net --> suri
    file --> av --> wazuh
    logs --> cs
    wazuh -->|"identifiant de règle"| hub
    falco -.->|"après mesure du bruit"| hub
    suri -.->|"après mesure du bruit"| hub
    cs -->|"403"| logs

Las flechas punteadas no son un detalle de diseño: indican motores que recolectan información antes de notificar. La razón es más profunda, y se encuentra en los principios.

Wazuh — Un SIEM

Un SIEM recopila los registros de todo el entorno, los correlaciona y genera alertas. En este caso, es Wazuh: un manager y un agente en cada máquina — hipervisor, máquinas virtuales, servidor GPU, NAS, servidor remoto y estación de trabajo. Una máquina que no está en la red local se comunica con el manager a través de una red privada, nunca utilizando una dirección local que no existe para ella.

Lo que aportan los agentes:

  • Integridad de los archivos en las rutas sensibles;
  • Evaluación de la configuración en comparación con los estándares CIS;
  • Detección de rootkits y archivos o puertos ocultos;
  • Vulnerabilidades mediante la correlación entre paquetes instalados y bases de datos CVE;
  • Inventario de hardware, paquetes y procesos.

osquery, dentro del SIEM y no a un lado

osquery consulta el estado de una máquina utilizando SQL: servicios, tareas programadas, claves SSH autorizadas, todo lo que sirve para la persistencia. Está integrado como un módulo de Wazuh, no como un servicio separado: dos inventarios del mismo entorno siempre terminan por diferir, y cuando lo hacen, nadie sabe cuál creer. Los resultados llegan en el mismo índice que el resto, y una consulta verifica que realmente llegan — un módulo activado que no envía nada se parece a un módulo activado.

Inteligencia sobre amenazas, consumida

Tres listas de IOC — direcciones, dominios, huellas de archivos — se obtienen de fuentes públicas y se actualizan mediante una tarea programada. Wazuh las consulta en el momento en que ocurre el evento (listas CDB). La lista de huellas también se alimenta de lo que han encontrado los motores de archivos del entorno: un archivo detectado una vez se reconoce en todas partes posteriormente.

Se ha descartado una plataforma de intercambio de información (del tipo MISP): esta se justifica cuando se genera información, no cuando se consumen tres listas. Un sensor supervisa la actualidad de las listas: una lista de IOC que ha dejado de actualizar no produce errores, sino solo detecciones fallidas.

Dos niveles de alerta

  • Reglas específicas, una por cada detección que se quiera recibir (un malware encontrado, un "canario" que no responde, un contenedor terminado por falta de memoria), cada una relacionada con su identificador.
  • Un umbral general, para todo aquello que las reglas específicas no han previsto. Este solo se activa después de un período de medición del volumen que produciría en un entorno sano.

La ejecución — Falco

El SIEM observa el estado de un host; no observa qué está haciendo un programa. Sin la telemetría de llamadas al sistema, un atacante que ya está presente en un contenedor solo es visible por lo que rompe.

Falco llena este vacío en los hosts que ejecutan contenedores. Las opciones de despliegue, cada una con su razón:

Elección ¿Por qué?
Motor moderno de eBPF, sin necesidad de módulos del kernel No hay nada que compilar, ni nada que se rompa en la próxima actualización del kernel.
Paquete del sistema, iniciado antes del motor de contenedores El primer contenedor iniciado ya está en funcionamiento.
Actualización automática de las reglas desde Internet desactivada Las reglas se modifican mediante el repositorio, se leen y nunca se cambian de forma encubierta.
Límite de procesador y memoria Una herramienta de seguridad no debe poder comprometer al sistema que protege.
Buffer dimensionado para evitar pérdidas en picos Un evento perdido durante un pico es precisamente el que se estaba buscando.

Además de las reglas estables del proyecto, se añaden reglas propias, escritas para los gestos. de un atacante en este parque: una escritura en una tarea programada o en las claves SSH autorizadas, un contenedor que monta el socket del motor de contenedores sin aparecer en la lista de aquellos que tienen acceso, una elevación de privilegios dentro de un contenedor.

Los falsos positivos — las herramientas de control de las bases de datos, que generan decenas de miles de eventos por día — se tratan mediante excepciones específicas, una por caso, nunca desactivando una regla.

Una regla puede cargarse sin errores y nunca más coincidir

Una actualización puede cambiar el significado de un campo que utiliza una regla. La regla se carga, no aparecen errores al inicio, y ya no se activará. Revisar la configuración no detecta nada: es correcta, para la versión anterior.

De ahí la necesidad de un testigo: un sensor lanza un contenedor desechable, y abre una interfaz interactiva y lee un archivo sensible, y luego verifica que ambos gestos se hayan observado, en cada host. Su verificación inversa consistió en desactivar una regla y observar cómo el sensor cambiaba de color.

La red — Suricata

Suricata aplica firmas de ataques conocidos al tráfico que pasa por delante. Su salida, en formato JSON, se envía al motor de búsqueda de registros.

Un IDS solo ve lo que pasa delante de él: por lo tanto, su ubicación es la verdadera decisión. Una red doméstica no ofrece un puerto espejo para escuchar; el punto clave es el lugar donde el tráfico converge — un puente de red virtual puede ver tanto los intercambios entre máquinas como sus salidas hacia Internet, sin necesidad de más equipos.

Al igual que Falco, recopila antes de notificar, y su testigo es una firma de prueba activada intencionalmente desde una máquina, y luego encontrada en las alertas.

Los archivos — dos motores, dos preguntas

La arquitectura de la cadena antivirus — un motor central, un espejo de firmas, y el cliente que registra — se describe en la nota de arquitectura. Aquí, la pregunta es la de los testigos.

  • ClamAV responde a "¿es este un malware conocido?". El servicio de intercambio de archivos rechaza el depósito de un archivo detectado.
  • Strelka responde a "¿qué hay dentro, a todos los niveles?": despliega recursivamente archivos, documentos y objetos incrustados, y pasa decenas de escáneres sobre cada fragmento, incluyendo miles de reglas YARA públicas. Analiza cada noche una selección de rutas elegidas.

El peor fallo del parque — y por qué un contador no lo detecta

YARA recopila su conjunto de reglas en un único bloque. Un único archivo de reglas inválido provoca que todo el sistema falle: el contenedor permanece en buen estado, los análisis continúan y no se detecta nada.

Un contador de reglas cargadas parece ser suficiente. Pero no lo es: indica cuántas reglas están en memoria, pero no si todavía las reconoce. El testigo que se utiliza es una regla de prueba: una regla personalizada, ubicada en el mismo directorio que las demás, que se reinicia cada vez que se actualiza, y un archivo diseñado para activarla. Se envía este archivo a un sistema y se le exige que detecte algo. Si el sistema no compile más, el canary falla junto con él — exactamente lo que queremos.

Verificación inversa: un archivo de reglas intencionalmente dañado ha provocado una alerta crítica, seguida de la vuelta a la normalidad.

Para ClamAV, el testigo es el archivo EICAR, que se somete diariamente.

Una verificación inversa debe romper lo que pretende probar

Para probar el testigo EICAR, la primera idea es ignorar la firma de prueba. Esto no provoca ningún fallo: el motor reconoce el mismo archivo bajo un segundo nombre de firma, que toma el relevo, y el testigo permanece en verde. Una verificación inversa que no provoca que el testigo falle no prueba que el testigo funciona — solo prueba que no sabíamos cómo hacerlo fallar.

Lo que se ha descartado, y por qué.

  • Un "sandbox" dinámico: el volumen de archivos no lo justifica, y además, añadiría una máquina pesada, que estaría expuesta a código malicioso. La cuestión se reabrirá cuando un ejemplo real pase por ambos motores.
  • Un tercer motor basado en reglas YARA: leería el mismo conjunto de reglas públicas. Tener una segunda herramienta que lee las mismas reglas no es tener una segunda opinión.

El perímetro — CrowdSec

CrowdSec lee los registros del proxy interno, identifica comportamientos maliciosos (escaneo, fuerza bruta, explotación conocida) y aplica la decisión mediante un módulo integrado en el proxy, que responde con 403. También utiliza una lista de bloqueo comunitaria, alimentada por todas las instalaciones que la comparten.

¿Por qué en la capa de aplicación en lugar del firewall: ver la nota de arquitectura. Su función verifica que el módulo aplique realmente una decisión, y no solo que esté cargado.

Las vulnerabilidades — el escáner y sus ejes

Un escáner de vulnerabilidades casero agrupa varias herramientas y, sobre todo, clasifica:

Área Herramienta Lo que aporta
Imágenes en ejecución, en cada host de contenedores Trivy CVE conocidas, diariamente
Repositorios de código Trivy (dependencias, IaC) + Semgrep (SAST) Fallos y dependencias vulnerables antes del despliegue
Secretos que permanecen en los hosts trufflehog La gravedad se basa en los permisos del archivo: un secreto legible por todos es más grave que el mismo secreto reservado para su servicio
Acciónabilidad Comparación con la imagen base ¿Existe una corrección ya?
Exposición Configuración del proxy Pública, detrás del proveedor de identidad, o interna
Explotación EPSS + KEV Probable, o ya constatada en otro lugar

La puntuación cruza gravedad, explotación y exposición: una CVE crítica en un servicio interno pasa después de una CVE de nivel medio, ya explotada, en un servicio público. Cada decisión de priorización se registra con su autor.

OpenCVE completa la tabla para lo que no es una imagen de contenedor: el sistema del hipervisor, el del NAS: cruza las CVE publicadas con el inventario versionado de los componentes del parque.

Dos complementos:

  • Un SBOM por imagen en ejecución, regenerado semanalmente. Cuando se publica una nueva vulnerabilidad, la pregunta "¿estamos afectados?" se responde en el inventario, sin tener que volver a escanear.
  • El tiempo de corrección también es una medida. Escanear sin medir el tiempo de corrección, es producir una lista que crece. Ver Cumplimiento.

La hardening, y la segunda opinión

La evaluación de la configuración del SIEM se realiza continuamente. Se utilizó una segunda herramienta (Lynis) de forma puntual, para comparar. En los casos en que ambas coincidían — un módulo declarado inactivo por una, activo por otra — la cuestión se resolvió mediante un test funcional: intentar la acción que el módulo debe impedir y comprobar el rechazo. El control automático fallaba.

No se añadieron herramientas específicas para la detección de rootkits: simplemente replican lo que ya hace el módulo del SIEM, y en máquinas virtuales generan ruido que dificultaría la detección de otras amenazas.

Lo que tienen en común estas opciones

1. Pruebas funcionales, no solo contadores. "El servicio está activo", "5.000 reglas cargadas", "el agente está conectado": son contadores, y un detector puede satisfacerlos todos sin detectar nada. Un test introduce un caso conocido y exige que se detecte. Cada motor de esta página tiene uno.

2. Medir el ruido antes de activar una alerta. Un nuevo detector primero funciona en modo de recopilación, con una fecha de activación predefinida. Una alerta activada sin una medición previa mide la frecuencia del instrumento, no el estado del entorno — y una alerta que se dispara cada hora desde el primer día se filtra antes del final de la semana.

3. Filtrar por identificador de regla, nunca por grupo. Un grupo incluye reglas relacionadas que no se han analizado. Un filtro por grupo genera duplicados; una respuesta automática por grupo actuaría sobre detecciones que nunca se han elegido.

4. Una excepción tiene un nombre. Un falso positivo se trata mediante una excepción específica, asociada a su caso. Desactivar una regla de forma global también elimina todas las detecciones verdaderas que habría realizado.

5. Un motor por pregunta. Añadir una herramienta se justifica por una pregunta sin respuesta, no por la reputación de la herramienta.

Para leer después

Dernière vérification de cette page : 2026-09-11