Detección de firmas maliciosas

Introducción

Los Sistemas de Detección de Intrusiones (IDS), como Snort, dependen en gran medida de reglas para identificar el tráfico de red malicioso. Una regla bien diseñada actúa como una firma, permitiendo que el sistema dispare una alerta cuando se observan patrones específicos en los paquetes de datos.

La detección basada en firmas funciona reconociendo patrones conocidos, no comprendiendo directamente la intención del atacante. Esto la hace rápida y útil, pero también imperfecta. Si el patrón es demasiado amplio, genera falsos positivos. Si es demasiado estrecho, los atacantes pueden evadirlo con pequeños cambios. Por lo tanto, escribir buenas reglas es un ejercicio de equilibrio entre precisión y cobertura.

En este laboratorio, te pondrás en la piel de un analista de seguridad. Escribirás reglas de Snort de coincidencia de contenido capaces de detectar ataques en la capa de aplicación. Específicamente, analizarás un payload de ataque de inyección SQL capturado en un archivo PCAP (Packet Capture) y crearás reglas de Snort precisas utilizando tanto coincidencia de contenido básica como expresiones regulares avanzadas (PCRE) para inspeccionar el tráfico HTTP y alertar siempre que se detecte esa cadena maliciosa.

Analizar el payload del ataque (PCAP)

En este paso, analizarás un archivo de captura de paquetes de red para comprender cómo se ve un payload malicioso. Antes de escribir una regla de detección, un analista de seguridad debe saber exactamente qué está tratando de detectar.

Este orden es importante. Un error común de los principiantes es comenzar a escribir firmas antes de inspeccionar el tráfico real. En la práctica, los defensores suelen comenzar con evidencia: un PCAP, una muestra de registro o una prueba de concepto de un exploit. Solo después de comprender el patrón observable lo traducen en una regla.

Tu entorno ha sido preconfigurado con un archivo llamado sqli_attack.pcap en tu directorio ~/project. Este archivo contiene un paquete de red simulado donde un atacante intenta realizar un ataque de inyección SQL contra un servidor web.

Para inspeccionar el contenido de este archivo PCAP, puedes usar una herramienta llamada tcpdump. El comando tcpdump es un potente analizador de paquetes de línea de comandos. Al usar el flag -A, puedes imprimir el contenido del paquete en ASCII (texto plano), lo cual es perfecto para leer solicitudes HTTP. El flag -r le indica a tcpdump que lea desde un archivo en lugar de una interfaz de red activa.

Ejecuta el siguiente comando en tu terminal para analizar el payload:

tcpdump -A -r sqli_attack.pcap

Deberías ver una salida similar a la siguiente:

reading from file sqli_attack.pcap, link-type EN10MB (Ethernet), snapshot length 262144
10:23:45.123456 IP 192.168.1.100.12345 > 192.168.1.10.http: Flags [P.], seq 1:78, ack 1, win 8192, length 77: HTTP: GET /login.php?user=admin'%20UNION%20SELECT%201,2,3-- HTTP/1.1
E..u..@.@............9.P..P.P.......+......GET /login.php?user=admin'%20UNION%20SELECT%201,2,3-- HTTP/1.1
Host: example.com

Observa detenidamente la parte de texto plano de la salida. Puedes ver una solicitud HTTP GET realizada a /login.php. Nota el parámetro user: admin'%20UNION%20SELECT%201,2,3--.

El %20 es la representación codificada en URL de un carácter de espacio. La frase UNION SELECT es una firma clásica de un ataque de inyección SQL, donde un atacante intenta combinar los resultados de su propia consulta maliciosa a la base de datos con la consulta original. Esta es la firma exacta que queremos detectar.

Escribir reglas de coincidencia de contenido

En este paso, escribirás tu primera regla personalizada de Snort para detectar la firma de inyección SQL que descubriste en el paso anterior.

La palabra clave content es la forma más sencilla de inspección de payload. Es rápida y fácil de razonar porque busca una cadena literal. La coincidencia literal suele ser el primer borrador adecuado para una firma porque hace que la lógica de detección sea transparente.

Las reglas de Snort se escriben con una sintaxis específica. Una regla básica consta de un encabezado de regla y opciones de regla.

• El encabezado define la acción, el protocolo, las direcciones IP de origen/destino y los puertos.
• Las opciones definen el contenido específico que se debe buscar y el mensaje que se mostrará cuando se active una alerta.

Crearemos una regla que busque la cadena exacta UNION%20SELECT en cualquier tráfico TCP destinado al puerto 80 (el puerto HTTP estándar).

Abre el archivo de reglas personalizadas usando el editor de texto nano:

nano ~/project/rules/local.rules

Agrega la siguiente línea al archivo:

alert tcp any any -> any 80 (msg:"Basic SQL Injection Detected"; content:"UNION%20SELECT"; sid:1000001; rev:1;)

Analicemos qué significa esta regla:

• alert: La acción a tomar cuando la regla coincide (generar una alerta).
• tcp: El protocolo a inspeccionar.
• any any -> any 80: IP y puerto de origen (cualquiera) hacia la IP de destino (cualquiera) en el puerto 80.
• msg:"...": El mensaje de alerta que se mostrará al analista.
• content:"UNION%20SELECT": La cadena exacta que Snort buscará en el payload del paquete.
• sid:1000001: El ID de Snort. Las reglas personalizadas deben tener un ID de 1,000,000 o superior.
• rev:1: El número de revisión de la regla.

Después de agregar la línea, guarda el archivo y sal de nano presionando Ctrl+O, Enter y luego Ctrl+X.

Puedes verificar el contenido de tu archivo de reglas usando el comando cat:

cat ~/project/rules/local.rules

Configurar PCRE (Expresiones Regulares)

En este paso, mejorarás tus capacidades de detección utilizando PCRE (Perl Compatible Regular Expressions).

Las expresiones regulares aumentan la flexibilidad porque describen familias de patrones en lugar de una secuencia de bytes exacta. Eso es potente, pero también aumenta el riesgo de coincidencias excesivas. Los defensores usan PCRE cuando es probable que los atacantes varíen el formato mientras mantienen reconocible el comportamiento subyacente.

Aunque la palabra clave content es rápida y efectiva, es muy rígida. Los atacantes a menudo intentan evadir la detección alterando ligeramente sus payloads. Por ejemplo, en lugar de %20 (espacio codificado en URL), un atacante podría usar un espacio normal (``), múltiples espacios o un signo más (+). Una coincidencia simple de content pasaría por alto estas variaciones.

PCRE te permite escribir patrones flexibles. Escribiremos una segunda regla que utiliza una expresión regular para detectar variaciones del ataque UNION SELECT.

Abre tu archivo de reglas nuevamente:

nano ~/project/rules/local.rules

Agrega la siguiente regla nueva en una línea nueva debajo de tu primera regla:

alert tcp any any -> any 80 (msg:"Advanced SQL Injection Detected"; pcre:"/UNION(%20|\s|\+)SELECT/i"; sid:1000002; rev:1;)

Analicemos la opción pcre:

• pcre:"/ ... /i": Las barras diagonales denotan el principio y el final de la expresión regular. La i al final hace que la búsqueda no distinga entre mayúsculas y minúsculas (coincidirá con union, UNION, UnIoN, etc.).
• UNION: Coincide con la palabra UNION.
• (%20|\s|\+): Este es un grupo de captura con lógica OR (|). Coincide con %20, O un carácter de espacio en blanco (\s), O un signo más (\+).
• SELECT: Coincide con la palabra SELECT.

Guarda el archivo y sal de nano (Ctrl+O, Enter, Ctrl+X).

Tu archivo local.rules ahora debería contener dos reglas distintas diseñadas para detectar intentos de inyección SQL.

Validar la detección de reglas

En este paso final, pondrás a prueba tus reglas personalizadas. Ejecutarás Snort en modo offline, indicándole que lea el archivo sqli_attack.pcap y aplique las reglas que acabas de escribir en local.rules.

Probar contra una muestra conocida es esencial porque una regla que parece correcta en papel puede fallar en la operación. La validación confirma que la regla realmente se dispara con el tráfico que pretendías, lo cual es el requisito mínimo antes de confiar en ella en un entorno real.

Snort se puede ejecutar con varios flags. Esto es lo que usaremos:

• -q: Modo silencioso (Quiet). Esto suprime el banner grande y el texto de inicialización, haciendo que la salida sea más fácil de leer.
• -c: Especifica el archivo de configuración o reglas a utilizar.
• -r: Especifica el archivo PCAP a leer.
• -A console: Le dice a Snort que imprima las alertas directamente en la consola de la terminal.

Ejecuta el siguiente comando para probar tus reglas contra el payload malicioso:

sudo snort -q -c rules/local.rules -r sqli_attack.pcap -A console

Si tus reglas se escribieron correctamente, deberías ver una salida similar a esta:

10/23-10:23:45.123456  [**] [1:1000001:1] Basic SQL Injection Detected [**] [Priority: 0] {TCP} 192.168.1.100:12345 -> 192.168.1.10:80
10/23-10:23:45.123456  [**] [1:1000002:1] Advanced SQL Injection Detected [**] [Priority: 0] {TCP} 192.168.1.100:12345 -> 192.168.1.10:80

¡Felicidades! Ambas reglas se activaron con éxito. La primera regla coincidió con la cadena exacta y la segunda regla coincidió con el patrón utilizando expresiones regulares. Has actuado con éxito como analista de seguridad, identificando una amenaza y desplegando una firma para detectarla.

Resumen

En este laboratorio, obtuviste experiencia práctica en la detección de intrusiones en la red escribiendo reglas personalizadas de Snort. Comenzaste analizando una captura de paquetes sin procesar para identificar la firma específica de un ataque de inyección SQL. Luego aprendiste a traducir esa firma en una regla de Snort básica de coincidencia de contenido. Finalmente, mejoraste tus capacidades de detección implementando expresiones regulares compatibles con Perl (PCRE) para detectar variaciones del ataque, y validaste con éxito tus reglas ejecutando Snort contra el tráfico malicioso. Estas habilidades son fundamentales para cualquier profesional de ciberseguridad encargado de defender la infraestructura de red.