El desarrollo de Reglas para Snort, que es uno de los sistemas de detección de intrusiones de red más populares, es una habilidad fundamental para detectar nuevos ciberataques cada vez más emergentes. Tan emergente, que gran parte de empresas más relevantes, ya lo estan empezando a usar, como observamos en la nueva version de Palo Alto ( PAN OS 10.0 ) la cual incluye como una de sus grandes mejoras la implementación/creación de relas SNORT.

A lo largo de este post, intentaremos conocer las reglas SNORT, cómo las mismas funcionan y cómo podriamos amplicarlas. No os puedo engañar, sirviéndome a mi también como punto de aprendizaje , intentando profundizar mucho más en ellas. Para los principiantes, es difícil determinar si una regla está escrita correctamente sin poder probarla en un entorno realista.

¿ Que son las reglas SNORT ?

SNORT es un software NIDS de código abierto. Combinando los beneficios de la inspección basada en firmas, protocolos y anomalías, SNORT es la tecnología IDS / IPS más utilizada en todo el mundo. Es capaz de realizar un "análisis de alto nivel" en todo el tráfico que fluye a través de su sensor.

La ubicación del sensor es importante. Normalmente, un buen punto de entrada se encuentra en el límite entre la LAN e Internet. Situar SNORT o aplicarlos un punto como los firewall perimetrales o similar, en un sitio estratégico, permite analizar todo el tráfico que entra y sale de la red local.

También es importante definir qué detectar con SNORT. Como las reglas de SNORT pueden detectar cualquier cosa en el tráfico, es importante definir claramente las necesidades. ¿Es suficiente detectar hosts comprometidos? ¿Hay políticas que se deban hacer cumplir? ¿Es útil registrar todos los ataques entrantes hacia la red?. Todas estas son preguntas que debemos responder antes de implementar las reglas de Snort.

Reglas de snort

SNORT puede implementar cualquier tipo de regla, las reglas de SNORT no están incluidas con el software. Sin embargo, existen diferentes fuentes para encontrar e implementar reglas:

1. Equipo de Investigación de Vulnerabilidad (VRT) : Estas son las reglas de Snort “oficiales”. Son proporcionados por Sourcefire y son actualizados semanalmente por Sourcefire VRT.
2. Emerging Threats (ET) : Las reglas de amenazas emergentes son un proyecto comunitario de código abierto. Este conjunto es el conjunto de reglas de Snort más diverso y de movimiento más rápido. Las reglas se actualizan varias veces al día.
3. Reglas de la comunidad : Estas reglas son creadas por la comunidad de SNORT. Hay muy pocas reglas y la última versión es de 2007 para Snort 2.4. La mayoría de las amenazas que detectan ya están implementadas en ET o VRT.
4. Reglas caseras y otras : Son las reglas, creadas y mantenidas localmente, según las necesidades específicas de la red. También pueden existir otras reglas. Para amenazas específicas y otras amenazas “únicas”, los motores de búsqueda pueden proporcionar reglas más específicas, pero es necesario saber qué buscar.

Definir reglas SNORT

Una regla de SNORT puede definirse mediante muchos parámetros. Una regla se compone de dos partes distintas: El encabezado de la regla y las opciones de la regla.

El encabezado de la regla contiene la acción de las mismas, el protocolo, las direcciones IP de origen y destino y las máscaras de red, y la información de los puertos de origen y destino. La sección de opciones de reglas contiene mensajes de alerta e información sobre qué partes del paquete deben inspeccionarse para determinar si se debe tomar la acción de la regla. Un ejemplo :

alert tcp any any -> 10.0.0.0/24 80 \ (content:"|00 00 00 00|"; depth: 8; \ msg:"Error de bytes nulos"; sid:9876)

Esta regla activará una alerta si se encuentran cuatro bytes nulos en los primeros ocho bytes de todo el tráfico enviado al puerto 80 a la red 10.0.0.0/24. El ID único de la regla es 9876 y el mensaje de alerta es "Error de bytes nulos". Las reglas son poderosas y hay muchas posibilidades: es posible buscar bytes en una posición específica, dentro del rango de otros bytes, o contar el número de ocurrencias de una coincidencia antes de una alertar. También es posible utilizar Expresiones regulares compatibles con Perl (PCRE) en los datos y limitar la búsqueda a bytes específicos.

Para que una regla active una alerta, todos los elementos contenidos en las opciones de la regla deben ser verdaderos. Estos elementos se comprueban secuencialmente. Si el primero es falso, los demás no se comprobarán. Por tanto, el orden de los argumentos es muy importante para optimizar las reglas.

Métricas en las reglas SNORT

Las métricas que deben evaluarse para cada conjunto de reglas incluyen por ejemplo:

Nivel de amenaza

Las amenazas por ejemplo, podriamos dividirlas en tres categorías:

1. Comprometidos : Estos son los incidentes más importantes. Incluyen hosts comprometidos, hosts infectados por virus o malwares, o usuarios que realizan acciones ilegales. Cada incidente debe ser detectado y actuar sobre el mismo.
2. Violaciones de políticas : Cuando un usuario no cumple con las políticas, este conjunto de reglas activará una alerta. Los ejemplos típicos son las reglas de Peer-to-Peer (P2P) e Internet Relay Chat (IRC), por ejemplo.
3. Ataques dirigidos, exploraciones y otros :  Los ataques potenciales entran en esta categoría, incluso si no tienen éxito. No significan que un host se haya visto comprometido. Los virus entrantes y otros malwares entrantes se clasificarán aquí. Proporcionan información sobre la actividad de la red, pero no requieren necesariamente ninguna acción.

La dirección de estas alertas es importante, porque los análisis y ataques salientes podrían indicar que un host ha sido comprometido, mientras que los análisis y ataques entrantes solo indican un evento actual por el que no se puede hacer mucho.

Para cada regla (o conjunto de reglas), se deben evaluar los beneficios. Si la proporción de falsos positivos para una regla es demasiado alta, es posible que no sea tan útil. Se necesita un análisis en profundidad de la regla y cierta interacción con los usuarios finales para evaluar esto adecuadamente.

La complejidad de las reglas se basa principalmente en el número de bytes comprobados en el tráfico, cuanto más específico, mejor. Se espera que las reglas que comprueben muy pocos bytes generen muchos falsos positivos con una gran cantidad de tráfico. Sin embargo, también depende de los bytes mismos: la comprobación de una cadena larga y común desencadenará más falsos positivos que la comprobación de unos pocos bytes inusuales.

Clasificación de las reglas SNORT

Utilizando la clasificación propuesta por Snort ,  se propone el siguiente esquema de clasificación:

• Comprometido : Esta categoría contiene todas las firmas que detectan un exploit exitoso o que indican que un host ha sido comprometido. Los siguientes conjuntos de reglas contienen reglas que se incluyen en esta categoría: attack-answers.rules, backdoor.rules, ddos.rules, emergen-attack response.rules, emergenvirus.rules, virus.rules. Esta categoría propuesta solo detecta hosts comprometidos o que ejecutan malware que podrían llevar a un atacante remoto a tomar el control abriendo una puerta trasera o robando contraseñas. Los adwares y otros badwares no están incluidos y se colocaron en otra categoría.
• Política : Esta categoría contiene todas las firmas que ayudan a detectar P2P e IRC, que no están permitidas por nuestra organización o que recomiendan ciertos CERTs. Los siguientes conjuntos de reglas contienen reglas que entran en esta categoría: p2p.rules, emergentes-p2p.rules y local.rules. El último, local.rules, contiene reglas caseras adicionales para detectar el uso de IRC. Los conjuntos P2P contienen firmas para detectar todo tipo de tráfico, y hay algunas reglas que deben desactivarse antes de que este conjunto dé resultados utilizables.
• Ataques y otros : Otros archivos fuente entran en esta gran categoría. Existen otras políticas como mensajería instantánea (IM), información sobre ataques entrantes o conjuntos para detectar hosts que ejecutan programas publicitarios y otros programas maliciosos.

Evaluación de las reglas SNORT

Pear-to-Pear

La primera gran sorpresa aquí, es la gran cantidad de protocolos diferentes que se ven en el tráfico. Parece que Bittorrent es la red P2P dominante, muchos usuarios todavía confían en protocolos antiguos.

La eficiencia de Snort para detectar estos protocolos varía de un caso a otro. Algunos protocolos P2P se reconocen muy fácilmente, mientras que otros generan demasiados falsos positivos para proporcionar datos útiles sobre el uso de P2P.

Las reglas ET y VRT proporcionan un archivo llamado p2p.rules que contiene todo tipo de reglas que detectan el tráfico P2P.

Emule es el protocolo de intercambio de archivos que tiene más reglas en VRT y ET, tal vez por su uso entre los usuarios a lo largo del tiempo. Sin embargo, también es el protocolo de intercambio de archivos más difícil de detectar . Con todas las reglas basadas en dos o cuatro bytes, tiene las reglas más débiles.

Las reglas de Emule plantean problemas en muchos niveles, son débiles y computacionalmente son costosas, la mayoría de las reglas, solo verifican patrones de dos bytes en todo el tráfico UDP. Con tráfico aleatorio, un patrón de dos bytes activa una alerta cada 65'536 paquetes en promedio. Con más de 100.000 paquetes IP por segundo pasando por el IDS durante el día, esto claramente es un problema. Las dos reglas P2P que consumen más tiempo son 2003322 y 2003321. Según la herramienta de perfiles de rendimiento de SNORT, cada una de ellas requiere diez veces más tiempo de CPU que otras reglas P2P.

Bittorrent, con 13 reglas diferentes, el protocolo está bien cubierto en cuanto a detección. Hay todo tipo de reglas que cubren todas las posibilidades de la red (DHT, conexión de seguimiento, transferencias, agentes de usuario). Este conjunto de alertas , puede llegar a  producir decenas de miles de alertas todos los días.

Como nota, debe mencionarse que la mayoría de los clientes Bittorrent actuales admiten el uso de cifrado de protocolo. El uso de cifrado hace que todas las reglas basadas en el tráfico de igual a igual sean ineficientes y, por lo tanto, permite que el tráfico de Bittorrent pase sin ser detectado.

Snort no puede detectar un cliente conectado a un rastreador https, con el cifrado de protocolo habilitado y DHT deshabilitado. A dia de hoy, sin rotura TLS,  SNORT es ineficiente para detectar el tráfico de Bittorrent. Sin embargo, todavía hay muchos usuarios que usan versiones antiguas y estas reglas detectan a los usuarios que utilizan este software.

La mayoría de los protocolos están experimentando cambios similares que los harán mucho más difíciles de detectar, ya vemos como el malware usa SSL por ejemplo. La mayoría de los protocolos actuales ofrecen ahora un modo "cifrado", en el que todos los paquetes están cifrados y, por lo tanto, ya no contienen patrones fácilmente reconocibles.

Cuando estos cambios se vuelvan comunes, será mucho más difícil detectar P2P ( entre otros ) usando patrones de bytes en el tráfico. Otros enfoques, como el aprendizaje automático o el análisis de datos de flujo de red, probablemente darán mejores resultados, decantandome personalmente por mi parte por este último.

Equipos comprometido

Este conjunto de reglas fue diseñado para detectar hosts comprometidos o hosts infectados por virus o malware.

No comprometidos: Las amenazas detectadas por spywareput.rules y emergentes-malware.rules no encajan realmente en esta categoría. Estos dos archivos contienen programas publicitarios de detección de firmas y otros programas maliciosos, pero este tipo de software, incluso siendo molesto para el usuario final, no indica un dispositivo "comprometido".

Shellcode : La mayoría de las reglas contenidas en este archivo, shellcode.rules ,  activaban alertas regulares para muchos hosts diferentes, y la cantidad de falsos positivos que genera, puede llegar a ser consideró excesivo. La mayoría de las reglas de este archivo buscaban un patrón binario específico que pudiera indicar un exploit exitoso.

Detección de Ataques

Este conjunto de reglas intenta agrupar todas las reglas que indican que hay un ataque en curso. Como cualquier otra gran organización o empresa, el principal problema con este conjunto es que hay ciertas organizaciones que están constantemente bajo ataque y, por lo tanto, constantemente hay cientos de alertas activadas por SNORT, en según que casos.

La cobertura de ataque de SNORT es muy amplia. Existen reglas destinadas a detectar vulnerabilidades específicas, reglas que analizan el uso anormal de un protocolo, reglas que detectan intentos de fuerza bruta, reglas que detectan tráfico anormal, etc. Si bien los ataques entrantes son conocidos y resueltos, los ataques salientes son mucho más interesantes y podrían indicar hosts comprometidos.

Ataques normales : La implementación de estos archivos suele producir  resultados inutilizables debido a la gran cantidad de alertas que genera. Lo más interesante de estas, es que la gran mayoría de las alertas son informativas y no muy útiles en un entorno corporativo con un alto grado de madurez en seguridad. Dichas alertas incluyen: ping de hosts de Windows, acceso al servicio de calendario de Google, datos publicados en un formulario web, enlace enviado a través de MSN ( Aun que no creo que esta salte mucho ;) ). Estas son algunos ejemplos de las alertas informativas detectadas por este conjunto de posibles ataques normales.

También hay muchas reglas que detectan vulnerabilidades conocidas, a menudo de más de cinco años. Curiosamente, muchos de ellos activan muchas alertas en el tráfico normal. Pero si bien es cierto, en muchos casos, aun siendo vulnerabilidades antiguas, muchas de ellas no se parchean y dicha alerta, tiene cierta utilidad. Aunque algo muy útil seria, tener una marca de tiempo en las reglas, esto nos podría permitir desactivar fácilmente las reglas antiguas y obsoletas, pero desafortunadamente, este campo aún no existe.

También hay muchas reglas dirigidas a aplicaciones y servidores web específicos. Sin embargo, para que estas reglas sean útiles, es obligatorio saber qué servidor web ejecuta qué sistema operativo y qué servidor web aloja qué aplicación web. Este conocimiento es difícil de tener en una red muy grande con cientos de servidores web, y sin una gestión de activos adecuada, y habilitar todo a ciegas, crea demasiados falsos positivos o alertas no deseadas.

SNORT también ofrece algunas reglas DDOS que detectan intentos de fuerza bruta, escaneos o ataques a gran escala contra la red, pero existen otros medios para detectar estas amenazas, que nos serian más útiles.

Otro dato interesante es que existen cientos de reglas que detectan un tráfico perfectamente inofensivo y normal y que se clasifica como “intento”. Las reglas más notables que hacen esto son las reglas de "ping". En una red de tamaño razonable, estas reglas podrían proporcionar información útil sobre los ataques entrantes. Estas alertas, simplemente parecen no ser adecuadas en según que organizaciones, pero tambien debemos tenerlas en cuenta.

Ataques web : Hay ocho archivos de reglas dirigidos a ataques web, cada uno de los cuales es específico para un servidor web determinado, un tipo específico de tráfico o vulnerabilidades web conocida.

Todas las alertas web suelen ser legítimas. El principal problema con las mismas son los motores de búsqueda. Las solicitudes que contienen cadenas potencialmente maliciosas siempre o casi siempre, son activadas por usuarios legítimos que consultan motores de búsqueda.

Para ilustrar esto con un ejemplo muy simple, imaginemos que un usuario está intentando insertar algo en una base de datos. Es muy probable que este usuario consulte en Google "INSERT INTO (...)". Esta consulta se publicará en la URL a través del método GET, y las reglas de inyección SQL de SNORT pensarán que se trata de un intento de inyección y activarán una alerta.

La ineficiencia de estas reglas web parece deberse principalmente a los motores de búsqueda. Uno podría pensar en crear excepciones para todas las direcciones IP de los motores de búsqueda conocidos, pero desafortunadamente no existe tal lista y probablemente nunca la tengamos. Incluso si existiese, la lista sería demasiado grande para manejarla con SNORT,  el principal problema, es que SNORT es lento para procesar listas de IP en reglas.

Unido a esto, también hay muchas reglas asociadas a usuarios accediendo a un directorio potencialmente peligroso como / cgi-bin o /viewtopic.php. Muchos sitios web cumplen con estos requisitos en el propio servidor web, lo que generan alertas de falso positivo.

Conclusion

SNORT es una herramienta realmente poderosa, pero no es perfecta. Es buena para detectar ataques conocidos, pero no detendrá los ataques dirigidos. Esto es especialmente cierto si solo usamos las reglas predeterminadas de SNORT ( Ya vimos de donde podriamos obtener más ), ya que el atacante puede probar su ataque con anticipación para evitar la detección. El uso de reglas personalizadas puede funcionar, pero debemos recordar, que las reglas más generales generarán más alertas de falsos positivos, y si nadie está tratando las alertas, o si el atacante puede esconderse detras de  este desbordamiento en las alertas , entonces, la solución no valdría de nada.

SNORT detectará scripts kiddies y escáneres automáticos, lo cual es bueno, pero también debemos tener en cuenta que hoy en día, escanear todo el espacio de direcciones IPv4 lleva menos de 5 minutos, por lo que si nuestro servidor está  publicado en internet, obtendremos un gran cantidad de alertas de escáneres automáticos.

En general, SNORT es excelente, pero debemos considerarlo como una parte del sistema de defensa, y no como una solución definitiva.