¿Cómo puedo escribir pruebas automatizadas para iptables?

Estoy configurando un enrutador Linux con iptables. Quiero escribir pruebas de aceptación para la configuración que afirman cosas como:

• el tráfico de algún tipo en Internet no se reenvía
• Se reenvía el TCP al puerto 80 en el servidor web en la DMZ desde los hosts en la LAN corporativa.

Un antiguo FAQ alude a una iptables -Copción que le permite a uno preguntar algo como, "dado un paquete de X, a Y, en el puerto Z, ¿sería aceptado o descartado?" Aunque las preguntas frecuentes sugieren que funciona así, para iptables(pero tal vez no ipchainscomo se usa en los ejemplos) la -Copción parece no simular un paquete de prueba que ejecuta todas las reglas, sino que verifica la existencia de una regla que coincida exactamente. Esto tiene poco valor como prueba. Quiero afirmar que las reglas tienen el efecto deseado, no solo que existen.

He considerado crear aún más máquinas virtuales de prueba y una red virtual, y luego probar con herramientas como nmapefectos. Sin embargo, estoy evitando esta solución debido a la complejidad de crear todas esas máquinas virtuales adicionales, que es realmente una forma bastante pesada de generar algo de tráfico de prueba. También sería bueno tener una metodología de prueba automatizada que también pueda funcionar en un servidor real en producción.

¿De qué otra forma podría resolver este problema? ¿Hay algún mecanismo que pueda usar para generar o simular tráfico arbitrario, y luego saber si fue (o sería) descartado o aceptado iptables?

Si está preparado para hacer un poco de codificación, puede intentar esto:

• Cree un nuevo espacio de nombres de red utilizando el CLONE_NEWNETindicador para la clonellamada al sistema o utilizando los comandos ip netns addy ip netns exec.
• En este espacio de nombres, cree un conjunto de interfaces de red virtuales utilizando el tuncontrolador o ip link add.
• Cargue la configuración usando iptables-restore
• Alimente varios paquetes a las reglas a través de los dispositivos tunoveth
• Observe que obtiene los paquetes correctos de los dispositivos tunoveth

Es probable que este enfoque funcione mejor para probar reglas para paquetes reenviados. Las conexiones hacia / desde la máquina donde se usa iptables requiere un poco más de esfuerzo, pero también debería ser factible probar de esta manera.

Aquí hay un ejemplo de una secuencia de comandos, que podría usarse:

ip netns add test-iptables
ip netns add test-iptables-some-guy-on-the-internet
ip netns add test-iptables-lan-host

ip netns exec test-iptables ip link add eth0 type veth peer name eth0-peer
ip netns exec test-iptables ip link set eth0-peer netns test-iptables-some-guy-on-the-internet
ip netns exec test-iptables ip link add eth1 type veth peer name eth1-peer
ip netns exec test-iptables ip link set eth1-peer netns test-iptables-lan-host

ip netns exec test-iptables ifconfig eth0 192.0.2.2 netmask 255.255.255.0
ip netns exec test-iptables ifconfig eth1 203.0.113.1 netmask 255.255.255.0

ip netns exec test-iptables-some-guy-on-the-internet ifconfig eth0-peer 192.0.2.1 netmask 255.255.255.0
ip netns exec test-iptables-some-guy-on-the-internet route add default gateway 192.0.2.2

ip netns exec test-iptables-lan-host ifconfig eth1-peer 203.0.113.2 netmask 255.255.255.0
ip netns exec test-iptables-lan-host route add default gateway 203.0.113.1

ip netns exec test-iptables-some-guy-on-the-internet telnet 203.0.113.2
ip netns exec test-iptables iptables-restore < /tmp/iptables-test
ip netns exec test-iptables-some-guy-on-the-internet telnet 203.0.113.2

ip netns del test-iptables
ip netns del test-iptables-some-guy-on-the-internet
ip netns del test-iptables-lan-host

Esto crearía tres espacios de nombres de red para probar y cargar un conjunto de reglas de iptables en una de ellas. Los otros dos sirven como el papel de un tipo en Internet y un host en la LAN.

En el ejemplo anterior, el primer telnetcomando obtiene la conexión rechazada desde el test-iptables-lan-hostespacio de nombres, el segundo telnetcomando obtiene un tiempo de espera si el conjunto de reglas descarta el paquete.

Esto no toca el espacio de nombres de la red inicial, que es en el que estará ocurriendo toda su producción de forma predeterminada. La única forma de obtener más separación de su producción es ejecutarla en un host separado (físico o virtual).

el mundo profesional lo hace con la ayuda de hardware / software provisto por 2 compañías.

www.ixiacom.com

www.spirent.com

En el primer caso, puede usar algo como un chasis Ixia 400T + Ixload.

En el segundo caso, la línea Smartbits o Testcenter con sus aplicaciones correspondientes

Estos dispositivos pueden (entre otras cosas) emular a muchos clientes que realizan diferentes tipos de solicitudes en el servidor de destino seleccionado. Vienen listos para probar la seguridad de sus servidores, incluido un conjunto predefinido de pruebas de ataque, además de que siempre puede definir su propio conjunto. También tienen muchas otras capacidades como pruebas de estrés de carga y similares.

No es una opción barata.