Contenido

Introducción

Determinación del Estado de Regla en una Política Predeterminada

¿Cómo determina Sourcefire un estado predeterminado adecuado para una nueva regla?

Impacto

Rendimiento

Confianza

Introducción

En este artículo se explica cómo el equipo de investigación de vulnerabilidades (VRT) determina el estado de regla en las políticas de intrusión predeterminadas y cómo un dispositivo Sourcefire determina el estado predeterminado adecuado para una nueva regla.

Determinación del Estado de Regla en una Política Predeterminada

Cada regla tiene un campo de metadatos, con cero o más valores de política. Actualmente hay seis valores de políticas posibles:

1. security-ips drop

2. security-ips alert

3. caída de ips equilibrada

4. alerta de Balanceo-IPS

5. conexión-ips drop

6. alerta de IPS de conectividad

Si una política IPS desciende de, digamos, la política de seguridad equilibrada y conectividad proporcionada por Sourcefire, el dispositivo administrado está en modo en línea y una regla tiene un valor de política de metadatos de descarte de ips equilibrado, la regla se establecerá para descartar y generar eventos en su política IPS. Si una regla tiene un valor de política de sólo eliminación de IPS de seguridad, se desactivará en la directiva.

Nota: Si una regla tiene especificados varios valores de política, por ejemplo: caída de IPS de seguridad de políticas, caída de ips de equilibrio de políticas, aparece en ambas políticas. Si no se especifica ningún valor de política para una regla determinada, aparece en ninguna política de forma predeterminada.

Si un dispositivo administrado se establece en modo pasivo y una política se establece en drop, esto no tiene efecto. El dispositivo simplemente genera alertas. Si un dispositivo está en modo en línea y un valor de política se establece en drop, la regla descarta los paquetes de forma predeterminada. Si su valor de política se establece en alerta, sólo genera eventos, sin descartar.

Finalmente, en la mayoría de los casos, si se descarta un paquete, se genera una alerta. Esto es cierto a menos que la supresión de alertas se configure independientemente para una regla determinada.

¿Cómo determina Sourcefire un estado predeterminado adecuado para una nueva regla?

El estado predeterminado de una regla se basa en varios factores. Por ejemplo:

Impacto

Puntos a considerar

¿Qué probabilidades hay de que se intente aprovechar esta vulnerabilidad y qué porcentaje de nuestros usuarios (tanto los clientes de Sourcefire como la comunidad de Snort en general) es probablemente vulnerable a esta vulnerabilidad?

Aspectos a recordar

Una vulnerabilidad de Internet Explorer con ataques conocidos en el entorno silvestre tiene un impacto mucho mayor que, digamos, una función de base de datos SAP que se puede utilizar maliciosamente cuando los permisos se configuran incorrectamente, o un ataque de negación de servicio complejo en un módulo oscuro del núcleo Linux. VRT realiza un juicio de impacto comenzando con la puntuación CVSS de una vulnerabilidad, ajustándola según sea necesario con cualquier información adicional que podamos tener. Esta es la métrica más importante de todas, porque a veces habilitaremos una regla que de otra manera no se activaría / no se establecería para caer si el impacto es lo suficientemente alto.

Rendimiento

Puntos a considerar

¿Esperamos que esta regla sea rápida o lenta en una red "media"?

Aspectos a recordar

Aunque la velocidad de una regla depende completamente del tráfico que inspecciona, lo que dificulta la medición del rendimiento, tenemos una idea general de lo que constituye una red normal y de cómo funciona una regla determinada en esa red normal. También sabemos que una regla con, por ejemplo, una coincidencia de contenido único relativamente larga (6 o más bytes, normalmente) y relativamente única (es decir, "obscureJavaScriptFunction()", y no "|00 00 00|" o "GET / HTTP/1.1") evaluarán más rápido que una regla con un PCRE complejo, una serie de cláusulas byte_test y/o byte_hop, etc. Con este conocimiento podemos determinar si una regla será rápida o lenta y tenerla en cuenta.

Confianza

Puntos a considerar

¿Qué probabilidades hay de que esta regla genere falsos positivos?

Aspectos a recordar

Algunas vulnerabilidades requieren condiciones muy específicas y fáciles de detectar para poder explotarlas, en cuyo caso podemos estar muy seguros de que cada vez que se activa la regla asociada, se está produciendo una vulnerabilidad en directo. Por ejemplo, si hay un desbordamiento de búfer en un protocolo que tiene una cadena mágica única en una posición fija y luego una longitud especificada que está a una distancia fija de esa cadena mágica, podemos confiar en nuestra capacidad de encontrar la cadena mágica y verificarla con un valor conocido para los problemas. En otros casos, los problemas están mucho menos bien definidos; por ejemplo, ciertos ataques de envenenamiento de caché DNS pueden ser indicados por un número anormalmente grande de respuestas NXDOMAIN que vienen de un servidor en un determinado período de tiempo. En tal caso, la mera presencia de una respuesta NXDOMAIN no es en sí misma un indicador de una explotación; es la presencia de un gran número de esas respuestas en poco tiempo lo que indica el problema. Dado que ese número será diferente para las diferentes redes, el VRT se ve obligado a elegir un valor que debería funcionar para la mayoría de las redes y a liberarlo; sin embargo, no podemos confiar al 100% en que, cuando se activa la regla, se produce una actividad maliciosa real.

Por fin, aunque no por ello menos importante, si bien de vez en cuando otros factores pueden considerarse relevantes, el impacto es importante al final del día: asegurarnos de que nuestros clientes estén protegidos frente a las amenazas que probablemente vean en su entorno natural es nuestra principal preocupación.