Debido a que la contabilidad IP se relaciona estrechamente con el cortafuegos de IP, la misma herramienta fue designada para configurarla, de modo que ipfwadm, ipchains o iptables sean utilizados para configurar la contabilidad IP. La sintaxis de �rdenes es muy similar a la de las reglas del cortafuegos, as� que no nos centraremos en eso, pero discutiremos qu� puede descubrir sobre la naturaleza de su tr�fico de red utilizando esta caracter�stica.
La sintaxis general para contabilidad IP con ipfwadm es:
# ipfwadm -A [sentido] [orden] [par�metros] |
El argumento sentido es nuevo. Esto se codifica simplemente como entrada (in), salida (out), o ambos (both). Estas trayector�as son desde la perspectiva de la propia m�quina GNU/Linux. entrada (in) se refiere a datos que entran a la m�quina desde una conexi�n de red y salida (out) se refiere a datos que est�n transmiti�ndose por este nodo en una conexi�n de red. El sentido ambos (both) es la suma de ambas trayectorias, entrante y saliente.
La sintaxis general para la orden ipchains e iptables es:
# ipchains -A cadena especificaci�n-de-regla
# iptables -A cadena especificaci�n-de-regla |
Las �rdenes ipchains e iptables permiten especificar el sentido de una manera m�s consistente con las reglas de cortafuegos. El cortafuegos de cadenas IP[1] no le permite configurar una regla que agrege ambos sentidos, pero permite configurar reglas en la cadena forward que la antigua implementaci�n no hac�a. Veremos la diferencia que produce, en algunos ejemplos un poco mas adelante.
Las �rdenes son bastante iguales a las reglas de cortafuegos, excepto que las pol�ticas de reglas no se aplican aqu�. Podemos agregar, insertar, eliminar y listar las reglas de contabilidad. En el caso de ipchains e iptables, todas las reglas v�lidas son reglas de contabilidad, y cualquier orden que no especifica la opci�n -j s�lo realiza recuento.
Las reglas de especificaci�n de par�metros para contabilidad IP son las mismas que aquellas usadas para cortafuegos IP. �stas son las que nosotros usamos para definir precisamente qu� tr�fico de la red deseamos contabilizar y sumar.
Trabajemos con un ejemplo para ilustrar como usar�amos la contabilidad IP.
Imagine que tenemos un encaminador basado en Linux que sirve a dos departamentos en la Cervecer�a Virtual. El encaminador tiene dos dispositivos Ethernet, eth0 y eth1, cada uno de los cuales sirve a un departamento; y un dispositivo PPP, ppp0, que nos conecta v�a un enlace serie de alta velocidad al campus principal de la Universidad Groucho Marx.
Tambi�n imaginemos que para prop�sitos de faturaci�n queremos conocer el total de tr�fico generado por cada uno de los departamentos a lo largo del enlace serie, y para prop�sitos de administraci�n queremos conocer el total de tr�fico generado entre los dos departamentos.
La siguiente tabla muestra las interfaces y direcciones que usaremos en nuestro ejemplo:
Para responder a la pregunta, “� Cu�ntos datos genera cada departamento en el enlace PPP ?”, podr�amos usar una regla parecida a:
# ipfwadm -A both -a -W ppp0 -S 172.16.3.0/24 -b
# ipfwadm -A both -a -W ppp0 -S 172.16.4.0/24 -b |
# ipchains -A input -i ppp0 -d 172.16.3.0/24
# ipchains -A output -i ppp0 -s 172.16.3.0/24
# ipchains -A input -i ppp0 -d 172.16.4.0/24
# ipchains -A output -i ppp0 -s 172.16.4.0/24 |
# iptables -A FORWARD -i ppp0 -d 172.16.3.0/24
# iptables -A FORWARD -o ppp0 -s 172.16.3.0/24
# iptables -A FORWARD -i ppp0 -d 172.16.4.0/24
# iptables -A FORWARD -o ppp0 -s 172.16.4.0/24 |
La primera mitad de cada una de estas reglas dice, “Cuente todos los datos viajando en cualquier direcci�n por la interfaz llamada ppp0 con una direcci�n origen o destino (recuerde la funci�n de la bandera -b en ipfwadm e iptables) de 172.16.3.0/24.” La segunda mitad de cada conjunto de reglas es la misma, pero para la segunda red Ethernet en nuestro sitio.
Para responder a la segunda pregunta , “� Cu�ntos datos viajan entre los dos departamentos ?”, necesitamos una regla como esta:
# ipfwadm -A both -a -S 172.16.3.0/24 -D 172.16.4.0/24 -b |
# ipchains -A forward -s 172.16.3.0/24 -d 172.16.4.0/24 -b |
# iptables -A FORWARD -s 172.16.3.0/24 -d 172.16.4.0/24
# iptables -A FORWARD -s 172.16.4.0/24 -d 172.16.3.0/24 |
Bien, supongamos que tambi�n queremos una mejor idea de qu� tipo de tr�fico exactamente est� transport�ndose por nuestro enlace PPP. Por ejemplo, nosotros podr�amos querer saber cu�nto del enlace est�n consumiendo los servicios FTP, SMTP, y Web.
Un gui�n de reglas para permitirnos coleccionar esta informaci�n podr�a parecerse a:
#!/bin/sh
# Coleccionar estad�sticas de volumen FTP, SMTP y WWW para los datos
# transportados en nuestro enlace PPP utilizando ipfwadm
#
ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data
ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 smtp
ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 www |
#!/bin/sh
# Coleccionar estad�sticas de volumen FTP, SMTP y WWW para los datos
# transportados en nuestro enlace PPP utilizando ipchains
#
ipchains -A input -i ppp0 -p tcp -s 0/0 ftp-data:ftp
ipchains -A output -i ppp0 -p tcp -d 0/0 ftp-data:ftp
ipchains -A input -i ppp0 -p tcp -s 0/0 smtp
ipchains -A output -i ppp0 -p tcp -d 0/0 smtp
ipchains -A input -i ppp0 -p tcp -s 0/0 www
ipchains -A output -i ppp0 -p tcp -d 0/0 www |
#!/bin/sh
# Coleccionar estad�sticas de volumen FTP, SMTP y WWW para los datos
# transportados en nuestro enlace PPP utilizando iptables
#
iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport ftp-data:ftp
iptables -A FORWARD -o ppp0 -m tcp -p tcp --dport ftp-data:ftp
iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport smtp
iptables -A FORWARD -o ppp0 -m tcp -p tcp --dport smtp
iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport www
iptables -A FORWARD -o ppp0 -m tcp -p tcp --dport www |
Hay un par de rasgos interesantes a esta configuraci�n. Primeramente, hemos especificado el protocolo. Cuando especificamos puertos en nuestras reglas, tambi�n debemos especificar un protocolo porque TCP y UDP proveen conjuntos separados de puertos. Ya que todos estos servicios est�n basados en TCP, lo hemos especificado como el protocolo. Segundo, tenemos especificado dos servicios ftp y ftp-data en un comando. ipfwadm permite establecer puertos simples, rango de puertos o una lista arbitraria de puertos. La orden ipchains permite cualesquiera, puertos simples o rango de puertos, que es lo que hemos usado aqu�. La sintaxis “ftp-data:ftp” significa “puertos ftp-data (20) hasta ftp (21),” y es como nosotros codificamos rangos de puertos en ambos: ipchains e iptables. Cuando usted tiene una lista de puertos en una regla de contabilidad, eso significa que cualquier dato recibido para alguno de los puertos en la lista, provocar� que el dato sea sumado a los totales de esa entrada. Recordando que el servicio FTP utiliza dos puertos, el de �rdenes y el de transferencia de datos, los hemos a�adido a la vez para sumar el tr�fico de FTP. Finalmente, especificamos la direcci�n origen como “0/0”, que es la notaci�n especial que coincide con todas las direcciones y es requerida por ambas �rdenes ipfwadm e ipchains para especificar los puertos.
Podemos extendernos un poco en el segundo punto para darnos una vista diferente de los datos en nuestro enlace. Ahora imaginemos que nosotros clasificamos tr�fico FTP, SMTP, y del Web como tr�fico esencial, y todo el otro tr�fico como no esencial. Si nosotros estuvi�ramos interesados en ver la proporci�n del tr�fico esencial al tr�fico no esencial, podr�amos hacer algo como:
# ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data smtp www
# ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 1:19 22:24 26:79 81:32767 |
Si ya ha examinado su fichero /etc/services, observar� que la segunda regla cubre todos los puertos excepto (ftp, ftp-data, smtp, y www).
�C�mo hacemos esto con las �rdenes ipchains o iptables, puesto que ellas permiten s�lo un argumento en la especificaci�n de puerto ?. Podemos aprovecharnos en contabilidad, de las cadenas definidas por usuario tan f�cil como en las reglas del cortafuegos. Considere el siguiente acercamiento:
# ipchains -N a-essent
# ipchains -N a-noness
# ipchains -A a-essent -j ACCEPT
# ipchains -A a-noness -j ACCEPT
# ipchains -A forward -i ppp0 -p tcp -s 0/0 ftp-data:ftp -j a-essent
# ipchains -A forward -i ppp0 -p tcp -s 0/0 smtp -j a-essent
# ipchains -A forward -i ppp0 -p tcp -s 0/0 www -j a-essent
# ipchains -A forward -j a-noness |
# iptables -N a-essent
# iptables -N a-noness
# iptables -A a-essent -j ACCEPT
# iptables -A a-noness -j ACCEPT
# iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport ftp-data:ftp -j a-essent
# iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport smtp -j a-essent
# iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport www -j a-essent
# iptables -A FORWARD -j a-noness |
Esto parece bastante simple. Desafortunadamente, hay un peque�o pero inevitable problema al intentar efectuar contabilidad por el tipo de servicio. Recordar� que discutimos el rol que desempe�a la MTU en redes TCP/IP en un cap�tulo anterior. La MTU define el datagrama m�s largo que se transmitir� en un dispositivo de red. Cuando un datagrama se recibe por un encaminador que es m�s grande que el MTU de la interfaz que necesita al retransmitirlo, el encaminador realiza un truco llamado fragmentaci�n. El encaminador fragmenta el datagrama largo en piezas peque�as no m�s largos que la MTU de la interfaz y entonces transmite �stas piezas. El encaminador construye nuevas cabeceras para poner delante de cada una de estas piezas, y �stas son las que la m�quina remota usa para reconstruir el dato original. Desafortunadamente, durante el proceso de fragmentaci�n el puerto se pierde para todos menos para el primer fragmento. Esto significa que la contabilidad IP no puede contar adecuadamente datagramas fragmentados. Puede contar fiablemente s�lo el primer fragmento o datagramas no fragmentados. Hay un peque�o truco permitido por ipfwadm que asegura que mientras nosotros no podamos saber exactamente desde qu� puerto el segundo y siguientes fragmentos vienen, podemos todav�a contarlos. Una temprana versi�n del software de contabilidad Linux asign� a los fragmentos un n�mero de puerto falso, 0xFFFF, que podr�amos contar. Para asegurarnos que capturamos el segundo y posteriores fragmentos, podemos usar una regla como �sta:
# ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 0xFFFF |
La implementaci�n de cadenas IP tiene una soluci�n ligeramente m�s sofisticada, pero el resultado es muy similar. Usando la orden ipchains usar�amos en cambio:
# ipchains -A forward -i ppp0 -p tcp -f |
# iptables -A FORWARD -i ppp0 -m tcp -p tcp -f |
�stos no nos dir�n el puerto original para estos datos, pero por lo menos podemos ver cuanto de nuestros datos son fragmentos, y seremos capaces de contabilizar el volumen de tr�fico que ellos consumen.
En n�cleos 2.2 podemos seleccionar una opci�n del n�cleo en tiempo de compilaci�n, que niega este problema completo si su m�quina GNU/Linux est� actuando como el �nico punto de acceso para una red. Si habilita la opci�n IP: Desfragmentar siempre cuando compila su n�cleo, todos los datagramas recibidos ser�n reensamblados por el encaminador Linux antes de encaminar y retransmitir. Esta operaci�n es realizada antes que el software de contabilidad y cortafuegos miren el datagrama, y as� no tendr� trato con ning�n fragmento. En n�cleos 2.4 usted puede compilar y cargar el m�dulo netfilter forward-fragment.
El protocolo ICMP no usa n�mero de puerto de servicio y es por eso un poco m�s dificultoso coleccionar detalles. ICMP usa un n�mero de tipos diferentes de datagramas. Muchos de �stos son inofensivos y normales, mientras otros s�lo deben observarse bajo circunstancias especiales. A veces las personas con mucho tiempo en sus manos intentan maliciosamente deteriorar el acceso de un usuario a la red, generando grandes cantidades de mensajes ICMP. Esto es com�nmente denominado saturamiento ping[2]. Aun cuando la contabilidad IP no puede hacer nada para prevenir este problema ( � Aunque el cortafuegos IP puede ayudar ! ) podemos al menos colocar reglas de contabilidad en un lugar que nos muestre si alguien lo ha estado intentando.
ICMP no usa los puertos como lo hacen TCP y UDP. En cambio ICMP tiene mensajes tipo ICMP. Podemos construir reglas de contabilidad para cada tipo de mensaje ICMP. Para hacer esto, colocamos el mensaje ICMP y el n�mero del tipo en lugar del puerto en la orden de contabilidad ipfwadm. Listamos los tipos de mensaje ICMP en “Secci�n 9.6.3.5” ref�erase a �l si usted necesita recordar cu�les son.
Una regla de contabilidad IP para coleccionar informaci�n sobre el volumen de datos ping que est� envi�ndose a usted o que usted est� generando podr�a verse como:
# ipfwadm -A both -a -P icmp -S 0/0 8
# ipfwadm -A both -a -P icmp -S 0/0 0
# ipfwadm -A both -a -P icmp -S 0/0 0xff |
# ipchains -A forward -p icmp -s 0/0 8
# ipchains -A forward -p icmp -s 0/0 0
# ipchains -A forward -p icmp -s 0/0 -f |
# iptables -A FORWARD -m icmp -p icmp --sports echo-request
# iptables -A FORWARD -m icmp -p icmp --sports echo-reply
# iptables -A FORWARD -m icmp -p icmp -f |
Si usted especifica la direcci�n origen y/o destino en sus reglas, puede seguir la pista de d�nde est�n viniendo los ping, tales como si ellos se originan dentro o fuera de su red. Una vez que ha determinado de d�nde est�n viniendo los datagramas pillos, usted puede decidir si quiere poner reglas de cortafuegos en un sitio para evitarlos o tomar alguna otra acci�n, como avisar al due�o de la red agraviante para avisarles del problema, o quiz�s incluso, acci�n legal si el problema es un acto mal�volo.
Imaginemos ahora que estamos interesados en conocer cu�nto tr�fico en nuestro enlaces es TCP, UDP, e ICMP. Usar�amos reglas como las siguientes:
# ipfwadm -A both -a -W ppp0 -P tcp -D 0/0
# ipfwadm -A both -a -W ppp0 -P udp -D 0/0
# ipfwadm -A both -a -W ppp0 -P icmp -D 0/0 |
# ipchains -A forward -i ppp0 -p tcp -d 0/0
# ipchains -A forward -i ppp0 -p udp -d 0/0
# ipchains -A forward -i ppp0 -p icmp -d 0/0 |
# iptables -A FORWARD -i ppp0 -m tcp -p tcp
# iptables -A FORWARD -o ppp0 -m tcp -p tcp
# iptables -A FORWARD -i ppp0 -m udp -p udp
# iptables -A FORWARD -o ppp0 -m udp -p udp
# iptables -A FORWARD -i ppp0 -m icmp -p icmp
# iptables -A FORWARD -o ppp0 -m icmp -p icmp |
| [1] | Traducci�n de IP Chains Firewall. N. del T. |
| [2] | Traducci�n de ping flooding N. del T. |
| [3] | Traducci�n de ICMP Echo Request. N. del T. |