Un Análisis Profundo de la Arquitectura de Iptables y Netfilter

Introducción

Los firewalls son una herramienta importante que se puede configurar para proteger tus servidores e infraestructura. En el ecosistema de Linux, iptables es una herramienta de firewall ampliamente utilizada que funciona con el marco de filtrado de paquetes netfilter del kernel. Crear políticas de firewall confiables puede ser desalentador, debido a la sintaxis compleja y al número de partes interrelacionadas involucradas.

En esta guía, profundizaremos en la arquitectura de iptables con el objetivo de hacerla más comprensible para los usuarios que necesitan construir sus propias políticas de firewall. Discutiremos cómo iptables interactúa con netfilter y cómo se ajustan los diversos componentes para proporcionar un sistema de filtrado completo.

¿Qué son IPTables y Netfilter?

Durante muchos años, el software de firewall más utilizado en Linux se llamaba iptables. En algunas distribuciones, ha sido reemplazado por una nueva herramienta llamada nftables, pero la sintaxis de iptables todavía se utiliza comúnmente como referencia. El firewall iptables funciona interactuando con los ganchos de filtrado de paquetes en la pila de red del kernel de Linux. Estos ganchos del kernel se conocen como el marco netfilter.

Cada paquete que pasa por la capa de red (entrante o saliente) activará estos ganchos, lo que permite a los programas interactuar con el tráfico en puntos clave. Los módulos del kernel asociados con iptables se registran en estos ganchos para garantizar que el tráfico cumpla con las condiciones establecidas por las reglas del firewall.

Ganchos de Netfilter

Existen cinco ganchos de netfilter a los que los programas pueden registrarse. A medida que los paquetes avanzan a través de la pila, activarán los módulos del kernel que se hayan registrado en estos ganchos. Los ganchos que activa un paquete dependen de si el paquete es entrante o saliente, del destino del paquete y de si el paquete fue descartado o rechazado en un punto anterior.

Los siguientes ganchos representan estos puntos bien definidos en la pila de red:

  • NF_IP_PRE_ROUTING: Este gancho se activará muy pronto después de que cualquier tráfico entrante ingrese a la pila de red. Este gancho se procesa antes de tomar cualquier decisión de enrutamiento con respecto a dónde enviar el paquete.
  • NF_IP_LOCAL_IN: Este gancho se activa después de que un paquete entrante ha sido enrutado si el paquete está destinado al sistema local.
  • NF_IP_FORWARD: Este gancho se activa después de que un paquete entrante ha sido enrutado si el paquete debe ser reenviado a otro host.
  • NF_IP_LOCAL_OUT: Este gancho se activa por cualquier tráfico saliente creado localmente tan pronto como llega a la pila de red.
  • NF_IP_POST_ROUTING: Este gancho se activa por cualquier tráfico saliente o reenviado después de que se haya realizado el enrutamiento y justo antes de ser enviado por el cable.

Los módulos del kernel que necesitan registrarse en estos ganchos también deben proporcionar un número de prioridad para ayudar a determinar el orden en el que serán llamados cuando se active el gancho. Esto proporciona los medios para que múltiples módulos (o múltiples instancias del mismo módulo) se conecten a cada uno de los ganchos con un orden determinista. Cada módulo se llamará sucesivamente y devolverá una decisión al marco de trabajo de netfilter después de procesar, indicando qué se debe hacer con el paquete.

Tablas y Cadenas de IPTables

El firewall iptables utiliza tablas para organizar sus reglas. Estas tablas clasifican las reglas según el tipo de decisiones que se utilizan para tomar. Por ejemplo, si una regla se ocupa de la traducción de direcciones de red, se colocará en la tabla nat. Si la regla se utiliza para decidir si permitir que el paquete continúe hacia su destino, probablemente se agregará a la tabla filter.

Dentro de cada tabla iptables, las reglas están organizadas en “cadenas” separadas. Mientras que las tablas están definidas por el objetivo general de las reglas que contienen, las cadenas integradas representan los ganchos de netfilter que las activan. Las cadenas determinan cuándo se evaluarán las reglas.

Los nombres de las cadenas integradas reflejan los nombres de los ganchos de netfilter con los que están asociadas:

  • PREROUTING: Activado por el gancho NF_IP_PRE_ROUTING.
  • INPUT: Activado por el gancho NF_IP_LOCAL_IN.
  • FORWARD: Activado por el gancho NF_IP_FORWARD.
  • OUTPUT: Activado por el gancho NF_IP_LOCAL_OUT.
  • POSTROUTING: Activado por el gancho NF_IP_POST_ROUTING.

Las cadenas permiten al administrador controlar dónde en el camino de entrega de un paquete se evaluará una regla. Dado que cada tabla tiene múltiples cadenas, la influencia de una tabla se puede ejercer en varios puntos del procesamiento. Debido a que ciertos tipos de decisiones solo tienen sentido en ciertos puntos de la pila de red, no todas las tablas tendrán una cadena registrada con cada gancho del kernel.

Hay solo cinco ganchos del kernel netfilter, por lo que las cadenas de varias tablas se registran en cada uno de los ganchos. Por ejemplo, tres tablas tienen cadenas PREROUTING. Cuando estas cadenas se registran en el gancho asociado NF_IP_PRE_ROUTING, especifican una prioridad que dicta en qué orden se llama a la cadena PREROUTING de cada tabla. Cada una de las reglas dentro de la cadena PREROUTING de mayor prioridad se evalúa secuencialmente antes de pasar a la siguiente cadena PREROUTING. Echaremos un vistazo al orden específico de cada cadena en un momento.

¿Cuáles son las tablas disponibles?

Démosle un paso atrás por un momento y echemos un vistazo a las diferentes tablas que proporciona iptables. Estas representan conjuntos distintos de reglas, organizados por área de interés, para evaluar paquetes.

La Tabla de Filtros

La tabla de filtros es una de las tablas más utilizadas en iptables. Se utiliza para tomar decisiones sobre si permitir que un paquete continúe hacia su destino previsto o denegar su solicitud. En la jerga de los firewalls, esto se conoce como “filtrar” paquetes. Esta tabla proporciona la mayor parte de la funcionalidad que la gente asocia al hablar de firewalls.

La Tabla NAT

La tabla nat se utiliza para implementar reglas de traducción de direcciones de red. A medida que los paquetes ingresan en la pila de red, las reglas de esta tabla determinarán si y cómo modificar las direcciones de origen o destino del paquete para afectar la forma en que se enrutan el paquete y cualquier tráfico de respuesta. Esto se usa a menudo para enrutar paquetes a redes cuando el acceso directo no es posible.

La Tabla Mangle

La tabla mangle se utiliza para alterar los encabezados IP del paquete de diversas formas. Por ejemplo, puedes ajustar el valor de TTL (Tiempo de Vida) de un paquete, alargando o acortando el número de saltos de red válidos que el paquete puede soportar. Otros encabezados IP pueden ser alterados de formas similares.

Esta tabla también puede colocar una “marca” interna del kernel en el paquete para su procesamiento posterior en otras tablas y por otras herramientas de red. Esta marca no toca el paquete real, pero agrega la marca a la representación del paquete del kernel.

La Tabla Raw

El firewall iptables es stateful, lo que significa que los paquetes se evalúan en relación con los paquetes anteriores. Las funciones de seguimiento de conexión construidas sobre el marco netfilter permiten que iptables vea los paquetes como parte de una conexión o sesión en curso en lugar de como una secuencia de paquetes discretos e independientes. La lógica de seguimiento de conexión suele aplicarse muy pronto después de que el paquete llega a la interfaz de red.

La tabla raw tiene una función muy específica. Su único propósito es proporcionar un mecanismo para marcar paquetes con el fin de excluirlos del seguimiento de conexión.

La tabla de seguridad

La tabla security se utiliza para establecer marcas de contexto de seguridad SELinux internas en los paquetes, lo que afectará cómo SELinux u otros sistemas que puedan interpretar contextos de seguridad SELinux manejan los paquetes. Estas marcas se pueden aplicar en función de cada paquete o conexión.

Relaciones entre cadenas y tablas

Si tres tablas tienen cadenas PREROUTING, ¿en qué orden se evalúan?

La siguiente tabla indica las cadenas disponibles dentro de cada tabla de iptables cuando se leen de izquierda a derecha. Por ejemplo, podemos ver que la tabla raw tiene tanto las cadenas PREROUTING como OUTPUT. Cuando se lee de arriba hacia abajo, también muestra el orden en el que se llama a cada cadena cuando se activa el gancho netfilter.

A few things should be noted. In the representation below, the nat table has been split between DNAT operations (those that alter the destination address of a packet) and SNAT operations (those that alter the source address) in order to display their ordering more clearly. We have also include rows that represent points where routing decisions are made and where connection tracking is enabled in order to give a more holistic view of the processes taking place:

Tables↓/Chains→ PREROUTING INPUT FORWARD OUTPUT POSTROUTING
(routing decision)
raw
(connection tracking enabled)
mangle
nat (DNAT)
(routing decision)
filter
security
nat (SNAT)

Al activar un gancho netfilter, las cadenas asociadas se procesarán en el orden en que aparecen en la tabla de arriba hacia abajo. Los ganchos (columnas) que activará un paquete dependen de si es un paquete de entrada o salida, las decisiones de enrutamiento que se tomen y si el paquete cumple con los criterios de filtrado.

Ciertos eventos harán que se omita la cadena de una tabla durante el procesamiento. Por ejemplo, solo el primer paquete de una conexión se evaluará según las reglas NAT. Cualquier decisión de nat tomada para el primer paquete se aplicará a todos los paquetes siguientes de la conexión sin una evaluación adicional. Las respuestas a las conexiones con NAT aplicado tendrán automáticamente las reglas NAT inversas aplicadas para enrutarse correctamente.

Orden de Traversal de Cadenas

Suponiendo que el servidor sabe cómo enrutar un paquete y que las reglas del firewall permiten su transmisión, los siguientes flujos representan los caminos que se recorrerán en diferentes situaciones:

  • Paquetes entrantes destinados al sistema local: PREROUTING -> INPUT
  • Paquetes entrantes destinados a otro host: PREROUTING -> FORWARD -> POSTROUTING
  • Paquetes generados localmente: OUTPUT -> POSTROUTING

Si combinamos la información anterior con el orden establecido en la tabla anterior, podemos ver que un paquete entrante destinado al sistema local primero se evaluará en las cadenas PREROUTING de las tablas raw, mangle y nat. Luego atravesará las cadenas INPUT de las tablas mangle, filter, security y nat antes de entregarse finalmente al socket local.

Reglas de IPTables

Las reglas se colocan dentro de una cadena específica de una tabla específica. A medida que se llama cada cadena, el paquete en cuestión se verificará contra cada regla dentro de la cadena en orden. Cada regla tiene un componente de coincidencia y un componente de acción.

Coincidencia

La parte de coincidencia de una regla especifica los criterios que un paquete debe cumplir para que se ejecute la acción asociada (o “objetivo”).

El sistema de coincidencia es muy flexible y se puede ampliar significativamente con extensiones adicionales de iptables. Las reglas se pueden construir para coincidir por tipo de protocolo, dirección de destino o origen, puerto de destino o origen, red de destino o origen, interfaz de entrada o salida, encabezados o estado de conexión, entre otros criterios. Estos se pueden combinar para crear conjuntos de reglas complejas para distinguir entre diferentes tráficos.

Objetivos

A “target” refers to the actions that are triggered when a packet meets the matching criteria of a rule. Targets are generally divided into two categories:

  • Objetivos terminales: Los objetivos terminales realizan una acción que termina la evaluación dentro de la cadena y devuelve el control al gancho de netfilter. Dependiendo del valor de retorno proporcionado, el gancho puede descartar el paquete o permitir que el paquete continúe hacia la siguiente etapa de procesamiento.
  • Objetivos no terminales: Los objetivos no terminales realizan una acción y continúan la evaluación dentro de la cadena. Aunque cada cadena debe finalmente enviar una decisión terminante final, se pueden ejecutar cualquier número de objetivos no terminales antes.

La disponibilidad de cada objetivo dentro de las reglas dependerá del contexto. Por ejemplo, la tabla y el tipo de cadena pueden dictar los objetivos disponibles. Las extensiones activadas en la regla y las cláusulas de coincidencia también pueden afectar la disponibilidad de los objetivos.

Saltando a Cadenas Definidas por el Usuario

También existe una clase especial de objetivo no terminante: el objetivo de salto. Los objetivos de salto son acciones que hacen que la evaluación se mueva a una cadena diferente para un procesamiento adicional. Ya hemos cubierto las cadenas integradas que están vinculadas a los ganchos de netfilter que las llaman. Sin embargo, iptables también permite a los administradores crear sus propias cadenas con fines organizativos.

Las reglas pueden ser colocadas en cadenas definidas por el usuario de la misma manera en que pueden ser colocadas en cadenas integradas. La diferencia es que las cadenas definidas por el usuario solo pueden ser alcanzadas “saltando” a ellas desde una regla (no están registradas con un gancho de netfilter por sí mismas).

Las cadenas definidas por el usuario actúan como extensiones de la cadena que las llamó. Por ejemplo, en una cadena definida por el usuario, la evaluación volverá a pasar a la cadena que llama si se alcanza el final de la lista de reglas o si un objetivo RETURN es activado por una regla coincidente. La evaluación también puede saltar a otras cadenas definidas por el usuario.

Esta construcción permite una mayor organización y proporciona el marco necesario para un ramificación más robusta.

IPTables y Seguimiento de Conexiones

Introdujimos el sistema de seguimiento de conexiones implementado sobre el marco de netfilter cuando discutimos la tabla raw y los criterios de coincidencia del estado de la conexión. El seguimiento de conexiones permite a iptables tomar decisiones sobre paquetes vistos en el contexto de una conexión en curso. El sistema de seguimiento de conexiones proporciona a iptables la funcionalidad que necesita para realizar operaciones “con estado”.

El seguimiento de conexiones se aplica muy pronto después de que los paquetes ingresan a la pila de redes. Las cadenas de la tabla raw y algunas verificaciones de coherencia son la única lógica que se realiza en los paquetes antes de asociarlos con una conexión.

El sistema verifica cada paquete contra un conjunto de conexiones existentes. Actualizará el estado de la conexión en su almacenamiento si es necesario y agregará nuevas conexiones al sistema cuando sea necesario. Los paquetes que hayan sido marcados con el destino NOTRACK en una de las cadenas raw evitarán las rutinas de seguimiento de conexiones.

Estados Disponibles

Las conexiones rastreadas por el sistema de seguimiento de conexiones estarán en uno de los siguientes estados:

  • NEW: Cuando llega un paquete que no está asociado con una conexión existente, pero no es inválido como primer paquete, se agregará una nueva conexión al sistema con esta etiqueta. Esto sucede tanto para protocolos conscientes de la conexión como TCP como para protocolos sin conexión como UDP.
  • ESTABLECIDO: Una conexión cambia de NUEVO a ESTABLECIDO cuando recibe una respuesta válida en la dirección opuesta. Para las conexiones TCP, esto significa un SYN/ACK y para el tráfico UDP e ICMP, esto significa una respuesta donde se intercambian la fuente y el destino del paquete original.
  • RELACIONADO: Los paquetes que no forman parte de una conexión existente, pero están asociados con una conexión ya existente en el sistema, se etiquetan como RELACIONADO. Esto podría significar una conexión auxiliar, como es el caso de las conexiones de transmisión de datos FTP, o podrían ser respuestas ICMP a intentos de conexión por otros protocolos.
  • INVÁLIDO: Los paquetes pueden marcarse como INVÁLIDO si no están asociados con una conexión existente y no son apropiados para abrir una nueva conexión, si no pueden ser identificados, o si no son enrutables, entre otras razones.
  • SIN SEGUIMIENTO: Los paquetes pueden marcarse como SIN SEGUIMIENTO si han sido seleccionados en una cadena de tabla raw para evitar el seguimiento.
  • SNAT: Este es un estado virtual establecido cuando la dirección de origen ha sido alterada por operaciones NAT. Esto es utilizado por el sistema de seguimiento de conexiones para que sepa que debe cambiar las direcciones de origen nuevamente en los paquetes de respuesta.
  • DNAT: Este es un estado virtual establecido cuando la dirección de destino ha sido alterada por operaciones NAT. Esto es utilizado por el sistema de seguimiento de conexiones para que sepa que debe cambiar la dirección de destino nuevamente al enrutar los paquetes de respuesta.

Los estados rastreados en el sistema de seguimiento de conexiones permiten a los administradores crear reglas que apunten a puntos específicos en la vida útil de una conexión. Esto proporciona la funcionalidad necesaria para reglas más exhaustivas y seguras.

Conclusión

El marco de filtrado de paquetes netfilter y el firewall iptables son la base de la mayoría de las soluciones de firewall en servidores Linux. Los ganchos del kernel netfilter están lo suficientemente cerca de la pila de red para proporcionar un control poderoso sobre los paquetes mientras son procesados por el sistema. El firewall iptables aprovecha estas capacidades para proporcionar un método flexible y extensible para comunicar los requisitos de política al kernel. Al aprender cómo encajan estas piezas, puedes utilizarlas mejor para controlar y asegurar tus entornos de servidor.

Si deseas saber más sobre cómo elegir políticas efectivas de iptables, echa un vistazo a esta guía.

Estas guías pueden ayudarte a comenzar a implementar tus reglas de firewall iptables:

Source:
https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture