Confesiones de un probador: cómo rebusqué en un competidor IDS

Ninguna puerta de enlace de seguridad de red UTM que se precie puede prescindir de un sistema de detección de intrusiones (IDS). Otra cosa es que el fabricante a menudo indica la opción de una marca para mantenerse al día con los competidores. Sé por mi experiencia como probador cómo sucede esto: parece que hay IDS, pero de hecho no es bueno. Es por eso que, cuando me ofrecieron probar un hardware UTM relativamente económico, sugerí en primer lugar que "expulsara" su OWL.


Pieza UTM de Traffic Inspector Next Generation S100 y Cisco 2960G Switch


Si tiene experiencia trabajando con IDS, es interesante leerlo en los comentarios al artículo. Es aconsejable, no sobre el hardware costoso (está claro que algunos Cisco NGFW son buenos por un millón), sino sobre soluciones que son más asequibles. Creo que los administradores de lokalka y los usuarios potenciales de las puertas de enlace de red tendrán curiosidad por discutir quién trabaja con IDS y si vale la pena comprar a un precio alto, cuando puede, después de bailar con una pandereta, lograr lo mismo por menos dinero.

En esta prueba, estamos hablando del modelo S100: el precio más asequible en la línea de la próxima generación de Traffic Inspector (los números significan que está diseñado para 100 suscriptores). Aquí está su descripción en el sitio web oficial >>> . En resumen, el hardware contiene, por ejemplo, un filtro de red, una VPN, un bloqueador de recursos y, por supuesto, IDS.

Propongo una metodología de prueba simple: verificamos el rendimiento y creamos la dependencia del número de paquetes descartados en la intensidad del tráfico en incrementos de 50, 100, 150 y 200 Mb / s. ¿Por qué tomamos tales intervalos? Comenzamos desde 100 Mb / s, la solicitud del cliente más popular, y posponemos más y menos para ver qué sucede en los modos más o menos cargados, así como en el modo extremo 200 Mb / s.

La experiencia de la vida me dice que con todas las reglas activas, el S100 puede no funcionar, por lo que sugiero que el procedimiento descrito se lleve a cabo en tres modos: primero cuando todas las reglas están activas, luego con la parte de las reglas apagada (llamémosla Grupo No. 1) y, finalmente, solo cuando está activo solo unas pocas reglas (llamémoslo Grupo No. 2). Formamos los siguientes grupos de reglas:

- Grupo No. 0: bueno, eso es comprensible, todas las reglas sin excepción.
- Grupo n. ° 1: grupo de reglas de subprocesos emergentes (conozco las reglas desde que probé IDS Snort, con la excepción de las reglas de juegos emergentes).
- Grupo No. 2: un grupo de reglas que considero simplemente vinculantes para IDS (ver más abajo), incluida la adición de reglas p2p, porque por mi propia experiencia sé cómo las grandes empresas se relacionan negativamente con el hecho de que sus empleados utilizan activamente las empresas red para descargar sus programas de TV favoritos.

La prueba es posible utilizando la utilidad tcpreplay . Esta utilidad le permite reproducir tráfico de red pregrabado a una velocidad específica. Comando: tcpreplay –i <interfaz> -l 0 testTI.pcap . El archivo testTI.pcap contiene 1.146.313 paquetes (elegimos dicho volumen para que, por un lado, haya buenas estadísticas, por otro lado, el tiempo de "ejecución" no sería demasiado largo, en nuestro caso, no más de 15 minutos). Además de esto, como dije, lanzamos un rastreador de torrents.

Diseño de banco de prueba:



Si alguien tiene preguntas sobre la metodología de prueba, estoy listo para responder en los comentarios.

Entonces, los resultados.

Grupo 0

La prueba en un conjunto completo implica cargar todas las reglas, y hay 30 305 de ellas.

Al realizar la prueba, utilizamos la configuración predeterminada de IDS:



Comenzamos a probar con 100 Mb / sy entendemos que la pieza de hierro apenas puede extraerse: de 114 mil paquetes, ¡se descartan 109 mil! Por lo tanto, no tiene sentido probar a 150 y aún más a 200 Mb / s. Por el contrario, propongo darle una oportunidad al dispositivo y realizar una prueba adicional a 10 Mb / s. El resultado en la tabla:



Nota:

kernel_packets - paquetes enviados;
kernel_drops: paquetes descartados. Como puede ver, con la configuración predeterminada y con un conjunto completo de reglas, se producen grandes pérdidas de paquetes (> 30% en relación con kernel_packets). Esperemos que la optimización de las reglas para la configuración cambie la situación;
decoder_packets: la cantidad de paquetes que el sistema procesó correctamente;
detect_alerts: número de ataques detectados. La mayor parte de los ataques son del tipo de paquete fragmentado, pero también se han identificado los ataques de detección de rastreadores de torrents.

Grupo número 1

Obviamente, el hardware no está optimizado para funcionar como un IDS potente y completo, pero hay margen de maniobra, es decir, la capacidad de cambiar el mecanismo de búsqueda de rutas, deshabilitar la descarga del contenido del paquete (carga útil) y deshabilitar grupos de reglas y grupos específicos de paquetes. Un poco de experimentación con la configuración, y llegamos a la opción que presento en la siguiente figura.



La lista de reglas activas que dejamos:



Resultado de la prueba:



Como puede ver, la imagen mejoró significativamente con este grupo de reglas (el porcentaje de paquetes descartados disminuyó varias veces). Se detectó con éxito un ataque como "Detectar un rastreador de torrents" (ya no aparecían los ataques de "Paquete fragmentado").

Grupo número 2

La configuración es la misma. Lista de reglas activas:



El resultado en la tabla:


Aquí la imagen del procesamiento de paquetes es aún mejor, lo que se espera.

Resumen

La tabla de resultados finales, expresada como un porcentaje de kernel_drops en relación con kernel_packets, se muestra a continuación:



Gráficamente, el resultado es el siguiente:



Como puede ver, el número de reglas y configuraciones activas afecta directamente la eficiencia. No tiene sentido activar la configuración al máximo y todas las reglas al mismo tiempo: las pérdidas se reducen inmediatamente incluso en 10 Mb / s. En modos optimizados, la pieza de hardware se siente normal hasta 100 Mb / s, pero las pérdidas aumentan considerablemente en el tráfico más intenso. Sin embargo, para uso de "oficina", 100 Mb / s es suficiente. Si maneja el dispositivo a esta velocidad y selecciona las reglas, puede lograr IDS bastante satisfactorios.

Quizás, para usar el conjunto completo de reglas, se necesitan mejoras para usar el mecanismo pf_ring (https://www.ntop.org/products/packet-capture/pf_ring/) como mecanismo para transferir un paquete al espacio de usuario desde el búfer de interfaz de red. Para hacer esto, necesitará usar varias instancias de Suricata, que, por supuesto, tomará recursos de otros procesos, pero quizás el juego valga la pena.

Repito que, en mi opinión, el objetivo principal del dispositivo probado es un firewall, y la opción IDS es auxiliar. Honestamente, estaba listo para el hecho de que el hardware fallará. Resultó que con una cierta percepción intuitiva del administrador del sistema, el sistema de detección de intrusos en el S100 está en pleno funcionamiento.

PD Como dije anteriormente, insto a los lectores a escribir sobre su experiencia en el uso de IDS en soluciones relativamente económicas.

La prueba PPS se publica en la cuenta del fabricante, porque no quiero "brillar" yo mismo. Sin embargo, estoy listo para responder todas las preguntas y debatir en los comentarios, pero, nuevamente, no en mi propio nombre :)