Netfilter e IP Tables (Núcleos 2.4)

Mientras desarrollaba el cortafuegos ’IP Chains’, Paul Russell decidió que realizar funciones de cortafuegos de IP debería ser algo menos difícil; pronto asumió como tarea simplificar los aspectos de procesamiento de datagramas en el código de cortafuegos del núcleo y produjo un esquema de filtrado que era mucho más claro y mucho más flexible. Denominó este nuevo esquema netfilter.

Nota: En el momento de la preparación de este libro, el diseño de netfilter no está todavía estable. Esperamos que perdone cualquier error en la descripción de netfilter o de cualquiera de las herramientas de configuración asociadas que sea debido a cambios ocurridos tras la preparación de este material. Consideramos el trabajo realizado sobre netfilter suficientemente imporante como para justificar la inclusión de este material, pese a que partes de él sean especulativas por sí mismas. Si tiene alguna duda, los documentos HOWTO correspondientes contendrán la información más precisa y actualizada sobre los detalles asociados con la configuración de netfilter.

Pero, ¿ qué era lo que no estaba bien con las cadenas de IP de ipchains ? Habían aumentado de forma importante la eficiencia y la gestión de las reglas del cortafuegos. Pero la forma que tenían de procesar los datagramas eran todavía complejas, en especial en conjunción con características relacionadas con las funciones de cortafuegos como el enmascaramiento de IP (discutido en el Capítulo 11) y con otras formas de traducciones de direcciónes. Parte de esta complejidad era debida a que el enmascaramiento de IP y la traducción de direcciones de red 22 fueron funciones desarrolladas independientemente del código de cortafuegos e integradas más tarde, en vez de haber sido diseñadas como partes mismas del código del cortafuegos desde el principio. Si un desarrollador deseara añadir todavía más características a la secuencia de procesamiento de datagramas, entonces se encontraría con dificultades para encontrar el lugar donde insertar el código y se habría visto obligado a realizar cambios en el núcleo.

Además, había otros problemas. En concreto, la cadena “input” describía la entrada a la capa de red de IP tomada en conjunto. La cadena input afectaba tanto a los datagramas que estaban destinados a este ’host’ así como los datagramas que iban a ser encaminados. Esto resulta contrario a la intuición porque se confundía la función de la cadena ’input’ con la de la cadena ’forward’, que se aplicaba sólo a los datagramas que iban a ser reenviados, pero que siempre seguía a la cadena ’input’. Se se quería tratar de forma diferente los datagramas para el propio ’host’ de los que iban a ser reenviados, era necesario construir reglas compleajas que excluían a unos o a otros. El mismo problema aparecía con la cadena “output” de salida.

Esta complejidad influía de forma inevitable en el trabajo del administrador de sistemas porque se veía reflejada en la forma en que se debían diseñar los conjuntos de reglas. Además, cualquier extensión al proceso de filtrado exigía la modificación directa del núcleo, porque todas las políticas de filtrados estaban implementadas allí y no había forma de proporcionar una interfaz transparente. netfilter aborda tanto la complejidad como la rigidez de las soluciones antiguas implementando un esquema generíco en el núcleo que simplifica la forma en que se procesan los datagramas y proporciona la posibilidad de extender las políticas de filtrado sin tener que modificar el núcleo.

Veamos dos de los cambios claves realizados. La Figura 9-8 ilustra cómo se procesan los datagramas en la implementación de ’IP Chains’, mientras que Figura 9-9 ilustra cómo se procesan en la implementación de netfilter. La diferencias claves consisten en la eliminación de la función de enmascaramiento del código central y de un cambio en la localización de las cadenas de entrada y de salida. En acompañamiento a estos cambios, se creó una herramienta de configuración nueva y extensible que se denominó iptables.

En ’IP Chains’ la cadena de entrada se aplica a todos los datagramas recibidos por el ’host’, indepen-dientemente de si están destinados al ’host’ local o de si serán encaminados a otro ’host’. En netfilter, la cadena ’input’ de entrada se aplica sólamente a los datagramas destinados al ’host’ local, y la cadena ’forward’ de reenvío se aplica sólo a los datagramas destinados a otro ’host’. De forma similar, en ’IP chains’, la cadena ’output’ de salida se aplica a todos los datagramas que abadonene el ’host’ local, independientemente de si el datagrama se genera en el ’host’ local o ha sido encaminado desde otro ’host’. En netfilter, la cadena ’output’ de salida se aplica sólamente a los datagramas generados en este ’host’ y no se aplica a los datagramas que están siendo encaminados provenientes de otro ’host’. Este cambio por sí solo ofrece una enorme simplificación de muchas configuraciones de cortafuegos.