Netfilter es un marco de trabajo proporcionado por el núcleo de Linux que permite implementar diversas operaciones relacionadas con la red en forma de controladores personalizados. Netfilter ofrece varias funciones y operaciones para el filtrado de paquetes , la traducción de direcciones de red y la traducción de puertos , que proporcionan la funcionalidad necesaria para dirigir paquetes a través de una red y prohibir que los paquetes lleguen a ubicaciones sensibles dentro de una red.
Netfilter representa un conjunto de enlaces dentro del núcleo Linux que permiten que módulos específicos del núcleo registren funciones de devolución de llamadas con la pila de red del núcleo. Esas funciones, que normalmente se aplican al tráfico en forma de reglas de filtrado y modificación, se invocan para cada paquete que atraviesa el enlace respectivo dentro de la pila de red. [2]
Rusty Russell inició el proyecto netfilter/iptables en 1998; también fue autor del proyecto predecesor, ipchains . A medida que el proyecto crecía, fundó el equipo central de Netfilter (o simplemente coreteam ) en 1999. El software que produjeron (llamado netfilter de aquí en adelante) utiliza la licencia pública general de GNU (GPL), y el 26 de agosto de 1999 se fusionó con la versión 2.3.15 de la línea principal del núcleo Linux y, por lo tanto, se incluyó en la versión estable 2.4.0. [3]
En agosto de 2003, Harald Welte se convirtió en presidente del equipo central. En abril de 2004, tras una ofensiva del proyecto contra quienes distribuían el software del proyecto integrado en enrutadores sin cumplir con la GPL, un tribunal alemán concedió a Welte una orden judicial histórica contra Sitecom Alemania, que se negó a cumplir con los términos de la GPL (ver Disputas relacionadas con la GPL ). En septiembre de 2007, Patrick McHardy, quien dirigió el desarrollo durante los últimos años, fue elegido como nuevo presidente del equipo central.
Antes de iptables, los paquetes de software predominantes para crear cortafuegos Linux eran ipchains en el kernel Linux 2.2.x e ipfwadm en el kernel Linux 2.0.x, [3] que a su vez se basaba en ipfw de BSD . Tanto ipchains como ipfwadm modifican el código de red para poder manipular paquetes, ya que el kernel Linux carecía de un marco de control de paquetes general hasta la introducción de Netfilter.
Mientras que ipchains e ipfwadm combinan el filtrado de paquetes y NAT (en particular, tres tipos específicos de NAT , denominados enmascaramiento , reenvío de puertos y redirección ), Netfilter separa las operaciones de paquetes en varias partes, que se describen a continuación. Cada una de ellas se conecta a los ganchos de Netfilter en diferentes puntos para acceder a los paquetes. Los subsistemas de seguimiento de conexiones y NAT son más generales y más potentes que las versiones rudimentarias de ipchains e ipfwadm.
En 2017, se agregó la infraestructura de descarga de flujo IPv4 e IPv6 , lo que permitió acelerar el reenvío de la tabla de flujo de software y el soporte de descarga de hardware. [4] [5]
Los módulos del núcleo denominados ip_tables
, ip6_tables
, arp_tables
(el guión bajo es parte del nombre) y ebtables
comprenden la parte de filtrado de paquetes heredada del sistema de gancho Netfilter. Proporcionan un sistema basado en tablas para definir reglas de firewall que pueden filtrar o transformar paquetes. Las tablas se pueden administrar a través de las herramientas de espacio de usuario iptables
, ip6tables
, arptables
y ebtables
. Observe que, aunque tanto los módulos del núcleo como las utilidades de espacio de usuario tienen nombres similares, cada uno de ellos es una entidad diferente con una funcionalidad diferente.
Cada tabla es en realidad su propio gancho y cada tabla se introdujo para cumplir un propósito específico. En lo que respecta a Netfilter, ejecuta una tabla en particular en un orden específico con respecto a otras tablas. Cualquier tabla puede llamarse a sí misma y también puede ejecutar sus propias reglas, lo que permite posibilidades de procesamiento e iteración adicionales.
Las reglas se organizan en cadenas o, en otras palabras, "cadenas de reglas". Estas cadenas se nombran con títulos predefinidos, como INPUT
, OUTPUT
y FORWARD
. Estos títulos de cadena ayudan a describir el origen en la pila de Netfilter. La recepción de paquetes, por ejemplo, cae en PREROUTING
, mientras que INPUT
representa los datos entregados localmente y el tráfico reenviado cae en la FORWARD
cadena. La salida generada localmente pasa a través de la OUTPUT
cadena y los paquetes que se enviarán están en POSTROUTING
la cadena.
Los módulos Netfilter no organizados en tablas (ver más abajo) son capaces de verificar el origen para seleccionar su modo de operación.
iptable_raw
móduloiptable_mangle
móduloiptable_nat
móduloiptable_filter
módulosecurity_filter
móduloSECMARK
y CONNSECMARK
. (Estos denominados "destinos" hacen referencia a los marcadores de Linux con seguridad mejorada). El control de acceso obligatorio se implementa mediante módulos de seguridad de Linux como SELinux. La tabla de seguridad se llama después de la llamada a la tabla de filtros, lo que permite que cualquier regla de control de acceso discrecional (DAC) en la tabla de filtros surta efecto antes que cualquier regla MAC. Esta tabla proporciona las siguientes cadenas integradas: INPUT
(para paquetes que ingresan al equipo en sí), OUTPUT
(para alterar los paquetes generados localmente antes del enrutamiento) y FORWARD
(para alterar los paquetes que se enrutan a través del equipo).nftables es la nueva parte de filtrado de paquetes de Netfilter. nft
es la nueva utilidad de espacio de usuario que reemplaza a iptables
, ip6tables
, arptables
y ebtables
.
El motor del kernel de nftables agrega una máquina virtual simple al kernel de Linux, que puede ejecutar bytecode para inspeccionar un paquete de red y tomar decisiones sobre cómo debe manejarse ese paquete. Las operaciones implementadas por esta máquina virtual se hacen intencionalmente básicas: puede obtener datos del paquete mismo, echar un vistazo a los metadatos asociados (interfaz de entrada, por ejemplo) y administrar los datos de seguimiento de la conexión. Se pueden usar operadores aritméticos, de bit a bit y de comparación para tomar decisiones basadas en esos datos. La máquina virtual también es capaz de manipular conjuntos de datos (normalmente direcciones IP), lo que permite reemplazar múltiples operaciones de comparación con una única búsqueda de conjunto. [6]
Esto contrasta con el código heredado de Xtables (iptables, etc.), que tiene el conocimiento del protocolo tan profundamente integrado en el código que ha tenido que ser replicado cuatro veces (para IPv4, IPv6, ARP y puente Ethernet), ya que los motores de firewall son demasiado específicos del protocolo para ser utilizados de manera genérica. [6] Las principales ventajas son la simplificación de la ABIiptables
del kernel de Linux , la reducción de la duplicación de código , la mejora de los informes de errores y una ejecución y un almacenamiento más eficientes y cambios incrementales y atómicos de las reglas de filtrado.
El nf_defrag_ipv4
módulo desfragmentará los paquetes IPv4 antes de que lleguen al nf_conntrack_ipv4
módulo de seguimiento de conexión de Netfilter. Esto es necesario para el seguimiento de conexión dentro del núcleo y los módulos auxiliares NAT (que son una forma de "mini- ALG ") que solo funcionan de manera confiable en paquetes completos, no necesariamente en fragmentos.
El desfragmentador de IPv6 no es un módulo en sí mismo, sino que está integrado en el nf_conntrack_ipv6
módulo.
Una de las características importantes construidas sobre el marco Netfilter es el seguimiento de conexiones. [7] El seguimiento de conexiones permite al núcleo realizar un seguimiento de todas las conexiones o sesiones de red lógicas y, de ese modo, relacionar todos los paquetes que pueden formar esa conexión. NAT se basa en esta información para traducir todos los paquetes relacionados de la misma manera y iptables
puede usar esta información para actuar como un firewall con estado.
Sin embargo, el estado de la conexión es completamente independiente de cualquier estado de nivel superior, como el estado de TCP o SCTP. Parte de la razón de esto es que cuando solo se reenvían paquetes, es decir, no hay entrega local, el motor TCP puede no necesariamente ser invocado en absoluto. Incluso las transmisiones en modo sin conexión como UDP , IPsec (AH/ESP), GRE y otros protocolos de tunelización tienen, al menos, un pseudoestado de conexión. La heurística para tales protocolos se basa a menudo en un valor de tiempo de espera preestablecido para la inactividad, después de cuya expiración se descarta una conexión Netfilter.
Cada conexión Netfilter se identifica de forma única mediante una tupla (protocolo de capa 3, dirección de origen, dirección de destino, protocolo de capa 4, clave de capa 4). La clave de capa 4 depende del protocolo de transporte; para TCP/UDP son los números de puerto, para túneles puede ser su ID de túnel, pero en caso contrario es simplemente cero, como si no fuera parte de la tupla. Para poder inspeccionar el puerto TCP en todos los casos, los paquetes se desfragmentarán obligatoriamente.
Las conexiones de Netfilter se pueden manipular con la herramienta de espacio de usuario conntrack
.
iptables
Puede utilizar la comprobación de la información de la conexión, como estados, situaciones y más, para que las reglas de filtrado de paquetes sean más eficaces y fáciles de gestionar. Los estados más comunes son:
NEW
ESTABLISHED
RELATED
nf_conntrack_ftp
módulo ve un comando FTP " "PASV
INVALID
UNTRACKED
Un ejemplo normal sería que el primer paquete que ve el subsistema conntrack se clasificaría como "nuevo", la respuesta se clasificaría como "establecido" y un error ICMP se clasificaría como "relacionado". Un paquete de error ICMP que no coincidiera con ninguna conexión conocida se clasificaría como "inválido".
Mediante el uso de módulos de complemento, se puede proporcionar al seguimiento de conexiones el conocimiento de los protocolos de la capa de aplicación y, de esta manera, comprender que dos o más conexiones distintas están "relacionadas". Por ejemplo, considere el protocolo FTP . Se establece una conexión de control, pero siempre que se transfieren datos, se establece una conexión separada para transferirlos. Cuando nf_conntrack_ftp
se carga el módulo, el primer paquete de una conexión de datos FTP se clasificará como "relacionado" en lugar de "nuevo", ya que es parte lógica de una conexión existente.
Los asistentes solo inspeccionan un paquete a la vez, por lo que si la información vital para el seguimiento de la conexión se divide en dos paquetes, ya sea debido a la fragmentación de IP o a la segmentación de TCP, el asistente no necesariamente reconocerá patrones y, por lo tanto, no realizará su operación. La fragmentación de IP se maneja con el subsistema de seguimiento de la conexión que requiere desfragmentación, aunque la segmentación de TCP no se maneja. En el caso de FTP, se considera que la segmentación no ocurre "cerca" de un comando como PASV
con los tamaños de segmento estándar, por lo que tampoco se maneja en Netfilter.
Cada conexión tiene un conjunto de direcciones originales y direcciones de respuesta , que inicialmente son las mismas. NAT en Netfilter se implementa simplemente cambiando la dirección de respuesta y, si se desea, el puerto. Cuando se reciben paquetes, su tupla de conexión también se comparará con el par de direcciones de respuesta (y puertos). No tener fragmentos también es un requisito para NAT. (Si es necesario, los paquetes IPv4 pueden ser refragmentados por la pila IPv4 normal, que no sea de Netfilter).
De manera similar a los ayudantes de seguimiento de conexión, los ayudantes NAT realizarán una inspección de paquetes y sustituirán las direcciones originales por direcciones de respuesta en la carga útil.
Aunque no son módulos del kernel que utilizan el código Netfilter directamente, el proyecto Netfilter alberga algunos programas más dignos de mención.
conntrack-tools
es un conjunto de herramientas de espacio de usuario para Linux que permiten a los administradores de sistemas interactuar con las entradas y tablas de seguimiento de conexiones. El paquete incluye el conntrackd
demonio y la interfaz de línea de comandos conntrack
. El demonio de espacio de usuario conntrackd
se puede utilizar para habilitar cortafuegos con estado basados en clústeres de alta disponibilidad y recopilar estadísticas del uso del cortafuegos con estado. La interfaz de línea de comandos conntrack
proporciona una interfaz más flexible para el sistema de seguimiento de conexiones que el obsoleto /proc/net/nf_conntrack
.
A diferencia de otras extensiones como Connection Tracking, ipset
[8] está más relacionada con iptables
Netfilter que con el código central. ipset
Por ejemplo, no utiliza ganchos de Netfilter, pero en realidad proporciona un iptables
módulo para hacer coincidir y realizar modificaciones mínimas (establecer/borrar) conjuntos de IP.
La herramienta de espacio de usuario ipset
se utiliza para configurar, mantener e inspeccionar los denominados "conjuntos de IP" en el núcleo de Linux. Un conjunto de IP suele contener un conjunto de direcciones IP , pero también puede contener conjuntos de otros números de red, según su "tipo". Estos conjuntos son mucho más eficientes en cuanto a búsqueda que iptables
las reglas simples, pero, por supuesto, pueden requerir una mayor memoria. Se proporcionan diferentes algoritmos de almacenamiento (para las estructuras de datos en la memoria) ipset
para que el usuario seleccione una solución óptima.
Cualquier entrada de un conjunto puede vincularse a otro conjunto, lo que permite realizar operaciones de correspondencia sofisticadas. Un conjunto solo puede eliminarse (destruirse) si no existen iptables
reglas u otros conjuntos que hagan referencia a él.
SYNPROXY
El objetivo permite gestionar grandes inundaciones SYN sin las grandes penalizaciones de rendimiento que impone el seguimiento de conexiones en tales casos. Al redirigir SYN
las solicitudes iniciales al SYNPROXY
objetivo, las conexiones no se registran dentro del seguimiento de conexiones hasta que alcanzan un ACK
estado final validado, lo que libera al seguimiento de conexiones de tener que contabilizar grandes cantidades de conexiones potencialmente no válidas. De esta manera, se pueden gestionar inundaciones enormes SYN
de forma eficaz. [9]
El 3 de noviembre de 2013, SYN
la funcionalidad de proxy se fusionó con Netfilter, con el lanzamiento de la versión 3.12 de la línea principal del kernel de Linux. [10] [11]
ulogd
es un demonio de espacio de usuario para recibir y registrar paquetes y notificaciones de eventos de los subsistemas Netfilter. ip_tables
puede entregarle paquetes a través del mecanismo de cola de espacio de usuario, y el seguimiento de conexión puede interactuar con él ulogd
para intercambiar más información sobre paquetes o eventos (como la interrupción de la conexión o la configuración de NAT).
Netfilter también proporciona un conjunto de bibliotecas que tienen libnetfilter
como prefijo de su nombre, las cuales pueden ser utilizadas para realizar diferentes tareas desde el espacio de usuario. Estas bibliotecas están publicadas bajo la licencia GNU GPL versión 2. En concreto, son las siguientes:
libnetfilter_queue
libnfnetlink
libnetfilter_conntrack
libnfnetlink
libnetfilter_log
libnfnetlink
libnl-3-netfilter
libnl
proyecto [12]libiptc
netlink
biblioteca y su API es utilizada internamente por las iptables
utilidadeslibipset
libmnl
.El proyecto Netfilter organiza una reunión anual para desarrolladores, que se utiliza para discutir los esfuerzos de investigación y desarrollo en curso. El taller Netfilter de 2018 se llevó a cabo en Berlín, Alemania, en junio de 2018. [13]