¿Cuánto tráfico puede manejar un nodo de firewall? ¿Algún ejemplo real? [cerrado]

Habiendo realizado pruebas para varios clientes en los que afirman que "los escaneos no se derrumbarán, estarás bien", luego, una hora más tarde, tendremos una reunión para discutir cómo van a manejar un incidente de inactividad grave , Puedo decir con seguridad algunas cosas:

1. Las cifras de marketing que describen el rendimiento son, en el mejor de los casos, un caso de rendimiento máximo, producido en una situación de laboratorio en la que el caso de prueba se ha optimizado por completo para obtener las estadísticas de rendimiento máximo sin tener en cuenta la funcionalidad o la facilidad de uso real. En el peor de los casos, son una fabricación completa o una representación errónea de los datos. Debe ignorar las estadísticas de rendimiento.
2. Las pruebas de inundación estándar (por ejemplo, la inundación ICMP, la inundación SYN) son, en el mejor de los casos, herramientas rudimentarias. La resistencia a las inundaciones de ICMP rara vez es una medida útil de cualquier cosa, ya que las personas aprendieron sus lecciones en los años 90. SYN flooding le dirá si el sistema es capaz de eliminar la prioridad de las conexiones semiabiertas en espera detrás de los clientes que realmente enviaron un ACK final para completar la conexión, junto con la implementación de un sistema básico anti inundaciones como las cookies TCP SYN. Estas son cosas rudimentarias que puede esperar de cualquier producto de red.
3. Las pruebas de inundación de ancho de banda pueden ser útiles para resolver los problemas de saturación de la red, pero solo te dicen realmente cuál es el límite de ancho de banda continuo de la tubería de la red. Al inundar un enlace de red con paquetes grandes (generalmente datagramas UDP) puede saturar la tubería y dificultar la entrada de nuevos paquetes legítimos. Dicho esto, por lo general, le brinda más información sobre la red en sí misma que sobre el dispositivo bajo prueba (el firewall o IDS).
4. Los sistemas IPS / IDS / Firewall tienen una tasa de rendimiento ridículamente rápida para el tráfico, pero los cuellos de botella reales se producen en el lado de la administración. Por ejemplo, si inicia sesión cada vez que se ve un paquete desde una dirección IP que no tiene una entrada ARP (he visto esto hecho), enviar un montón de paquetes desde una IP falsificada (o simplemente sin ARP) primero llene rápidamente el búfer de registro en la memoria y sature la E / S del disco en la unidad que almacena los registros, normalmente eliminando todo el sistema. El dispositivo puede ser capaz de pasar el tráfico legítimo hacia adelante a una tasa ridículamente alta, pero un solo caso de borde como este puede aplanarlo en minutos.
5. Puede realizar todas las pruebas de DoS / DDoS que desee, verificar sus resultados en producción, abrirlo al tráfico del mundo real y ver grandes resultados, luego descubrir que se cae de bruces tan pronto como un pentester (o algunos skript kiddie) ejecuta Nessus o sqlmap a través de él, porque se están emitiendo tantas alertas que el sistema de alerta no puede mantenerse al día.
6. Si prueba un dispositivo en un entorno de prueba y luego lo mueve a producción, no se sorprenda cuando su dispositivo ya no funcione como se esperaba. Las pruebas se deben realizar en la configuración del mundo real con la misma configuración y la misma topología. Algo sutilmente diferente puede arrojar completamente tus resultados.

Si desea probar adecuadamente las capacidades realistas de uno de estos dispositivos, debe instalarlo en su entorno de producción y ejecutar una batería completa de pruebas en su configuración de producción final. Los resultados serán diferentes para cada modelo o versión del firewall / IDS / IPS, diferentes opciones de configuración y diferentes topologías de red y sistemas backend que se alcanzarán a través del dispositivo. Cualquiera sea la respuesta que obtenga para, por ejemplo, un firewall pfSense, será completamente diferente a, por ejemplo, un firewall de Checkpoint.

Ya que estás hablando de investigación, lo primero que debes hacer es definir lo que quieres decir con firewall e IDS. Son cosas diferentes; a un nivel trivial, un firewall (con estado) se ocupa de la capa de red, mientras que un IDS debe hacer al menos una inspección de paquetes y un análisis a nivel de aplicación para que sea útil.

Si bien hay otros tipos de cortafuegos e IDS, lo que limita su rendimiento es, en última instancia, el elemento más lento en la cadena de procesamiento. Aquí hay un ejemplo trival:

1. El paquete llega a la tarjeta de red
2. En el nivel del kernel, la pila de red funciona en el marco (por ejemplo, lo desfragmenta)
3. El firewall (por ejemplo, iptables) compara el paquete reconstruido con su conjunto de reglas
4. El sistema de registro escribe un evento en /dev/log y luego se olvida de ello
5. El IDS examina el paquete y espera a que lleguen más paquetes para completar la inspección

En este caso, los componentes involucrados son:

• tarjeta de red (bus PCI)
• CPU y RAM

El elemento más lento de la cadena es el bus PCI, así que ese es el factor limitante en el caso de paquetes individuales. Esto significa que, a menos que coloque una tarjeta de 10 Gb en una CPU 486 con un reloj de 100 MHz, la tarjeta de red siempre será el cuello de botella. Es un cálculo del fondo del sobre pero le da un límite inferior.

Una vez que tenga una línea de base, puede comenzar a complicarla: por ejemplo, ¿qué sucede si el sistema está sobrecargado? ¿Cuál es el número mínimo de subprocesos que su CPU debe poder asignar para mantenerse al día con un rendimiento máximo? En otras palabras: aísle sus variables y, manteniendo todo lo demás igual, analice sus límites. Podría considerar un enfoque de análisis de límites.

También necesita aclarar su pregunta de investigación: habla sobre

  

los paquetes máximos (tráfico de Internet) pueden ser una instancia de proceso de firewall / IDS

¿Qué quieres decir con "proceso"? ¿Es su IDS activo o pasivo (por ejemplo, bloquea el flujo de paquetes hasta que está contento, o solo realiza un análisis pasivo)? Si está bloqueando, tiene un modelo de cola de productor / consumidor en el que su límite superior depende de si el IDS puede escalar en múltiples núcleos. Otras cosas que puede considerar son la huella de memoria, la susceptibilidad a los ataques de denegación de servicio, etc. Piense en lo que sucede si un atacante envía un paquete fragmentado. ¿El firewall esperará por siempre para ensamblarlo? ¿Qué sucede si el atacante envía solo la primera parte de una solicitud HTTP fragmentada?

Para resumir: comience por definir exactamente lo que está tratando de evaluar; para cada elemento, determine sus límites inferiores y (posiblemente) superiores; Combina los resultados.