Por ejemplo, ¿cómo determinan el equipo VRT de Snort o alguien que nos da las firmas?
Me gustaría saber más, ¿cómo se analizan los patrones de tráfico en comparación con algunos modelos teóricos conocidos (algún modelo estadístico / probabilístico) para determinar las firmas?
Sashank, esa es una buena pregunta.
Escribir reglas es un trabajo de investigación divertido. A menudo se necesita mucha investigación y análisis, y a veces para algunas amenazas es muy fácil escribir una firma.
Este es un resumen rápido y de muy alto nivel de escritura de firmas. Las cosas que debe saber de antemano para realizar un análisis y comenzar a escribir reglas -
Muy buena comprensión de los Protocolos según sus RFC : esto incluye todos los protocolos (IP, ICMP, DHCP, TCP, UDP, SMTP, FTP, POP3, ssh, telnet, etc.) en capas OSI (enlace de datos, red, transporte, sesión, etc.). El RFC es la guía de cómo se diseña un protocolo, cómo debe comportarse. Esta es una referencia muy importante en la escritura de reglas. RFC define la estructura de los protocolos, sus encabezados, estados, indicadores / atributos. En la red, cualquier desviación observada de estos estándares de RFC es la clave para escribir las reglas.
Comprensión detallada de la vulnerabilidad - What do you want to write a signature for? Do you understand how the vulnerability works? Do you know what are you looking for in the network traffic? Where shall you concentrate on in the application/service? . El intentar responder estas preguntas le dará un camino para comprender la vulnerabilidad. Ejemplo: si está escribiendo una regla para el desbordamiento de búfer remoto en el puerto 80 / http en IIS, debe comprender la arquitectura del servidor web, cómo se manejan los datos internamente en el servidor web, cómo maneja las solicitudes el servidor web y genera respuestas . Esto aclarará la vulnerabilidad. Si entiendes esto, te llevará a lo que debes buscar exactamente. Esto es aplicable para cualquier servicio / proceso / software remoto o local para el que desee una regla de vulnerabilidad.
Mucho trabajo de laboratorio : ejecute las vulnerabilidades una y otra vez en diferentes escenarios, obtenga muchas capturas de paquetes o volcados de memoria. Analice la línea de tiempo, analice los encabezados de los paquetes y compare eso con los estándares RFC, analice las cargas útiles . Si ejecuta un exploit 10 veces, las capturas de paquetes le proporcionarán el cronograma, el tamaño de la carga útil / datos, la secuencia de bits (datos) en la carga útil y, lo que es más importante, aclarará las condiciones bajo las cuales La explotación es más probable que tenga éxito. Al juntar todo esto se obtendrá una buena precisión para la firma, entonces usted conoce el patrón de bits que debe buscar y cuándo buscar, y dónde buscar
Reemplazando 'firma' con 'regla'.
A veces es una tarea simple, otras no tanto.
Las reglas generalmente se crean (afaik) al examinar las capturas de paquetes de ataques / explotaciones y luego crear reglas que coincidan con ese patrón de tráfico. La habilidad es crear una regla que sea lo más precisa posible para limitar los falsos positivos, pero lo suficientemente genérica como para asegurar que atrapes todo. Las reglas incorporadas se crean de la misma manera que muchas personas crean sus propias reglas: analizan las capturas de paquetes, observan los bits y los bytes para crear un patrón apropiado. El bit fácil es, obviamente, coincidir con los puertos y el protocolo (es decir, el encabezado de la regla).
El flujo de tráfico (es decir, desde / hacia el servidor), pero luego se vuelve más complejo con los operadores (contenido, desplazamiento, profundidad, dentro, distancia, etc.) o invocando pcre. El otro elemento complicado es garantizar que una regla no solo atrape el tráfico, sino que también afecte negativamente el rendimiento.
Snort es ahora una bestia complicada (de una buena manera) y hay mucho más que simples reglas que buscan patrones de tráfico. El trabajo real ocurre con los preprocesadores y el módulo DAQ .
Aquí hay una publicación anterior que habla sobre cómo las firmas de IDS / Se crean las reglas.
Una buena persona para conversar sería Joel Esler (@joelesler), un veterano de Sourcefire y miembro del equipo de VRT. No estoy seguro de lo que pueda decirte, aunque es un muestra de él. . La gente en el equipo de VRT son monos de paquetes reales, grandes desarrolladores y realizan pruebas exhaustivas de sus reglas antes del lanzamiento. Muy a menudo, estas pruebas se realizan con el proveedor o compañía que ha descubierto o ha sido afectado por el ataque.
Hay literalmente un montón de documentos en la red sobre cómo se escriben las reglas de snort, muchas de las cuales están escritas por Empleados de Sourcefire y el manual .