Guía de Administración de Redes con Linux - 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.

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 y con otras formas de traducciones de direcciones. Parte de esta complejidad era debida a que el enmascaramiento de IP y la traducción de direcciones de red [1] 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 complejas 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 genérico 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', independientemente 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 abadonen 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.

En la Figura 9-8, los componentes etiquetados como “demasq” y “masq” son componentes separados del núcleo que son responsables del procesamiento de los datagramas enmascarados entrantes y salientes. Estos componentes han sido reimplementados como módulos de netfilter.

Considérese el caso de una configuración para la que la política por defecto para cada una de las cadenas 'input', 'forward' y 'output' es deny. En 'IP Chains', se necesitarían seis reglas para permitir cualquier sesión a través del 'host' cortafuegos; dos para cada una de las cadenas 'input, 'forward' y 'output' (una cubriría el camino en un sentido y la otra en el sentido contrario). Puede imaginarse cómo esto puede llegar a resultar extremadamente complejo y difícil de gestionar cuando se mezclan sesiones que pueden ser encaminadas y sesiones que podrían conectarse al 'host' local sin que deban ser encaminadas. 'IP chains' le permite crear cadenas que le simplificarían esta tarea un poco, pero su diseño no resulta evidente y requiere de un cierto nivel de experiencia.

En la implementación de netfilter con iptables, esta complejidad desaparece completamente. Para que se pueda encaminar por un 'host' cortafuegos un servicio que se desea prohibir que termine en el propio 'host', sólo se necesitan dos reglas: una para un sentido y otra para el contrario ambas en la cadena 'forward'. Esto es la forma obvia de diseñar reglas de cortafuegos, y servirá para simplificar enormemente el diseño de las configuraciones del cortafuegos.

El documento PACKET-FILTERING-HOWTO ofrece una lista detallada de los cambios que se han realizado, por lo que aquí nos vamos a centrar en los aspectos más prácticos.

    rmmod ip_tables
      modprobe ipchains
      ipchains ...

    modprobe ip_tables

    iptables orden especificación_de_regla extensiones

    # modprobe ip_tables
      # iptables -F FORWARD
      # iptables -P FORWARD DROP
      # iptables -A FORWARD -m tcp -p tcp -s 0/0 --sport 80 -d 172.16.1.0/24 /
      --syn -j DROP
      # iptables -A FORWARD -m tcp -p tcp -s 172.16.1.0/24 --sport /
      80 -d 0/0 -j ACCEPT
      # iptables -A FORWARD -m tcp -p tcp -d 172.16.1.0/24 --dport 80 -s 0/0 -j /
      ACCEPT

Notas