Nota de recuperación: el manuscrito menciona Grafico.bmp. Esa imagen sigue pendiente de localización. El documento íntegro se recuperó de otra copia local del mismo paquete.
NRO. DE EDICIÖN Linux USERS #v1.3
SECCIÓN Expertos
SUB-SECCION Servers
CANT. DE PAGINAS
ARCHIVO
AUTOR Arturo Alberto Busleiman
E-MAIL [email protected]
TEXTO AUTOR
EDICION:
CORRECCIÓN:
DETALLE DE IMÁGENES, INFOGRAFIAS E ILUSTRACIONES
Grafico.bmp Se adjunta un grafico muy tosco, que por favor los Maestros del area de diseño gráfico lo transformen como sólo ellos con su élfica sabiduria pueden.
FRASES DESTACADAS:
“Para poder hacer buenas reglas es necesario conocer como viajan los
paquetes y su estructura interna.”
“Hay diversos motivos para querer filtrar: el Control, la Seguridad y
la Observacion, dice Rusty Russel, creador de ipchains/iptables.”
Aqui esta IPTABLES! (parte 2)
Netfilter, el filtrado de paquetes de Linux 2.4, es excelente. Sigamos aprendiendo!
En Linux USERS v1.2 intente explicar basicamente el uso y funcionamiento de Netfilter, y de la utilidad de usuario Iptables y sus parametros. Mostre
tambien algunos ejemplos simples. Me gustaria mostrarles ahora como es que
estos paquetes se manejan a nivel interno (o sea, en Netfilter), y asi
tambien comprederemos que son las cadenas (‘chains’), con lo que sera mucho mas simple crear nuevas reglas en base a nuestras necesidades.
EL TRAFICO DE RED
Llamamos trafico a los datos que viajan por una red IP (no solo Internet,
por supuesto). Estos datos viajan en la forma de paquetes de cierta cantidad
de bytes cada uno (1400, por ejemplo), por lo que para transmitir, digamos,
un archivo de 100 kilobytes, este es dividido en varias decenas de paquetes.
Ok, dicen ustedes. Pero cada paquete que tiene, aparte de un pedazo del
archivo transmitido? Un paquete (sea TCP o UDP, diferencias mas adelante)
esta dividido basicamente en dos partes: la cabecera y el area de datos
llamada ‘body’ (cuerpo). En este cabecera (‘header’) hay varios campos que
definen diferentes cosas, como el origen y direccion del paquete, tipo de
paquete, banderas (‘flags’) que son como comandos y/o variables que indican
diferentes estados digamos, administrativos. El protocolo TCP utiliza el
concepto de ‘coneccion’. O sea, antes de enviar un paquete con datos,
primero se hace un intercambio de paquetes de una manera especifica,
manejando los flags. Luego de este proceso, conocido como ‘handshaking’, que
no tiene traduccion pero que significa algo asi como ‘apreton de manos’, se
define que la coneccion ha sido establecida y se inicia el intercambio de
datos. Tambien el protocolo utiliza paquetes especiales para mantener y
finalizar una coneccion, y para ensamblar cada parte en el orden correcto.
La bandera (flag) que tiene activada un paquete para iniciar una
coneccion se llama ‘SYN flag’. (En USERS te da MAS de la primer parte de esta nota di una regla que la utilizaba, por eso la aclaro especificamente).
TCP es el protocolo que estamos usando cuando navegamos, cuando bajamos o enviamos email, y para muchos otras aplicaciones.
La unica diferencia de UDP con respecto a TCP radica en el aspecto
del handshaking: este no se realiza, por lo que nunca se puede saber si un
paquete llego a su destino, ya que no hay un ‘vinculo de coneccion’
definido, ni un protocolo que garantice la correcta transmision del paquete.
El protocolo UDP lo utiliza el ICQ. Ahora seguro entienden el motivo por el
cual a veces no llegan los mensajes, no?
EL FILTRADO
Bueno, ahora que vimos algunos conceptos podemos definir al filtrado de
paquetes como la operacion de examinar la cabecera de cada paquete y decidir
el destino del mismo. Estos destinos son 3:
ACCEPT: Como su nombre lo indica, es aceptar el paquete, dejarlo pasar.
DROP: Desechar el paquete, como si nunca hubiera llegado.
REJECT: Como DROP, excepto que va a emitir un aviso a la direccion de origen del paquete.
Bueno, podemos hacer algunos truquitos mas con los paquetes, pero esto es lo
basico: examinar y decidir.
Veamos como es que se mueven los paquetes y vamos a entender aun mas el
concepto:
Tenemos 3 cadenas: INPUT (entrada), OUTPUT (salida) y FORWARD (re-envio).
Los paquetes atraviesan estas cadenas, representadas en los circulos. Si una
regla dice que el paquete sea descartado (DROP o REJECT) se detiene ahi.
Caso contrario (ACCEPT), el paquete continua en el sentido que indica el
diagrama.
Una cadena es una lista de reglas que indican que hacer si algun paquete
cumple los requirimientos que hayamos especificado (protocolo, destino,
origen, puerto, etc). Estas reglas se revisan en el orden en que fueron
creadas, una por una. Si una regla no concuerda con el paquete, se pasa a la
proxima regla, y asi sucesivamente. Si ninguna regla tuvo concordancia el
paquete vera su destino cuando se consulte la ‘politica’ de la cadena (chain
policy). Esto es, digamos, la opcion predeterminada para los paquetes que no
cumplen ninguna regla. En un sistema bien seguro, el destino deberia ser
DROP.
* Si el paquete llega desde una placa de red o por nuestro vinculo PPP via
modem, se ve que destino tiene el paquete.
* Si el destino es para nuestra computadora, el paquete llega a la cadena
INPUT, y las reglas de esa cadena lo examinaran en orden y si no se aplicara
la politica del sistema. En caso de que sea aceptado (ACCEPT), el proceso
local (programa) que lo este esperando (por ejemplo, sendmail) lo tendra a
su disposicion para utilizarlo, o sea, lo recibira.
* Si el paquete es para re-enviar y si nuestro kernel no tiene re-envio (IP
Forwading) habilitado o no sabemos como reenviarlo, el paquete se descartara
(DROP). Si tenemos reenvio habilitado, y el paquete es para otra interfaz de
red (placa de red), el paquete seguira de largo hacia la cadena FORWARD
donde sera procesado y en caso de ser aceptado se enviara a la interfaz que
corresponda.
* Si un paquete es originado en nuestra computadora, sea de la forma que
sea, para ser enviado, el paquete llega a la cadena OUTPUT (salida), se lo
procesara y, en caso de ser ACCEPTado, viajara a la interfaz
correspondiente.
RAZONES PARA FILTRAR
Bueno, quiza muchos vean sin sentido el utilizar el filtrado de paquetes si
se conectan a InterNet a traves de modem, y de forma no constante, aunque
mas de una vez habran querido ‘filtrar’ a alguien que los molesta, sea en
IRC o ICQ. Esto ya es un motivo para ustedes. Pero los que usan conecciones
de banda ancha como ADSL o cable, o son administradores de red o incluso si
trabajan en un ISP, van a ver automaticamente las aplicaciones. Pero, de
todas formas, me gustaria compartir con ustedes lo que piensa el autor de
Netfilter/Iptables al respecto. El da tres motivos: Control, Seguridad y
Observacion.
CONTROL: Cuando estamos usando nuestro Linux para conectarnos a otra red
(Internet, por ejemplo), con Netfilter tenemos la oportunidad de aceptar o
filtrar diferente tipo de trafico. Por ejemplo, la cabecera de un paquete
contiene el destino de red del mismo: se puede prevenir que un paquete vaya
a ciertas partes de la red externa. Por ejemplo, yo uso Netscape para
acceder a los archivos de Dilbert. La pagina se llena de publicidades de
doubleclick.net, y pierdo valioso tiempo en cargarlas. Yo lo soluciono
creando reglas para no permitir trafico desde o hacia doubleclick.net
SEGURIDAD: Cuando tu sistema Linux es lo unico que existe entre el caos de
InterNet y tu ordenada y maravillosa intranet, es lindo saber que podes
restringir que viene a tocar nuestra puerta. Podemos decidir que todo el
trafico saliente sea aceptado, pero tambien podemos preocuparnos por el
famoso ‘Ping de la Muerte’ (Ping of Death: PoD) enviado por personitas
molestas de afuera. O quiza no queremos que nadie ingrese remotamente a
nuestro sistema via telnet, o como fuere, aunque las cuentas tengan claves
seguras, quiza solo queres ser un observador y no un SERVIDOR en la Red de
redes, como la mayoria. En ambos casos, con solo no dejar que ninguno entre
alcanza. Para esto filtramos los paquetes necesarios para crear una
coneccion.
OBSERVACION: A veces un sistema mal configurado de la red local puede llegar a decidir enviar paquetes al mundo exterior. Es bueno el poder decirle a
Netfilter que nos avise de cualquier cosa anormal que ocurra. Podemos
solucionarlo si sabemos que esta pasando. O podemos ser solo curiosos.
ALGUNOS PARAMETROS MAS
Si especificamos el protocolo TCP con el parametro -p, se nos habilitan
ciertas opciones muy utiles que se agregan luego del ‘-p TCP’, a saber:
–tcp-flags – Nos permite filtrar en base a flags activos o no (recuerden el
modificador ‘!’ que actua como negador delante de lo que lo coloquemos).
Ejemplo:
iptables -A INPUT –protocol tcp –tcp-flags ALL SYN,ACK -j DENY
-syn – Equivale a ‘–tcp-flags SYN,RST,ACK SYN’
–source-port o –sport – Filtramos por puerto o rango de puertos (separados
por un guion.
Ejemplo:
–source-port 1-1024 – Filtramos los paquetes que vengan de los puertos
entre 1 y 1024
–destination-port o –dport – Usado igual que –sport, pero filtramos los
paquetes que VAYAN a los puertos que especifiquemos.
Para el protocolo UDP, las opciones –sport y –dport tambien son
soportadas.
En el caso del protocolo ICMP, solamente tenemos dos opciones:
–help Nos detalla todos los tipos y codigos ICMP disponibles para utilizar
con la opcion –icmp-type
–icmp-type Especificamos el tipo ICMP por el cual queremos filtrar.
Algunas de estas opciones se encuentran en USERS te da MAS de la primera
parte de esta nota, en http://users.tectimes.com/l2
Esta nota es mas tecnica, porque he visto muchos pedidos de notas de este
tipo en los foros de TecTimes. Tambien es la razon por la cual la primera
parte era mas de resumen de comandos. Espero que la hayan disfrutado y que
envien sus comentarios a [email protected]