9.6. El cortafuegos original de IP (núcleos 2.0)

La primera generación del soporte de cortafuegos de IP para GNU/Linux apareció en la serie de núcleos 1.1. Consistía en una implementación del cortafuegos ipfw de BSD por Alan Cox. El soporte de cortafuegos que apareció en la serie de núcleos 2.0 que constituye la segunda generación fue una mejora de Jos Vos, Pauline Middelink y otros.

9.6.1. Uso de ipfwadm

La orden ipfwadm era la herramienta de configuración para la segunda generación de cortafuegos de IP de GNU/Linux. Quizás la forma más simple de describir el uso de la orden ipfwadm es con un ejemplo. Para empezar, se codificará el ejemplo que se presentó antes.

9.6.1.1. Un ejemplo trivial

Supóngase que se dispone de una red en nuestra organización y que se utiliza una máquina cortafuegos basada en GNU/Linux para conectar la red a Internet. Además, supóngase que se desea que los usuarios de la red sean capaces de acceder a servidores 'web' de Internet, pero que cualquier otro tipo de tráfico no sea permitido.

Se pondrá una regla de tipo 'forwarding' para permitir que los datagramas con dirección de origen en nuestra red y un conector de destino con puerto 80 sean reenviados hacia fuera, y los correspondientes datagramas de respuesta sean reenviados de vuelta vía el cortafuegos.

Asúmase que nuestra red tiene una máscara de 24 bits (clase C) y una dirección de 172.16.1.0. La reglas que se podrían utilizar serían:
    # ipfwadm -F -f
    # ipfwadm -F -p deny
    # ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80
    # ipfwadm -F -a accept -P tcp -S 0/0 80 -D 172.16.1.0/24

El argumento -F de la línea de órdenes significa especifica a ipfwadm que es una regla de tipo 'forwarding', es decir, de reenvío. La primera orden instruye a ipfwadm que se "desprenda" de todas las reglas de tipo 'forwarding'. Esto asegura que se trabajará con un estado conocido antes de que se añadan reglas específicas.

La segunda regla establece nuestra política predeterminada de reenvío. Se le dice al núcleo que niegue o que no permita el reenvío de datagramas de IP. Es muy importante establecer la política por omisión, porque describe qué le pasará a cualquier datagrama que no esté específicamente controlado por cualquier otra regla. En la mayoría de las configuraciones de cortafuegos, usted querrá establecer la política por defecto a 'deny' [1], como se muestra en el ejemplo, para estar seguro de que sólo el tráfico que usted específicamente permita pasar su cortafuegos sea reenviado.

La tercera y la cuarta reglas son las que implementan el requisito. La tercera orden permite que nuestros datagramas salgan, y la cuarta permite las respuestas de vuelta.

Vamos a revisar cada unos de los argumentos:

-F

Esta es una regla de tipo 'forwarding'.

-a accept

Añadir esta regla con la política establecida a "aceptar", lo que quiere decir que se reenviará cualquier datagrama que se ajuste a esta regla

-P tcp

Esta regla se aplica a los datagramas de TCP (en lugar de UDP o ICMP).

-S 172.16.1.0/24

Los primeros 24 bits de la dirección de origen deben coincidir con los de la dirección de red 172.16.1.0.

-D 0/0 80

La dirección de destino debe tener cero bits coincidentes con la dirección 0.0.0.0. Esto en el fondo es una forma de decir "cualquier dirección". El 80 es el puerto de destino, en este caso el de WWW. También puede utilizarse cualquier entrada que aparezca en el fichero /etc/services para describir el puerto, de tal forma que -D 0/0 www habría funcionado igual de bien.

ipfwadm acepta las máscaras de red en una forma con la que puede no esté familiarizado. La notación /nn es una forma de describir cuántos bits de la dirección suministrada son significativos, es decir, es el tamaño de la máscara de red. Los bits se cuentan siempre de izquierda a derecha; algunos ejemplos habituales se muestran en la Tabla 9-1.

Se mencionó antes que ipfwadm implementa un pequeño truco que permite que sea más fácil añadir estos tipos de reglas. Este truco consiste en el uso de la opción -b, que convierte a la orden en una regla bidireccional.

El modificador de bidireccionalidad nos permite unir nuestras dos reglas en una sola como sigue:
    # ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 -b

9.6.1.2. Un refinamiento importante

Eche una mirada más atenta a nuestro conjunto de reglas. ¿ Puede apreciar que todavía existe un método de ataque que alguien de fuera podría utilizar para engañar a nuestro cortafuegos ?

Nuestro conjunto de reglas permite que todos los datagramas procedentes de fuera de nuestra red con un puerto de origen de 80 pasen. ¡ Esto incluiría a aquellos datagramas cuyo bit de SYN valga 1 ! El bit SYN es lo que declara a un datagrama de TCP que sea una petición de conexión. Si una persona de fuera tuviera un acceso privilegiado a un 'host', podría realizar una conexión a través de nuestro cortafuegos con cualquiera de nuestros 'hosts', dado el supuesto de que utilizará el puerto 80 en su extremo. Esto no es lo que se deseaba.

Afortunadamente, existe una solución a este problema. La orden ipfwadm proporciona otro modificador que permite construir reglas que coincidan con datagramas cuyo bit de SYN valga 1. Cambiemos nuestro ejemplo para incluir una regla de este tipo:
    # ipfwadm -F -a deny -P tcp -S 0/0 80 -D 172.16.10.0/24 -y
    # ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 -b

El modificador -y hace que la regla coincida sólo si el bit SYN del datagrama vale 1. Así nuestra nueva regla dice: "Deniega cualquier datagrama destinado a nuestra regla procedente de cualquier sitio con un puerto de origen igual a 80 y bit SYN igual a 1", o "deniega cualquier petición de conexsión desde 'hosts' utilizando el puerto 80"

¿Por qué se ha puesto esta regla especial antes de la regla principal? Las reglas de cortafuegos de IP operan de tal forma que la primera coincidencia es la regla que se utiliza. Ambas reglas coincidirían con los datagramas que queremos detener, por tanto debemos asegurarnos que se ha puesto la regla con la instrucción deny antes que la regla con la instrucción accept.

9.6.2. Un ejemplo más complejo

El ejemplo anterior era un ejemplo simple. No todo los servicios de red son tan simples de configurar como el servicio de WWWW; en la práctica, la configuración de un cortafuegos típico resultaría ser mucho más compleja. Vamos a examinar otro ejemplo común, esta vez FTP. Se quiere que los usuarios de la red interna puedan entrar en servidores de FTP de Internet para leer y escribir ficheros. Pero no se desea que personas de Internet puedan entrar en nuestros servidores de FTP.

Es sabido que FTP utiliza dos puertos de FTP: el puerto 20 (ftp-data) y el puerto 21 (ftp), por tanto:
    # ipfwadm -a deny -P tcp -S 0/0 20 -D 172.16.1.0/24 -y
    # ipfwadm -a accept -P tcp -S 172.16.1.0/24 -D 0/0 20 -b
    #
    # ipfwadm -a deny -P tcp -S 0/0 21 -D 172.16.1.0/24 -y
    # ipfwadm -a accept -P tcp -S 172.16.1.0/24 -D 0/0 21 -b
¿Correcto? Bueno, no necesariamente. Los servidores de FTP pueden operar en dos modos diferentes: el modo pasivo y el modo activo.
[2] En el modo pasivo, el servidor de FTP permanece escuchando en espera de una conexión desde el cliente. En el modo activo, es el servidor el que realmente realiza la conexión con el cliente. El modo activo es el habitual por omisión. Las diferencias se ilustran en la Figura 9-3.

Muchos servidores de FTP realizan su conexión de datos desde el puerto 20 cuando operan en el modo activo, lo que simplifica las cosas un poco, pero, degraciadamente, no todos proceden así. [3]

Pero, ¿cómo nos afecta todo esto? Fíjese en nuestra regla del puerto 20, el puerto de datos de FTP (FTP-data). La regla, tal como se tiene en este momento, asume que la conexión será realizada por nuestro cliente al servidor. Esto funcionará si se utiliza el modo pasivo. Pero resulta muy difícil para nosotros el configurar una regla satisfactoria que permita el modo activo de FTP, porque no se puede saber de antemano qué puertos serán los utilizados. Si abrimos nuestro cortafuegos para permitir conexiones entrantes en cualquier puerto, estaríamos exponiendo nuestra red a un ataque sobre todos los servicios que acepten conexiones.

El dilema se resuelve de la forma más satisfactoria insistiendo en que nuestros usuarios operen en el modo pasivo. La mayoría de los servidores de FTP y muchos clientes de FTP funcionarán de esta forma. El cliente popular ncftp también soporta el modo pasivo, pero requiere un pequeño cambio de configuración para conseguir que su modo por omisión sea el pasivo. Muchos navegadores de 'World Wide Web' como el navegador de Netscape también soportan el modo pasivo de FTP, por lo que no debería ser muy difícil el encontrar el 'software' adecuado para utilizar. De forma alternativa, se puede evitar el asunto de forma completa utilizando un programa intermediario de FTP que acepten una conexión desde la red interna y establezca conexiones con las redes externas.

Cuando construya su cortafuegos, probablemente se encontrará con varios de estos problemas. Debería siempre pensar cuidadosamente cómo funciona un servico realmente para estar seguro de que ha puesto un conjunto de reglas adecuado a ese servicio. La configuración de un cortafuegos de verdad puede resultar bastante compleja.

9.6.3. Resumen de los argumentos de ipfwadm

La orden ipfwadm tiene muchos argumentos diferentes que están relacionados con la configuración del cortafuegos de IP. La sintaxis general es:
    ipfwadm categoría orden parámetros [opciones]

Veamos cada cosa.

9.6.3.3. Parámetros

Al menos uno de los siguientes parámetros debe ser introducido. Utilice los parámetros para especificar a qué datagramas se aplica esta regla:

-P protocolo

Puede ser TCP, UDP, ICMP o todos. Ejemplo:

-P tcp

-S dirección[/máscara] [puerto]

La dirección IP de origen que buscar coincidencias coná con esa regla. Se asumirá una máscara de “/32” bits si no se proporciona una. Opcionalmente, puede especificar a qué puertos se aplicará esta regla. También puede especificar el protocolo utilizando el argumento -P que se describió más arriba. Si no se especifica el puerto o un rango de puertos, se supondrá que “todos” los puertos buscar coincidencias conán. Los puertos pueden especificarse por su nombre, utilizando la entrada del fichero /etc/services que desee. En el caso del protocolo de ICMP, el campo de puerto se utiliza para indicar el tipo de datagrama de ICMP. Pueden introducirse rangos de puertos; para ello utilice la sintaxis genérica: puerto inferior:puerto superior. Ejemplo:

-S 172.29.16.1/24 ftp:ftp-data

-D dirección[/máscara] [puerto]

Especifica la dirección IP de destino que buscar coincidencias coná con la regla. La dirección de destino se codifica con las mismas reglas que la dirección de origen descrita previamente. Ejemplo:

-D 172.29.16.1/24 smtp

-V dirección

Especifica la dirección del interfaz de red por el que el paquete se recibe (-I) o se envía (-O). Esto nos permite crear reglas que sólo se apliquen a ciertas interfaces de red de nuestra máquina. Ejemplo:

-V 172.29.16.1

-W nombre

Especifica el nombre del interfaz de red. Este argumento funciona de la misma manera que el argumento -V, excepto que se proporciona el nombre del dispositivo en lugar de su dirección. Ejemplo:

-W ppp0

9.6.3.5. Tipos de datagrama de ICMP

Cada una de las órdenes de configuración del cortafuegos le permite especificar tipos de datagrama de ICMP. Al contario que los puertos de TCP y de UDP, no existe un fichero de configuración conveniente que liste los tipos de datagramas y sus significados. Los tipos de datagrama de ICMP se definen en el RFC-1700, el RFC de los números asignados. Los tipos de datagrama de ICMP aparecen también listados en uno de los ficheros de cabecera de la biblioteca estándar de C. El fichero /usr/include/netinet/ip_icmp.h, que pertenece al paquete con la biblioteca estándar de GNU, y que los programadores de C utilizan cuando escriben 'software' de red que utilice el protocolo de ICMP, también define los tipos de datagrama de ICMP. Para su conveniencia, se incluyen aquí en la Tabla 9-2 [4]. La interfaz de la orden iptables le permite especificar los tipos de ICMP por su nombre, por lo que también se muestran los nombre nemotécnicos que utiliza.

Notas

[1]

N. del T.: "denegación"

[2]

El modo activo de FTP se habilita, de forma poco intuitiva, con la orden PORT. El modo pasivo de FTP se habilita con la orden PASV.

[3]

El demonio ProFTPd constituye un buen ejemplo de un servidor de FTP que no procede así, al menos,en sus versiones antiguas.

[4]

N.del T.: se han utilizado las descripciones de la traducción al español por P.J. Ponce de León, dentro del proyecto RFC-ES, del RFC0792 "Protocolo de mensajes de control de internet"