osquery es un agente de código abierto que expone el estado del sistema operativo como una base de datos SQL relacional, permitiéndote consultar procesos en ejecución, conexiones de red, módulos del kernel, hashes de binarios o eventos de auditoría con sentencias SELECT estándar. En Linux, es una de las herramientas más usadas para telemetría de seguridad y detección de amenazas en 2026, porque combina el poder expresivo de SQL con hooks al kernel vía Audit y eBPF. Esta guía explica cómo desplegarlo en producción, escribir queries alineadas con MITRE ATT&CK e integrarlo con Fleet, Elastic o Wazuh.
osquery 5.15 (junio 2026) añadió soporte estable para eventos eBPF en el kernel 6.6+, superando las limitaciones históricas de la tabla process_events basada en Audit.
El daemon osqueryd ejecuta packs programados y envía resultados diferenciales a un log; osqueryi es la shell interactiva para desarrollar queries.
Fleet DM y Kolide son los gestores de flota más maduros para escalar osquery a miles de endpoints con TLS mutuo y actualizaciones remotas de configuración.
Los packs oficiales incident-response, vuln-management e it-compliance cubren detección MITRE ATT&CK para T1055 (Process Injection), T1053 (Scheduled Tasks) y persistencia por unidades systemd.
osquery consume muy poca CPU (<2% en cargas típicas) pero genera volúmenes considerables de logs, así que conviene planificar retención y filtrado en el SIEM antes de habilitar packs completos.
Complementa (no reemplaza) a Falco y auditd: osquery es óptimo para inventario, hunting histórico y correlación multi-host; Falco/Tetragon dominan la detección en tiempo real con eBPF.
¿Qué es osquery y para qué sirve en Linux?
osquery expone el sistema operativo como una base de datos SQLite virtual: cada aspecto observable (procesos, sockets abiertos, usuarios, módulos del kernel, cron jobs, unidades de systemd, hashes SHA-256 de binarios, extensiones cargadas de un Chromium empaquetado, incluso la política SELinux vigente) se materializa como una tabla que puedes consultar con SQL. Fue creado por Facebook (ahora Meta) en 2014 y donado a la Linux Foundation en 2019; el proyecto vive hoy bajo osquery.readthedocs.io con releases mensuales activas.
El caso de uso típico en 2026 es telemetría de seguridad de endpoints en flotas heterogéneas (servidores Linux, workstations macOS, algunos Windows). En mi día a día lo uso para tres cosas concretas: inventario continuo (qué binarios setuid aparecieron en las últimas 24 h), threat hunting histórico (búscame todos los procesos node hijos de sshd del último mes en 400 hosts) y detección estructurada de tácticas MITRE ATT&CK, como veremos más abajo. También sirve para compliance (Palantir mantiene una configuración pública que mapea CIS Benchmarks a queries osquery) y para forense en frío cuando arrancas osqueryi contra el volumen montado de un host comprometido.
Honestamente, la liberación 5.15 de junio de 2026 marcó un salto importante en Linux: la tabla bpf_process_events pasó a estable y ya no requiere kernels ≥5.13 con configuraciones exóticas. Esto significa que por fin puedes recoger eventos de execve, fork y apertura de sockets sin depender del subsistema Audit del kernel, que en cargas altas pierde eventos silenciosamente. Puedes revisar el changelog completo en las releases oficiales de osquery en GitHub.
Arquitectura: osqueryd, osqueryi y extensiones
osquery se distribuye como un único binario estático (~35 MB) que opera en dos modos según cómo lo invoques. osqueryi es la shell interactiva: arranca sin persistencia, lee un fichero opcional de configuración y te suelta un prompt SQL donde puedes iterar consultas mientras aprendes las tablas. osqueryd es el daemon de producción: se lanza como servicio systemd, lee su configuración (JSON) desde /etc/osquery/osquery.conf o desde un servidor TLS remoto (Fleet DM, Kolide), ejecuta packs de queries programadas y envía resultados a un logger.
Ambos comparten el mismo motor SQL basado en SQLite virtual tables. Cada tabla es en realidad un módulo C++ que se ejecuta bajo demanda cuando el planificador la consulta: hacer SELECT * FROM processes dispara un recorrido de /proc en ese instante, no lee un caché. Esta arquitectura pull es clave para entender el rendimiento. Una query barata como SELECT COUNT(*) FROM users cuesta microsegundos, pero SELECT * FROM file WHERE path LIKE '/var/log/%%' AND directory != '' recorre stat() sobre miles de inodos y puede tardar segundos.
Las extensiones son plugins externos que hablan con osquery vía Thrift sobre un socket Unix. Se usan para añadir tablas propias (por ejemplo, un endpoint que exponga métricas de una aplicación interna) o para loggers y config plugins personalizados. Las extensiones ejecutan en su propio proceso, así que un crash en tu código no derriba al daemon principal, algo importante si expones datos sensibles.
# Arrancar osqueryi con verbose para ver el planificador
osqueryi --verbose --disable_extensions=false
# Listar tablas disponibles en tu build actual
osquery> .tables
# Ver el schema de una tabla
osquery> .schema process_events
Instalación en Debian, Ubuntu y RHEL en 2026
El proyecto publica repositorios APT y YUM firmados con GPG. Para Debian 12/Ubuntu 24.04:
Tras instalar, copia la configuración de ejemplo y arranca el daemon como servicio:
sudo cp /usr/share/osquery/osquery.example.conf /etc/osquery/osquery.conf
sudo systemctl enable --now osqueryd
sudo systemctl status osqueryd
# Verificar que está recogiendo métricas
sudo tail -f /var/log/osquery/osqueryd.results.log
Para entornos donde el binario oficial no encaje (contenedores minimalistas, arquitecturas exóticas) existen builds mantenidos por la comunidad, notablemente el fork osquery-plus con parches para arm64 y musl libc. Para servidores estándar, quédate con el paquete oficial: incluye actualizaciones automáticas y firma la release.
Queries de detección alineadas con MITRE ATT&CK
Lo interesante de osquery no es que puedas listar procesos (eso lo hace ps), sino que puedes hacer joins entre tablas para reconstruir tácticas ATT&CK enteras. Estos son cuatro ejemplos que uso en producción, con la técnica ATT&CK correspondiente entre paréntesis.
T1053.003: Persistencia por cron jobs sospechosos.
SELECT c.command, c.path, c.event, u.username, u.uid
FROM crontab c
LEFT JOIN users u ON c.path LIKE '%/' || u.username || '/%'
WHERE c.command LIKE '%curl%'
OR c.command LIKE '%wget%'
OR c.command LIKE '%base64 -d%'
OR c.command LIKE '%/tmp/%'
OR c.command LIKE '%bash -i%';
T1543.002: Unidades systemd creadas fuera de rutas estándar (típico de mineros Kinsing).
SELECT id, description, fragment_path, user, unit_file_state
FROM systemd_units
WHERE fragment_path NOT LIKE '/lib/systemd/%'
AND fragment_path NOT LIKE '/usr/lib/systemd/%'
AND fragment_path NOT LIKE '/etc/systemd/%'
AND unit_file_state = 'enabled';
T1055: Procesos con memoria RWX (indicador de inyección). Requiere la tabla process_memory_map, que hace ptrace y necesita CAP_SYS_PTRACE. En osquery 5.15 se optimizó para no leer regiones enormes.
SELECT p.pid, p.name, p.cmdline, m.start, m.end, m.permissions
FROM processes p
JOIN process_memory_map m ON p.pid = m.pid
WHERE m.permissions = 'rwxp'
AND p.name NOT IN ('java', 'node', 'python3'); -- runtimes JIT esperados
T1071.001: Conexiones salientes a puertos no comunes.
SELECT p.name, p.cmdline, s.remote_address, s.remote_port, s.state
FROM process_open_sockets s
JOIN processes p ON s.pid = p.pid
WHERE s.state = 'ESTABLISHED'
AND s.remote_port NOT IN (80, 443, 53, 22, 5432, 6379)
AND s.remote_address NOT LIKE '10.%'
AND s.remote_address NOT LIKE '192.168.%'
AND s.remote_address NOT LIKE '172.%';
Estas queries funcionan aisladamente en osqueryi, pero su verdadero valor emerge cuando las programas en packs y correlas resultados en el tiempo. Si estás construyendo detecciones a nivel de kernel con eBPF (una capa complementaria), revisa nuestra comparativa de Falco, Tetragon y Tracee para seguridad runtime antes de decidir qué eventos capturas dónde.
Packs programados y logging diferencial
Un pack es un fichero JSON que agrupa queries relacionadas con su intervalo de ejecución, plataforma objetivo y descripción. osquery incluye packs oficiales en /usr/share/osquery/packs/: incident-response.conf, vuln-management.conf, hardware-monitoring.conf, it-compliance.conf. Palantir mantiene además una configuración completa en GitHub que muchos equipos usan como punto de partida.
La distinción crítica es snapshot: true vs snapshot: false. Con snapshot: true, cada ejecución envía el resultado completo (útil para inventario diario). Con snapshot: false (el default para queries programadas), osquery mantiene el resultado de la ejecución anterior en su base RocksDB local y envía solamente el diff: filas nuevas (action: added) y filas desaparecidas (action: removed). Esto reduce drásticamente el volumen de logs cuando el estado del sistema es relativamente estable.
Los logs se escriben por defecto en /var/log/osquery/osqueryd.results.log con un formato JSON por línea (JSONL), ideal para consumir con Filebeat, Vector o Fluent Bit y reenviarlos a un SIEM.
Gestión de flota con Fleet DM y Kolide
Instalar osquery en tres hosts es trivial. Hacerlo en trescientos y mantener la configuración actualizada, versionar packs, correlar respuestas y responder a incidentes ya requiere un plano de control. Las dos opciones maduras en 2026 son Fleet DM (código abierto MIT, con edición comercial) y Kolide K2 (SaaS enfocado en device trust). Ambas hablan el protocolo TLS server nativo de osquery, así que no necesitas parches en el agente.
Fleet corre como un binario Go conectado a MySQL y Redis. Genera certificados TLS que despliegas a cada host y expone una UI web más API REST para lanzar queries en tiempo real, gestionar packs y ver los resultados de forma agregada. La documentación oficial de Fleet incluye una guía de despliegue en Kubernetes que uso yo en producción con unos 800 endpoints.
La feature más útil de Fleet para respuesta a incidentes son las live queries: escribes SQL en la UI y se ejecuta contra todos los hosts en menos de un minuto, sin esperar al siguiente tick del scheduler. Cuando un IOC nuevo aparece en un feed, puedes escribir la query correspondiente y obtener la lista de hosts afectados en tiempo casi real. Personalmente, esta es la razón por la que dejé de mantener scripts de Ansible ad-hoc para IR.
Integración con Elastic, Splunk y Wazuh
osquery no es un SIEM: recoge datos, no los analiza ni los almacena a largo plazo. Necesitas un backend. Las tres integraciones más comunes en Linux son:
Elastic Stack: osquery-beat (ahora integrado en el paquete oficial de Agent) reenvía los results.log a Elasticsearch con mapping ECS. Kibana incluye dashboards nativos para osquery bajo la app Security.
Splunk: el TA Splunk_TA_osquery parsea el JSONL, extrae los campos action/columns/hostIdentifier y los normaliza al CIM (Common Information Model).
Wazuh: Wazuh incluye un módulo osquery desde la 4.x que lanza osqueryd como subproceso y correla los resultados con las reglas Wazuh. Si ya tienes Wazuh desplegado por auditd/AIDE, es la opción con menos fricción.
Para arquitecturas más recientes, Vector.dev con la source file y el transform remap te permite normalizar los eventos a un esquema propio antes de mandarlos a ClickHouse o Loki. Si ya tienes montado un stack de detección con auditd y Wazuh y estás valorando añadir osquery encima, revisa primero nuestra guía de detección de intrusiones con auditd, AIDE y Wazuh para no duplicar telemetría innecesaria.
osquery vs auditd vs Falco: cuándo usar cada uno
Esta es la pregunta que más me hacen. La respuesta corta: las tres herramientas atacan capas distintas del problema y en producción coexisten con roles diferenciados.
Dimensión
osquery
auditd
Falco
Modelo
Pull (SQL bajo demanda)
Push (kernel → userspace)
Push (eBPF/kmod streaming)
Fuente principal
/proc, /sys, tablas virtuales
Kernel Audit subsystem
eBPF / kernel module
Latencia de detección
Segundos a minutos
Milisegundos
Milisegundos
Riqueza de contexto
Muy alta (JOINs entre tablas)
Media (eventos crudos)
Alta (rules DSL con macros)
Impacto CPU típico
<2%
3-8% con reglas amplias
1-5% (eBPF)
Curva de aprendizaje
Baja (SQL)
Alta (audit.rules)
Media (YAML rules DSL)
Retroactividad
Sí (queries sobre estado actual)
No (solo streaming)
No (solo streaming)
Multi-plataforma
Linux, macOS, Windows
Solo Linux
Linux (portable/kmod)
En la práctica: auditd para eventos syscall críticos con requisitos de compliance (STIG, PCI). Falco o Tetragon para reglas de detección en tiempo real donde importa el orden y la baja latencia (fuga de contenedores, exec en pods). Y osquery para inventario, hunting histórico y respuesta a incidentes distribuida (lanzar una query contra 800 hosts y consolidar respuestas en 60 segundos). Las tres alimentan el mismo SIEM y los tres tipos de señal se correlan allí.
Tuning de rendimiento y watchdog
osquery incluye un watchdog que mata el proceso worker si excede umbrales de memoria o CPU sostenida. Los valores por defecto son conservadores (200 MB RSS, 20% de CPU durante intervalos de watchdog). En hosts con packs pesados o tablas caras como hash o file, puedes toparte con logs del tipo osqueryd worker (12345) memory limits exceeded: restarting.
El parámetro schedule_splay_percent es crítico en flotas grandes. Sin él, todos los hosts ejecutan la misma query en el mismo segundo del minuto y saturas el backend TLS; con un splay del 10% cada host aleatoriza el arranque de sus queries dentro de esa ventana. Y ya que hablamos de hardening del propio servicio, revisa nuestra guía sobre hardening de servicios systemd con ProtectSystem y NoNewPrivileges. El unit file oficial de osqueryd es funcional pero puede endurecerse bastante.
Preguntas frecuentes
¿Sigue mantenido osquery en 2026?
Sí. El proyecto está bajo la Linux Foundation con releases mensuales; la 5.15 se publicó en junio de 2026 con soporte estable para eventos eBPF. Empresas como Uber, Fastly, GitHub y varios bancos europeos lo usan en producción a escala de decenas de miles de hosts.
¿Cuál es la diferencia entre osquery y auditd?
auditd es un consumidor push del subsistema Audit del kernel: recibe eventos syscall en streaming en milisegundos y los escribe a disco. osquery es una capa de consulta pull sobre estado del sistema con SQL. Puedes hacer hunting retroactivo con osquery (¿qué procesos hay ahora?), pero no puedes hacerlo con auditd, que solo tiene lo que ocurrió mientras estaba activo. Son complementarios, no sustitutos.
¿Cuánto consume osquery en un servidor Linux?
Con la configuración por defecto y sin packs, osqueryd consume 40-60 MB de RSS y menos del 1% de CPU. Al añadir packs completos como incident-response, el consumo sube a 150-200 MB y 2-3% de CPU medio, con picos al ejecutar queries de hash o file. El watchdog te protege de fugas, pero conviene tunear los umbrales según tu perfil de carga.
¿Puedo usar osquery en contenedores Docker?
Sí, pero con matices. Correr osqueryd dentro de cada contenedor da visibilidad de ese contenedor, pero es antipatrón de imagen. La aproximación recomendada es correr osqueryd en el host con acceso a /proc, /sys y opcionalmente al socket de Docker; osquery expone entonces las tablas docker_containers, docker_container_processes y docker_image_layers para inspeccionar el estado desde fuera.
¿Qué es Fleet DM y por qué necesito un gestor de flota?
Fleet DM es un servidor de código abierto (licencia MIT) que implementa el protocolo TLS server de osquery. Te permite gestionar configuración, ejecutar live queries contra toda la flota, distribuir packs versionados y visualizar resultados agregados. Por encima de 20-30 hosts, gestionar osquery a mano con Ansible se vuelve inviable, así que Fleet o Kolide son prácticamente obligatorios.
¿osquery reemplaza a Falco para seguridad de contenedores?
No. Falco opera en la capa de kernel con eBPF y detecta eventos con latencia sub-segundo, ideal para reglas del tipo bloquea si un pod ejecuta bash. osquery da visibilidad pull con SQL, ideal para lístame todos los pods con imagen sin firma cosign. Los equipos maduros ejecutan ambos: Falco para respuesta en tiempo real, osquery para inventario y hunting histórico.
Priya is a threat hunter who spent four years at CrowdStrike on the OverWatch team chasing eCrime intrusions on Linux endpoints, then moved to a mid-size SaaS company in 2023 to build out their detection engineering function from scratch. Her day job is writing Falco rules, tuning auditd, and arguing with developers about why curl-piped-to-bash in a Dockerfile is not, in fact, fine.
She's GCFA and GCIH certified, contributed a handful of Sigma rules to the public repo, and gave a talk at BSides Bangalore on detecting Kinsing miner infections through cgroup anomalies.
Before security she did three years as a Linux sysadmin at Flipkart's logistics arm, which is where she learned that most "sophisticated APT activity" turns out to be a forgotten cron job running as root.
Falco, Tetragon y Tracee son los tres pilares de la seguridad runtime con eBPF. Esta guía 2026 compara detección, enforcement, rendimiento y casos de uso reales, con reglas y despliegues listos para producción en Linux y Kubernetes.
Guía práctica para implementar detección de intrusiones en Linux combinando auditd, AIDE y Wazuh. Desde reglas de auditoría alineadas con MITRE ATT&CK hasta respuesta automatizada con Wazuh como SIEM/XDR.
