Charlas 11-12-2000 Umeet'2000

Charlas 11/12/2000

Log de la conferencia. Se han suprimido las líneas correspondientes a entradas y salidas de diferentes personas en el canal durante la conferencia

[22:20] -> *uni* topic #media Horacio Peña "Policy-routing" (spanish version)
[22:16] (Horape> Algunos ejemplos del uso de ruteo por políticas.
[22:16] (Horape> ------------------------------------------------
[22:16] (Horape> Hace ya más de dos años, cuando estaba por salir el kernel 2.2 de
[22:16] (Horape> linux me tocó ser el primero que intentará documentar
[22:16] (Horape> en forma facilmente comprensible las en ese entonces nuevas
[22:16] (Horape> capacidades de ruteo avanzado por políticas de linux. Básicamente
[22:16] (Horape> el ruteo por políticas difiere del ruteo tradicional en que no usa
[22:17] (Horape> solamente la dirección de destino para determinar la ruta a seguir
[22:17] (Horape> sino que puede aprovecharse también de la dirección de origen, del
[22:17] (Horape> campo "Tipo de Servicio" del encabezado IP, y de características
[22:17] (Horape> de los protocolos de niveles más altos (puertos de TCP y UDP)
[22:17] (Horape> Puede verse mi documento original en http://compendium.ar.uninet.edu/policy-routing.es.txt.
[22:17] (Horape> (de Nov/98, hay una versión más actualizada pero en inglés en
[22:18] (Horape> http://compendium.ar.uninet.edu/policy-routing.txt) Hace bastante tiempo
[22:18] (Horape> he dejado de mantener ese documento, ya que el "Advanced Routing HOWTO"
[22:18] (Horape> en desarrollo planea abarcar los temas tocados con algo más de profundidad
[22:19] (Horape> (ver http://www.ds9a.nl/2.4Routing/)
[22:19] (Horape> Durante estos años he recibido una gran cantidad de consultas al
[22:19] (Horape> respecto y en ellas me basaré para presentar esta pequeña muestra
[22:20] (Horape> de formas en que se usa el ruteo por políticas.
[22:20] (Horape> - Ruteo diferenciado según clientes.
[22:20] (Horape> Es el uso más simple de ruteo por políticas. Se crean varias tablas
[22:21] (Horape> de ruteo y luego las reglas que determinen qué tabla usar se basarán
[22:21] (Horape> en las direcciones IP de origen. Ejemplo:
[22:21] (Horape> # Tabla de rutas 1
[22:22] (Horape> ip route add 0.0.0.0/0 dev ippp0 table 100
[22:22] (Horape> ip rule add from 10.0.0.0/8 table 101
[22:22] (Horape> En este ejemplo el tráfico de la red 192.168.0.0/16 será ruteado
[22:23] (Horape> por la interfaz de RSDI y el de la red 10.0.0.0/8 por el router
[22:23] (Horape> con dirección 10.0.2.3.
[22:23] (Horape> - Ruteo diferenciado según servicios.
[22:24] (Horape> Este es el caso más común y sobre el que he recibido más consultas. El
[22:24] (Horape> caso típico es disponer de dos enlaces con características y costos
[22:24] (Horape> distintos y querer distribuir el tráfico de acuerdo con los servicios
[22:25] (Horape> usados. Para hacerlo debemos utilizar el marcado de paquetes provisto
[22:25] (Horape> por el subsistema de firewall. Ejemplo:
[22:25] (Horape> Supongamos que en iface0 tenemos un vínculo con poca latencia pero también
[22:26] (Horape> poco ancho de banda y en iface1 un vínculo con muchísimo ancho de banda
[22:26] (Horape> pero con mucha latencia. Es razonable querer envíar el tráfico interactivo
[22:26] (Horape> por iface0 y el resto por iface1:
[22:26] (Horape> # Creamos las tablas de ruteo
[22:27] (Horape> ip route add 0.0.0.0/0 dev iface0 table 100
[22:27] (Horape> ip route add 0.0.0.0/0 dev iface1 table 101
[22:27] (Horape> # Marcamos los paquetes de SSH (tráfico interactivo)
[22:27] (Horape> ipchains -I input -p tcp -d 0/0 22 -m 2
[22:28] (Horape> # Hacemos que los paquetes marcados salgan por la tabla de rutas de poca
[22:28] (Horape> # latencia
[22:28] (Horape> ip rule add fwmark 2 table 100
[22:28] (Horape> # Por defecto usamos la tabla de rutas con preferencia por el ancho de banda
[22:28] (Horape> ip rule add 0/0 table 101
[22:28] (Horape> En muchos casos este tipo de ruteos va acompañado de IP Masquerade. Como este
[22:28] (Horape> determina bajo qué IP va a realizarse el enmascaramiento utilizando el
[22:29] (Horape> sistema de elección de rutas el retorno de los paquetes va a elegir los
[22:29] (Horape> mismos vínculos elegidos a la salida.
[22:29] (Horape> Es interesante jugar con estas cosas para permitir que el establecimiento de
[22:29] (Horape> las conexiones se realize utilizando el vínculo con poca latencia pero la
[22:29] (Horape> comunicación en sí se haga por el vínculo barato.
[22:29] (Horape> Nota: Hasta el advenimiento de netfilter (en la serie 2.3 del kernel de
[22:30] (Horape> linux) no se podía utilizar el ruteo según servicio para conexiones
[22:30] (Horape> establecidas en el mismo router, dado que los paquetes pueden ser marcados
[22:30] (Horape> solo en la cadena de entrada de ipchains por la que no circulan los paquetes
[22:30] (Horape> generados localmente. En netfilter existe NF_IP_LOCAL_OUT que permite esto.
[22:30] (Horape> Para más información sobre cómo hacerlo puede verse la charla de Harald Welte
[22:31] (Horape> en http://umeet.uninet.edu/spanish/calendario.html
[22:31] (Horape> - "Conexión multi-ISP independiente"
[22:31] (Horape> Con este nombre se me presentó un escenario en que se daba conexión satelital
[22:31] (Horape> asimétrica a internet en una red educativa de Canadá. Los usuarios se
[22:31] (Horape> conectaban por teléfono a sus ISP locales y utilizaban un proxy que devolvía
[22:32] sus pedidos por la red satelital. Dado que los clientes satelitales iban a
[22:32] (Horape> tener direcciones IP sin ningún patrón que permita determinar que lo son
[22:32] (Horape> decidimos que toda respuesta del proxy sería enviada por la red satelital:
[22:32] (Horape> ip route add 0/0 dev sat0 table 100
[22:33] (Horape> ipchains -I input -p tcp -s proxy 3128 -m 2
[22:33] (Horape> ip rule add fwmark 2 table 100
[22:33] (Horape> - Redes trampa.
[22:33] (Horape> Las redes trampa se utilizan para estudiar los métodos utilizados por los
[22:33] (Horape> crackers para vulnerar los sistemas. El problema es que para poder estudiar
[22:34] (Horape> estos intentos necesitamos dirigir los ataques a la red trampa. Para ello
[22:34] (Horape> qué mejor que hacer que los mismos servidores legítimos sean parte de la
[22:34] (Horape> red trampa... O al menos que lo parezcan.
[22:34] (Horape> Este enfoque fue desarrollado con Juan Manuel Pascual Escribá que creo
[22:34] (Horape> lo ha implementado en sus sistemas (no he podido contactar con él para
[22:34] (Horape> confirmarlo) Se basa en tener la red trampa configurada con las mismas
[22:35] (Horape> direcciones ip que la red de servidores real y dirigir todo el tráfico
[22:35] (Horape> que no corresponda a los servicios legítimos hacia ella:
[22:35] (Horape> (Supongamos un servidor de web con dirección 10.5.6.7 en la eth0 y
[22:35] (Horape> un equipo que usaremos para estudiar los ataques con igual ip en la
[22:36] (Horape> eth1)
[22:36] (Horape> # Definimos las tablas
[22:36] (Horape> ip route 10.5.6.0/24 dev eth0 table 100 # Real
[22:36] (Horape> ip route 10.5.6.0/24 dev eth0 # Por defecto enviamos los
[22:36] (Horape> # paquetes a la red trampa
[22:37] (Horape> # Marcamos los paquetes válidos.
[22:37] (Horape> ipchains -I input -p tcp -d 10.5.6.7 80 -m 2
[22:37] (Horape> # Enviamos los paquetes válidos por la red real.
[22:37] (Horape> ip rule add fwmark 2 table 100
[22:37] (Horape> ---------------
[22:37] (HoraPe> listo, la conferencia sigue en #linux
Y seguimos un buen rato más charlando...

Contact: