Guía de Administración de Redes con Linux - Cortafuegos 'IP Chains' (núcleos 2.2) (II)

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. 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.

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.

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.

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.

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.

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

    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.