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 [email protected].