Estoy investigando dispositivos IPS y sus firmas con estado y sin estado. La red de prueba en la que estoy buscando implementar el IPS tiene tráfico asimétrico, por lo que la inspección de estado sería casi imposible. ¿Qué porcentaje de amenazas solo se puede mitigar a partir de la inspección de estado?
Si tuviera que desactivar la inspección de estado en el IPS, ¿a qué amenazas estoy dejando abierta la red de prueba?
La detección de intrusiones de red con estado, y más aún la prevención, es una tarea difícil frente a múltiples enlaces ascendentes. Cuando el tráfico puede fluir en un enlace y salir en otro, un solo monitor no puede reconstruir el estado del host final de manera efectiva. Puede aceptar esta situación con todas sus implicaciones (por ejemplo, protección mediocre en el mejor de los casos) o recurrir a una solución distribuida que propague el estado entre los nodos.
Lo ideal sería empujar los monitores al borde de la red [1], pero parece que no tienes control sobre el borde. Sin una comprensión detallada de la topología de la red, esta es una pregunta difícil de responder. Para el resto de esta respuesta, asumo que tiene al menos la capacidad de implementar varios monitores en su red para aproximarse al ideal de inspeccionar todo el tráfico ascendente.
El monitor de seguridad de red de Bro tiene un modo de clúster , donde un nodo puede propagar el estado a otros nodos. Por ejemplo, cuando el nodo A ve una conexión de control de FTP, puede propagar esta información al nodo B , para que sepa cómo interpretar la siguiente conexión de datos de puerto alto. Otro escenario donde esto es útil es la detección de escaneo distribuido. Si tiene una máquina infectada en su red que realiza escaneos salientes a través de múltiples enlaces, cada nodo puede mantener un contador local e intercambiarlo regularmente con otros nodos. Para obtener un análisis más detallado del intercambio de estado, eche un vistazo al documento del grupo NIDS .
Este enfoque de grupo se adapta bien a las siguientes ideas:
La granularidad del análisis y la agrupación es una conexión completa. Siempre que pueda asegurarse de que los paquetes que pertenecen a la misma conexión terminen en el mismo nodo de clúster, obtendrá una buena escalabilidad. En entornos de una sola fase, un frontend generalmente corta el tráfico de entrada para lograr esta restricción. En redes de tamaño mediano, un enrutador Click que reescribe la dirección MAC suele ser suficiente, pero los entornos más grandes a menudo tienen que usar dispositivos dedicados de alto rendimiento. Nuestro grupo de investigación tiene muy buenas experiencias con las interfaces cPacket CVU , que pueden equilibrar la carga de varios enlaces de 10 Gbps a la velocidad de la línea sin dejar caer paquetes.
El tamaño del estado intercambiado suele ser órdenes de magnitud más pequeños que el tráfico que observa un nodo. Por ejemplo, si uno de los nodos observa una descarga de imagen ISO grande, no propagará la imagen ISO misma a otros nodos, sino, por ejemplo, solo el nombre de la imagen ISO. Además, el análisis de conexión intra ya tiene estado, por ejemplo, Bro sigue la máquina de estados TCP y expone la canalización de mensajes HTTP al usuario.
Aplicar esto a su escenario es un poco más complicado, porque no tiene un solo enlace ascendente. Para poder escalar bien, debe asegurarse de que el tráfico de la misma conexión sea inspeccionado por el mismo nodo. En otras palabras, la noción de un frontend es un poco borrosa porque tiene que enrutar manualmente los paquetes al nodo del clúster correspondiente. La sobrecarga exacta de este enfoque depende de su topología concreta.
[1] Esto no excluye a defensa en profundidad . También es una buena idea agregar más monitores en el núcleo, por ejemplo, cuando no se establecen subredes de "roadwarrior" para aislar dispositivos móviles.