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 |
# 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 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 |
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.1. Categor�as
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'
9.6.3.2. �rdenes
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.
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.4. Argumentos opcionales
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.
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.
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 |