La arquitectura de Iptables y Netfilter

Un firewall es un dispositivo de seguridad (hardware/software) que protege la red filtrando el tráfico y bloqueando el acceso no deseado/no autorizado a los datos privados. Contar con un firewall adecuado es importante para proteger sus servidores e infraestructura. No solo puede bloquear el tráfico no deseado, sino también evitar que el software malicioso infecte el sistema.

En el ecosistema de Linux, iptables es un firewall popular que interactúa con el netfilter framework en el kernel de Linux. La mayoría de los sistemas Linux modernos vienen con estas herramientas preinstaladas. Para aprovechar al máximo estos sistemas, es fundamental comprender sus arquitecturas. De lo contrario, desarrollar políticas de firewall confiables puede ser una tarea abrumadora. Podría llevar a la creación de sintaxis complicadas, partes interrelacionadas en el framework, etc.

Esta guía profundizará en la arquitectura de iptables para ayudar a los usuarios que necesitan crear sus propias políticas de firewall. También exploraremos cómo iptables interactúa con netfilter y cómo encajan los distintos componentes.

Iptables y Netfilter

En Linux, el iptables firewall es el más común. Funciona interactuando con los hooks de filtrado de paquetes en la pila de red del kernel de Linux. Son estos hooks del kernel los que se conocen colectivamente como el netfilter framework.

Cada paquete entrante/saliente en el sistema activará estos hooks a medida que avanza por la pila. Por lo tanto, los programas registrados con estos hooks pueden interactuar con el tráfico en puntos clave. Finalmente, los módulos del kernel asociados con iptables se conectan a estos hooks para aplicar las reglas de firewall especificadas.

Hooks de Netfilter

Para que los programas se conecten, existen cinco hooks de netfilter diferentes. A medida que los paquetes avanzan por la pila, los hooks activan los módulos del kernel registrados con ellos. La condición de activación depende de condiciones tales como:  la dirección del paquete (entrante/saliente), el destino del paquete, si el paquete fue descartado/rechazado en un punto anterior, etc.

Estos son los hooks que representan varios puntos bien definidos en la pila de red:

• NF_IP_PRE_ROUTING: Este hook se activa con cualquier tráfico entrante. La activación ocurre antes de que se tome cualquier decisión de enrutamiento con respecto al destino del paquete.

• NF_IP_LOCAL_IN: Este hook se activa después de enrutar un paquete entrante. El paquete también debe tener como destino el sistema local.

• NF_IP_FORWARD: Este hook también se activa después de enrutar un paquete entrante. Sin embargo, se activa si el paquete debe ser enrutado a otro host.

• NF_IP_LOCAL_OUT: Cualquier tráfico saliente local, tan pronto como llega a la pila de red, activa este hook.

• NF_IP_POST_ROUTING: Este hook se activa con cualquier tráfico saliente/reenviado después de que se haya realizado el enrutamiento y antes de que el paquete llegue al cable.

Los módulos del kernel que deseen registrarse en estos hooks deben proporcionar un número de prioridad. Este valor ayuda a determinar el orden en el que se llamarán una vez que se active el hook. Dicho mecanismo permite que múltiples módulos (diferentes módulos o múltiples copias del mismo módulo) se conecten a cada uno de los hooks en un orden determinista. Cada módulo devolverá una decisión al netfilter framework después de procesar los paquetes.

Tablas y cadenas en Iptables

Para organizar sus reglas, el iptables firewall utiliza tablas. Las tablas categorizan las reglas según el tipo de decisiones que toman. Por ejemplo, si una regla tiene que ver con NAT (traducción de direcciones de red), entonces la regla se coloca bajo la nat tabla. De manera similar, si una regla decide si permitir o denegar un paquete a su destino, se agrega a la filter tabla.

Dentro de cada tabla de iptables, las reglas se organizan además dentro de “cadenas” separadas. Mientras que la tabla representa el tipo de reglas que contienen, las cadenas describen los netfilter hooks que activan las reglas. En resumen, las cadenas determinan cuándo se evaluará la regla.

Aquí están las cadenas integradas de iptables. Curiosamente, los nombres de las cadenas también reflejan el nombre del netfilter hook asociado:

Al usar las cadenas, los administradores pueden determinar en qué etapa de la entrega del paquete se evaluará la regla. Como cada tabla contiene múltiples cadenas, también puede extender su influencia en múltiples puntos del procesamiento. Ciertas decisiones solo tienen sentido en ciertos puntos de la pila de red. Por lo tanto, no todas las tablas tendrán una cadena registrada con cada hook del kernel.

El netfilter framework solo ofrece 5 hooks de kernel. Como tal, las cadenas de múltiples tablas se registran en cada punto de los hooks. Por ejemplo, si tres cadenas tienen las cadenas PREROUTING , entonces se registra con el NF_IP_PRE_ROUTING hook. Cada una de ellas debe proporcionar una prioridad que decida en qué orden la cadena PREROUTING de cada tabla es llamada. La cadena PREROUTING de mayor prioridad se evalúa primero, la siguiente de mayor prioridad se evalúa en segundo lugar, y así sucesivamente.

Las tablas de iptables

Demos un paso atrás y echemos un vistazo a las tablas que ofrece iptables . Como se mencionó anteriormente, cada tabla representa diferentes conjuntos de reglas, organizados por área de interés, para la evaluación de paquetes.

• Tabla filter

En iptables , la tabla filter es una de las más populares. Se utiliza para determinar si se permitirá que un paquete continúe hacia su destino o no. En la terminología de cortafuegos, este proceso se conoce como “filtrado” de paquetes.

Es a las funciones de la tabla filter a las que la gente se refiere cuando habla de cortafuegos (en su mayor parte).

• Tabla nat

Esta tabla implementa reglas que regulan NAT. Cuando los paquetes ingresan a la pila de red, las reglas descritas en esta tabla deciden cómo modificar la dirección de origen/destino del paquete, lo que afecta el enrutamiento del paquete y cualquier tráfico de respuesta.

A menudo, la tabla nat se utiliza para enrutar paquetes a redes donde no hay acceso directo.

• Tabla mangle

Esta tabla contiene las reglas que modifican las cabeceras IP de los paquetes de diversas formas. Por ejemplo, puede modificar el valor TTL (Time to Live) de un paquete alargando o acortando el número de saltos de red válidos que el paquete puede soportar. Además, la tabla mangle puede modificar otras cabeceras IP de manera similar.

Esta tabla también tiene permitido colocar una “marca” interna del kernel en el paquete que otras tablas y herramientas de red pueden recoger para su posterior procesamiento. Esta marca no toca el paquete real, sino que añade la marca a la representación del paquete en el kernel.

• Tabla raw

El cortafuegos iptables es de estado (stateful), lo que implica que los paquetes se evalúan en el contexto de su relación con paquetes anteriores. La función de seguimiento de conexiones (connection tracking) desarrollada sobre el netfilter framework permite a iptables ver los paquetes como parte de una conexión o sesión en curso en lugar de como un flujo de paquetes discretos y no relacionados. Generalmente, la lógica de seguimiento de conexiones se aplica muy poco después de que el paquete llega a la interfaz de red.

La tabla raw viene con una función muy definida y limitada. El único propósito de esta tabla es proporcionar un mecanismo para marcar paquetes con el fin de excluirse del seguimiento de conexiones.

• Tabla security

La tabla security coloca marcas de contexto de seguridad internas de SELinux en los paquetes. Esto, a su vez, afecta la forma en que SELinux (o cualquier otra aplicación que interprete los contextos de seguridad de SELinux) manejará los paquetes.

Las marcas de SELinux se pueden aplicar por paquete o por conexión.

Cadenas implementadas en cada tabla

Hasta ahora, hemos hablado de tablas y cadenas por separado. Es hora de repasar qué cadenas están disponibles en cada tabla. Este tema amplía la discusión sobre el orden de evaluación de las cadenas registradas en el mismo hook. Por ejemplo, ¿qué pasa si tres tablas tienen cadenas PREROUTING ? ¿Cuál es su orden de evaluación?

A continuación, eche un vistazo a la siguiente tabla. Indica las cadenas que están disponibles dentro de cada iptables tabla.

Cuando se lee de izquierda a derecha, describe qué tablas contienen qué cadenas. Por ejemplo, la tabla raw tiene tanto las cadenas PREROUTING como OUTPUT . Cuando se lee de arriba a abajo, describe en qué orden se llama a cada cadena cuando se activa su netfilter hook asociado.

Tenga en cuenta que la tabla nat se dividió entre operaciones DNAT (alteración del destino de un paquete) y operaciones SNAT (alteración del origen de un paquete) para especificar su orden de manera más clara. La tabla también incluye puntos de representación donde se toman las decisiones de enrutamiento y donde se habilita el seguimiento de conexiones.

Los hooks (columnas) que activará un paquete se basan en la naturaleza del paquete (entrante/saliente), las decisiones de enrutamiento que se toman y si un paquete cumple con los criterios de filtrado.

Ciertos eventos pueden omitir la cadena de una tabla durante el procesamiento. Por ejemplo, solo el primer paquete de una conexión se evaluará con respecto a las reglas NAT descritas por la tabla nat. A cualquier paquete posterior en la misma conexión se le aplicarán las mismas decisiones de nat sin ninguna evaluación adicional. Las respuestas a las conexiones NAT tendrán automáticamente aplicadas las reglas NAT inversas para un enrutamiento adecuado.

Orden de recorrido de cadenas

Asumiendo que el servidor conoce las reglas de enrutamiento de paquetes y las reglas del firewall permiten la transmisión, los siguientes flujos representan cómo se recorrerán las diferentes rutas:

• Paquetes entrantes destinados al sistema local: PREROUTING >> INPUT

• Paquetes entrantes destinados a otro host: PREROUTING >> FORWARD >> POSTROUTING

• Paquetes generados localmente: OUTPUT >> POSTROUTING

En conclusión, combinando toda la información que hemos discutido hasta ahora, podemos ver que cualquier paquete entrante destinado al sistema local será evaluado con respecto a las cadenas PREROUTING de las tablas raw, mangle, y nat. Luego, pasará a través de las cadenas INPUT de las tablas mangle, filter, security, y nat antes de llegar finalmente al socket local.

Reglas de iptables

Las reglas de firewall de iptables se colocan dentro de una cadena específica de una tabla específica. Cuando se llama a una cadena, el paquete en cuestión se evaluará con respecto a cada regla de la cadena. Cada regla tiene dos componentes: un componente de coincidencia y un componente de acción.

• Coincidencia

La parte de coincidencia de una regla especifica las condiciones que debe cumplir un paquete antes de que se ejecute la acción especificada (o “target”).

El sistema de coincidencia ofrece una flexibilidad increíble. Su funcionalidad también se puede ampliar con la ayuda de las extensiones de iptables. Se pueden describir reglas para que coincidan con paquetes por tipo de protocolo, dirección de origen/destino, puerto de origen/destino, red de origen/destino, interfaz de entrada/salida, cabeceras, estado de la conexión y otros criterios. Una regla también puede tener una combinación de estas condiciones, lo que da como resultado conjuntos de reglas complejos para diferenciar entre diferentes tipos de tráfico.

• Targets

Un target es la acción que se toma cuando un paquete cumple con los criterios de coincidencia de una regla. Generalmente, los targets se dividen en dos grupos:

• • Targets de terminación: Termina el proceso de evaluación dentro de la cadena y devuelve el control al hook de netfilter. Según el valor de retorno, el hook permitirá que el paquete continúe su camino o lo descartará.

  • Targets de no terminación: El target realiza una acción y la evaluación en la cadena continúa. Aunque cada cadena debe pasar por una decisión de terminación final, se puede producir cualquier número de targets de no terminación de antemano.

La disponibilidad de cada objetivo dentro de las reglas depende del contexto. Por ejemplo, el tipo de cadena y de tabla puede afectar la disponibilidad de los objetivos. Otros factores posibles incluyen las extensiones activadas en la regla y las cláusulas de coincidencia.

Cadenas definidas por el usuario

También existe una clase especial de objetivos no terminales: el objetivo de salto (jump target). Los objetivos de salto son acciones que se realizan cuando la evaluación pasa de una cadena a otra para un procesamiento adicional. Hasta ahora, hemos hablado de las cadenas integradas que están estrechamente conectadas a los netfilter hooks que las llaman. Sin embargo, iptables también permite a los administradores crear sus propias cadenas personalizadas.

Las reglas en las cadenas definidas por el usuario también son similares a las de las cadenas integradas. La diferencia clave es que a las cadenas definidas por el usuario solo se puede acceder “saltando” a ellas desde una regla. Esto se debe a que las cadenas definidas por el usuario no están vinculadas con ningún netfilter hooks.

Puede pensar en las cadenas definidas por el usuario como extensiones de la cadena que las llamó originalmente. Por ejemplo, en una cadena definida por el usuario, la evaluación volverá a la cadena de llamada si llega al final de la lista de reglas o si una regla coincidente ejecuta un RETURN objetivo. Curiosamente, una cadena definida por el usuario también puede hacer “saltar” la evaluación a otra cadena definida por el usuario.

Esta característica sienta las bases para una mejor organización y el marco de trabajo necesario para una ramificación robusta.

Seguimiento de conexiones

Al analizar la tabla raw y los criterios de coincidencia del estado de la conexión, analizamos el sistema de seguimiento de conexiones implementado sobre el marco de trabajo netfilter . Esta característica permite a iptables  ver los paquetes en el contexto de una conexión en curso. El sistema de seguimiento de conexiones también proporciona a iptables la funcionalidad necesaria para realizar operaciones “con estado” (stateful).

Justo después de que un paquete ingresa a la pila de red, se aplica el seguimiento de conexiones. Las cadenas de la tabla raw y algunas comprobaciones básicas de integridad son toda la lógica necesaria para asociar los paquetes con una conexión.

El sistema comprueba cada paquete con un conjunto de conexiones existentes. Si es necesario, el sistema actualizará el estado de las conexiones existentes o creará otras nuevas. Los paquetes que fueron marcados con el objetivo NOTRACK en cualquier cadena de la tabla raw omitirán las rutinas de seguimiento de conexiones adicionales.

• Estados disponibles

A las conexiones que son rastreadas por el sistema de seguimiento de conexiones se les asignará cualquiera de los siguientes estados:

• • NEW : Al llegar un paquete que no está asociado con una conexión existente pero que no es inválido como primer paquete, se agrega una nueva conexión al sistema con esta etiqueta. Esto ocurre tanto para protocolos orientados a la conexión (TCP, por ejemplo) como para protocolos no orientados a la conexión (UDP, por ejemplo).

  • ESTABLISHED: El estado de una conexión se actualiza de NEW  a ESTABLISHED cuando recibe una respuesta válida desde la dirección opuesta. Para conexiones TCP, esto significa un SYN/ACK. Para el tráfico UDP e ICMP, significa una respuesta donde el origen y el destino del paquete original se intercambian.

  • RELATED: Los paquetes que no forman parte de una conexión pero que están relacionados con una conexión establecida se etiquetan como RELATED . Puede significar una conexión auxiliar (por ejemplo, en una conexión de transmisión de datos FTP), o respuestas ICMP a intentos de conexión por parte de otros protocolos.

  • INVALID: Los paquetes que no forman parte de una conexión establecida, se consideran inapropiados para abrir una nueva conexión, no se pueden identificar, no son enrutables, etc., se etiquetan como INVALID.

  • UNTRACKED: Un paquete puede etiquetarse como UNTRACKED si fue el objetivo en una cadena de la tabla raw para omitir el seguimiento.

  • SNAT: Significa un estado virtual establecido cuando la dirección de origen es modificada por una operación NAT. Es manejado por el sistema de seguimiento de conexiones para que las direcciones de origen se traduzcan en los paquetes de respuesta.

  • DNAT: Similar a SNAT, significa un estado virtual cuando la dirección de destino es modificada por una operación NAT. El sistema de seguimiento de conexiones lo maneja de manera que sabe cómo traducir la dirección de destino de vuelta al enrutar los paquetes de respuesta.

Estos estados rastreados por el sistema de seguimiento de conexiones permiten a los administradores diseñar reglas específicas dirigidas a puntos concretos del ciclo de vida de una conexión. Proporciona la funcionalidad necesaria para obtener reglas más exhaustivas y seguras.

Reflexiones finales

En Linux, el netfilter framework y el iptables cortafuegos sirven como base para la mayoría de los cortafuegos. Los hooks de netfilter están lo suficientemente cerca de la pila de red para permitir un control potente sobre los paquetes procesados por el sistema. Aprovechando estas capacidades, el iptables cortafuegos ofrece una forma flexible de comunicar los requisitos de las políticas al kernel.

Esta guía profundiza en la estructura interna del netfilter framework y del iptables cortafuegos. Además, analiza el sistema de seguimiento de conexiones. Al comprender cómo encajan estas piezas, podrá utilizarlas mejor para diseñar entornos de servidor más robustos y seguros.

Finalmente, aunque esta guía aborda el funcionamiento interno, consulte esta guía sobre cómo configurar iptables para aplicarlas en acción. Además, puede ver cómo el cortafuegos UFW simplifica aún más iptables. Además, será útil aprender a listar y eliminar reglas del cortafuegos iptables.

¡Feliz computación!