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 |
o:
# 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 |
y con
iptables:
# 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 |
o:
# ipchains -A forward -s 172.16.3.0/24 -d 172.16.4.0/24 -b |
o:
# 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 |
Estas reglas contar�n todos los datagramas con una direcci�n origen perteneciente
a una de las redes de departamento y una direcci�n destino perteneciente a la otra.
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 |
o:
#!/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 |
o:
#!/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 |
Aqu� creamos dos cadenas definidas por usuario, una llamada
a-essent, donde capturamos datos de contabilidad
para servicios esenciales y otra llamada a-noness,
donde capturamos datos de contabilidad para servicios no esenciales.
Entonces agregamos a nuestra cadena forward las
reglas que coinciden con nuestros servicios esenciales y saltan a la cadena
a-essent, donde tenemos justamente una regla que
acepta todos los datagramas y los cuenta. La �ltima regla en nuestra
cadena forward es una regla que salta a nuestra
cadena a-noness, donde otra vez tenemos solamente
una regla que acepta todos los datagramas y los cuenta. La regla que
salta a la cadena a-noness no ser� alcanzada por
ninguno de nuestros servicios esenciales, puesto que ellos se habr�n
aceptado en su propia cadena. Nuestras cuentas para servicios esenciales
y no esenciales estar�n por consiguiente disponibles en las reglas
dentro de esas cadenas. �ste es simplemente un acercamiento que podr�a
tomar; hay otros. Nuestra implementaci�n iptables
del mismo acercamiento se parecer�a a:
# 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 |
y con
iptables usar�amos:
# 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 |
o, con
ipchains:
# 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 |
o, con
iptables:
# 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 |
La primera regla colecciona informaci�n sobre datagramas “Petici�n de eco ICMP”
(petici�n ping)
[3],
y la segunda regla colecciona informaci�n sobre datagramas “Respuesta de eco ICMP”
(respuesta ping). La tercera regla colecciona informaci�n sobre fragmentos de datagrama ICMP.
Este es un truco similar al descrito para fragmentos de datagramas TCP y UDP.
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 |
o:
# 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 |
o:
# 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 |
Con estas reglas situadas, todo el tr�fico fluyendo por la interfaz
ppp0 ser� analizado para determinar si es TCP,
UDP, o tr�fico de IMCP y los contadores apropiados ser�n actualizados
para cada uno. El ejemplo con
iptables divide
el flujo entrante del flujo saliente como lo exige su sintaxis.