Entre las reglas de comunidad y las reglas registradas, todas son solo reglas de tipo "alerta". Dado que hay más tipos de reglas como registro, aprobación, activación, dinámica, sdrop, sdrop disponibles, los conjuntos de reglas oficiales de snort utilizan solo el tipo de alerta. ¿Por qué no se incluye otro tipo de reglas en los conjuntos de reglas oficiales de snort?
¿Hay alguna razón específica detrás de esto para usar solo la regla de "alerta" en todos ¿Conjuntos de reglas oficiales?
Es una precaución de seguridad. La definición de todas las coincidencias para las alertas permite que snort se instale inicialmente sin causar problemas a sus usuarios.
Imagina que estás en el equipo de la red que está configurando snort por primera vez en tu organización. De repente, su equipo de aplicaciones está recibiendo llamadas de que el sitio web dejó de funcionar. Nadie sabría por qué, y sería una gran emergencia. Eventualmente, podemos esperar que alguien sea lo suficientemente inteligente como para romper Wireshark y descubrir estos extraños paquetes RST que vienen de la nueva caja de snort. Cuando fue a investigar por qué, descubrió que había una regla de resoplido que coincidía con uno de sus paquetes existentes y que estaba configurada para rechazar, lo que eliminó la conexión legítima. La gente de su organización estaría muy descontenta con usted.
Al establecerlos en alertas primero, cuando instales snort, tu organización no se verá afectada. Por supuesto que puede (y debe) investigar todas las alertas que ve. Verá que es probable que algunos de ellos sean falsos positivos: si alguno de estos se hubiera configurado para restablecer las conexiones o eliminar los paquetes, snort habría sido la causa de una catástrofe.
Lo contrario también es cierto. Al no configurarlos para que se registren solo como una configuración predeterminada, también están teniendo cuidado de no permitir que se ignore el tráfico malicioso real.
La idea es que cuando enciendas snort, de repente recibirás un montón de alertas como parte de tu tráfico normal, y tendrás que evaluarlas todas. La mayoría tendrá explicaciones seguras, y usted puede elegir transmitirlas; Algunos serán un poco raros y puedes elegir registrarlos. Algunas pueden ser alertas legítimas de datos que desea eliminar. Y cualquier otra cosa que descubra, bueno, podría ser un tráfico realmente malo que no desea en su red, por lo que configura esos para rechazar.
El tipo de "alerta" es el predeterminado que puede usarse si desea generar ese tipo de evento cuando la firma coincide. Según su necesidad, y para personalizar el uso de la aplicación, es posible que desee no recibir alertas todo el tiempo, por ejemplo.
Es posible que desee establecer el tipo de "registro" para algunas reglas que pueden ser demasiado ruidosas, de modo que pueda analizarlas una vez al día, con alguna metodología analítica.
Bueno, ALERTA son las acciones de la regla predeterminada. Es más una cuestión de práctica recomendada utilizar ALERT como las acciones de la regla para las reglas de la comunidad y las reglas registradas. No tengo ninguna razón técnica detrás de mi conocimiento.
Aquí es por qué? Las otras opciones de acciones de reglas son realmente específicas del usuario. Solo los usará para lograr un propósito específico o alcanzar un objetivo específico para su red. Las reglas de la comunidad y las reglas registradas también son reglas de propósito general, lo más probable es que termine personalizándolas.
Además, el uso de otras acciones de reglas sin comprender realmente cómo funcionan podría ser perjudicial, especialmente para las personas que son nuevas en el bufido. Por ejemplo, ¿por qué tendría una regla con un registro o ignoraría las acciones en el conjunto de reglas predeterminado? Este podría ser el comportamiento deseado en su implementación de SNORT pero no para otros.