Firewall iptables - Curso completo - Teoría y práctica

Tablas, cadenas y reglas

Hay varios conceptos que debemos tener claros para poder trabajar con iptables… entre ellos, los de tablas, cadenas y reglas.

Iptables maneja varias tablas que agrupan tipos particulares de reglas, y a su vez, éstas están clasificadas según diversas cadenas propias de cada tabla.

Las tablas permiten configurar el tipo de regla que estamos seteando. Así, por ejemplo, tenemos las tablas filter, nat y mangle.

La tabla filter permite filtrar, como su nombre lo indica, ciertos y determinados paquetes que cumplan con un patrón de selección específico.

La tabla nat, por su parte, permite la modificación de paquetes, específicamente en la cabecera IP, cambiando las direcciones IP de origen o destino según correspondan, y también permite cambiar los números de puertos en la cabecera de transporte, ya sea tcp o udp.

Cuándo se llevan a cabo estas modificaciones? Al momento de ingresar o salir tráfico del procesamiento del firewall. Esto vamos a aprenderlo en seguida, cuando hablemos sobre el flujo de trabajo y procesamiento de datos dentro de iptables.

Mangle, a su vez, permite manipular los paquetes y modificar otros campos de la cabecera IP, y también marcar paquetes mediante tags internos del firewall para aplicarles algún tratamiento particular, como puede ser QoS mediante tc u otras herramientas de iproute2.

En este curso, como hemos comentado, hablaremos sobre las tablas NAT y FILTER específicamente, que van a permitirnos montar un firewall completo para redireccionamiento y filtrado de tráfico en un nodo de la red LAN.

Tabla filter

La tabla filter, como bien comentamos antes, permite bloquear o dejar pasar tráfico de red que cumpla con algún patrón característico.

Esta tabla consta de tres cadenas, o chains, a saber:

• INPUT: identifica todo el tráfico destinado al firewall, aquel que tiene en la cabecera de capa 3 (generalmente IP) como dirección destino (destination address) a la dirección del firewall (o alguna de las direcciones IP del mismo).

• OUTPUT: identifica todo el tráfico generado en el firewall, aquel que tiene en la cabecera de capa 3 (generalmente IP) como dirección origen (source address) a la dirección del firewall (o alguna de las direcciones IP del mismo).

• FORWARD: es todo el tráfico de red que pasa por el firewall por una cuestión topológica, pero que no posee, en capa 3, ninguna de las direcciones IP del firewall, ya sea como dirección de origen o de destino.

Tabla nat

La tabla nat dijimos que sirve para modificar campos en las cabeceras de los paquetes… particularmente en la cabecera IP y de transporte TCP/UDP, tales como las direcciones IP de origen y destino, o los puertos de origen y destino en capa 4.

Las cadenas disponibles en esta tabla son las siguientes:

• PREROUTING: Permite alterar la información de los paquetes antes de tomar la primer decisión de enrutamiento, ni bien llegan al firewall.

• POSTROUTING: Permite alterar la información de los paquetes después de tomar la segunda y última decisión de enrutamiento, antes de salir del firewall y encaminarse al destinatario.

• OUTPUT: Permiten alterar la información de los paquetes generados por el mismo firewall, y antes de tomar la segunda y última decisión de enrutamiento.

Iptables y el flujo de funcionamiento

Vamos a ver ahora uno de los puntos más importantes a tener en cuenta para poder configurar correctamente un firewall iptables: el funcionamiento interno del mismo.

Montar un firewall iptables regla por regla es complejo en el sentido de que las reglas deben escribirse en determinado orden para que tengan efecto.

Ahora bien, ¿cómo saber qué orden darle al escribirlas? ¿Qué dirección IP utilizar como patrón de búsqueda en un paquete? ¿La que trae originalmente desde la red? ¿O la que resultó de editarla con una regla de la tabla NAT?

Para saber ésto y prácticamente todo acerca del núcleo de trabajo de iptables, analicemos la siguiente figura.

Imaginemos que se trata de una capa 3, la capa de red, o IP, en la que realmente está trabajando el firewall iptables.

Imaginemos que en la parte superior se encuentra la capa 4 (transporte) del ordenador que orquesta el firewall, y debajo, la capa 2 (enlace).

Así, cuando el ordenador que hace las veces de firewall recibe un paquete de red, entrará desde la capa inferior, y pasará a capas superiores si el paquete está destinado a él, o saldrá nuevamente por la capa inferior a otro equipo en la red, si es que el paquete estaba destinado a otro nodo.

Ni bien el paquete entra a nuestro firewall, en la imágen, desde la esquina inferior izquierda, procesará las reglas de la tabla NAT cuya cadena sea la de PREROUTING.

Estas reglas permitirán cambiar, por ejemplo, la dirección de destino de los paquetes IP para reenviarlos a un nodo con direccionamiento privado dentro de nuestra LAN o DMZ.

Una vez procesadas estas reglas (si es que existen estas reglas), el paquete pasará a la primer toma de decisión de enrutameinto.

Aquí el firewall actuará como router, y determinará si el paquete está destinado realmente al firewall, o el destinatario es otro nodo de la red.

Si el paquete tiene como dirección ip destino a una de las direcciones IP del firewall, entonces se procederá a pasar a capas superiores, previo haber evaluado las reglas de la tabla filter, cuya cadena es INPUT.

Si el paquete es aceptado por una regla de filter-INPUT, o, en el caso de que no existan reglas que lo validen, si las políticas por defecto lo habilitan, el paquete pasará a capas superiores, donde se evaluará y, eventualmente, se responderá.

En el caso de que así sea, que el paquete pase a capas superiores, y se genere una respuesta, o en el caso de que sea el firewall el que genere un paquete nuevo para establecer una conexión con un nodo del exterior, el dato de aplicación se encapsulará en transporte, y éste a su vez en IP, formando el paquete que el firewall va a pasar a evaluar.

En este caso, el paquete vendrá desde las capas superiores, y entrará al firewall desde la esquina superior derecha, y pasarán a evaluarse las reglas de la tabla nat cuya cadena sea OUTPUT, para modificarle datos a la cabecera IP o TCP/UDP.

Luego se evaluarán las reglas de la tabla filter para la cadena OUTPUT también, de modo que se dejará pasar, o se descartará, el paquete en cuestión.

Si el paquete pasa el filtro de OUTPUT, se tomará una segunda y última decisión de enrutamiento, para determinar a qué host en la red está destinado el paquete, o si es el mismo firewall el destinatario, y así armar la cabecera IP saliente.

Luego de la decisión de enrutamiento, se evaluarán, si existen, las reglas de la tabla nat para la cadena POSTROUTING, donde se podrá, por ejemplo, modificar la dirección ip origen de los paquetes salientes para enmascarar la salida y cambiar direccionamiento privado por direccionamiento púlbico.

En el caso particular de que el paquete que entra al firewall vaya destinado a otro nodo en la red, al igual que un paquete INPUT, primero se evaluarán las reglas de PREROUTING de la tabla nat, y luego de la decisión de enrutamiento, en vez de enviarlo a capas superiores como en el caso anterior, el paquete pasará a evaluar las reglas de FORWARD de la tabla filter.

Si el paquete es aceptado en esta instancia, seguirá su camino y se tomará la segunda decisión de enrutamiento, al igual que un paquete saliente generado en el firewall.

Luego de esta segunda y última decisión de enrutamiento, se evaluarán, si las tuviere, las reglas de POSTROUTING de la tabla nat, y se enviará al medio.

Flujo de trabajo: otra apreciación

Veamos ahora otro diagrama que puede aclararnos este funcionamiento del firewall.

Aquí, consideremos que el tráfico entra por la esquina superior izquierda.

Primeramente se evaluarán las reglas de PREROUTING de la tabla nat, y luego se tomará la decisión de enrutamiento.

Si el paquete está destinado al firewall, entonces se procederá a evaluar las reglas de INPUT de la tabla filter, y, al igual que en el caso anterior, si el paquete es aceptado, pasa a capas superiores.

En capas superiores se lleva a cabo el procesamiento del mismo, y se genera una respuesta (o un paquete nuevo hacia otro destino).

Esta respuesta evaluará el destinatario, para poder armar la cabecera saliente de IP, y se procederá a evaluar la tabla nat, particularmente la cadena de OUTPUT, modificando, si existen reglas, algunos parámetros de la cabecera IP.

Acto seguido, se evaluarán, si existen, las reglas de OUTPUT para la tabla filter, bloqueando el paso, o aceptando el paquete.

Si el paquete es aceptado, se procederá a evaluar la serie de reglas de POSTROUTING de la tabla nat, al igual que en el caso anterior, para enviar finalmente el paquete al destinatario.

Vamos a ver en esta oportunidad vamos a aprender qué es el NAT, o Network Address Translation... en español, traducción de direcciones de red.

Vamos a ver cómo es posible que un equipo en una red LAN, con direccionamiento privado (por ejemplo, una IP de la red 192.168.0.0/24 en IPv4) puede enviar tráfico a Internet, donde dicho direccionamiento no es "routeable" o enrutable en la red de redes.

Aprenderemos qué es lo que permite a un servidor remoto responder un paquete de consulta en Internet, y que esta respuesta pueda llegar a un host cliente en una LAN cuya dirección IP pertenece a un rango privado.

Ahora veamos otro ejemplo de firewall Linux, quizás más común en organizaciones: un cortafuegos que separa una red LAN corporativa, o un cliente, de Internet, o cualquier otra red considerada hostil.

En este caso supongamos que tenemos una serie de clientes en una red LAN, y ésta se conecta a un firewall Linux que le da salida a Internet.

Supongamos también que la red LAN necesita unicamente navegar en el puerto tcp80 (http) y resolver nombres utilizando dns (udp53).

Aquí, a diferencia del caso anterior, todo el tráfico es FORWARD, ya que los paquetes desde la LAN hacia Internet tendrán como IP destino servicios en Internet, y las respuestas tendrán como IP destino los equipos de la LAN que iniciaron las conexiones. Al no tener ningún paquete en el campo de IP destino de la cabecera IP la dirección del firewall (o una de ellas), no es tráfico INPUT, sino FORWARD.

Vamos a montar un firewall que deniegue todo el tráfico, igual que en el ejemplo anterior:

iptables -P INPUT DROP

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

Y ahora vamos a permitir el paso de los paquetes http y dns desde la LAN hacia el exterior, y por supuesto, las respuestas de los servidores en la nube:

iptables -A FORWARD -s ip_lan -p tcp --dport 80 -j ACCEPT

iptables -A FORWARD -d ip_lan -p tcp --sport 80 -j ACCEPT

iptables -A FORWARD -s ip_lan -p udp --dport 53 -j ACCEPT

iptables -A FORWARD -d ip_lan -p udp --sport 53 -j ACCEPT

A estas reglas también le podríamos agregar otros parámetros, como la interfaz de red por la que entra o sale el tráfico.

Un firewall intermedio con DMZ

Configuremos ahora nuestro primer firewall con DMZ.

Como explicamos en la parte teórica, una DMZ, o zona desmilitarizada (demilitarized zone) es un segmento de red IP que generalmente contiene servidores que están expuestos al acceso desde Internet.

Esta zona nos permite aislar a la red interna de los servicios expuestos, de modo que si éstos son comprometidos, le resulte más difícil al atacante acceder a la red interna, y a los servicios confidenciales que tengamos dentro.

Volvamos a plantear el ejemplo del firewall stateless, pero en este caso, agregándole una DMZ con dos servicios, uno web, y uno de correo electrónico (smtp).

La red LAN contiene clientes que requerirán acceso a Internet y a los recursos de la DMZ, mientras que los clientes desde Internet solamente podrán tener acceso a los servicios de la DMZ.

El firewall cuenta con tres interfaces de red, a saber:

• eth0: interfaz que conecta al firewall con la red LAN.

• eth1: interfaz que conecta al firewall con la DMZ.

• eth2: interfaz que conecta al firewall con Internet.

Aquí los requisitos planteado para el ejemplo son los siguientes:

• Firewall en modo denegar todo.

• Acceso desde la LAN a Internet (tcp80 y udp53)

• Acceso desde la LAN al servidor web (tcp443)

• Acceso desde la LAN al servidor SMTP (tcp25)

• Acceso desde Internet al servidor web (tcp443)

• Acceso SSH al firewall (tcp22)

Como se puede apreciar, requerimos principalmente de reglas de FORWARD para todo el tráfico que pasa por el firewall, dirigido desde la LAN a la DMZ o a Internet, o desde Internet a la DMZ.

Además, también serán necesarias reglas INPUT/OUTPUT para permitir el tráfico de SSH destinado a administrar el firewall.

Igual que antes, primero definimos un firewall en modo denegar todo:

iptables -P INPUT DROP

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

Y luego habilitamos las reglas.

Vamos por parte, según los requerimientos expuestos:

• Acceso desde la LAN a Internet (tcp80 y udp53)

Aquí necesitamos reglas que permitan el paso de paquetes desde la LAN hacia los puertos tcp80 y udp53 de Internet, y sus respectivas respuestas.

iptables -A FORWARD -s ip_lan -p tcp --dport 80 -j ACCEPT

iptables -A FORWARD -d ip_lan -p tcp --sport 80 -j ACCEPT

iptables -A FORWARD -s ip_lan -p udp --dport 53 -j ACCEPT

iptables -A FORWARD -d ip_lan -p udp --sport 53 -j ACCEPT

• Acceso desde la LAN al servidor web (tcp443)

Aquí, similar al anterior, necesitamos abrir el puerto tcp443 desde la LAN hacia Internet.

iptables -A FORWARD -s ip_lan -d ip_web -p tcp --dport 443 -j ACCEPT

iptables -A FORWARD -d ip_lan -s ip_web -p tcp --sport 443 -j ACCEPT

• Acceso desde la LAN al servidor SMTP (tcp25)

Ahora abrimos el puerto tcp25 de smtp desde la LAN hacia el servidor smtp que tenemos en la zona desmilitarizada, y cuya ip vamos a suponer que es ip_smtp.

iptables -A FORWARD -s ip_lan -d ip_smtp -p tcp --dport 25 -j ACCEPT

iptables -A FORWARD -d ip_lan -s ip_smtp -p tcp --sport 25 -j ACCEPT

• Acceso desde Internet al servidor web (tcp443)

Idem al anterior, pero para permitir el acceso de la LAN hacia el servidor https de la DMZ. La ip del servidor vamos a suponer que es ip_web.

iptables -A FORWARD -i eth2 -d ip_web -p tcp --dport 443 -j ACCEPT

iptables -A FORWARD -o eth2 -s ip_web -p tcp --sport 443 -j ACCEPT

• Acceso SSH al firewall (tcp22)

Por último, permitimos el acceso desde cualquier origen a nuestro firewall mediante el servicio de SSH, puerto tcp22 por defecto, con tráfico entrante y saliente (respuestas).

iptables -A INPUT -s ip_lan -d ip_fw -p tcp --dport 22 -j ACCEPT

iptables -A OUTPUT -d ip_lan -s ip_fw -p tcp --sport 22 -j ACCEPT

Aplicando NAT al firewall del ejemplo

Recordemos, en el ejemplo 2 teníamos un firewall que separaba una red LAN de Internet, y sin DMZ. Un ejemplo sencillo, que ahora vamos a completar.

Ya habíamos escrito las reglas de filter para permitir el paso de paquetes en ambas direcciones, ahora, para lograr que las direcciones IP origen de los paquetes salientes cambien, debemos agregar al menos una regla de NAT.

Si tenemos ip pública en el firewall, bien podríamos utilizar MASQUERADE como se vió recién:

iptables -t nat -A POSTROUTING -s ip_lan -j MASQUERADE

O, en el caso de conocer la ip pública, por una razón de mejora de rendimiento, podemos “hardcodear” la ip pública en una regla SNAT de esta forma:

iptables -t nat -A POSTROUTING -s ip_lan -j SNAT --to-source ip_pub_fw

donde ip_pub_fw es la ip pública del firewall de cara a Internet.

Escribiendo un script completo

Como hemos visto, un firewall iptables se configura cargando reglas, una detrás de otra, mediante la ejecución de comandos iptables por línea de órdenes.

Es por esto que una de las principales formas que suelo utilizar para configurarlo es mediante scripts de shell.

Además, resulta sumamente útil para configurar políticas por defecto, y luego agregar reglas según las necesidades, y ordenarlas como mejor nos convenga.

Escribir un script también soluciona una parte importante de las configuraciones de firewalling: editar reglas.

Al ejecutarse en orden las reglas de iptables, deben cargarse en orden también, agregándose al final, o insertándose al principio, según sean generales o específicas respectivamente. Con el script, simplemente agregamos reglas al final en el orden que necesitemos, y movemos hacia arriba y abajo las reglas según sea nuestro menester.

Aquí, un punto importante es, al iniciar la configuración del firewall en el script, limpiar todas las reglas de iptables antes de cargarlas, de modo que podamos modificar el script, y las reglas se carguen desde cero en el orden correcto, no interfiriendo con las reglas cargadas en la corrida anterior del mismo.

En este apartado aprenderemos a crear nuestro shell script completo para montar nuestro firewall desde cero.

Finalmente, y antes de pasar a las configuraciones, debemos plantearnos dos maneras de montar un firewall.

Por un lado, podemos establecer políticas por defecto a aceptar todo, y luego ir denegando el tráfico que no deseemos que pase. Por otro, las políticas por defecto serían las de denegar todo, y luego ir aceptando el tráfico que necesitemos.

Para la primera opción, la configuración resulta relativamente sencilla, no requiere mayores conocimientos, y suele funcionar en la mayor parte de los casos. Esta opción puede considerarse, a simple vista, más insegura que la de denegar todo, puesto que si olvidamos bloquear algún tipo de tráfico no deseado, por defecto será aceptado.

La otra opción, la de denegar todo, por su parte, bloquea por defecto todos los accesos en el firewall, y somos nosotros como administradores quienes debemos habilitar los protocolos que sean necesarios.

Esta segunda opción es un tanto más complicada de configurar que la primera, y requiere algunos conocimientos adicionales respecto de paquetes de red y protocolos del stack TCP/IP.

En un firewall denegar todo, por defecto todo el tráfico estará bloqueado, y deberemos habilitar el que sea necesario, por lo que si olvidamos activar algún tipo de filtro particular, el tráfico será descartado.

Políticas: Aceptar todo

Lo primero que tenemos que configurar en nuestro script son las reglas de limpieza del firewall, vaciado de los buffers, y de configuración de las políticas por defecto.

Esto podemos hacerlo de la siguiente manera:

#!/bin/bash

# Inicializamos el firewall limpiando las reglas

iptables -F

iptables -Z

iptables -t nat -F

# Cargamos las politicas por defecto

iptables -P INPUT -j ACCEPT

iptables -P OUTPUT -j ACCEPT

iptables -P FORWARD -j ACCEPT

Y luego deberemos empezar a colocar las reglas que vayan a denegar el tráfico que no creamos conveniente. Estas reglas serán de la tabla filter, corresponderán con cualquiera de las cadenas activas (INPUT, OUTPUT o FORWARD), y corresponderán con acciones como DROP o REJECT.

# Cargamos las reglas de denegación

iptables -A FORWARD … -j DROP

iptables -A INPUT … -j DROP

....

En cualquier ubicación de este script pueden colocarse las reglas de NAT necesarias para enmascarar el tráfico, o para permitir el acceso desde Internet a servicios internos (lo veremos más adelante).

Generalmente suelo colocar estas reglas luego de cargar las políticas por defecto, y de configurar, en caso de que así lo hagamos, el manejo de estados de las conexiones, tópico que analizaremos más adelante en el curso.

En el ejemplo 3 disponíamos de un firewall que conectaba a la LAN a Internet, y además tenía una “pata” en una DMZ con servicios expuestos.

Recordemos además que el firewall tenía una interfaz llamada eth0 que conectaba a la LAN, eth1 que daba con la DMZ, y eth2 conectada a Internet.

En este ejemplo, para “enmascarar” el tráfico que sale de la LAN a Internet podríamos escribir la siguiente regla:

iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

O, mediante SNAT, de esta forma:

iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source ip_pub_fw

Aquí, todo el tráfico que salga a Internet será enmascarado con la IP pública del firewall.

Debemos hacer una importante aclaración en este caso. Particularmente, esto funcionaría correctamente si tanto la red LAN como la DMZ tienen direccionamiento privado.

En algunos casos, los servicios expuestos en la DMZ tienen direccionamiento público, por lo que no será necesario enmascararlos con NAT.

Una opción interesante en este caso, sería agregar otro modificador a nuestra regla de NAT que permita enmascarar el tráfico proveniente de la red LAN, pero excluya el de la DMZ.

¿Qué parámetro utilizar? ¿qué diferencias tienen los dos segmentos de red? Básicamente, la dirección IP.

Suponiendo, por ejemplo, que la red LAN tiene un direccionamiento 192.168.10.0/24, podríamos reescribir las anteriores reglas como sigue:

iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth2 -j MASQUERADE

O, mediante SNAT, de esta forma:

iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth2 -j SNAT --to-source ip_pub_fw

Con lo que estaríamos solamente enmascarando el tráfico saliente por la interfaz eth2 (conectada a Internet) y proveniente desde la red LAN.

Políticas: Denegar todo

Veamos ahora los pasos necesarios para montar nuestro firewall denegando todo el tráfico por defecto.

Lo primero será exactamente igual, limpiar el firewall, y al cargar las políticas, utilizaremos DROP en vez de ACCEPT, de una manera similar a esta:

#!/bin/bash

# Inicializamos el firewall limpiando las reglas

iptables -F

iptables -Z

iptables -t nat -F

# Cargamos las politicas por defecto

iptables -P INPUT -j DROP

iptables -P OUTPUT -j DROP

iptables -P FORWARD -j DROP

Ahora bien, dado que estamos denegando todo tipo de tráfico, esto incluye al tráfico local que utilicen los procesos de nuestra computadora.

En GNU/Linux muchos procesos se comunican entre si utilizando sockets, tanto de tipo UNIX como de tipo INET. Estos últimos hacen uso del stack TCP/IP exactamente igual que los procesos que se comunican en una red de computadoras, con la diferencia de que, en vez de utilizar las interfaces de red físicas, hacen uso de la interfaz de red lógica de loopback, comúnmente llamada “lo” en la mayoría de los sistemas Linux.

Es por esto que, si montamos un firewall que deniegue todo tipo de contenidos de red, será menester habilitar el tráfico saliente y entrante desde y hacia la interfaz de loopback para que los procesos locales puedan trabajar sin inconvenientes.

# Habilitamos el tráfico local

iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT

Una vez hecho esto, ya podremos comenzar a cargar las reglas de filter que acepten el contenido en la dirección que creamos conveniente.

Y por supuesto, podremos cargar las reglas de NAT adicionalmente para realizar los enmascaramientos y traducciones de direcciones de destino.

Hemos analizado los diferentes tipos de tráfico desde el punto de vista de nuestro firewall, tráfico que pasa por el firewall en modo forward, tráfico que se genera en el firewall y sale hacia otra red, a otro destino, en modo output, o tráfico que se genera en otro destino y viene hacia nuestro firewall en modo input.

En este punto cabe recalcar el hecho de que los tipos de tráfico son relativos al equipo que estamos analizando, por ejemplo, en este caso en nuestro firewall, como hemos acabado de ver en la presentación anterior, si el cliente envía un paquete a Internet, hacia un servidor cualquiera en Internet, en el firewall ese tráfico será de tipo forward, pasará por el firewall hacia un cliente en Internet, desde el cliente hacia, por ejemplo, un servicio en Internet, pero si lo analizamos desde el punto de vista del cliente, el tráfico será output en el cliente... el mismo que en el firewall es forward, en el cliente es de tipo output.

Así, el tráfico de respuesta será de tipo forward en el firewall, pero a su vez ese tráfico va a llegar destinado a la ip propia del cliente, por lo tanto va a ser tráfico input en ese cliente.

Como conclusión de esta primera parte podríamos decir que el sentido del tráfico, si es input, output o forward, se analiza de forma relativa al equipo que estamos viendo, si el paquete se genera en mi equipo, y la ip de origen de ese paquete es la ip que tiene mi equipo, será un tráfico de tipo output desde ese equipo hacia otro equipo en la red, mientras que, por ejemple, el paquete generado en otro nodo de la red y destinado a mi equipo, con la dirección ip destino en la cabecera ip coincidente con la dirección ip de mi equipo, será tráfico input a mi equipo, a mi cliente por ejemplo, o a mi firewall.

Por otro lado, el tráfico que sea generado en un nodo de la red y pase por mi equipo hacia otro nodo de la red, es decir, el tráfico generado desde una IP determinada, y con destino a otra ip específica de la red, y que no sean estas ip's ninguna de las de mi firewall, va a ser tráfico forward en el mismo.

Por lo tanto un cliente genera un paquete, sale de ese cliente (es tráfico output para ese cliente), pasa por el firewall (tráfico forward en el firewall), y entra a un servidor remoto (tráfico input en el servidor remoto). El tráfico de respuesta del servidor será output en el servidor, pues es generado en el servidor, con su ip de origen, pasa por el firewall (forward en el firewall) y entra al cliente que lo llamó (tráfico input en el cliente). 

Por lo tanto siempre tenemos que tener en cuenta la ubicación relativa en la cual estamos analizando el sentido de tráfico de nuestro firewall.

Como conclusión, debemos recordar entonces, y un poco para cerrar esta sección del curso, el tipo de tráfico depende del equipo en el que estamos analizandolo. En la generalidad de los casos, y particularmente en el caso de este curso, salvo que se indique lo contrario, todo el tráfico input, output y forward hará referencia al firewall de la red, o a alguno de dichos firewalls.

Este es un concepto muy importante por el hecho de que las reglas de firewalling de iptables que carguemos tendrán el efecto deseado si sabemos interpretar correctamente el sentido en el que viajan los paquetes de la red, y dónde estamos cargando estas reglas... y por supuesto, el tipo de tráfico que representa para nuestro firewall y no para un cliente cualquiera.

¿Qué significa esto?

Que si yo estoy cargando una regla de tipo output por ejemplo, en mi firewall para filtrar tráfico que venga desde un cliente hacia un servicio remoto en Internet, no va a funcionar, simplemente porque esa regla está filtrando tráfico generado en el firewall con cualquier otro destino... si bien el paquete sale del firewall, es paquete que pasa por el firewall desde un cliente cualquiera, y no es paquete generado en el firewall.

Es importante entonces que recordemos la posición relativa del tráfico respecto de la ubicación de nuestro firewall para poder configurarlo correctamente.

Iptables: el comando

Iptables es un firewall completo, y sus reglas, tablas y cadenas se configuran mediante un comando homónimo.

Veremos ahora la sintaxis de este comando, y cómo podemos utilizarlo para ingresar las reglas a nuestro firewall.

Antes que nada, es importante notar que el ingreso de las reglas es secuencial, una por una, y en el orden en el que fueron ingresadas, serán luego evaluadas.

Es decir, si en el firewall tenemos configuradas 10 reglas, con cada paquete que pase por el mismo se irán evaluando una a una, hasta que alguna de ellas calce, mediante su patrón de selección, con el paquete en cuestión.

Si la regla coincide, entonces se ejecutará la acción correspondiente, y se saldrá de la ejecución del firewall para ese paquete, así sea aceptarla o denegarla (caso de la tabla filter).

Por lo que, si por ejemplo tenemos una regla que descarta un paquete, porque coincide con una dirección ip de origen o destino, y debajo una que lo acepta, más específica, que a la dirección le agrega un puerto, el paquete será descartado por la primera regla, y nunca llegará a evaluarse la segunda, que lo aceptaba.

Es por esto que siempre las reglas más específicas deben configurarse en la parte superior del firewall, de modo que si no hay reglas que coincidan en primera instancia, se siga evaluando el resto, hasta que alguna regla lo acepte o deniege.

En el caso particular de no tener reglas, o que ninguna regla coincida con el paquete en cuestión, se aplicarán las políticas por defecto, ya sea para aceptar o denegar, según se tenga configurado.

Por esto es importante saber, según vimos en el flujo de trabajo de iptables, qué cadenas y tablas se ejecutan primero, y cuales después, y con ello tener claro cómo escribir las reglas, y en qué orden cargarlas.

Veamos la sintaxis del comando:

Los modificadores explicados son los siguientes, para poder montar una regla básica en iptables:

• -t: este modificador permite especificar la tabla sobre la que se está agregando la regla. Entre las opciones tenemos “filter”, “nat” o “mangle”, siendo la primera la opción por defecto en el caso de omitir este modificador.

• Patrón: El patrón de selección permite especificar una serie de parámetros que permitirán validar determinados paquetes de red, o conexiones. Así, podremos “encontrar” cierto paquete con una dirección ip específica, o un puerto, o protocolo, o mac, etc.

• -j establece la acción (u objetivo, según la documentación) que se llevará a cabo si el paquete que está pasando por el análisis del firewall coincide con el patrón de selección.

• Y finalmente, el comando nos permite agregar regla, eliminar regla, y hacerlo en determinada cadena de la tabla. Aquí, por ejemplo, un “-A INPUT” permite agregar una regla (-A: Append) en la cadena INPUT de la tabla que hayamos utilizado con “-t”, idealmente, “filter”.

Patrones de selección de tráfico

Veamos ahora cómo podemos especificar los patrones de selección de tráfico que deberán coincidir con los paquetes de nuestro interés.

• -i | --in-interface name

  Especifica el nombre de una interfaz de red por la que el paquete entró al firewall. Por ejemplo, si queremos capturar todos los paquetes que entran por la interfaz eth0, deberiamos colocar: “-i eth0”.

• -o | --out-interface name

  Especifica el nombre de una interfaz de red por la que el paquete salió del firewall. Por ejemplo, si queremos capturar todos los paquetes que salen por la interfaz eth0, deberiamos colocar: “-o eth0”.

• -s | --source address[/mask][,···]

  Especifica la dirección ip de origen que tienen los paquetes en el campo “source” de su cabecera IP. Aquí se pueden colocar:

  • La dirección ip del ordenador de origen, y su máscara en la notación /xx.

  • La dirección ip de la red a la que pertenece el ordenador de origen, y su máscara en la notación /xx.

  • Un nombre de host que, al momento de interpretar la regla, será resuelto a una dirección IP. En este último caso hay que tener cuidado con el nombre de host, y si éste resuelve a varias direcciones IP según balanceo de carga o geolocalización, pues, por ejemplo, si colocamos “google.com” puede que nuestra regla resuelva a una dirección IP determinada, y el paquete venga desde otra dirección IP del mismo google.com, lo que hará que la regla no tenga efecto.

• -d | --destination address[/mask][,···]

  Idem al anterior, pero considerando la dirección IP destino de los paquetes en la cabecera IP.

• -p | --protocol proto

  Este parámetro permite especificar el protocolo encapsulado encima de IP. Aquí las opciones válidas son tcp, udp, icmp, icmpv6, esp, ah, sctp o all.

  En el caso de las opciones tcp y udp, además podemos agregar parámetros para especificar puerto de origen o destino que traigan los paquetes en la correspondiente cabecera de transporte:

• --sport: permite marcar el puerto origen que llevarán los paquetes en la cabecera tcp o udp, en el campo “source port”.

• --dport: permite marcar el puerto origen que llevarán los paquetes en la cabecera tcp o udp, en el campo “destination port”.

  Por otro lado, utilizando la opción icmp, el protocolo de mensajería en redes tcp/ip, nos da la posibilidad de agregar nuevos parámetros respectivos a este protocolo, como ser el código y tipo de mensaje icmp que deberán llevar los paquetes de red. Esto puede realizarse con la opción:

  • --icmp-type, que permite cargar el tipo y código con el nombre de tipo directamente, o medianteel par tipo/código. Es decir, podemos especficar tipo_mensaje o nro_tipo/nro_codigo, donde el nro_codigo es opcional.

Mas adelante en el curso analizaremos otros patrones adicionales, ya que iptables provee una gran variedad de alternativas a la hora de establecer los patrones de selección de tráfico.

Comandos

Veamos ahora algunos comandos que podemos utilizar en iptables.

Los comandos deben escribirse en mayúsculas, y generalmente van acompañados de una cadena, aunque los hay para tareas generales en el firewall.

Veamos algunos:

• -A | --append cadena

  Permite agregar una regla en una cadena particular.

• -D | --delete cadena

  Permite eliminar una regla desde una cadena particular.

• -I | --insert cadena

  Permite insertar una regla en una cadena particular. A diferencia del “-A”, el “-I” inserta la regla encima de las demás reglas de la tabla, lo que hace que sea evaluada antes que las demás, mientras que “-A” agrega una regla al final de la tabla.

• -R | --replace cadena

  Permite reemplazar una regla con otra.

• -L | --list [cadena]

  Permite listar las reglas de una cadena. Si se omite la cadena, se listarán todas las reglas de todas las cadenas de la tabla en cuestión, por defecto, “filter”.

• -F | --flush [cadena]

  Permite eliminar todas las reglas de una tabla. Si se especifica la cadena, solamente aplicará a la cadena de dicha tabla.

• -Z | --zero [cadena]

  Pone a cero los contadores de paquetes del firewall para una cadena particular, o para todas.

• -P | --policy cadena

  Permite especificar una política por defecto para una cadena particular de una tabla. Aquí, por ejemplo, se puede establecer aceptar o denegar todos los paquetes en el caso de que no se encuentre ninguna regla que los deniegue/acepte. Esto se analizará más adelante.

Analicemos algunas acciones

Ya hemos visto cómo se establece una regla con el comando iptables, cómo especificar una tabla, un patrón de selección, y un comando para agregar o eliminar, por ejemplo, la regla, de una cadena.

Veamos ahora cómo especificar la acción a llevar a cabo con los paquetes que coincidan con la regla, y cómo podemos establecer esta acción.

Entre las acciones comunes, tenemos las siguientes:

• DROP / ACCEPT

  DROP descarta el paquete, lo elimina, sin ningún tipo de notificación, mientras que ACCEPT lo acepta y deja pasar dentro del firewall.

  • Esta acción está disponible para la tabla filter.

• LOG

  Permite generar una línea de log mediante protocolo syslog. Por defecto en implementaciones como rsyslog en Debian, los logs van a ser almacenados en el archivo /var/log/messages. Esta opción también da la posibilidad de agregar un nivel de log para syslog, al igual que un prefijo dentro del archivo de texto para identificar el log. Algunas opciones válidas son:

  • --log-level nivel: especifica un nivel de log para syslog.

  • –log-prefix prefijo: especifica un prefijo, en texto.

  • --log-uid: loguea el uid del usuario que genera el log.

  • --log-tcp-sequence: agrega al mensaje los numeros de secuencia de tcp,

  • --log-ip-options: agrega al mensaje la información de opciones de la cabecera IP.

• DNAT (solo en PREROUTING y OUTPUT)

  Permite realizar destination nat en las cadenas OUTPUT y PREROUTING de la tabla NAT. Aquí podremos modificar la ip de destino de los paquetes salientes desde el firewall (OUTPUT), o los paquetes entrantes al mismo (PREROUTING).

  Esta dirección IP de destino se establece mediante el modificadro –-to-destination.

  • Esta acción está disponible para la tabla nat.

• SNAT (solo en POSTROUTING e INPUT)

  Idem al anterior, pero para modificar la dirección ip de origen de los paquetes salientes (POSTROUTING) o entrantes directamente al firewall (INPUT).

  Esta dirección ip origen se establece mediante la opción --to-source.

  • Esta acción está disponible para la tabla nat.

• MASQUERADE (solo para POSTROUTING)

  Idem al SNAT, con la diferencia de que, en vez de especificar una dirección ip de origen con “--to-source”, lee la información desde la interfaz de red saliente del firewall, y reemplaza esa dirección IP en la cabecera IP del paquete, en el campo “source address”.

  Esto es muy útil cuando nuestro firewall tiene una conexión ip pública con ip dinámica.

  • Esta acción está disponible para la tabla nat.

• REDIRECT (solo para OUTPUT y POSTROUTING)

  Permite redirigir el paquete saliente a otro puerto que es diferente del puerto destino original en cabecera de transporte.

  • Esta acción está disponible para la tabla nat.

• REJECT (solo para INPUT, OUTPUT Y FORWARD)

  Es similar a DROP, con la diferencia que en vez de descartar el paquete, lo rechaza, enviando al originante un mensaje particular.

  Este mensaje puede especificarse con la opción “--reject-tith tipo”, donde el tipo puede ser, por ejemplo, icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited, icmp-host-prohibited, o icmp-admin-prohibited.

Hagamos un breve paréntesis de lo que hemos visto hasta ahora para ordenarnos un poco las ideas.

Hablamos de la sintaxis del comando iptables, dijimos que el comando iptables cada vez que se ejecuta permite modificar el estado del firewall en el núcleo linux, agregando, eliminando o modificando reglas, y esta sintaxis involucraba un modificador -t que nos permitía especificar la tabla en la cual íbamos a estar trabajando con la regla, y en el caso de no especificar ninguna tabla, decíamos que la tabla por defecto era filter.

Luego teníamos diferentes comandos para manipular las reglas dentro del firewall.

Esos comandos eran por ejemplo:

• -A para agregar una regla al final del firewall, 
• -I para insertar una regla al principio del firewall
• -D para eliminar una regla
• -R para reemplazar una regla por otra
• -F por ejemplo cuando nosotros queremos "flushear" o eliminar todas las reglas del firewall, o de alguna cadena particular
• -Z para limpiar los contadores de tráfico entrante, saliente, descartado y demás.

Esos eran algunos de los comandos que nosotros teníamos en nuestro iptables.

El patrón de selección nos iba a permitir a nosotros especificar si la regla iba a coincidir con cierto y determinado tipo de tráfico o no.

En este caso si nosotros queremos aceptar o denegar o llevar a cabo alguna acción particular sobre un determinado tipo de tráfico, el patrón de selección debe coincidir con ese tipo de tráfico.

Y aquí teníamos algunas opciones particulares como ser:

• -i o -o en minúscula para permitirnos especificar si el tráfico entra por una determinada interfaz de red, o sale una detemrinada interfaz de red.
• -s o -d para especificar la dirección IP o la dirección IP de una red, o el nombre de dominio de un host que luego va a ser resuelto a una dirección IP para poder "matchear" con ese tipo de tráfico, ya sea una dirección IP entrante o saliente, siempre considerando la cabecera IP de los paquetes.
• Además este patrón nos iba a permitir especificar el protocolo a nivel de capa 3, capa 4, en este caso serían protocolos TCP, UDP, ICMP, ICMPv6, ALL para especificar todos los protocolos. Esto quiere decir que si nosotros especificamos un protocolo particular podíamos hacer coincidir esa regla con todos los paquetes de ese protocolo, podíamos denegar por ejemplo, o aceptar todo el tráfico de protocolos TCP, de protocolos UDP, de protocolos ICMP.

A su vez, ciertos protocolos, como TCP o UDP, nos habilitaban unas opciones extra como ser --sport o --dport, que nos permitían especificar el puerto origen y el puerto destino para hacer mas específica la regla que nosotros estamos escribiendo. Por ejemplo podíamos aceptar o denegar tráfico de cierto protocolo de capa 4 como TCP, con cierto puerto destino u origen, coincidiendo por ejemplo la regla con lo que se encuentra por supuesto en las cabeceras de tráfico TCP o IP.

Y luego estos patrones que nos permiten seleccionar cierto y determinado tipo de tráfico nos iban a permitir llevar a cabo alguna acción particular, es decir, con todo el tipo de tráfico que coincide con cierto patrón yo podía llevar a cabo una acción: podía denegar o aceptar el tráfico, podía loguear ese tráfico, podíamos reenviar el tráfico con un redirect a otro puerto, a otro servicio de aplicación, podíamos descartar el tráfico enviándole un mensaje de paquete rechazado al originante de ese mensaje, en vez de simplemente descartar completamente el paquete.

Por otro lado hablamos del orden de las reglas. Dijimos que era importante especificarlas en orden, y dijimos que las reglas más específicas van en la parte superior del firewall y las reglas más generales van en la parte inferior del mismo.
De esta forma nosotros podíamos, si se quiere, denegar algún tipo de contenido en reglas superiores, y el tráfico que no coincide con ese contenido podíamos aceptarlo.

Nosotros cuando aceptamos un tipo de tráfico o paquete particular a través de iptables, automáticamente salimos de la ejecución del firewall y no volvemos a entrar hasta el siguiente paquete. De esta forma podemos ordenar correctamente las reglas, ya que si por ejemplo tengo una regla que deniega cierto tipo de contenido, y encima coloco una regla que lo acepta, vamos a aceptar el contenido y vamos a salir de la ejecución del firewall, y nunca vamos a llegar a ejecutar la regla que lo deniega. Si quiero denegar cierto tipo de tráfico debo colocar esa regla encima de la regla que lo acepta, por ejemplo.

Para esto también tenemos que tener en cuenta una concepción fundamental sobre cómo montar un firewall, y aquí tenemos dos formas: aceptar todo tipo de tráfico por defecto, mediante políticas por defecto (estas políticas las cargábamos al firewall con la opción -P) y luego ir denegando ciertos contenidos utilizando reglas comunes.

La política por defecto me iba a permitir a mi aceptar o denegar cierto tipo de tráfico en el caso de que éste no coincida con ninguna regla especificada en el firewall. De hecho, si no tengo ninguna regla especificada en el firewall, por defecto estoy siempre ejecutando estas políticas.

En un Linux recién instalado, por defecto las políticas son de aceptar todo, y es por eso que no hace falta que escribamos ninguna regla para permitirnos entrar a una página web, resolver nombres o conectarnos a un ssh, estamos aceptando todo.

Esta es una de las concepciones de un firewall: o ponemos políticas de aceptar todo tipo de contenido y luego vamos denegando algunos tipos de tráfico que no queremos que pasen.

Por otra parte podríamos denegar todo tipo de contenidos, y luego ir aceptando simplemente el tráfico que yo quiero que pase por ese firewall.

En la primera opción la escritura del firewall es sencilla, tenemos menos riesgos de cometer errores o bloquear tráfico que deberíamos dejar pasar, ya que si olvidamos escribir alguna regla que deniegue un paquete, lo estaremos aceptando. Eso también influye negativamente en la seguridad, nosotros, si vamos a abrir por defecto todo el firewall, debemos cerrar específicamente todos los puertos y tipos de conexiones que no queremos que pasen por el firewall, y debemos ser muy conscientes a la hora de escribir estas reglas.

Sin embargo, si escribimos el firewall que deniega todo y luego abrimos las conexiones que deseamos que pasen, ese problema de seguridad no lo tenemos, ya que al olvidar abrir un tipo de contenido, por defecto va a ser descartado o denegado, con las políticas por defecto a denegar todo (DROP). Sin embargo montar este tipo de firewalls es mas complejo y requiere más conocimientos por parte de quien lo administra, puesto que tenemos que saber muy bien los nombres de los protocolos, números de puertos, qué conexiones establecen conexiones relacionadas (si manejamos estados de conexiones), y algunas cuestiones que hacen al manejo más experto de un firewall.

En este caso la recomendación siempre es denegar todo, y luego ir abriendo lo que nos hace falta para poder trabajar.

Sin embargo en las primeras prácticas que hagamos vamos a trabajar con firewalls que tengan todo abierto por defecto para no comenter errores y para ir aprendiendo sobre el manejo del firewall y la configuración de las reglas.

Definiendo un firewall statefull

En un firewall stateless debemos aceptar el tráfico en ambas direcciones.

Esto puede traernos algunos inconvenientes, entre ellos:

1) Un atacante podría inyectar tráfico modificado por medio de las reglas que utilizamos para aceptar tráfico de respuesta.

Imaginemos que necesitamos que la red interna salga a Internet al puerto 80 de tcp (http).
Con lo que sabemos hasta ahora, deberíamos aceptar el tráfico saliente desde la red LAN, con protocolo tcp y puerto destino 80 y el tráfico entrante hacia la red LAN, con protocolo tcp y puerto origen 80.

Ahora bien, nada le impide a algún atacante en Internet generar tráfico, paquetes IP, colocando como puerto de origen al puerto tcp80, y enviarlo a nuestra red.

Ese tráfico (por supuesto, bajo algunas consideraciones) será aceptado por nuestro firewall ya que para el firewall no hay diferencia entre un paquete nuevo que llega desde un puerto 80 y uno que representa la respuesta de un paquete saliente.

2) La definición es compleja, y por ello es propensa a errores.

La solución para esto es utilizar los estados de conexiones que administra el mismo firewall iptables.

Estados de las conexiones

En iptables los paquetes se encuentran en un estado particular, y este puede ser:

• INVALID, o paquetes no asociados a ninguna conexión conocida
• NEW: primer paquete transferido entre dos nodos este paquete es el que crea una nueva conexión
• ESTABLISHED: paquete perteneciente a una conexión previamente establecida
• RELATED: paquete nuevo, pero asociado a una conexión previamente establecida.

Estas conexiones relacionadas son propias de protocolos multiconexión, como por ejemplo ftp, que utiliza una conexión para comandos de control y otra conexión relacionada para transferencia de datos de subida o bajada.

Módulos adicionales

Antes de seguir, es necesario, y para mejorara nuestra comprensión de las reglas que vendrán que hablemos de módulos de extensión de iptables, o simplemente, "match".

Las opciones que permiten especificar un patrón de selección para tráfico en iptables, mayormente, ya las hemos venido estudiando.

Hemos visto que podemos seleccionar tráfico por interfaz de red de entrada, o de salida, por dirección ip de host, red, etc., tanto de origen como destino por protocolo de transporte, puertos
de origen y destino, etc.

Para diseñar algunas reglas más específicas y con la intención de satisfacer algunas necesidades puntuales de los administradores de firewalls, iptables permite cargar módulos
de extensión o match que nos habilitan nuevas opciones para hacer aún más "fina" la selección
con nuestro patrón de tráfico.

Estos módulos se cargan con la opción "-m" acompañada del nombre del módulo, y cada módulo sumará opciones adicionales...

Algo así como cuando cargábamos la opción "-p" para protocolo, que en el caso de ser éste tcp o udp nos "habilitaba" las opciones de puerto origen o destino, --sport o --dport respectivamente.

Algunos módulos comunes son, por ejemplo,

• connbytes, para contabilizar bytes o numeros de paquetes de una conexión o flujo de tráfico.
• connlimit, para limitar el número de conexiones en paralelo, y con ello disminuir, por ejemplo, los destrozos que puede hacernos un ataque de denegación de servicios distribuido.
• ah, o esp, para gestionar paquetes de autenticación y cifrado de vpn's de capa 3 como ipsec.
• state, que nos permite especificar el estado de conexión que deberán tener los paquetes que coincidan con la regla.

En este apartado nos centraremos en state... al finalizar el curso comentaremos ejemplos de algunos módulos de extensión adicionales que pueden llegar a ser de utilidad.

Stateful FORWARD

Veamos ahora algunos ejemplos siempre, por supuesto, considerando un firewall con políticas por defecto DROP.
Supongamos que tenemos un cliente conectado a un firewall que le da acceso a Internet.

El primer paquete de una comunicación entre el cliente y un equipo en Internet para iptables será considerada de tipo nueva, o NEW.

Imaginemos que este cliente necesita salir a internet a los puertos http(tcp80) dns (udp53) y ssh (tcp22).

Estas tres reglas de firewalling iptables les va a permitir la salida de los primeros paquetes hacia Internet.

Todas son forward, puesto que el tráfico pasa por el firewall, proveniente desde el cliente y con un destino en Internet, dirección ip que no corresponde con ninguna de las del firewall.

Hemos especificado la dirección ip de la LAN  que incluye al cliente y los protocolos y puertos respectivos según las necesidades.

Ahora bien, las respuestas desde Internet no están aceptadas, y serán descartadas puesto que no hemos colocado las reglas que acepten estos paquetes en el sentido opuesto, como haríamos en un firewall stateless.

Sin embargo, si agregamos una sola regla podríamos tener un efecto similar y aceptar los paquetes de respuesta.

Como se ve, esta regla también es para  la tabla filter, cadena FORWARD, con la única diferencia, y contenido nuevo, que hemos agregado la opción "-m state".

Esta opción nos permite cargar el módulo de extensión "state" de iptables.

Al cargar módulos de extensión estamos habilitando una serie de modificadores y opciones nuevos para nuestra regla.
En este caso, el módulo state nos permite especificar, entre otras cosas, el estado del paquete, mediante la opción --state.

Como se ve en la regla, los modificadores completos quedaron "-m state --state ESTABLISHED" esto quiere decir que agregamos el módulo state, y como estado, dentro del patrón de selección solamente consideramos los paquetes que pertenezcan a conexiones establecidas.

En este caso, primero aceptamos todos los paquetes salientes desde nuestra red LAN con las reglas clásicas. Estos paquetes pertenecen a conexiones nuevas. Las respuestas serán aceptadas con la regla de gestión de estado, ya que perteneceran, para iptables, a una conexión de tipo ESTABLISHED.

Como se puede apreciar, por un lado, la regla de estado permite aceptar todo el tráfico de tipo establecido en cualquier sentido, ya sea desde la red LAN hacia Internet, o desde Internet hacia los clientes de la LAN, y no solamente para los protocolos expuestos, es decir, si por ejemplo, permitimos tráfico saliente al puerto tcp443 las respuestas también serán aceptadas por la regla de estado.

Claro está que podemos restringir la regla de estados, o incluso crear más de una, según nuestras necesidades.

Por otro lado, nótese que no hemos especificado el estado de las conexiones salientes, puesto que generalmente serán todas nuevas.

No obstante, si quisiéramos, y ya con un nivel de paranoia superior, podríamos especificarlo con algo similar a "-m state --state NEW" en cada una de las reglas de protocolo.

Stateful en OUTPUT

Consideremos un esquema similar al de recién donde tenemos un cliente en una LAN que conecta contra un firewall para permitirse su acceso a Internet.

En este caso, imaginemos que el cliente no desea salir a Internet si no conectar directamente al firewall por ejemplo, para administrarlo mediante un protocolo como ssh (tcp22).

Lo mismo, si desde Internet deseamos conectar contra nuestro firewall para administrarlo este tipo de tráfico será todo de tipo INPUT ya que la dirección destino de los paquetes que lleguen al firewall va a coincidir con alguna de las direcciones del firewall, ya sea la interna y privada de la LAN o la pública que expone a Internet.

La regla que no s va a permitir aceptar este tráfico desde la LAN, será una similar a la que se ve en pantalla.

Aquí, la regla es de tipo INPUT de la tabla filter tráfico proveniente desde la LAN o desde Internet (ya que no especificamos origen) y destinado al puerto 22 de tcp del firewall.

Este tráfico será aceptado, pero las respuestas no, puesto que no hemos habilitado el tráfico en sentido opuesto.

Bien, en este caso, podemos simplemente agregar una regla de gestión de estados para permitir estos paquetes de respuesta, tanto hacia la LAN, como hacia Internet.

Como se puede ver, el módulo match cargado vuelve a ser state, y el estado especificado established, como en el caso anterior.

La única diferencia es que la cadena es OUTPUT en vez de FORWARD, ya que como los paquetes entrantes
eran de tipo input, las respuestas fueron generadas en el mismo firewall, y enviadas desde su stack TCP/IP al destino, al cliente que los solicitó... esta es la definición del tráfico OUTPUT.

Como conclusión, aquí estamos aceptando todo el tráfico saliente, OUTPUT, perteneciente a conexiones ya establecidas, previamente mediante tráfico nuevo de INPUT como se puede ver en las reglas.

Al igual que el caso anterior, la regla de estados puede enriquecerse con otros modificadores y patrones de selección de paquetes, y hacerla más específica que ésta, para necesidades particulares.

Stateful en INPUT

Consideremos ahora este ejemplo, como siempre, un firewall que separa  una red LAN de Internet.

En este caso, supongamos que es el mismo firewall el que "desea" establecer conexiones hacia el exterior, por ejemplo, para llevar a cabo una actualización del sistema.

Si es este el caso, requerirá acceso a los puertos http, https y dns, tcp80, tcp443 y udp53 respectivamente.

Escribimos las reglas con las que vamos a permitir la salida de estos paquetes, son reglas OUTPUT de la tabla filter, ya que es tráfico generado en el firewall con un destino en Internet.

Ahora bien, las respuestas de estos paquetes OUTPUT, serán de tipo INPUT, ya que irán destinados al firewall, a alguna de sus direcciones IP.

Este tráfico podrá ser aceptado por medio de una regla de manejo de estados para conexiones establecidas, con la cadena INPUT de la tabla filter.

Stateful: conexiones relacionadas (RELATED)

Veamos ahora un ejemplo de conexiones relacionadas.

Una conexión relacionada puede considerarse una conexión establecida (established), pero que depende, o ha sido generada por otra conexión establecida ya en curso.

Este es el caso del protocolo FTP, file transfer protocol, o protocolo de transferencia de archivos.

Este protocolo utiliza dos canales  de comunicación, uno para control  y comandos, y otro para transferencia de datos.

Así, por ejemplo, cuando conectamos a un servidor ftp, estaremos utilizando el canal de control, y si ejecutamos un comando get para descargar un archivo, el comando irá por el canal de control mientras que el archivo,  viajará por el canal de datos.

Supongamos que en nuestra red LAN deseamos permitir a los clientes conectar contra servicios FTP del exterior.

Deberemos permitir, primero, las conexiones al puerto tcp21, el canal de control de FTP en el servidor.

En este caso, la regla será de tipo FORWARD, permitirá paquetes provenientes desde los equipos de la LAN y destinados al puerto 21 de tcp remoto.

Las respuestas a estos paquetes serán aceptadas por una regla de estado en la que permitamos las conexiones establecidas en forward.

Ahora bien, si el ordenador de la red ordena una descarga, o una subida de archivos al servidor ftp, la conexión puede generarse desde el interior de la red, en forma saliente, hacia el servidor, o puede ser generada por el servidor en forma entrante hacia la red.

Esto depende del modo en que el servidor y cliente estén interactuando, si es pasivo o activo, etc.

No vamos a hacernos eco de esto ahora, ya que cualquiera sea el caso, todos estos datos pertenecientes a la nueva conexión podemos tratarlos como datos pertenecientes a una conexión relacionada a otra conexión ya establecida, en este caso, la conexión de control.

Por lo que simplemente podríamos agregar una regla como esta para aceptar todos los datos de las conexiones relacionadas, independientemente de quién sea el que la establece.

Por último, el intercambio de paquetes subsiguiente, para subida o bajada de archivos, va a ser aceptado por medio de la primer regla para conexiones establecidas, puesto que la nueva conexión de datos,  la conexión relacionada, ahora es una conexión establecida nueva.

En esta clase veremos algunos ejemplos adicionales del uso de reglas que apliquen el módulo match state en otros ámbitos, y con algunas particularidades especiales que pueden llegar a ser útiles para entender mejor los conceptos y aplicabilidad del módulo de extensión.

Introducción a DNAT

Analicemos entonces el siguiente esquema.

De este lado tenemos un servidor conectado a nuestro firewall, y el firewall conectado a su vez a Internet.

El esquema es similar al que utilizamos para SNAT con la diferencia de que el servidor se encuentra en nuestra red LAN, conectado al firewall, y el firewall conectado a Internet, y en Internet vamos a disponer de clientes remotos, que bien pueden estar conectados en una ip pública directamente, o pueden estar colgados en alguna LAN corporativa por ejemplo, o alguna red hogareña en el lado de Internet.

La idea de esto es que nosotros podamos conectar desde nuestro cliente hacia nuestro servidor y podamos ver, por ejemplo, un sitio web, o cualquier otro servicio que nosotros quisiéramos acceder.

Para empezar vamos a tener un set de IP's privadas, una ip_priv1 del lado del servidor, y una ip_priv2 del lado del firewall. Vamos a denominarlas así para facilitar los cálculos.

Del lado de Internet vamos a tener una ip_pub1 del lado del firewall, va a ser la ip pública que va a tener el firewall hacia Internet, la que va a exponer a Internet, y una ip_pub2 que va a ser la de nuestro cliente.

Si bien nuestro cliente puede llegar a tener una ip privada, vamos a considerar la ip pública del router que le da acceso a ese cliente a Internet, ya que la negociación del SNAT del cliente con el router ya la conocemos.

La conexión va a venir directamente desde la IP pública del cliente hacia la ip pública de nuestro firewall, y la idea va a ser acceder desde esa ip_pub1 hacia nuestro servidor en una ip privada.

Consideremos la siguiente situación. En este caso el cliente va a intentar establecer una conexión a un protocolo que brinde nuestro servidor... un servicio que brinde nuestro servidor en nuestra ip privada.

El paquete que genera el cliente, como dijimos, si bien puede ser privado, después su router, una vez que haga el SNAT, va a ir destinado a la ip pública de nuestro firewall de alguna forma... ya sea, como dijimos, una resolución de nombres de dominio (DNS) o una DNS dinámica, o directamente mediante la dirección IP si la conocemos, y nuestro servicio por supuesto está atendiendo y trabajando con esa configuración.

El paquete va a estar originado en la ip pública del firewall o el router del cliente, y destinado a la ip pública de nuestro firewall.

Ese firewall deberá realizar un procesamiento interno que le permita cambiar la dirección ip destino, que en este caso es la ip_pub1, por la ip privada del servidor que nosotros tenemos en nuestra red LAN, y con esa ip privada automáticamente lo inyecta en la red LAN y el paquete va a llegarle al servidor que nosotros tenemos montado en la red.

Cuando el servidor pueda interpretar ese paquete, por ejemplo, si es un servidor web, generará una respuesta http o https; si es un servidor ftp generará una respuesta ftp, o DNS, o dependiendo del protocolo que esté atendiendo ese servidor, va a generar la respuesta y la respuesta va a ir originada en la IP privada del servidor, como puede verse, y va a ir destinada a la ip_pub2 que es la ip que utilizó el cliente que consultó... esa IP no se modificó en ningún momento.

El paquete va a viajar a nuestro router, y el router va a hacer ahora un paso inverso y va a cambiar la ip de origen, la ip privada del servidor, por la ip pública del router, que es la ip "routeable" en Internet que le va a permitir al cliente obtener una respuesta directa desde nuestro router firewall.

Ese cambio es automático y se lleva a cabo mediante la tabla de asociaciones de conexiones que mantiene el firewall, y que va a hacer uso para poder establecer o mantener esta conexión.

Esa ip_pub1 va a ser colocada entonces en la cabecera del protocolo IP del paquete saliente desde el firewall hacia Internet, y va a llegar al cliente, que va a poder interpretar esa información.

Este comportamiento puede analizarse desde dos puntos de vista diferentes.

Por un lado, si vemos desde la parte del cliente que intentó hacer la conexión con nuestro servidor privado en la LAN, vemos que el cliente genera tráfico desde su dirección ip pública, en este caso la ip_pub2, ya sea directamente o indirectamente a través del SNAT, y ese tráfico va a ser destinado a la ip publica del firewall, ip_pub1, por lo tanto desde el punto de vista del cliente, el cliente "cree" que el servidor es el firewall. Así, toda la interacción entre el cliente y el servidor va a ser tráfico que viaje entre el cliente y el firewall.

Por otro lado, si lo analizamos desde el punto de vista del nuestro servidor local en la LAN, va a "ver" que el tráfico proviene desde un cliente remoto, una ip_pub2, y va destinado a su ip privada, es decir, para el servidor también es indistinto quién genera o transforma esas IP's en el camino.

El servidor va a recibir tráfico desde la ip_pub2 a su ip_priv1 y va a generar la respuesta hacia la ip_pub2. Entonces, desde el punto de vista del servidor, el tráfico va a pertenecer a una conexión que se establece entre la ip del cliente, ip_pub2, y la ip del servidor, ip_priv1.

Veamos ahora cuáles son las reglas que permiten darle vida a este mecanismo de iptables.

Por un lado tenemos una regla de tipo filter de la cadena FORWARD, que va a permitir todo el tráfico con destino puerto tcp80, por ejemplo, si nuestro servidor privado es un servidor http, con destino a la ip_priv1, y vamos a aceptar ese tipo de tráfico.

Por supuesto aquí hay que agregar las reglas de manejo de estados para que las respuestas en forward también sean aceptadas, o en el caso de que no trabajemos con estados, para que las respuestas desde la ip_priv1, con puerto origen tcp80 también sean aceptadas por nuestro firewall.

Y por otro lado, tenemos una regla de la tabla NAT que es la que termina realizando la "magia" de traducir las direcciones de red para que el cliente remoto pueda acceder, en definitiva, al servidor privado que nosotros tenemos en la LAN.

Esta regla de la tabla NAt pertenece a la cadena de PREROUTING, antes de realizar cualquier decisión de ruteo cuando el paquete entra en nuestro firewall. Si el paquete pertenece o va destinado a un puerto tcp80 destino en este caso, vamos a realizarle una acción denominada DNAT para cambiar la ip de destino de ese paquete con --to-destination a la ip_priv1.

Recordemos, el paquete viene destinado a la ip_pub1 de nuestro firewall, y debemos con esta regla modificar esa ip de destino a la ip_priv1, la ip de nuestro servidor en la LAN.

Hasta aquí el paquete ha llegado al servidor, ha salido del cliente, hemos cambiado la dirección ip de destino por la dirección privada de nuestro servidor, el paquete ha sido aceptado con la cadena FORWARD de la tabla filter, ha pasado el firewall y ha llegado al servidor.

La respuesta del servidor irá destinada a la dirección IP pública del cliente, llegará al firewall, deberá ser aceptado con otra regla que previamente deberíamos haber agregado al firewall para que acepte los paquetes correspondientes de FORWARD, ya sea en stateless o stateful, y el cambio de la dirección de origen, en este caso, que es la dirección privada del servidor, ip_priv1, por la ip_pub1 va a ser automático gracias a que iptables mantiene una tabla de asociación de las conexiones, y el paquete va a llegar hacia el cliente en Internet.

Para terminar de entender esta implementación hay que tener en cuenta un punto muy importante. En la tabla filter la cadena de FORWARD que nos sirvió a nosotros para aceptar el tráfico que llega desde el cliente hacia nuestro servidor privado, hemos utilizado el puerto destino TCP 80, y hemos utilizado la dirección ip privada del servidor.

¿Por qué utilizando la dirección ip privada del servidor y no la ip pública con la que viene el paquete originalmente? Porque recordemos que antes de ejecutar esa regla de filtrado en la tabla filter con la cadena de FORWARD, primero se realiza una decisión de ruteo para saber a qué equipo interno vamos a enviarle, y para saber también si el paquete va destinado a un equipo que está detrás del firewall, o va destinado al propio firewall, y antes de realizar esa decisión de ruteo es que se ejecuta la regla de la tabla NAT para PREROUTING.

Entonces al ejecutar la regla de la tabla NAT, ni bien llega el paquete, cambiamos la dirección destino de ese paquete por la dirección privada de nuestro servidor, y cuando tomamos la decisión de ruteo, y cuando pasamos a la tabla filter, el paquete ya cuenta con la dirección privada en la cabecera IP, en el campo de ip de origen, de modo que una vez que entra el paquete, se ejecuta el PREROUTING de NAT, y todo el procesamiento interno de filtrado, ya sea para INPUT o para FORWARD, como es el caso de este ejemplo, va a tener ya la ip modificada.

Luego cambiará en el POSTROUTING, que en este caso es automático cuando el paquete sale a Internet hacia el cliente remoto... ahí cambiaremos la dirección origen del paquete por la dirección pública del router/firewall.

Esto es importante tenerlo en cuenta porque si colocamos la ip pública en la regla de filtrado, ningún paquete va a coincidir con esa ip pública en nuestro ejemplo, puesto que cuando se analiza el paquete ya la ip pública ha sido modificada por la ip privada del servidor, que es la que nosotros tenemos que tener en cuenta para analizar el tráfico y dejarlo pasar o bloquearlo.

En esta oportunidad aprenderemos a configurar iptables para que, mediante reglas de PREROUTING (tabla NAT) podamos publicar, hacia Internet, un servicio interno que tengamos montado en nuestra red local.

Cabe aclarar que, si bien el servicio estará publicado en la dirección IP que tenga el firewall, esta dirección IP puede cambiar periódicamente dependiendo del servicio de banda ancha que nos entregue nuestro proveedor de servicios de Internet (ISP), por lo que para poder acceder a nuestro servidor deben cumplirse algunas condiciones adicionales, tales como que la IP sea la correcta en el momento de establecer la conexión desde el cliente, y, opcionalmente, que tengamos apuntado correctamente un dominio o DDNS a la ip pública.

Por supuesto, no hay que olvidar que cada servicio tendrá sus parámetros de configuración particulares que también deberemos considerar a la hora de acceder al servicio.

En esta clase introduciremos nuestro entorno de laboratorio. Este ejemplo de configuración de firewall vamos a realizarlo sobre un sistema Debian GNU/Linux, que estará conectado a Internet por un lado, y por otro, conectado a un cliente Ubuntu, que hará las veces de red LAN.

Veremos qué configuraciones básicas tienen tanto el firewall Debian, como el Ubuntu, en cuanto a iptables, y analizaremos la topología de red y direccionamiento IP.

Aquí veremos cómo empezar a escribir nuestro script de firewalling paso a paso. Analizaremos y explicaremos las reglas básicas que debería tener un script de iptables.

A esto agregaremos las reglas necesarias para montar un firewall statefull mediante el módulo match state de extensión de iptables.

Por último, agregaremos las reglas necesarias para poder conectarnos al firewall en forma remota por medio de SSH, conexión necesaria en este ejemplo para poder administrarlo (caso particular de estudio).

Ahora agregaremos las reglas necesarias para permitirle a nuestro cliente Ubuntu la navegación en Internet. Esto es, puertos http, https y dns, por supuesto, con manejo de estados de conexiones.

También veremos en esta clase cómo listar las reglas del firewall para cada tabla, y cómo entender las salidas del comando "-L" y "-nL" de iptables.

Para el cometido de permitirle al cliente la navegación, también será necesario cargar la regla básica de NAT para la cadena POSTROUTING en la que "enmascaremos" o realicemos un SNAT/MASQUERADE con los paquetes salientes a la red.

Con el firewall configurado, ha llegado el momento de probarlo!

En esta oportunidad vamos a probar los protocolos que nuestro cliente Ubuntu tiene habilitados gracias a las reglas que cargamos en el firewall Debian, y veremos cómo funcionan.

Un caso interesante en este video es cómo, al modificar una regla de firewall y recargar el mismo, podemos ver el efecto inmediato en el cliente, particularmente bloqueándo el servicio de resolución de nombres (DNS, udp53).

Por último, vamos a considerar que este cliente Ubuntu es la estación de trabajo (workstation) del administrador de la red, o sysadmin, y necesita "salir" a Internet para conectarse a un servidor SSH remoto. Para ello configuraremos en el iptables las reglas necesarias para que el Ubuntu pueda realizar esta tarea, con un caso de ejemplo de conexión satisfactoria.

Ahora vamos a suponer que nuestro cliente Ubuntu es, además, un servidor web (o de cualquier otro servicio), y vamos a proceder a configurar las reglas de filter que permitan el acceso desde Internet a dicho servicio.

Por supuesto, aquí también configuraremos las reglas de NAT necesarias para permitir la redirección del tráfico desde Internet hacia el servidor Ubuntu, que está corriendo los servicios en una dirección IP privada de la red LAN (DNAT).

Finalmente hemos terminado de montar nuestro firewall! Aquí algunas notas adicionales.

Este ejemplo permite analizar cómo se utilizan las reglas de filter, tanto de INPUT como OUTPUT, y además las reglas FORWARD para conexión del cliente remoto.

Hemos visto también las reglas de NAT tanto para POSTROUTING (SNAT/MASQUERADE) como para PREROUTING (DNAT), abarcando prácticamente todo el espectro de reglas del firewall vistas en el curso.

Cada una de las reglas planteadas funcionan, pero pueden adaptarse con otros modificadores y patrones de selección de tráfico para que puedan servir en cualquier entorno. Esto fue solamente un ejemplo sencillo que tuvo la intención de mostrar, en directo, cómo ir escribiendo un script de iptables para un firewall GNU/Linux.

Si bien este ejemplo sirvió para configurar iptables en Debian, el firewall es parte del núcleo Linux, por lo que las mismas configuraciones son válidas para cualquier distribución del sistema operativo del pingüino :)

En el material adicional de esta clase podrán acceder a un link en el que explico cómo configurar un script para que se ejecute al inicio de la distribución GNU/Linux systemd (la mayoría de las distros actuales). Ese contenido es válido para permitir que nuestro script de iptables se ejecute cada vez que se inicie la computadora firewall.

aaaa

https://juncotic.com/tmux-y-screen-multiplexar-la-terminal-de-gnu-linux/

Udemy nos permite a los instructores facilitarles algunos beneficios a nuestros alumnos. En esta clase extra (Bonus Lecture) podrás encontrar mis otros cursos, y accesos al mínimo precio sólo disponibles para alumnos.