Guía de Administración de Redes con Linux
Anterior	Capítulo 9. Cortafuegos de TCP/IP	Siguiente

9.7. Cortafuegos 'IP Chains' (núcleos 2.2)

La mayoría de los aspectos de GNU/Linux evolucionan para satisfacer las cada vez mayores demandas de sus usuarios; el cortafuegos de IP no es una excepción. La implementación del cortafuegos de IP tradicional resulta suficiente para la mayoría de las aplicaciones, pero puede resultar engorroso y poco eficiente para configurar en entornos complejos. Para resolver este problema, se desarrolló un nuevo método de configuración del cortafuegos de IP así como nuevas características relacionadas. Este nuevo método fue denominado “Cortafuegos 'IP Chains'[1]” y fue liberado por vez primera para uso general en el núcleo 2.2.0.

El soporte del cortafuegos 'IP Chains' fue desarrollado por Paul Russell y Michael Neuling[2]. Paul es el autor del documento sobre 'IP Chains' IPCHAINS-HOWTO.

El cortafuegos 'IP Chains' le permite desarrollar clases de reglas de cortafuegos a las que puede entonces añadir y quitar 'hosts' o redes. Una consecuencia colateral del encadenamiento de reglas de cortafuegos es que puede mejorar el rendiminento del cortafuegos en aquellas configuraciones en las que haya montones de reglas.

El cortafuegos 'IP Chains' está soportado por las series de núcleos 2.2 y también se encuentran disponibles como un parche para la series de núcleos 2.0.*. El HOWTO describe dónde obtener el parche y proporciona montones de pistas útiles sobre cómo utilizar de forma efectiva la utilidad de configuración ipchains.

9.7.1. Uso de ipchains

Existen dos formas de emplear la utilidad ipchains. La primera forma consiste en utilizar el guión de "shell" ipfwadm-wrapper, que es básicamente un sustituto de la orden ipfwadm y que llama por debajo al programa ipchains. Si esto es lo que desea, no siga leyendo y relea las secciones previas que describen ipchains, poniendo ipfwadm-wrapper en su lugar. Esto funcionará, pero no se garantiza que el guión se mantenga en un futuro, y en ese caso no dispondrá de las características avanzadas que el cortafuegos 'IP Chains' vaya a ofrecer.

La segunda forma de utilizar ipchains consiste en aprender su nueva sintaxis y modificar cualquier configuración existente que exija utilizar la nueva sintaxis en lugar de la antigua. Con algunas consideraciones cuidadosas, se dará cuenta de que puede optimizar su configuración a la vez que realiza la conversión. La sintaxis de ipchains es más fácil de aprender que la de ipfwadm, por lo que resultará una buena opción.

La orden ipfwadm manipulaba tres conjuntos de reglas para el propósito de configurar el cortafuegos. Con el cortafuegos 'IP Chains', podrá crear un número arbitrario de conjuntos de reglas, cada una enlazada con otra, pero siguen estando presentes siempre tres conjuntos de reglas relacionadas con la función del cortafuegos. Los conjuntos de reglas estándares son los directos equivalentes de los utilizados con ipfwadm, exceptuando el hecho de que ahora tiene nombre: input, forward y output.

Veamos primero la sintaxis general de la orden ipchains, después se verá como utilizar ipchains en lugar de ipfwadm sin preocuparse acerca de sus características avanzadas de encadenamiento. Se hará reutilizando nuestros ejemplos anteriores

9.7.2. Sintaxis de la orden ipchains

La sintaxis de la orden ipchains es bastante directa. Se contemplarán los ejemplos más importantes. La sintaxis general de la mayoría de las órdenes de ipchains es:
ipchains orden especificación_de_regla opciones

9.7.3. Nuestro ejemplo simple revisado

Vamos de nuevo a suponer que se dispone de una red en nuestra organización y que se utiliza una máquina cortafuegos basada en GNU/Linux para permitir a nuestros usuarios el acceso a servidores de WWW en Internet, y para impedir cualquier otro tipo de tráfico.

r Si nuestra red tiene una máscara de red de 24 bits (clase C) y tiene como dirección 172.16.1.0, podrían utilizarse las siguientes reglas de ipchains:
# ipchains -F forward # ipchains -P forward DENY # ipchains -A forward -s 0/0 80 -d 172.16.1.0/24 -p tcp -y -j DENY # ipchains -A forward -s 172.16.1.0/24 -d 0/0 80 -p tcp -b -j ACCEPT

La primera de las órdenes borra todas las reglas del conjunto de reglas forward y el segundo establece la política predeterminada del conjunto de reglas forward a DENY. Por último, la tercera y cuartas órdenes establecen el filtrado específico que se desea. La cuarta orden permite que pasen los datagramas que provengan de o vayan a los servidores web de fuera de nuestra red, y la tercera red impide las conexiones entrantes de TCP con un puerto de origen igual a 80.

Si ahora se desea añadir reglas que permitan el modo pasivo sólo como modo de acceso a los servidores de FTP de fuera de nuestra red, se añadirían estas reglas:
# ipchains -A forward -s 0/0 20 -d 172.16.1.0/24 -p tcp -y -j DENY # ipchains -A forward -s 172.16.1.0/24 -d 0/0 20 -p tcp -b -j ACCEPT # ipchains -A forward -s 0/0 21 -d 172.16.1.0/24 -p tcp -y -j DENY # ipchains -A forward -s 172.16.1.0/24 -d 0/0 21 -p tcp -b -j ACCEPT

9.7.4. Listado de nuestras reglas con ipchains

Para mostrar nuestras reglas con ipchains, se utiliza su argumento -L. De igual forma que con ipfwadm, existen argumentos que controlan el grado de detalle de la salida. En su forma simple, ipchains produce una salida que se parece a ésta:
# ipchains -L -n Chain input (policy ACCEPT): Chain forward (policy DENY): target prot opt source destination ports DENY tcp -y---- 0.0.0.0/0 172.16.1.0/24 80 -> * ACCEPT tcp ------ 172.16.1.0/24 0.0.0.0/0 * -> 80 ACCEPT tcp ------ 0.0.0.0/0 172.16.1.0/24 80 -> * ACCEPT tcp ------ 172.16.1.0/24 0.0.0.0/0 * -> 20 ACCEPT tcp ------ 0.0.0.0/0 172.16.1.0/24 20 -> * ACCEPT tcp ------ 172.16.1.0/24 0.0.0.0/0 * -> 21 ACCEPT tcp ------ 0.0.0.0/0 172.16.1.0/24 21 -> * Chain output (policy ACCEPT):

Si no se proporciona el nombre de la cadena que se desea mostrar, ipchains mostrará todas las reglas de todas las cadenas. El argumento -n de nuestro ejemplo le dice a ipchains que no intente convertir ninguna dirección ni puerto en nombres. La información que presenta debería ser auto-explicativa.

Un formato de salida más explícito, que se invoca con la opción -u, proporciona mucho más detalle. Esta salida añade campos para los contadores de bytes y de datagramas, el tipo de servicio, los identificadores AND y XOR, el nombre de la interfaz, la marca, y el tamaño de la salida.

Todas las reglas creadas con ipchains tienen contadores de datagramas y bytes asociadas con ellas. Así es cómo se implementa la auditoría de IP y se discutirá con detalle en Capítulo 10. Por defecto, estos contadores se presentan de forma aproximada utilizando los sufijos K y M, que representan las unidades de mil y de millón, respectivamente. Si se proporciona el argumento -x, entonces se muestran los contadores en su forma completa y expandida.

9.7.5. Uso avanzado de las cadenas

Usted ya sabe que la orden ipchains sustituye a la orden ipfwadm con una sintaxis de línea de órdenes más simple y con algunas mejoras interesantes, pero sin duda alguna, usted desea saber dónde y por qué se deben utilizar las cadenas de usuario. Probablemente, también desee saber cómo utilizar los guiones de soporte que acompañan a la orden ipchains en su paquete de 'software'. Se investigarán a continuación estas materias y se dará respuesta a esas cuestiones.

9.7.5.1. Cadenas de usuario

Los tres conjuntos de reglas del código del cortafuegos de IP tradicional proporcionan un mecanismo para construir configuraciones de cortafuegos que eran bastante simples de entender y de gestionar en el caso de pequeñas redes con requisitos simples en cuanto a funcionalidad de cortafuegos. Cuando los requisitos de configuración no son tan simples, aparecen numerosos problemas. En primer lugar, las redes muy grandes requieren con frecuencia un número mucho mayor de reglas de cortafuegos que el pequeño que hemos visto hasta ahora; de forma inevitable, aparecen necesidades que requieren que se añadan reglas de cortafuegos para cubrir escenarios con casos especiales. Cuando el número de reglas empieza a crecer, el rendimiento del cortafuegos disminuye más y más según más y más comprobaciones tienen que realizarse sobre cada datagrama y la facilidad de gestión se convierte en un asunto importante. En segundo lugar, no es posible habilitar y deshabilitar conjuntos de reglas atómicamente; en cambio, usted se encontrará inevitablemente expuesto a ataques mientras se encuentre en medio de una reconstrucción de sus conjuntos de reglas.

El diseño del cortafuegos 'IP Chains' ayuda a soliviantar estos problemas al permitir al administrador de la red crear conjuntos arbitrarios de reglas de cortafuegos que se pueden enlazar con los tres conjuntos de reglas predefinidas. Se puede utilizar la opción -N de ipchains para crear una nueva cadena con el nombre de ocho caracteres o menos que nos plazca. (Probablemente sea buena idea restringir el nombre a uno formado por minúsculas solamente). La opción -j configura la acción que se tomará cuando el datagrama coincida con la especificación de la regla. La opción -j especifica que si un datagrama coincide con una regla, entonces deben realizarse más comprobaciones contra una cadena definida por usuario. Se ilustrará esto con un diagrama.

Considérese las siguientes órdenes de ipchains:
ipchains -P input DENY ipchains -N tcpin ipchains -A tcpin -s ! 172.16.0.0/16 ipchains -A tcpin -p tcp -d 172.16.0.0/16 ssh -j ACCEPT ipchains -A tcpin -p tcp -d 172.16.0.0/16 www -j ACCEPT ipchains -A input -p tcp -j tcpin ipchains -A input -p all

Se establece la política por defecto de la cadena de entrada a deny. La segunda orden crea una cadena de usuario denominada “tcpin.” La tercera orden añade una regla a la cadena tcpin que coincide con cualquier datagrama cuyo origen esté fuera de nuestra red; la regla no representa ninguna acción. Esta regla es una regla de auditoría que se discutirá con más detalle en Capítulo 10. Las dos reglas siguientes coinciden con cualquier datagrama destinado a nuestra red local tanto al puerto de ssh como al de www; los datagramas que coincidan con estas reglas son aceptados. La magia de ipchains empieza en la regla siguiente. Obliga al 'software' del cortafuegos a que compruebe cualquier datagrama del protocolo de TCP contra la cadena de usuario tcpin. Por último, se añade una regla a la cadena input que coincide con cualquier datagrama; esto es otra regla de auditoría. Todo esto producirá la cadenas de cortafuegos mostradas en la Figure 9-4.

Figura 9-4. Un conjunto simple de reglas de una cadena de IP

Nuestras cadenas input y tcpin están pobladas con nuestras reglas. El procesamiento de los datagramas siempre comienza por una de las cadenas predefinidas... Veamos cómo entran en juego las cadenas de usuario siguiendo el camino de procesamiento de los diferentes tipos de datagramas.

Primero, veamos qué pasa cuando se recibe un datagrama de UDP para uno de nuestros 'hosts'. La Figura 9-5 ilustra el flujo por las reglas.

Figura 9-5. La secuencia de reglas de comprobación de un datagrama de UDP recibido

El datagrama se recibe por la cadena input y cae dentro de las dos reglas porque coinciden con los protocolos de ICMP y TCP, respectivamente. Coincide con la tercera regla en la cadena, pero no se especifica ningún blanco por lo que los contadores de datagramas y bytes se actualizan pero se toma ninguna otra acción. El datagrama alcanza el final de la cadena input, se encuentra con la política predeterminada de la cadena input y no se acepta.

Para ver a nuestra cadena de usuario en acción, considérese qué pasa cuando se recibe un datagrama de TCP destinado al puerto ssh de uno de nuestros 'hosts'. La secuencia se muestra en la Figura 9-6.

Figura 9-6. Flujo de reglas para un datagrama de TCP recibido para ssh

Esta vez, la segunda regla de la cadena input coincide y especifica como blanco la cadena tcpin, nuestra cadena de usuario. Especificar una cadena de usuario como blanco causa que se compruebe el datagrama contra las reglas de esa cadena, por lo que la siguiente regla que se comprobará será la primera regla de la cadena tcpin. La primera regla coincide con cualquier datagrama que tenga una dirección de origen fuera de nuestra red local y no especifica ningún blanco, por lo que también es una regla de auditoría y la comprobación pasa a la siguiente regla. La segunda regla de nuestra cadena tcpin sí que coincide y especifica un blanco de ACCEPT. Se ha llegado a un blanco tal que no se realiza más procesamiento. El datagrama se acepta.

Por último, veamos lo que pasa cuando se alcanza el final de una cadena de usuario. Para ver esto, se representará el flujo de un datagrama de TCP destinado a un puerto distinto de los dos que estamos manejando específicamente, como se muestra en la Figura 9-7.

Figura 9-7. Flujo de reglas para un datagra de TCP recibido para telnet

Las cadenas de usuario no tienen políticas por defecto. Cuando se han comprobado todas las reglas de una cadena de usuario , y ninguna coincide, el código del cortafuegos actúa como si estuviera presente una regla de RETURN, por lo que si no es esto lo que usted desea, debe asegurarse de proporcionar una regla al final de la cadena de usuario que tome la acción que desee. En nuestro ejemplo, la comprobación vuelve a la regla del conjunto de reglas input situando inmediatamente después de la que nos movió a la cadena de usuario. En algún momento, se alcanza el final de la cadena input, que tiene una política predeterminada y no se acepta el datagrama.

Este ejemplo era muy simple, pero sirve de ilustración. Un uso más práctico de 'IP chains' sería mucho más complejo. Un ejemplo un poco más sofisticado es el proporcionado con la siguiente lista de órdenes:

    #
    # Establece la política de reenvío por defecto a REJECT
    ipchains -P forward REJECT
    #
    # crea nuestras cadenas de usuario
    ipchains -N sshin
    ipchains -N sshout
    ipchains -N wwwin
    ipchains -N wwwout
    #
    # Se asegura de que se rechazarán las conexiones provenientes por el camino incorrecto.
    ipchains -A wwwin -p tcp -s 172.16.0.0/16 -y -j REJECT
    ipchains -A wwwout -p tcp -d 172.16.0.0/16 -y -j REJECT
    ipchains -A sshin -p tcp -s 172.16.0.0/16 -y -j REJECT
    ipchains -A sshout -p tcp -d 172.16.0.0/16 -y -j REJECT
    #
    # se asegura que lo que alcance el final de una cadena de usuario se rechaza
    ipchains -A sshin -j REJECT
    ipchains -A sshout -j REJECT
    ipchains -A wwwin -j REJECT
    ipchains -A wwwout -j REJECT
    #
    # dirige los servicios de www y ssh a las cadenas de usuario relevantes
    ipchains -A forward -p tcp -d 172.16.0.0/16 ssh -b -j sshin
    ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 ssh -b -j sshout
    ipchains -A forward -p tcp -d 172.16.0.0/16 www -b -j wwwin
    ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 www -b -j wwwout
    #
    # Inserta nuestras reglas para buscar coincidencias con los 'hosts' en la segunda posición de
    # nuestras cadenas de usuario.
    ipchains -I wwwin 2 -d 172.16.1.2 -b -j ACCEPT
    ipchains -I wwwout 2 -s 172.16.1.0/24 -b -j ACCEPT
    ipchains -I sshin 2 -d 172.16.1.4 -b -j ACCEPT 
    ipchains -I sshout 2 -s 172.16.1.4 -b -j ACCEPT
    ipchains -I sshout 2 -s 172.16.1.6 -b -j ACCEPT
    #

En este ejemplo, se ha utilizado una selección de cadenas de usuario tanto para simplificar la gestión de la configuración de nuestro cortafuegos como para mejorar su eficiencia en comparación a una solución que involucrara sólo las cadenas predefinidas.

Nuestro ejemplo crea cadenas de usuario para cada uno de los servicios de ssh y www en cada sentido de la conexión. La cadena denominada wwwout es donde se colocan las reglas para los 'hosts' que tienen permisos para realizar conexiones de World Wide Web salientes, y sshin es donde se definen las reglas para los 'hosts' a los que se desea permitir las conexiones entrantes de ssh. Se asume que tenemos los requisitos de permitir o denegar a 'hosts' individuales de nuestra red la capacidad de empezar o recibir conexiones de ssh y www. La simplificación existe porque las cadenas de usuario nos permiten de forma clara agrupar las reglas para los permisos de entradas y salidas a los 'hosts' en vez de tenerlas todas revueltas. La mejora en la eficiencia se debe a que se ha reducido el número medio de comprobaciones requeridas sobre cualquier datagrama antes de que se encuentre un blanco. La ganancia de eficiencia aumenta conforme se añaden más 'hosts' Si no se hubiera utilizado cadenas de usuario, se tendría que buscar por la lista completa de reglas para determinar qué acción se toma con cada datagrama que se recibe. Incluso si se asume que cada una de las reglas de nuestra lista coincide con una proporción igual del número total de datagramas procesados, aún así estaríamos buscando en la mitad de la lista en promedio. Las cadenas de usuario nos permiten evitar la comprobación de números grandes de reglas si el datagrama que se comprueba no coincide con la regla simple en la cadena predeterminada a la que ha saltado.

9.7.5.2. Los guiones de soporte de ipchains

El paquete de 'software' de ipchains se proporciona con tres guiones de soporte. El primero de ellos ya se ha discutido brevemente, mientras que los dos restantes proporcian un método sencillo y conveniente de guardar y recuperar la configuración de su cortafuegos.

El guión ipfwadm-wrapper emula la sintaxis de la línea de órdenes de la orden ipfwadm, pero utiliza la orden ipchains para construir las reglas del cortafuegos. Esto es una forma conveniente de realizar la migración de la configuración existente de su cortafuegos o una alternativa al aprendizaje de la sintaxis de ipchains. El guión ipfwadm-wrapper se comporta de forma diferente de la orden ipfwadm en dos cosas: en primer lugar, porque la orden ipchains no soporta la especificación de una interfaz por su dirección, el guión ipfwadm-wrapper acepta el argumento -V pero intenta convertirlo en el equivalente en ipchains de -W buscando el nombre del interfaz configurado por la dirección proporcionada. El guión ipfwadm-wrapper le dará siempre un aviso cuando utilice la opción -V con el propósito de recordarle todo esto. En segundo lugar, las reglas de auditoría de los fragmentos no se traducen adecuadamente.

Los guiones ipchains-save e ipchains-restore convierten la tarea de construir y modificar la configuración del cortafuegos en una tarea mucho más simple. La orden ipchains-save lee la configuración actual y la escribe de forma simplificada por la salida estándar. La orden ipchains-restore lee datos con el formato de la salida de la orden ipchains-save y configura el cortafuegos de IP con esas reglas. La ventaja de utilizar estos guiones en vez de modificar directamente el guión de configuración de su cortafuegos y probar la nueva configuración consiste en la capacidad de construir dinámicamente su configuración una vez y entonces guardarla. Entonces usted puede recuperar esa configuración, modificarla, y volverla a guardar si así lo desea.

Para utilizar los guiones, se introduciría algo como:
ipchains-save >/var/state/ipchains/firewall.state
para guardar la configuración actual de su cortafuegos. Usted la recuperaría, quizás en el momento de arranque del sistema, con:
ipchains-restore </var/state/ipchains/firewall.state

El guión ipchains-restore comprueba si ya existe cualquiera de las cadenas de usuarios especifica en su entrada. Si se proporciona el argumento -f, entonces y de forma automáticaa, el guión borrará las reglas de la cadena de usuario antes de configurar las de la entrada. El comportamiento por defecto es que se le pregunte si desea saltarse esta cadena o inicializarla.

Anterior	Inicio	Siguiente
El cortafuegos original de IP (núcleos 2.0)	Subir	Netfilter e 'IP Tables' (Núcleos 2.4)

[1]	N. del T.: "cadenas de IP"
[2]	Puede contactar con Paul en Paul.Russell@rustcorp.com.au.