Control de estado en iptables

Descubre una de las características más interesantes de iptables, como es su capacidad para controlar el estado de las conexiones.

Seguimiento de la conexión

El control del estado de las conexiones es una de las características avanzadas de iptables o de cortafuegos que tienen funciones avanzadas, porque entra dentro de lo que se conoce como seguimiento de la conexión.

Los cortafuegos simples lo que proporcionan es una serie de reglas, que de acuerdo a las características de las cabeceras de las diferentes capas del modelo TCP/IP, permiten o no pasar el tráfico.

El seguimiento de la conexión hace que ese control sea mucho más exhaustivo y permite controlar o limitar una serie de ataques o de malos usos que podríamos recibir de paquetes modificados de una manera artificial, pero que con un cortafuegos simple se verían afectados los equipos que tuvieran detrás, porque no sería capaz el cortafuegos de cerrar ese tráfico.

En el caso de iptables esto realmente se realiza con un software que se denomina Conntrack, que se utiliza para el seguimiento de la conexión. Este software se puede utilizar de forma independiente, ya que existe el paquete Conntrack en la mayoría de las distribuciones y en la línea de comandos se puede utilizar. También se puede utilizar como módulo de iptables, es decir, una extensión de la iptables base, ya que permite extender su funcionalidad mediante módulos.

Conntrack se puede utilizar de forma completa, con una serie de configuraciones, aunque en este caso vamos a mostraros un subconjunto de las funcionalidades de Conntrack, que es el que hace referencia y gestiona el estado de los paquetes, lo cual se realiza mediante un módulo de iptables que se denomina state, que es un subconjunto de las funcionalidades que proporciona Conntrack.

2- Ejemplo de utilización de state

Vamos a ver un ejemplo de cuándo sería muy interesante la utilización de state.

Os mostramos un par de reglas de iptables en las que, asumiendo que tenemos una política por defecto DROP, por ejemplo permitiríamos el tráfico de una serie de clientes que tuviéramos detrás del cortafuego, a tráfico HTTP en el puerto 80.

iptables -A FORWARD -i eth0 -o eht1 -p tcp --dport 80 -s 192.168.1.0/24 -j ACCEPT

iptables -A FORWARD -o eth0 -i eht1 -p tcp --sport 80 -d 192.168.1.0/24 -j ACCEPT

Con la primera regla añadiríamos la cadena FORWARD, que es la de un cortafuegos, ya que suponemos que tenemos un cortafuego y detrás tenemos la red local que queremos que acceda al protocolo HTTP, suponiendo que las peticiones de los clientes entrasen por la interfaz eth0 y saliesen por la eth1, al protocolo TCP con el puerto destino 80, es decir HTTP, con origen nuestra red local, lo que hacemos es que este tráfico lo aceptamos.

Si tenemos un cortafuego con política por defecto DROP, no solo basta con aceptar las peticiónes de los clientes, sino que tenemos también que aceptar la respuesta de los servidores, que sería en principio la segunda regla.

Esta segunda regla lo que hace es que, mediante iptables, permite en la tabla FORWARD la respuesta, que es el paquete que entra por eth1 y sale por eth0, del mismo protocolo TCP, pero en este caso como puerto origen el 80, y que tiene como destino la dirección 192.168.1.0/24.

Esta regla es, en principio, un problema de seguridad, porque realmente con esa regla estamos permitiendo el acceso a cualquier paquete que se haya originado en un puerto 80.

Aunque en principio y tal como está diseñado, en el puerto 80 no se puede originar ningún paquete salvo la respuesta de un servidor web. Esto sería así salvo que alguien, de forma malintencionada, hiciese voluntariamente un paquete nuevo, crease una conexión nueva, y esa conexión la estableciera desde el puerto de origen 80.

En ese caso y, simplemente con esta regla, vemos que sería un cortafuegos simple, iptables no sería capaz de distinguir ese paquete de una respuesta a una petición de un cliente, y por tanto, ese paquete entraría. Y no solo entraría, sino que la respuesta, que tendría como destino el puerto 80 de nuestros clientes, también llegaría.

Con lo cual estaríamos permitiendo que cualquier máquina del exterior, que supiese de esta vulnerabilidad y, que por tanto la pudiera explotar, tuviese un acceso completo a todo el rango de puertos de nuestra red local, utilizando este agujero.

Lo que queremos es seguir teniendo tráfico hacia fuera, pero no queremos que entre tráfico nuevo desde el exterior. De todas formas, esta vulnerabilidad quedaría un poco limitada por el hecho de utilizar direccionamiento privado, pero independientemente es importante entenderla.

Para solucionarlo podemos utilizar el control de estado, ya que al introducirlo en iptables permite controlar cada petición para comprobar si ese paquete es una petición nueva, ya que puede saber si antes se ha hecho una petición previa.

Esto se realiza mediante la introducción del módulo state a las mismas reglas, de esta forma:

iptables -A FORWARD -i eth0 -o eht1 -p tcp --dport 80 -s 192.168.1.0/24 -m state --state NEW, STABLISHED -j ACCEPT

iptables -A FORWARD -o eth0 -i eht1 -p tcp --sport 80 -d 192.168.1.0/24 -m state --state NEW, STABLISHED -j ACCEPT

En la primera regla añadimos el módulo y además indicamos que en las peticiones de los clientes, que son las que van con origen la dirección 192.168.1.0 y con destino al puerto 80, permitimos que el estado sea NEW (nuevo) o STABLISHED (establecido).

En el caso del protocolo TCP, ese estado NEW implica varias cosas, por ejemplo el establecimiento de la conexión con TCP, los paquetes del SYN, SYN/ACK y ACK.

Sin embargo, en la segunda regla, en las respuestas limitamos que el estado de los paquetes sea solo STABLISHED (paquetes establecidos). Es decir, que inicialmente, por ejemplo la solicitud de SYN no se aceptaría porque se identificaría como un paquete nuevo.

De esta forma estamos limitando con las mismas reglas, pero estamos limitando que las reglas solo vayan en un sentido, es decir, peticiones de clientes y respuestas de los servidores.

Esto se entiende muy bien con el uso del protocolo TCP, puesto que el protocolo TCP incluye el paso previo de la conexión e incluye una serie de etiquetas en el encabezamiento, que configuran claramente lo que es la conexión y el estado. También tenemos las etiquetas que hacen el seguimiento continuo de la petición y la respuesta.

Sin embargo en otros protocolos más simples como udp o icmp, en principio no podríamos utilizar esas características, sin embargo, también podemos hacer reglas equivalentes con udp e icmp en iptables.

En ese caso, aunque no comprueba las etiquetas, lo que hace iptables es que cuando establecemos una conexión de tipo nueva, permite una conexión que no esté relacionada con una petición previa. Mientras que en el caso de conexiones establecidas, tiene que ser respuesta a peticiones que se hayan registrado previamente.

En resumen, de una manera bastante sencilla podemos mejorar mucho las características de seguridad y de funcionalidad de un cortafuegos con iptables.

Si quieres aprender en profundidad sobre Iptables, puedes hacer el curso de nuestro profesor experto Alberto Molina de esta herramienta, en el que te enseña paso a paso cómo crear un cortafuegos con Iptables.

Recuerda que puedes comenzar este curso con tu suscripción de OpenWebinars. Si todavía no estás suscrito, aprovecha para hacerlo ahora.