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

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.

Tabla 9-1. Valores habituales de máscaras de red y bits

Máscara	Bits
255.0.0.0	8
255.255.0.0	16
255.255.255.0	24
255.255.255.128	25
255.255.255.192	26
255.255.255.224	27
255.255.255.240	28
255.255.255.248	29
255.255.255.252	30

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.1.3. Listado de nuestras reglas

Después de haber introducido nuestras reglas, se puede pedir a ipfwadm que las liste con la orden:
# ipfwadm -F -l
Esta orden mostrará todas las reglas de reenvío configuradas. La salida debería parecerse a algo como esto:
# ipfwadm -F -l IP firewall forward rules, default policy: accept type prot source destination ports deny tcp anywhere 172.16.10.0/24 www -> any acc tcp 172.16.1.0/24 anywhere any -> www
La orden ipfwadm intentará traducir el número de puerto en un nombre de servicio utilizando el fichero /etc/services, si es que tiene alguna entrada correspondiente.

La salida por omisión carece de algunos detalles importantes para nosotros. En la salida con el listado predeterminado no se puede ver el efecto del argumento -y. La orden ipfwadm es capaz de producir un listado más detallado si se especifica además el argumento -e (salida extendida). Aquí no se muestra la salida completa porque es demasiado ancha para la página, pero sí que incluye una columna para las opciones de nombre opt que muestra la opción -y que controlla los paquetes de tipo SYN:

    # ipfwadm -F -l -e
    P firewall forward rules, default policy: accept
     pkts bytes type  prot opt  tosa tosx ifname  ifaddress   source        ...   
        0     0 deny  tcp  --y- 0xFF 0x00 any     any         anywhere      ...       
        0     0 acc   tcp  b--- 0xFF 0x00 any     any         172.16.1.0/24 ...

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.

Figura 9-3. Modos de un servidor de FTP

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.

Tabla 9-2. Tipos de datagramas de ICMP

Número de tipo	Nnemónico de iptables	Descripción del tipo
0	echo-reply	Respuesta a eco
3	destination-unreachable	Destino inaccesible
4	source-quench	Disminución del tráfico desde el origen
5	redirect	Redirección
8	echo-request	Solicitud de eco
11	time-exceeded	Tiempo superado
12	parameter-problem	Problema de parámetros
13	timestamp-request	Solicitud de marca de tiempo
14	timestamp-reply	Respuesta de marca de tiempo
15	none	Solicitud de información
16	none	Respuesta de información
17	address-mask-request	Petición de máscara de dirección
18	address-mask-reply	Respuesta de máscara de dirección

Anterior	Inicio	Siguiente
Las tres formas posibles de filtrado	Subir	Cortafuegos 'IP Chains' (núcleos 2.2)

[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"