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.
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.
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 |
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.
Después de haber introducido nuestras reglas, se puede pedir a ipfwadm que las liste con la orden:
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 ... |
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.
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.
Sólo puede introducirse una de estas categorías. La categoría le dice al cortafuegos qué tipo de regla de cortafuegos se está configurando:
- -I
-
regla de tipo 'Input'
- -O
-
regla de tipo 'Output'
- -F
-
regla de tipo 'Forwarding'
Al menos una de las siguientes órdenes debe ser introducida y se aplican sólo aquellas reglas relacionadas con la categoría introducida. La orden le dice al cortafuegos qué acción debe tomar.
- -a [política]
-
Añade una nueva regla
- -i [política]
-
Inserta una nueva regla
- -d [política]
-
Borra una regla existente
- -p política
-
Establece la política por defecto
- -l
-
Muestra todas las reglas existentes
- -f
-
Destruye todas las reglas existentes
Las políticas relevantes para el cortafuegos de IP y sus significados son:
- accept
-
Permite que los datagramas coincidentes sean recibidos, reenviados o transmitidos
- deny
-
Impide que los datagramas coincidentes sean recibidos, reenviados o transmitidos
- reject
-
Impide que los datagramas coincidentes sean recibidos, reenviados o transmitidos y envía al 'host' que envió el datagrama un mensaje de error de ICMP.
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
Estos argumentos resultan muy útiles a veces:
- -b
-
Utilizado para establecer el modo bidireccional. Este modificador hace que coincida el tráfico entre el origen y el destino especificados fluyendo en cualquier sentido. Esto ahorra el crear dos reglas: una para el sentido hacia delante de la conexión y otra para el sentido contrario.
- -o
-
Esto habilita el apunte en el registro del núcleo de información sobre los datagramas coincidentes. Cualquier datagrama que coincida con esta regla será registrado en un mensaje del núcleo. Esto resulta útil para posibilitar la detección de accesos no autorizados.
- -y
-
Utilizado para buscar coincidencias con datagramas de establecimiento de la conexión de TCP. Esta opción causa que la regla coincida sólo con los datagramas que intenten establecer conexiones de TCP. Únicamente los datagramas que tengan su bit SYN con un valor de uno, y su bit ACK con un valor de 0, buscar coincidencias conán. Esto resulta útil para filtrar los intentos de conexión de TCP y se ignora en el caso de otros protocolos.
- -k
-
Utilizado para buscar coincidencias con datagramas de acuse de recibo de TCP. Esta opción causa que la regla coincida sólo con los datagramas que sean acuse de recibos de paquetes que intentan establecer conexiones de TCP. Únicamente los datagramas que tenga su bit ACK con valor igual a 1. Esto resulta útil para filtrar los intentos de conexión de TCP y se ignora en el caso de otros protocolos.
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.
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 |
