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 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.
netfilter imita la interfaz de ipchains con las siguientes órdenes:
rmmod ip_tables modprobe ipchains ipchains ... |
modprobe ip_tables |
La orden iptables se utiliza para configurar tanto el filtrado de IP como la traducción de direcciones de red. Para facilitar esto, existen dos tablas de reglas denominadas filter y nat. Por defecto, se asume la tabla 'filter' salvo que se especifique la opción -t. También se proporciona cinco cadenas predefinidas. Las cadenas INPUT y FORWARD están disponibles para la tabla filter, las cadenas PREROUTING y POSTROUTING están disponbiles para la tabla nat , y la cadena OUTPUT está disponible para ambas tablas. En este capítulo se discutirá solamente la tabla filter. Se contemplará la tabla nat en el Capítulo 11
La sintaxis general de la mayoría de las órdenes de iptables es:
iptables orden especificación_de_regla extensiones |
Especifica el protocolo del datagrama que buscar coincidencias coná con esta regla. Los nombres válidos de protocolos son tcp, udp, icmp, o un número, si se conoce el número del protocolo de IP.[2] Por ejemplo, podría utilizarse un 4 para buscar coincidencias con el protocolo de encapsulamiento ipip. Si se proporciona el signo!, entonces se niega la regla y el datagrama buscar coincidencias coná con cualquier protocolo diferente del especificado. Si no se proporciona este parámetro, se asume por omisión la coincidencia con todos los protocolos.
Especifica la dirección de origen del datagrama que buscar coincidencias coná con esta regla. Se puede proporcionar la dirección como un nombre de 'host', como un nombre de red o como una dirección de IP. El parámetro opcional máscara es la máscara de red que se utilizará y puede proporcionarse tanto en la forma tradicional (e.g., /255.255.255.0) como en la forma moderna (e.g., /24).
Especifica la dirección de destino del datagrama que buscar coincidencias coná con esta regla. La codificación de este parámetro es la misma que la del parámetro -s.
Especifica qué acción se tomará cuando se coincida con esta regla. Puede pensarse en este parámetro como con el significado de “salta a”. Los blancos válidos son ACCEPT, DROP, QUEUE, y RETURN. Se describieron sus significados más arriba. Sin embargo, también puede proporcionarse el nombre de una cadena de usuario, que sería por donde el proceso continuaría. También puede proporcionarse el nombre de un blanco complementado con el de una extensión. Se hablará acerca de las extensiones en breve. Si se omite este parámetro, no se realizará ninguna acción sobre los datagramas coincidentes, excepto la actualización de los contadores de datagramas y bytes de esta regla.
Especifica la interfaz por la que se recibió el datagrama. De nuevo, el signo “! invierte el resultado de la coincidencia. Si el nombre de la interfaz acaba con un signo “+”entonces cualquier interfaz que comience con la cadena proporcionada buscar coincidencias coná. Por ejemplo, -i ppp+ buscar coincidencias coná con cualquier dispositivo de red de PPP y -i ! eth+ con todas las interfaces excepto las correspondientes a dispositivos de Ethernet.
Especifica la interfaz por la que se enviará el datagrama. Este argumento tiene la misma codificación que el argumento -i.
Especifica que esta regla se aplica al segundo y restantes fragmentos de un datagrama fragmentado, y no al primer fragmento.
- -tcp-flags SYN,RST,ACK SYN |
# 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 |
[1] | N. del T.: 'Network Address Translation' en el original en inglés |
[2] | Véase el fichero /etc/protocols para buscar los nombres y números de los protocolos. |