Documentación sobre reglas de Snort y ajuste de alertas, especialmente para usuarios nuevos

5

Acabo de empezar a usar Snort. Hay mucho por hacer. Solo estoy buscando una mejor documentación de lo que realmente significan algunas de las reglas de Snort, es decir, cómo debo reaccionar ante ellas cuando aparece una alerta para una determinada regla emergente. Parece que los documentos, ejemplos y foros de Snort suponen una gran cantidad de conocimientos previos de administradores de seguridad de redes esotéricos que aparentemente no tengo (aún).

Por ejemplo, encontré esto:

enlace

Sin embargo, esa sección del sitio web de Snort está lamentablemente desactualizada y la parte de búsqueda no funciona, y aparece la ventana 404 cuando ingreso manualmente muchos de los identificadores de reglas en los que estoy interesado.

Ejemplo, para el preprocesador stream5:

El segundo, "129: 12", tiene una descripción de texto de "Segmentos pequeños TCP consecutivos que exceden el umbral". ¿Y eso que significa? ¿De qué manera es eso indicativo de un problema? Examiné nuestra red, y solo hay actividad de red aceptable (que podría decir). Durante un evento en el que Snort fue muy detallado sobre este problema en particular (en el orden de 100 mensajes por minuto), el problema se debió al tráfico autorizado que pasa a través de nuestro proxy de calamar.

Entonces, ¿qué debería suprimir todos estos mensajes? ¿Es esa una forma normal de sintonizar Snort? ¿Solo suprimir el ruido? Eso me parece una locura ... Si reprimo todos estos mensajes, ¿qué sucede si hay mensajes de esta clase que realmente indican un problema?

Espero que se te ocurra.

Actualmente estoy utilizando pullpork para ensamblar conjuntos de reglas y suprimir reglas ruidosas mediante directivas de supresión en threshold.conf.

Por último, debo mencionar que estoy ejecutando Snort de una manera bastante poco convencional, como una solución para satisfacer los requisitos de IDS para PCI, mientras se ejecuta en la nube de AWS. En pocas palabras, tenemos a Snort corriendo en todas las casillas que clasificamos como casillas de "borde", y estamos olfateando el tráfico en ellas. Proporcionaré más detalles si así lo solicita, pero eso no cambia la esencia básica de esta pregunta.

    
pregunta JDS 17.02.2016 - 17:26
fuente

1 respuesta

3

Te encuentras con uno de los problemas más básicos con prácticamente todo el sistema de monitoreo: cómo manejar los datos generados correctamente y separar la señal del ruido.

Desafortunadamente para usted, no hay una respuesta fácil porque todo depende de sus recursos y del valor de lo que está protegiendo.

Permítame ser más específico: si está trabajando con una red pequeña y de gran valor y tiene muchas personas (competentes) para manejar la tarea, puede dejar todas las alertas e investigarlas todas por completo. Obviamente, esto es muy costoso y se necesitan personas altamente capacitadas (y probablemente un software muy inteligente) para poder manejarlo correctamente.

Por otro lado, si tiene una red grande y de bajo valor con pocas personas disponibles para el manejo de incidentes, puede decidir simplemente registrar todo y solo investigar los problemas que están marcados explícitamente como incidentes a través de una canal ("¿Quién cambió la contraseña del correo electrónico del CEO?"). Su IDS seguirá siendo valioso para usted porque puede usar los registros para algunos análisis post mortem de un incidente, pero no le permitirá reaccionar de manera proactiva.

La mayoría de las redes se encuentra entre estos dos extremos, por lo que se supone que debes crear alertas que coincidan lo más posible con tu nivel de amenaza real y la capacidad de respuesta. Eso lleva tiempo y es un proceso que debería ser continuo: tendrá que ajustar sus reglas para reaccionar ante nuevas amenazas, cambios en el uso o en la capacidad todo el tiempo.

    
respondido por el Stephane 17.02.2016 - 17:47
fuente

Lea otras preguntas en las etiquetas