SPL para principiantes: búsqueda e investigación en Splunk

La búsqueda inicial

Una búsqueda simple en Splunk puede comenzar así:

index=lab sourcetype=auth earliest=-24h

El Selector de Rango de Tiempo puede definir el tiempo, pero la escritura explícita de earliest y latest es útil para la reproducibilidad y la documentación. index limita a un repositorio específico y sourcetype describe la estructura de la fuente. Se puede añadir una condición de campo ya en la búsqueda inicial:

index=lab sourcetype=auth action=failure earliest=-24h

Cuando un campo existe en el momento de la búsqueda, especificar `field=value` es más preciso que una búsqueda de texto libre. Se requieren comillas para valores con espacios. Los comodines pueden ser útiles, pero un comodín principal o una búsqueda amplia afectan el rendimiento y pueden generar resultados inesperados.

Pipe y comandos de visualización

El signo | pasa los resultados al siguiente comando. `fields` mantiene o elimina campos, y `table` muestra una tabla en el orden seleccionado. Al comienzo de una investigación, table ayuda a la lectura, pero no lo use demasiado pronto si un comando posterior necesita campos que haya eliminado.

index=lab sourcetype=auth earliest=-24h
| fields _time user src_ip action host
| table _time user src_ip action host

`rename` cambia nombres para la visualización. `sort` ordena y `head` limita los resultados. Los eventos se muestran generalmente del más reciente al más antiguo, pero al construir una línea de tiempo, se recomienda ordenar explícitamente:

index=lab sourcetype=auth user="student" earliest=-4h
| table _time user src_ip action host
| sort 0 _time

El número 0 en sort cancela una limitación predeterminada particular de la cantidad de resultados a ordenar, pero en grandes volúmenes, la ordenación completa puede ser costosa. En una investigación, use un rango limitado.

eval — Creación de campos

`eval` calcula o crea un campo. Se pueden usar if, case, lower, coalesce, tonumber y otras funciones. Por ejemplo, crear un Outcome uniforme:

index=lab sourcetype=auth earliest=-24h
| eval outcome=case(action="success", "Success", action="failure", "Failure", true(), "Other")
| table _time user src_ip action outcome

`where` filtra usando una expresión después de que los eventos han sido recolectados o después de que se han creado campos. La búsqueda inicial `action=failure` suele ser preferible para un filtrado básico. `where` es útil para comparar campos, condiciones numéricas o campos creados con eval.

index=lab sourcetype=auth earliest=-24h
| stats count as attempts by user src_ip
| where attempts >= 5
| sort - attempts

stats — Convertir eventos en una pregunta

`stats` calcula agregaciones sobre los resultados. Sin BY, se obtiene una sola fila; con BY, se obtiene una fila para cada combinación de valores. Los comandos comunes incluyen count, sum, avg, min, max, values y dc — distinct count.

index=lab sourcetype=auth action=failure earliest=-24h
| stats count as failures,
        earliest(_time) as first_seen,
        latest(_time) as last_seen,
        values(src_ip) as src_ips
  by user
| convert ctime(first_seen) ctime(last_seen)
| sort - failures

`values` devuelve valores únicos sin un orden garantizado y puede crecer. Úselo con precaución y prefiera una lista limitada o un Drill-down cuando haya muchas IPs. `list` guarda valores en orden, pero puede consumir más memoria.

stats frente a eventstats y streamstats

Los principiantes deben dominar `stats` antes de usar `transaction`. `transaction` puede ser conveniente para agrupar, pero en grandes volúmenes es costosa y a veces oculta la lógica. Muchas veces `stats`, `streamstats` o `eventstats` ofrecen una solución más eficiente y transparente.

Ventanas de tiempo y timechart

`timechart` crea una serie temporal y agrupa por `_time`. Es bueno para identificar picos, tendencias y cambios en el volumen. Por ejemplo:

index=lab sourcetype=auth action=failure earliest=-24h
| timechart span=30m count by src_ip limit=10

Elija el span según la pregunta. Una ventana demasiado pequeña generará ruido, y una ventana demasiado grande ocultará los picos. timechart es un comando de transformación: el resultado es una tabla resumida, no los eventos brutos. Para fines de evidencia, realice un Drill-down al rango y la IP relevantes.

Ejercicio: Fallos y éxitos en la misma ventana

El objetivo es encontrar ventanas en las que el mismo usuario y IP generaron varios fallos y al menos un éxito. La siguiente Query utiliza eval, bin y stats:

index=lab sourcetype=auth earliest=-24h
| eval failed=if(action="failure", 1, 0), success=if(action="success", 1, 0)
| bin _time span=30m
| stats sum(failed) as failures,
        sum(success) as successes,
        earliest(_time) as window_start,
        latest(_time) as window_end
  by _time user src_ip
| where failures >= 5 AND successes >= 1
| sort - failures

La consulta señala una ventana que requiere investigación. Como los datos se resumieron, no prueba que el éxito ocurrió después de los fallos. Use el resultado para realizar un Drill-down en user, src_ip y el tiempo:

index=lab sourcetype=auth user="student" src_ip="203.0.113.25" earliest="08/01/2026:09:00:00" latest="08/01/2026:09:30:00"
| table _time user src_ip action host reason
| sort 0 _time

Verifique: ¿El éxito pertenece al mismo Host o App? ¿La dirección de origen es una VPN? ¿Los fallos fueron causados por una contraseña antigua en el servicio? ¿Hay actividad de seguimiento? SPL proporciona los datos; la clasificación requiere contexto.

Campos, extracción y CIM

Splunk extrae campos durante la indexación o la búsqueda. Un campo faltante puede requerir `rex`, `spath` para JSON o la definición de extracción de campo. La extracción ad-hoc puede ayudar en el laboratorio, pero la detección en producción necesita un analizador y un modelo de datos mantenidos.

CIM normaliza conceptos entre fuentes, por ejemplo, Authentication.user o Network_Traffic.src. Cuando la organización utiliza CIM, se pueden construir detecciones y paneles de control que se pueden usar en varios productos. Debe asegurarse de que los datos realmente se ajusten al modelo y no solo que la aplicación esté instalada.

Mejora del rendimiento y la legibilidad

• Establezca el rango de tiempo lo más estrecho posible.
• Comience con index, sourcetype y campos mapeados.
• Filtre temprano antes de stats o sort.
• Evite los comodines iniciales y la búsqueda de texto amplia cuando exista un campo.
• Use fields para reducir la carga útil, pero no antes de un comando que necesite el campo.
• Limite values/list y las operaciones que consumen mucha memoria.
• Dé nombres claros a los campos usando `as`.
• Guarde la consulta con descripción, propietario, tiempo y versión.
• Pruebe con una muestra pequeña antes de un rango largo.

Errores comunes

• Buscar en todos los índices sin necesidad.
• Asumir que un campo action o user existe en cada sourcetype.
• Usar table demasiado pronto y eliminar un campo que se necesita más adelante.
• Interpretar stats como una línea de tiempo precisa.
• Usar transaction como valor predeterminado.
• Activar una alerta en una consulta no probada contra la línea base.
• Copiar SPL de otra versión o modelo de datos sin adaptación.
• Ignorar la zona horaria y el retraso de ingesta.

Lista de verificación para la práctica

1. Encuentre el index y el sourcetype de los datos de laboratorio.
2. Muestre cinco eventos y verifique los campos.
3. Filtre un usuario o una IP.
4. Muestre una línea de tiempo usando table y sort.
5. Resuma los fallos usando stats.
6. Cree un campo usando eval y fíltralo con where.
7. Muestre el volumen a lo largo del tiempo usando timechart.
8. Escriba lo que cada consulta prueba y lo que no prueba.

Resumen y CTA

Establezca un pequeño índice de laboratorio o use datos autorizados, y ejecute el mismo escenario en tres vistas: Eventos sin procesar, estadísticas y gráfico de tiempo. Escriba junto a cada vista qué pregunta responde y qué contexto falta. El siguiente paso es convertir una búsqueda estable en una detección con Propietario, Umbral y Playbook, no solo guardar una consulta impresionante.

Preguntas frecuentes