ataque al protocolo rip - Departament d`Enginyeria Informàtica i

ENGINYERIA TÈCNICA DE TELECOMUNICACIÓ
ESPECIALITAT TELEMÀTICA
PROYECTO FINAL DE CARRERA
Curso 2007-2008
ATAQUE AL PROTOCOLO RIP
Alumno: Salvador Álvarez
Director: Francesc Sebè
Fecha entrega: Abril 2008
ATAQUE AL PROTOCOLO RIP
2
ÍNDICE
PRESENTACION
5
1. INTRODUCCIÓN
6
1.1 Tabla de encaminamiento
1.2 Encaminamiento estático y dinámico
1.3 Protocolo de encaminamiento
1.4 Concepto de EGP E IGP
2. RIP
2.1 Introducción a RIP
2.2 Algoritmo del Vector de Distancia
2.2.1 Cambios en la topologia
2.2.2 Prevención de la inestabilidad: Cuenta a infinito
2.2.3 Horizonte dividido con actualización inversa envenenada
2.2.4 Trigger Update
2.3 Especificaciones del Protocolo RIP
2.4 Formato del mensaje
2.5 Consideraciones en el direccionamiento
2.6 Temporizadores
2.7 Proceso de entrada
2.7.1 Comando Request
2.7.2 Comando Response
2.8 Proceso de salida
2.9 Ejemplo RIP
2.10 RIP VERSION 2
2.10.1 Formato mensaje RIP version 2
2.10.2 Consideraciones y compatibilidades
2.11 Limitaciones del protocolo
3. DISEÑO DE ATAQUE
3.1 Introducción
3.2 Conocimiento de la red
3.3 Mensajeria falsa
3.4 Expansión de la mensajeria falsa
3.5 Provocar cancelación de rutas
3.6 Persistencia
4. DESARROLLO
4.1 Introduccion
4.2 Análisis funcional
4.3 Análisis técnico
4.4 Pruebas
6
9
10
10
12
12
12
17
19
22
26
27
28
30
32
33
34
35
36
37
40
40
43
44
45
45
45
46
48
50
51
52
52
52
55
58
3
4.4.1 Pruebas ST
4.4.2 Pruebas IT
4.4.3 Pruebas PR
59
59
61
5. CONCLUSIONES
64
6. RECURSOS UTILIZADOS
65
7. MANUAL
66
7.1 Introducción
7.2 Requisitos
7.3 Características
7.4 Descripción de la aplicación
7.5 Mensajes de error
66
66
66
67
69
4
PRESENTACIÓN
Una ruta, en telemática, es el camino que los datos deben seguir desde un
origen hasta llegar a su destino. En una arquitectura o topología de red, es de
gran importancia que todas las entidades que forman parte de la misma,
ordenadores o routers, se puedan comunicar entre ellos. Una topología de
red, puede ser tan simple como dos ordenadores conectados punto a punto, o
una gran red conmutada. Por esta razón es necesario que exista un
mecanismo que permita la comunicación, sea cual sea la topología de red. A
este mecanismo se le denomina encaminamiento, y determina las rutas que
deben seguir los datos.
En las redes que utilizan el protocolo TCP/IP, las máquinas encargadas de
encaminar la información se denominan routers. Los routers son máquinas
que tienen diversos interfaces de red. Cuando un router recibe una trama de
datos por una interfaz observa su cabecera IP para ver la dirección IP donde
va dirigida la trama. Según el destino donde va dirigida la trama, ésta va a ser
reenviada por un interfaz o por otro. La decisión sobre por qué lugar se debe
reenviar una trama se toma a partir de la información contenida en las tablas
de encaminamiento de un router. Esta información se puede configurar de
forma manual (proceso muy laborioso) por parte del administrador o se puede
obtener de forma automática mediante la utilización de protocolos de
encaminamiento. Un protocolo de encaminamiento es utilitzado por los routers
de una red para intercambiar la información necesaria para que cada router
pueda configurar sus tablas de encaminamiento.
Uno de los protocolos de encaminamiento más antiguos y conocidos, es el
Protocolo RIP, de las siglas en inglés, Routing Informacition Protocol. Pero,
¿Es realmente RIP un buen protocolo de encaminamiento? Este proyecto,
pretende demostrar las vulnerabilidades y problemas de seguridad que
presenta la utilización del protocolo RIP en redes conmutadas.
Primeramente, se analiza el protocolo, como funciona, que particularidades
tiene. A continuación se hace un estudio de los posibles problemas de
seguridad del protocolo. Y por último, se muestra la implementación de una
aplicación para ejecutar un ataque de denegación de servicio en una red
conmutada que utilice el protocolo RIP como protocolo de encaminamiento.
Este ataque tiene como finalidad interferir en el correcto funcionamiento de la
red en cuestión. El ataque consiste en introducir en la red un equipo que
inserte mensajes falsos. Estos mensajes falsos, al ser recibidos y procesados
por los routers causaran su desconfiguración de las tablas de
encaminamiento.
Para una buena comprensión de los temas tratados en el presente
proyecto, se recomienda que el lector tenga conocimientos básicos en
configuración de redes, conocimientos del protocolo TCP/IP, y conocimientos
del lenguaje de programación JAVA.
5
1 INTRODUCCIÓN
1.1 TABLA DE ENCAMINAMIENTO
La función de encaminamiento de una red trata de encontrar las rutas de
mínimo coste a través de la red, estando el parámetro de coste basado en el
número de saltos, el retardo esperado u otras métricas.
Una red de comunicaciones puede ser muy simple. Por ejemplo, dos
ordenadores conectados mediante un cable determinan una red de
comunicaciones. En una red de estas características es evidente que el flujo
de datos que ira de un ordenador a otro será siempre por el cable que los une.
Fig 1.
Pero, lo habitual encontrarnos arquitecturas de red más complejas. En ese
caso, los routers deben estar configurados para que los datos enviados entre
dos máquinas cualquiera lleguen a su destino. Por ejemplo, en la Fig 2. se
muestra una red con 4 ordenadores.
Fig 2.
Cada ordenador debe poder comunicarse con el resto de ordenadores de
la red. El ordenador A esta directamente conectado con B. Por lo tanto,
utilizan el cable de red que los une para comunicarse. En el caso de que el
ordenador A quiera comunicarse con el ordenador C, es necesario que el flujo
de datos pase por el ordenador B. Entonces, en ordenador B debe ser el
encargado de hacer llegar los datos que quiere enviar A a su destino. En este
6
caso como el destino es el ordenador C, reenviaría los datos por su interfaz 3.
De manera similar se pueden determinar cada ruta necesaria para que todos
los ordenadores de la red se puedan comunicar.
Se pueden presentar las rutas fácilmente en una tabla para cada
ordenador de la red. Por ejemplo, el ordenador A tendría la siguiente tabla de
rutas:
Destino
B
C
D
Puerta enlace
B
B
Interfaz
1
1
1
La puerta de enlace es la máquina a través de la cual una máquina envía
sus datos para que lleguen a destinos con los cuales no está conectada
directamente. En este caso, el ordenador A utiliza el ordenador B como puerta
de enlace para comunicarse con el resto de la red. Según este esquema, es
responsabilidad de B que los datos acaben llegando a su destino. La interfaz,
es el medio físico que se utiliza en cada ruta. En el ejemplo, como el
ordenador A solo dispone de una interfaz, enviará todos sus datos por esta. A
cada ruta posible, también se le conoce con el nombre de Entrada de la tabla.
La tabla de rutas del ordenador B tendría la siguiente pinta:
Destino
A
C
D
Puerta enlace
Interfaz
1
3
2
Como el ordenador B esta interconectado con todos los ordenadores de la
red en cuestión, no necesita puertas de enlace para comunicarse.
De forma similar se puede determinar las tablas del ordenador C y del
ordenador D:
Destino
B
D
D
Puerta enlace
Destino
C
B
A
Puerta enlace
B
B
Interfaz
2
1
2
Interfaz
1
3
2
7
Se puede observar como utilizan B como puerta de enlace para
comunicarse con A.
Según lo visto hasta el momento, una tabla de rutas contiene la
información que indica a una máquina como encaminar una trama de datos a
partir del destino donde esta va dirigida. A esta tabla se le denomina Tabla de
encaminamiento.
En una tabla de encaminamiento, se incluye el destino que se quiere
alcanzar, la puerta de enlace, si procede, y la interfaz que se utiliza para llegar
al destino. Adicionalmente se incluyen otros parámetros útiles para el
encaminamiento, que se verán más adelante. En las redes TCP/IP, el destino
se indica mediante la dirección IP del ordenador de destino, y la puerta de
enlace por la dirección IP del ordenador que hace tal función.
Fig. 3
La red representada en la Fig.3, esta constituida por tres ordenadores, y
dos redes. Por una parte, tenemos la red 192.168.1.0/24, y por otra, la red
192.168.2.0/24. Se han asignado direcciones IP en las interfaces de los
ordenadores respetando la singularidad en la red. La tabla de
encaminamiento que obtendríamos del ordenador A seria similar a la
siguiente:
Ordenador A
Destination
192.168.1.0
192.168.2.0
Gateway
0.0.0.0
192.168.1.2
Genmask
255.255.255.0
255.255.255.0
Iface
eth0
eth0
Cuando una máquina esta directamente conectada a una red, no necesita
puerta de enlace, gateway, para comunicarse con esta. En ese caso se utiliza
la dirección 0.0.0.0 para indicar que no es necesario puerta de enlace. El
ordenador A, como esta directamente conectado a la red 192.168.1.0 no
necesita puerta de enlace. En cambio, para comunicar con la red 192.168.2.0,
necesita de la puerta de enlace 192.168.1.2.
Las tablas de encaminamiento de los ordenadores B y C tendrían la
siguiente pinta:
8
Ordenador B
Destination
192.168.1.0
192.168.2.0
Gateway
0.0.0.0
0.0.0.0
Genmask
255.255.255.0
255.255.255.0
Iface
eth0
eth1
Como el ordenador B está directamente conectado a las dos redes no
necesita de puertas de enlace.
Ordenador C
Destination
192.168.1.0
192.168.2.0
Gateway
192.168.2.1
0.0.0.0
Genmask
255.255.255.0
255.255.255.0
Iface
eth0
eth0
Si el ordenador A desea enviar una trama de datos a la máquina C,
consultará la tabla de encaminamiento para decidir donde tiene que dirigir los
datos. En este caso enviará los datos por la única interfaz que tiene, la interfaz
eth0, que conecta directamente con B. Cuando el ordenador B recibe los
datos de A, ve que va dirigido al ordenador C en la cabecera IP. Entonces,
consultará en las tablas de encaminamiento por que interfaz tiene que
reencaminar los datos. En este caso por su interfaz eth1. Finalmente los datos
llegan a su destino, el ordenador C.
1.2 ENCAMINAMIENTO ESTÁTICO Y DINÁMICO
En redes no demasiado grandes, es factible configurar las tablas de
encaminamiento de forma manual. Cuando las tablas de encaminamiento se
configuran de forma manual, el encaminamiento se denomina Estático. En el
encaminamiento estático la información de las tablas de encaminamiento se
configuran una única vez. Esta información permanecerá inalterada a no ser
que la modifiquemos manualmente.
Para redes más grandes y complejas, esto no es factible. En primer lugar,
un número mayor de ordenadores, implica un número mayor de rutas a
configurar, siendo una tarea laboriosa, y en ocasiones difícil de hacer. Por otra
parte, cambios en la topología, tales como incluir más ordenadores, suponen
reconfigurar todos los ordenadores de la red para obtener comunicación con
los ordenadores incluidos. Además, si un enlace falla, como las rutas son
fijas, este método no es capaz de encontrar rutas alternativas para encaminar
los datos. En definitiva, la técnica de encaminamiento estático no se adapta al
estado de la red.
Por consiguiente, es necesario disponer de un mecanismo automático para
solucionar todos estos problemas. Este mecanismo debe rellenar la
9
información de las tablas de encaminamiento de los routers de forma
automática. Además, en caso de cambios en la topología de la red, la
información de las tablas debe actualizarse también de forma automática. De
esta forma, evitamos que cambios en la topología de red, tales como fallos en
enlaces o ampliaciones de red, provoquen problemas de comunicación. A este
mecanismo se le denomina Encaminamiento Dinámico. El contenido de las
tablas de encaminamiento cambia en la medida que lo hacen las condiciones
de la red.
Para hacer posible el encaminamiento dinámico es necesario que las
estaciones intercambien información acerca del estado de la red.
1.3 PROTOCOLO DE ENCAMINAMIENTO
Un protocolo de encaminamiento define el mecanismo mediante el cual los
routers de una red intercambian la información necesaria para configurar sus
tablas de encaminamiento.
Es necesario que en una red, todos los routers utilicen el mismo protocolo
de encaminamiento para intercambiar información. Solo así se puede tener la
certeza de que el mecanismo funcionará correctamente.
La meta de un protocolo de encaminamiento es muy simple:
“Proporcionar la información necesaria para el encaminamiento”.
1.4 CONCEPTO DE EGP E IGP
En una red tal como Internet, es inverosímil que se use un único protocolo
de encaminamiento. La red está organizada por diferentes Sistemas
Autónomos. Se entiende por sistema autónomo un conjunto de redes y
dispositivos que se encuentran administrados por una solo entidad, o al
menos tiene un grado razonable de control a nivel técnico y de administración.
Cada sistema autónomo tiene su propia tecnología de encaminamiento. Esta,
por tanto, puede ser diferente o no para cada sistema autónomo. El protocolo
de encaminamiento usado dentro de un sistema autónomo se le denomina un
IGP (Interior Gateway Protocol). Este protocolo se ocupa de que el contenido
de las tablas de encaminamiento de los routers del sistema autónomo sea
correcto.
10
Fig. 4
Para interconectar sistemas autónomos se usa otro protocolo a parte. Los
protocolos usados en este caso, son los EGP (Exterior Gateway Protocol).
Mediante estos protocolos, los distintos sistemas autónomos pueden
intercambiar información sobre las redes que se encuentran en su interior.
11
2 RIP
2.1 INTRODUCCIÓN A RIP
RIP, de las siglas en ingles Routing Information Protocol, es un protocolo
de encaminamiento dinámico basado en el Algoritmo de Bellman-Ford (o
Vector de Distancia). La descripción de este algoritmo fue a manos de Ford
and Fulkerson, de ahí que este algoritmo a veces también se le denomine
como el Algoritmo Ford-Fulkerson. El término Bellman-Ford también es usado
para referirse a este algoritmo. Viene del hecho que la formulación se basa en
la ecuación del Bellman, la base de la “Programación Dinámica”. El algoritmo
del Vector de Distancia, define los procedimientos utilizados en el protocolo
RIP para llevar a cabo en encaminamiento, así como de otros protocolos de
encaminamiento como IGRP y EIGRP de Cisco.
Este protocolo se ha utilizado para el encaminamiento de redes de
ordenadores desde la aparición de ARPANET. La red ARPANET nació en
1969 como resultado de un proyecto de investigación del Departamento de
Defensa norteamericano, que trataba de encontrar una vía de comunicación
alternativa a la comunicación a través de radio, ya que se preveía que en el
caso de una guerra nuclear, temor con fundamento en aquella época, las
comunicaciones por radio se verían fuertemente afectadas. ARPANET se
considera como el origen de Internet.
RIP Comenzó a ser un estándar de facto para intercambiar información de
encaminamiento entre routers y hosts. Se utilizó para dicho propósito por la
mayoría de los vendedores comerciales de routers IP.
El protocolo RIP se usa como un IGP. Fue diseñado para trabajar con un
tamaño de red moderado. Por consiguiente, esta pensado para redes que no
sean demasiado grandes. No está pensado para el uso en ambientes muy
complejos.
2.2 ALGORITMO DEL VECTOR DE DISTANCIA
El algoritmo del vector de distancia, define un procedimiento que busca la
mejor ruta para cada destino en una red cualquiera de computadores. Para
llevar a cabo esto, los routers de la red intercambian un conjunto de mensajes.
Con la información obtenida, cada router guarda una ruta hacia cada
destinación posible en el sistema, es decir, construye una tabla de
encaminamiento. En la práctica es necesario guardar la siguiente información
para cada destinación:
- Dirección de destino: En implementaciones IP de este algoritmo, esto se
traduce como la dirección IP de destino del host o de la red.
- Puerta de enlace: El siguiente router donde se deben enviar los datos para
que este se encarge de reencaminarlos hasta su destino.
12
- Interfaz: La conexión física que se debe usar para alcanzar la primera puerta
de enlace.
- Métrica: Parámetro que mide el coste de la ruta. En RIP, la métrica utilizada
es el número de saltos que se debe realizar para alcanzar el destino.
-Temporizador: Indica cuando fue la última actualización de la ruta.
A este conjunto de información se le conoce como Vector de distancia, ya
que para cada ruta posible se incluye la distancia hasta llegar al destino,
mediante el parámetro de métrica. Por tanto los routers de la red intercambian
vectores de distancia para que todos los participantes en el algoritmo
obtengan información sobre el estado de la red.
La métrica es una medida que sirve para comparar rutas. Si se obtienen
dos rutas para llegar al mismo destino, se dice que la mejor ruta para llegar a
ese destino es la que consuma un número menor de recursos de la red, es
decir la del mínimo coste. En el protocolo RIP, se utiliza una métrica que
cuenta a través de cuantos routers deben pasar los datos hasta llegar a su
destino, es decir, el número de saltos que se debe realizar para alcanzar el
destino. Por tanto, ante dos rutas posibles, la mejor, la del mínimo coste, será
la que realice un número menor de saltos hasta llegar a un destino dado.
Fig. 5
Por ejemplo, en la Fig. 5, la métrica de la ruta que va del ordenador A
hasta el ordenador D es 2, ya que tiene que pasar a través del ordenador B
hasta llegar a su destino. Para llegar al ordenador F, existen dos
posibilidades, o dos rutas: a través de B o a través de C. Si se escoge a través
de B la métrica de esa ruta es 3. En cambio si se escoge a través de C la
métrica es 2. Por tanto esta última es la mejor ruta ya que su métrica es
13
menor. Por otra parte, se considera métrica 0 la ruta de ir de una estación a sí
misma. Aunque esta ruta parezca inútil, se debe incluir en los vectores de
distancia.
En el ejemplo anterior se ha considerado una métrica de 1 para cada
enlace de la red. En ocasiones la métrica puede ser diferente en cada enlace.
Esto es así porque puede ser que un enlace sea más lento que otro, o
simplemente menos fiable. Por esta razón se definen métricas diferentes. En
cualquier caso, en RIP se utiliza por defecto métricas de valor 1 en todos los
enlaces.
Inicialmente cada máquina de la red solamente tiene información de sí
misma. Con los primeros mensajes intercambiados obtienen información
sobre sus vecinos. A medida que se van intercambiando más mensajes con
las máquinas vecinas el conocimiento de la red es mayor. Es necesario que la
información se reciba periódicamente para mantener las mejores rutas en todo
momento. De esta forma, es posible mantener las rutas óptimas para todo el
sistema entero solamente usando la información obtenida de routers vecinos.
Es de esperar que este algoritmo converja en las estimaciones correctas
sobre las rutas en un tiempo finito, siempre y cuando no haya cambios de la
topología de red. No existe un orden sobre el envío de información entre
entidades. Simplemente, es importante que las entidades no paren de enviar
actualizaciones, y que las redes no retrasen los mensajes demasiado. Cada
entidad puede enviar actualizaciones según su propio reloj. Ante un cambio de
sistema o topología el algoritmo de encaminamiento comienza a moverse
hacia un nuevo equilibrio, usando el viejo como su punto de partida.
Cogiendo como referencia la Fig. 5, veamos como evoluciona el algoritmo
partiendo desde el inicio.
Fig. 6
Primeramente, cada estación solo tiene información de sí misma, por tanto
la información que contendran los vectores de distancia será la siguiente:
14
ESTACION
A
B
C
D
E
F
Vector de distancia
[A:0]
[B:0]
[C:0]
[D:0]
[E:0]
[F:0]
Cada estación puede llegar a ella misma con métrica 0. Con la información
enviada, las estaciones aprenderan las rutas a las estaciones vecinas que
tienen directamente conectadas, con un coste de 1.
ESTACION
A
B
C
D
E
F
Rutas aprendidas
[A:0, B:1:i1, C:1:i2]
[B:0, A:1:i1, D:1:i2]
[C:0, A:1:i1, E:1:i2]
[D:0, B:1:i1, E:1:i2]
[E:0, C:1:i3, D:1:i1, F:1:i2]
[F:0, E:1:i1]
En los vectores de distancia, se incluyen ahora las rutas aprendidas:
ESTACION
A
B
C
D
E
F
Vector de distancia
[A:0, B:1, C:1]
[B:0, A:1, D:1]
[C:0, A:1, E:1]
[D:0, B:1, E:1]
[E:0, C:1, D:1, F:1]
[F:0, E:1]
Las estaciones aprenden rutas de sus vecinos, y actualizan sus tablas de
encaminamiento. En la siguiente actualización incluyen las rutas que han
aprendido en sus vectores de distancia que envían:
ESTACION
A
B
C
D
E
F
Rutas aprendidas
[A:0, B:1:i1, C:1:i2, D→B:2:i1, E→C:2:i2]
[B:0, A:1:i1, D:1:i2, C→A:2:i1, E→D:2:i2]
[C:0, A:1:i1, E:1:i2, B→A:2:i1, D→E:2:i2, F→E:2:i2]
[D:0, B:1:i1, E:1:i2, F→E:2:i2, C→E:2:i2, A→B:2:i1]
[E:0, C:1:i3, D:1:i1, F:1:i2, B→D:2:i1, A→C:2:i3]
[F:0, E:1:i1, D→E:2:i1, C→E:2:i1]
Cuando se aprende una ruta nueva, se debe almacenar la puerta de
enlace y el interfaz. Por ejemplo, La estación A, ha aprendido la ruta de D,
pero para llegar a D debe enviar los datos a través de B. En la tabla se
simboliza como D→B (D vía B). Se puede observar que la estación A y B aún
15
no saben de la existencia de la estación F, y al revés, la estación F no sabe de
la existencia de A y B.
Las estaciones envían sus vectores de distancia, con las rutas aprendidas:
ESTACION
A
B
C
D
E
F
Vector de distancia
[A:0, B:1, C:1, D:2, E:2]
[B:0, A:1, D:1, C:2, E:2]
[C:0, A:1, E:1, B:2, D:2, F:2]
[D:0, B:1, E:1, F:2, C:2, A:2]
[E:0, C:1, D:1, F:1, B:2, A:2]
[F:0, E:1, D:2, C:2]
Obsérvese que en los vectores de distancia no se incluye la puerta de
enlace de la ruta ni el interfaz. Sola se informa la métrica de cada destinación.
En la tercera iteración las estaciones siguen aprendiendo nuevas rutas:
ESTACION
A
B
C
D
E
F
Rutas aprendidas
[A:0, B:1:i1, C:1:i2, D→B:2:i1, E→C:2:i2, F→C:3:i2]
[B:0, A:1:i1, D:1:i2, C→A:2:i1, E→D:2:i2, F→D:3:i2]
[C:0, A:1:i1, E:1:i2, B→A:2:i1, D→E:2:i2, F→E:2:i2]
[D:0, B:1:i1, E:1:i2, F→E:2:i2, C→E:2:i2, A→B:2:i1]
[E:0, C:1:i3, D:1:i1, F:1:i2, B→D:2:i1, A→C:2:i3]
[F:0, E:1:i1, D→E:2:i1, C→E:2:i1, B→E:3:i1, A→E:3:i1]
La red ha llegado al equilibrio en tres actualizaciones. Todas las
estaciones se pueden comunicar entre ellas, ya que han aprendido todas las
rutas. Aun así es necesario seguir enviando actualizaciones para mantener el
equilibrio de forma periódica para que las estaciones detecten cambios en la
topología. Por ejemplo, si dejamos de recibir el vector de distáncia de un
router vecino, esto se debe a que dicho router ya no resulta accesible para
nosotros.
Se puede resumir las acciones que debe hacer cada estación que
participa en el algoritmo en tres puntos:
Mantener una tabla con una entrada para cada destinación posible en el
sistema. La entrada contendrá la distancia a la destinación, y la primera puerta
de enlace en la ruta de esa red y el interfaz. Conceptualmente, debe de haber
una entrada para ella misma, con métrica 0, pero no será realmente incluida
en la tabla de encaminamiento.
-
Periódicamente, enviar su vector de distancia a cada vecino.
Recibir los vectores de distancia de sus vecinos y comparar las entradas
recibidas con las almacenadas en la tabla de encaminamiento. Si se
encuentra alguna con una métrica menor, escoger la nueva ruta.
16
2.2.1 CAMBIOS EN LA TOPOLOGIA
En una red, los routers y líneas fallan. Esto implica que la topología de red
cambia, y por el mismo motivo, el sistema de vecinos cambia. Por lo tanto, la
próxima vez que se hace el cálculo de rutas, el cambio tiene que reflejarse.
Para solventar este problema, el algoritmo del vector de distancia debe
disponer de un mecanismo de caducidad de las rutas. Este mecanismo es
propio del protocolo específico que se utilice. En el protocolo RIP, cada puerta
de enlace que participa en el encaminamiento envía un mensaje de
actualización a todos sus vecinos una vez cada 30 segundos. Si no se obtiene
la actualización transcurridos 180 segundos, se considera que o la puerta de
enlace se ha roto o que la red de conexión ha dejado de funcionar. Entonces,
se marca la ruta como inválida. Si recibimos de otro vecino una ruta válida, se
substituye por la ruta que esta marcada como inválida. Se espera 180
segundos antes de dar por caducada una ruta a pesar de esperar respuesta
de nuestros vecinos cada 30 segundos. Desafortunadamente, en las redes,
los datos se pierden de vez en cuando, por lo tanto, no es buena idea
invalidar una ruta basándose en una sola actualización que falte.
Es útil tener una manera de notificar a nuestros vecinos que no hay
actualmente una ruta válida de una cierta red. RIP, como otros protocolos de
esta clase, hace esto a través de un mensaje normal de actualización,
marcando esa red como inalcanzable. Se elige una métrica específica para
indicar una destinación inalcanzable; ese valor es más grande que la métrica
válida más grande que esperamos ver. En la implementación existente del
RIP, se utiliza 16. Este valor se refiere normalmente al ‘infinito’, puesto que es
más grande que la métrica válida más grande. 16 puede parecer un número
asombrosamente pequeño. Más adelante se verá porque se escoge este y no
otro.
En la Fig. 7, tenemos una topología de red constituida por cuatro
ordenadores conectados.
Fig. 7
17
Con la red en equilibrio, las estaciones tienes las siguientes rutas
aprendidas:
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:1:i1, C:1:i2, D→C:2:i2]
[B:0, A:1:i1, C:1:i2, D→C:2:i2]
[C:0, A:1:i3, B:1:i1, D:1:i2]
Por tanto, enviarián los siguientes vectores de distancia:
ESTACION
A
B
C
Vector de distancia
[A:0, B:1, C:1, D:2]
[B:0, A:1, C:1, D:2]
[C:0, A:1, B:1, D:1]
En la Fig. 8 se ilustra el caso anterior, pero el enlace entre la estación A y
C ha dejado de funcionar. Se simboliza con una ‘x’.
Fig. 8
La estación A y la estación C se ven afectadas por este cambio de
topología y marcan sus rutas como inválidas. Se incluyen las rutas inválidas
con una métrica de 16, es decir, inalcanzables:
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:1:i1, C:16, D:16]
[B:0, A:1:i1, C:1:i2, D→C:2:i2]
[C:0, A:16, B:1:i1, D:1:i2]
En la siguiente actualización, las estaciones afectadas aprenden de la
estación B una ruta alternativa. La red se vuelve a equilibrar.
18
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:1:i1, C→B:2:i1, D→B:3:i1]
[B:0, A:1:i1, C:1:i2]
[C:0, A→B:2:i1, B:1:i1, D:1:i2]
Según lo visto hasta ahora, se puede garantizar que el algoritmo permite a
las estaciones, que encuentren las rutas idóneas a las destinaciones de la red.
En caso de un cambio de topología el algoritmo es capaz de equilibrarse en
un cierto tiempo.
2.2.2 PREVENCIÓN DE LA INESTABILIDAD: CUENTA A INFINITO
El valor de métrica escogido en RIP para representar un destino
inalcanzable, es 16. Si suponemos que un destino es inaccesible, todas las
puertas de enlace inmediatamente vecinas fijarán la métrica para ese destino
a 16. Las puertas de enlace un salto más lejos de los vecinos directos
terminarían con una métrica 17; las entradas dos saltos más lejos con 18, y
así sucesivamente. Esto es debido a que el cálculo de la métrica es la suma
de costes para esa ruta. Aún así en RIP el valor máximo permitido para una
métrica es 16. Por tanto el sistema converge en una métrica de 16 para el
destino inalcanzable, en todas las puertas de enlace, es decir, una puerta de
enlace como máximo puede fijar una métrica 16 en sus rutas, y esta indica
que el destino de esa ruta es inalcanzable.
En el apartado anterior, se ha visto que el algoritmo del vector de distancia
permite equilibrar la red en un cierto tiempo cuando se produce un cambio en
la topología de red. En algunos casos, según la topología de red y el cambio
de topología producido, el tiempo de convergencia no es aceptable.
En la Fig. 9 se ilustra una topología de tres ordenadores.
Fig. 9
19
Las rutas aprendidas al inicio son:
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:1:i1]
[B:0, A:1:i1, C:1:i2]
[C:0, B:1:i1]
Desde este punto, A y C envían sus vectores de distancia:
Fig. 10
Vector de A: [A:0, B:1]
Vector de C: [C:0, B:1]
La estación B también envía su vector de distancia:
Fig. 11
Vector de B: [B:0, A:1, C:1]
La estación A aprende la ruta a la estación C. Y la estación C aprende la
ruta a la estación A.
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:1:i1, C→B:2:i1]
[B:0, A:1:i1, C:1:i2]
[C:0, B:1:i1, A→B:2:i1]
La red ha llegado al equilibrio, cada estación puede comunicarse con el
resto de estaciones del sistema. Supóngase que la línea de comunicación
entre la estación A y B deja de funcionar:
20
Fig. 12
En la siguiente actualización B no recibe el vector de distancia de A.
Transcurrido un tiempo sin recibir información sobre la estación A, la ruta a la
estación A que tiene almacenada la estación B, caduca, y se marca como
inalcanzable, es decir con métrica 16. Recuérdese que en RIP, el tiempo de
caducidad de una ruta, es de 180 segundos.
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:16, C:16]
[B:0, A:16, C:1:i2]
[C:0, B:1:i1, A→B:2:i1]
Como la estación A queda aislada, tampoco recibe vectores de distancia
de B y marca sus rutas como inalcanzables.
La estación C envía su vector de distancia.
Fig. 13
Vector de C: [C:0, B:1, A:2]
Como C aún no sabe que la línea entre la estación A y la estación B ha
fallado, tiene en su base de datos una ruta para llegar hasta la estación A ,
que para ella es válida. Por tanto se incluye esta ruta en su vector de
distancia. B piensa que C tiene un camino alternativo para llegar a la estación
A e incluye una nueva entrada en su base de datos con métrica 3.
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:16, C:16]
[B:0, A→C:3:i2, C:1:i2]
[C:0, B:1:i1, A→B:2:i1]
En este punto, como la estación C no recibe de la estación B la ruta que
aprendió para llegar a la estación A (A→B:2), después de un cierto tiempo
21
marcará esa ruta como inválida, y en la actualización siguiente aprenderá de
nuevo la ruta de la estación B, pero esta vez, con métrica 4.
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:16, C:16]
[B:0, A→C:3:i2, C:1:i2]
[C:0, B:1:i1, A→B:4:i1]
Ahora es B quién no recibe actualización de la ruta A que aprendió de C
(A→C:3). Por tanto, a la larga adoptara una métrica de 5 para esta ruta.
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:16, C:16]
[B:0, A→C:5:i2, C:1:i2]
[C:0, B:1:i1, A→B:4:i1]
Por culpa de estos rebotes de información entre las estaciones, la métrica
de la ruta a la estación A se va incrementando, y no es eliminada de las tablas
de encaminamiento. No se cancelará por completo hasta que no se alcance
una métrica de 16, la máxima permitida. Por tanto se puede concluir que el
tiempo de convergencia es lento. A este tipo de problemas se le conoce como
Cuenta a infinito.
Para prevenir este tipo de situaciones, en el protocolo RIP se implementa
dos mecanismos: ‘Horizonte dividido con actualización inversa’, y ‘Trigger
Update’.
2.2.3 HORIZONTE DIVIDIDO CON ACTUALIZACIÓN INVERSA
ENVENENADA
El problema descrito en el apartado anterior es causado por el hecho de
que las estaciones se engañan mutuamente sobre las estimaciones que
hacen.
Horizonte dividido, es una técnica para evitar estos problemas. Para
conseguirlo, no se envía información sobre una ruta por el mismo enlace por
el que ha llegado. Además se utiliza la técnica de ‘Inversa envenenada’. Si
una ruta es inalcanzable si que se anuncia por la misma interfaz que se
aprendió que la ruta es inalcanzable.
Véase la evolución de la topología de la Fig. 12, aplicando estas técnicas.
Partimos del equilibrio antes de que la estación A dejara de funcionar.
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:1:i1, C→B:2:i1]
[B:0, A:1:i1, C:1:i2]
[C:0, B:1:i1, A→B:2:i1]
22
Cuando la estación A deja de funcionar:
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:16, C:16]
[B:0, A:16, C:1:i2]
[C:0, B:1:i1, A→B:2:i1]
La estación C envía su vector de distancia:
Vector de C: [C:0, B:1]
Como C aprendió la ruta a la estación A por la interfaz que la une con la
estación B, en su vector de distancia no incluye esta ruta. Por lo tanto, la
estación B no aprenderá de nuevo la ruta a la red que ha dejado de funcionar
cuando C mande su vector. Con el tiempo C marcara su ruta a la estación A
como no válida por el hecho de no recibir actualizaciones por parte de B:
ESTACION
A
B
C
Rutas aprendidas
[A:0, B:16, C:16]
[B:0, A:16, C:1:i2]
[C:0, B:1:i1, A:16]
Se puede concluir que utilizando estas técnicas la convergencia es mucho
más rápida. De todas formas, en algunas topologías no es suficiente con
utilizar estas técnicas.
En la Fig. 15 se muestra un escenario con 5 estaciones.
Fig. 14
23
ESTACION
N
A
B
C
D
Rutas aprendidas
[N:0, A:1:i1, C→A:2:i1, B→A:2:i1, D→A:3:i1]
[A:0, N:1:i3, B:1:i1, C:1:i2, D→B:2:i1]
[B:0, A:1:i2, D:1:i1, C→A:2:i2, N→A:2:i2]
[C:0, A:1:i2, D:1:i1, B→A:2:i2, N→A:2:i2]
[D:0, B:1:i1, C:1:i2, A→B:2:i1, N→B:3:i1]
La red funciona correctamente y todas las estaciones se pueden
comunicar con el resto de estaciones del sistema. De repente, la línea que
une estación N con la estación A deja de funcionar.
Fig. 15
Como consecuencia a esto la estación N queda aislada del sistema y con
el tiempo eliminará todas sus rutas por no recibir vectores de distancia de la
estación vecina A. Por otra parte, la estación A marcará la ruta a la estación N
como inválida al no recibir actualizaciones. A envía su vector de distancia
indicando con métrica 16 la ruta a la estación N.
24
Fig. 16
Esto implica que las estaciones B y C marquen la ruta a la estación N
como inalcanzable. Supóngase en este punto que D envía su vector de
distancia.
Fig. 17
Como la estación D aprendió la ruta a la estación N gracias a la estación
B, no incluye en el vector de distancia dirigido a B esta ruta. Pero, en el vector
de distancia dirigido a la estación C si que incluye esta ruta. Debido a esto, la
estación C cree encontrar una ruta alternativa a través de la estación D y
activa de nuevo la ruta a la estación N con métrica 4 vía D.
En las siguientes actualizaciones se entra en un proceso de cuenta a
infinito de la ruta N:
25
Fig. 18
En este ejemplo se puede observar que la convergencia ante cambios en
la topología es lenta. Por tanto se necesita de otro mecanismo adicional para
evitar estas situaciones. Este mecanismo es ‘Trigger Update’.
2.2.4 TRIGGER UPDATE
La técnica ‘Trigger Update’, consiste en enviar las actualizaciones
inmediatamente ante un cambio de rutas. Es decir, si una estación cambia
una ruta de su base de datos, inmediatamente informa a sus vecinos de dicho
cambio. Con este tipo de técnica se evita el problema descrito en el ejemplo
anterior.
26
Fig. 19
Retómese el ejemplo cuando la estación A envía sus vectores de
distancia, indicando que la ruta a la estación N es inalcanzable.
Inmediatamente después de que B y C reciben la noticia de que la ruta a la
estación N es inalcanzable, reenvían esta información. Con esto se consigue
que la estación D se entere de que la ruta a la estación N es inalcanzable
antes de su próxima actualización periódica, y se evita de esta forma la cuenta
a infinito.
Hasta el momento se ha enseñado las bases de los protocolos de
encaminamiento basados en vectores de distancia. Se han mostrados
diversos ejemplos donde en las rutas de encaminamiento se incluyen rutas
hacia diferentes máquinas. No obstante, en redes IP, las máquinas se
agrupan en redes. Conceptualmente, el proceso de encaminamiento es igual
al mostrado en los ejemplos del algoritmo del vector de distancia, pero se
incluye información de como llegar a una determinada red.
2.3 ESPECIFICACIONES DEL PROTOCOLO RIP
El Protocolo RIP tiene 2 versiones. La versión 1 descrita en el RFC
(Request For Comments) 1058, y la versión 2, descrita en el RFC 2453. En el
presente texto se describe primeramente el protocolo basándose en la versión
1. Finalmente, se dedica un apartado adicional para indicar las ampliaciones y
mejoras que aporta la versión 2 del protocolo.
Cada router que utilice RIP se entiende que tiene interfaces a una o más
redes del sistema. La métrica que se usa en RIP es el número de saltos y es
un número entero entre 1 y 15 inclusivos. Por defecto se utiliza una métrica de
27
1 por salto. Sin embargo, un administrador del sistema puede fijar la métrica
de cada red manualmente.
Cada entidad que usa RIP debe tener una tabla de encaminamiento. Esta
tabla de encaminamiento debe tener una entrada para cada destinación
posible en el sistema. Cada entrada contiene por lo menos la información
siguiente:
La dirección IP del destino o un rango de direcciones indicado mediante
dirección de red + máscara
-
La métrica, o número de saltos hasta alcanzar el destino
La dirección IP de la puerta de enlace siguiente. Si el destino está en una
de las redes directamente conectadas, este campo no será necesario.
Una bandera para indicar que la información sobre la ruta ha cambiado
recientemente.
-
Temporizadores de tiempo asociados a la ruta.
La dirección IP de destino, puede ser tanto una dirección IP de una
máquina como una dirección IP de una red o subred. Por tanto, en los
vectores de distancia que intercambian los routers se puede anunciar rutas
tanto de máquinas como de redes o subredes.
Inicialmente, las tablas de encaminamiento de cada router solo contienen
entradas a las redes que están directamente conectadas. Después, cada
router empieza a enviar vectores de distancia. Con los vectores de distancia
recibidos los routers aprenden rutas nuevas de sus vecinos que van
introduciendo en sus tablas de encaminamiento, siguiendo las pautas que
marca el algoritmo del vector de distancia descrito en el apartado anterior.
2.4 FORMATO DEL MENSAJE
RIP envía su información encapsulada en datagramas del protocolo UDP
(User Datagram Protocol). UDP es un protocolo del nivel de transporte para el
intercambio de datagramas. Permite el envío de datagramas a través de la red
sin que se haya establecido previamente una conexión, ya que el propio
datagrama incorpora suficiente información de direccionamiento en su
cabecera. Tampoco tiene confirmación, ni control de flujo, por lo que los
paquetes pueden adelantarse unos a otros, y tampoco se sabe si ha llegado
correctamente, ya que no hay confirmación de entrega o de recepción. Cada
router que usa RIP tiene un proceso de encaminamiento que envía y recibe
datagramas por el puerto 520 UDP. Por tanto, un datagrama RIP tendrá una
cabecera IP y una cabecera UDP.
28
Además RIP permite procesos ‘silenciosos’. Un proceso silencioso
normalmente no envía ningún mensaje. Sin embargo, escucha los mensajes
enviados por otros. Estos procesos son utilizados habitualmente por
ordenadores que no actúan como puertas de enlace, pero desean escuchar
los mensajes de encaminamiento para supervisar las puertas de enlace
locales y mantener sus tablas de encaminamiento actualizadas.
A continuación se muestra el formato que tienen los datagramas que se
utilizan en RIP versión 1 para enviar información de la red. Los tamaños de
campo están en octetos.
0
7
8
15 16
COMANDO (1)
VERSIÓN (1)
ADDRESS FAMILY IDENTIFIER
ADDRESS (4)
0 (4)
0 (4)
MÉTRICA (4)
31
0 (2)
0 (2)
Estos datagramas no son otra cosa que vectores de distancia. Cada
datagrama contiene un comando, un número de versión, y otros argumentos
referentes a una ruta. Cada datagrama puede contener hasta 25 rutas. Hay
campos que quedan con valor 0. Estos campos están pensados para
ampliaciones en futuras versiones del protocolo.
Si se tiene que enviar más de 25 entradas, se debe enviar en más de un
mensaje.
29
A continuación se describirá el formato de la versión 1 del protocolo. Los
comandos utilizados en esta versión son:
1 – Request: Una petición al sistema para enviar toda o parte de su tabla de
encaminamiento.
2 – Response: Mensaje que contiene toda o parte de la tabla de
encaminamiento del remitente. Este mensaje se puede enviar en respuesta a
una petición, o puede ser un mensaje de actualización generado por el
remitente.
3 – Traceon: Obsoleto. Los mensajes que contienen este comando deben ser
ignorados.
4 – Traceoff: Obsoleto. Los mensajes que contienen este comando deben ser
ignorados.
5 – Reserved: Este comando reservado es utilizado por Sun Microsystems
para propósitos suyos. Si se añaden nuevos comandos en alguna versión más
actual, deben comenzar por el 6. Los mensajes que contienen este comando
pueden ser ignorados si en las implementaciones utilizadas no esta definido.
Para Request y Response, el resto del datagrama contiene una lista de
destinaciones, con información sobre cada una. Cada entrada en esta lista
contiene:
Identificador de la familia: Específica el tipo de dirección de esa entrada.
En direcciones IP el identificador de la familia es 2.
Dirección: Dirección destino de la ruta.
Métrica: Número de saltos hasta llegar a la dirección de destino. Debe
ser un valor entre 1 y 16 inclusivos.
El tamaño máximo del datagrama es 512 octetos. Esto incluye solamente
las partes del datagrama descritos arriba. No tiene en cuenta las cabeceras
propias del IP o del UDP.
2.5 CONSIDERACIONES EN EL DIRECCIONAMIENTO
Los routers de una red RIP, intercambian mensajes de petición y de
respuesta para llevar a cabo el encaminamiento. Sin embargo, las
destinaciones que aparecen en estos mensajes pueden ser de redes, de
ordenadores, o una dirección por defecto (la dirección 0.0.0.0). Generalmente,
la información de encaminamiento de ordenadores individuales no es
necesaria. Si cada ordenador en una red o subred dada es accesible a través
de una puerta de enlace, entonces no es necesario considerar a estos en las
tablas de encaminamiento.
30
Fig. 20
En la Fig. 20 se muestran dos redes: La red 10.0.0.0 y la red 192.168.1.0.
Para que el ordenador A se pueda comunicar con la red 192.168.1.0 no es
necesario que almacene en su tabla de encaminamiento la ruta a cada uno de
los ordenadores de esta red, ya que todos estos son accesibles a través de la
puerta de enlace B, con dirección 10.0.0.2. Por lo tanto su tabla de
encaminamiento sería:
RED
10.0.0.0
192.168.1.0
GW
DC
10.0.0.2
Métrica
0
1
GW: Gateway
DC: Directamente conectado
Si se incluyen las rutas a los ordenadores individuales la tabla de
encaminamiento sería más complicada:
RED
10.0.0.0
192.168.1.0
192.168.1.2
192.168.1.3
192.168.1.4
GW
DC
10.0.0.2
10.0.0.2
10.0.0.2
10.0.0.2
Métrica
0
1
1
1
1
Claramente se puede ver que en este caso se puede resumir las rutas a
los ordenadores individuales por la ruta a la red.
Por tanto, los routers que utilizan RIP, al encaminar un datagrama, primero
deben comparar su dirección de destino con la lista de direcciones ya
aprendida, para ver si es posible emparejarla con una dirección de subred o
una red ya aprendida.
Cuando un router evalúa una destinación nueva que recibe, su
interpretación dependerá de si conoce o no la máscara de subred que se le
aplica. Si la conoce, es posible determinar que tipo de dirección es. Por
ejemplo, considérese que la red 128.6.0.0 tiene una máscara de subred de
255.255.255.0. Por tanto la dirección 128.6.0.0 es de red, la 128.6.4.0 es de
31
subred, y la 128.6.4.1 es una dirección de un ordenador en particular. Sin
embargo, si el router no sabe la máscara de subred, la interpretación de una
dirección puede ser ambigua. En este tipo de casos, se considera que estas
direcciones corresponden a direcciones de ordenador. Para evitar esta clase
de ambigüedad, no se debe enviar rutas de subred a otros vecinos que no
sepan la máscara apropiada. Por tanto, a menos que se hayan hecho las
provisiones especiales, las rutas a una subred no se deben enviar fuera de la
red de la cual forma parte dicha subred.
La dirección especial 0.0.0.0 es usada como la ruta por defecto. Esta
dirección se utiliza para agrupar todas aquellas direcciones que no se sabe
donde encaminarlas. Normalmente, es decisión del administrador la manera
de manejar este tipo de entrada.
2.6 TEMPORIZADORES
Para determinar la caducidad de una ruta es necesario el uso de
temporizadores. Cada router asocia tres temporizadores para cada ruta que
tiene almacenada:
- Tiempo de actualización cada 30 segundos. Cada vez que el temporizador
llega a 30 segundos se produce una actualización. El proceso de RIP
despierta y envía un mensaje de respuesta no solicitado con el vector de
distancia, a todos los routers vecinos.
- Tiempo de En cancelación a los 180 segundos. Una vez transcurridos 180
segundos sin recibir actualización de una ruta, se considera no válida. Sin
embargo la ruta se retiene un cierto periodo de tiempo, lo cual permite advertir
a los vecinos que la ruta ha sido eliminada.
- El temporizador del ‘recolector de basura’, a los 120 segundos. Una vez
transcurridos 120 segundos, después de que una ruta haya pasado al estado
‘En cancelación’, la ruta es definitivamente eliminada de la tabla de
encaminamiento. El nombre de este temporizador, ‘recolector de basura’,
viene del hecho que esta asociado a todas aquellas rutas residuales que se
deben ir borrando de la tabla de encaminamiento.
Por consiguiente, para que una ruta pase al estado ‘En Cancelación’
deben transcurrir 6 períodos de actualización sin recibir noticias de esta ruta, y
120 segundos más para que sea definitivamente eliminada.
32
Una ruta puede ser marcada como no válida por dos razones:
- El temporizador de ‘En cancelación’ expire.
- La métrica de la ruta es 16.
En cualquier caso, se sigue el siguiente proceso para cancelar una ruta:
- El temporizador de ‘recolector de basura’ se fija a 120 segundos.
- La métrica para la ruta se fija a 16 (infinito). Esto hace que la ruta sea
quitada del servicio.
- Se activa una bandera indicando que ha cambiado esta entrada. Esto implica
el envío inmediato del nuevo vector de distancia (Trigger Update).
Hasta que expira el contador de tiempo de ‘recolector de basura’, la ruta se
incluye en todas las actualizaciones enviadas, con una métrica de 16. Cuando
expira el contador, la ruta se suprime de la base de datos y no se incluye en
los vectores de distancia.
Si se encuentra una nueva ruta a esta red mientras el contador ‘recolector
de basura’ esta activo, la nueva ruta substituye la que está a punto de ser
suprimida, y el contador se desactiva.
2.7 PROCESO DE ENTRADA
El proceso de entrada del protocolo RIP se produce cuando un router que
utiliza este protocolo recibe un vector de distancia RIP, y consiste en el
procesamiento de este. Antes de procesar los vectores detalladamente, se
debe observar el formato de estos. Para ello se mira el campo ‘Versión’ en el
datagrama:
Versión 0:
Los datagramas con versión 0, son ignorados. Estos
corresponden a una versión anterior del protocolo, en la que el formato del
paquete era de una máquina específica.
Versión 1: Los datagramas se procesarán. Todos los campos que tienen que
ser 0 se comprueban. Si una de ellos no lo es, el mensaje entero se ignora.
Versión >1: Versiones futuras del protocolo, que pueden utilizar los campos
puestos a 0. Este es el caso de la versión 2 que veremos más adelante.
Después de comprobar la versión, el proceso dependerá del valor que
tenga el campo ‘Comando’.
33
2.7.1 COMANDO REQUEST
La petición (Request) se usa para recibir toda o parte de la tabla de
encaminamiento. Normalmente, se envía una petición broadcast por el puerto
UDP 520. En este caso, los ordenadores que participan de forma pasiva, es
decir, que solo están a la ‘escucha’ no responden a la petición. Sin embargo,
puede haber situaciones que interese que respondan también. En ese caso, la
petición se debe enviar por un puerto UDP que no sea el 520. Si la petición
viene de cualquier otro puerto, deben responder.
La petición es procesada entrada a entrada. Si no hay entradas, no se da
ninguna respuesta. Existe un caso especial. Si hay una sola entrada en la
petición, con un identificador de la familia de la dirección de 0 (que significa
sin especificar), y una métrica al infinito, es decir, a 16, esto es equivalente a
una petición de toda la tabla de encaminamiento.
0
7
1 (Request)
8
15
16
VERSIÓN
0
31
0
0
0
0
0
16 (Metrica)
Este tipo de mensaje suele ser enviado por routers que acaban de ser
reiniciados o routers que se ponen en funcionamiento por primera vez. A
excepción de este caso especial, el proceso es muy simple. Para cada
entrada, se mira la destinación en la base de datos de encaminamiento. Si
hay una ruta, poner la métrica de esa ruta en el campo métrica
correspondiente del datagrama. Si no hay ruta para esa destinación
especificada, poner a infinito, es decir, 16, en el campo métrica. Una vez que
se hayan completado todas las entradas, poner el comando en respuesta, es
decir comando a valor 2, y enviar el datagrama nuevo por el puerto por el cual
vino.
Si la petición es de la tabla completa, se hace el proceso normal con horizonte
dividido. Por tanto ciertas entradas de la tabla de encaminamiento no serán
mostradas. En cambio, si la petición es de un número específico de entradas,
se enviarán las pedidas, pero no se aplicara el proceso de horizonte dividido.
Normalmente esto último se utiliza para hacer diagnósticos.
2.7.2 Comando Response
Para generar un mensaje de respuesta el campo comando del mensaje
debe ser 2. Las respuestas se pueden recibir por varias razones:
- Respuesta a una consulta específica
- Una actualización regular
- Accionados por un cambio en la métrica
34
Indiferentemente de cómo fueron generadas las respuestas, el proceso a
seguir es el mismo.
Como el proceso de respuesta puede actualizar la tabla de
encaminamiento de un router, es importante comprobar que el mensaje de
respuesta sea válido. La respuesta debe ser ignorada si viene por otro puerto
que no sea el 520. La dirección IP de la respuesta se debe comprobar para
que sea de un vecino válido.
Una vez el datagrama es considerado válido, se procesan las entradas una
a una. Mirar la dirección de destino. Comprobar el identificador de la familia de
la dirección. Si no es un valor esperado, por ejemplo direcciones IP, ignorar la
entrada. También se tiene que comprobar que las direcciones no sean de la
clase D o E, o si es la 127 ‘loopback’ o de ‘localhost’. Comprobar que la
versión sea coherente con los campos a 0 que debe llevar.
Cuando el mensaje de respuesta recibido tiene el formato correcto según
las comprobaciones anteriores, se cotejan las rutas recibidas por las ya
aprendidas. Primeramente se mira si la ruta esta o no en la tabla de
encaminamiento. En caso de que no este, generalmente se agregará una
entrada nueva. Sin embargo, hay varias excepciones. Si la métrica es infinita,
no se agregará la entrada. Se debe evitar agregar rutas a ordenadores si son
parte de una red o subred para la cual ya se tiene entrada buena. En
cualquier otro caso, se agregará una nueva entrada a la base de datos de
encaminamiento. Esto incluye las acciones siguientes:
-
Insertar la destinación y la métrica.
-
Insertar la puerta de enlace.
Inicializar el temporizador de caducidad de la ruta. Si el temporizador
‘recolector de basura’ está funcionando en esa ruta, pararlo.
Activar la bandera de cambio de ruta, y señalar el proceso de salida para
provocar una actualización.
Si hay una ruta ya existente, primero se tiene que comparar las puertas de
enlace. Si es la misma, se inicializa el temporizador de caducidad. Después se
compara la métrica. Si la métrica es más baja:
Se actualiza la ruta por la del datagrama, Es decir, se pone la nueva
métrica y la puerta de enlace nueva.
-
Inicializar el temporizador.
Activar la bandera de cambio de ruta, y señalar el proceso de salida para
provocar una actualización.
Si la métrica nueva es 16, se inicia el proceso para suprimir la ruta. La ruta
se utilizará solo para los paquetes de encaminamiento, y se inicializa el
35
temporizador de cancelación. Observar que una cancelación se produce solo
cuando la métrica se pone por primera vez en 16. Si la métrica era ya 16, una
futura cancelación será ignorada.
Si la métrica nueva es igual que la vieja, lo más simple es no hacer nada,
solo se inicializa el temporizador de caducidad.
Cualquier entrada se ignora en el caso que fallen las comprobaciones,
pues esta es considerada peor que la ruta actual.
2.8 Proceso de salida
En este apartado se detalla el proceso usado para crear los mensajes de
respuesta que contienen toda o parte de una tabla de encaminamiento. Este
proceso puede ser accionado por varios motivos:
Debido a una petición. En este caso, el mensaje solo se envía a una
destinación.
Por una actualización regular. Cada 30 segundos, la tabla entera se
envía a los vecinos.
Debido a actualizaciones accionadas. Siempre que la métrica de una ruta
cambia, se acciona una actualización.
Cuando una respuesta se tiene que enviar a todas las destinaciones, es
decir, la actualización regular o una actualización accionada, se envía un
mensaje broadcast a todas las redes conectadas. En la mayoría de los casos
esto equivale a todas las puertas de enlace vecinas. Sin embargo, hay
algunos casos donde esto no es bueno, ya que puede llegar a redes que no
interesa que lleguen mensajes de encaminamiento. Si este es el caso, se
debería crear una lista real de los vecinos, y enviar un datagrama a cada uno
explícitamente. Este mecanismo es definido por cada implementador.
Las actualizaciones accionadas pueden causar cargas excesivas en redes
con capacidad limitada o con muchas puertas de enlace. Por consiguiente, el
protocolo requiere que se incluyan provisiones para limitar la frecuencia de
actualizaciones accionadas. Las actualizaciones accionadas se pueden anular
si coincide al mismo tiempo con la actualización regular.
Las actualizaciones accionadas no necesitan incluir la tabla de
encaminamiento entera. Solo las rutas que han cambiado. Más
concretamente, en los mensajes generados se incluirán las rutas que tengan
la bandera de cambio activada. Cuando se hacen actualizaciones accionadas
o normales se usa el horizonte dividido. Una vez se hayan hecho las
actualizaciones accionadas, las banderas de cambio se deben desactivar.
La única diferencia entre una actualización accionada y otros mensajes de
actualización es la posible omisión de las rutas que no han cambiado. El resto
de los mecanismos son similares.
36
A continuación se detalla como se genera un datagrama de respuesta para
una red directamente conectada en particular:
La dirección IP origen debe ser la del ordenador que envía la actualización.
Esto es importante porque esta dirección se pone en las tablas de
encaminamiento de otros routers. Si se utiliza una dirección incorrecta, otros
routers pueden no encaminar bien los datagramas.
Poner el número de la versión RIP. Poner el comando en respuesta. Poner los
campos que deben ser cero, a cero. Ahora se van completando las entradas.
El tamaño máximo del datagrama es 512 octetos. Cuando no hay
suficiente espacio hay que enviar dos datagramas.
Las rutas se deben incluir en el datagrama aunque sus métricas sean
infinitas. Si la puerta de enlace de una ruta está en la red para la cual esta
destinado el datagrama, la métrica se pone a 16, o se quita la entrada entera.
Ignorar las entradas según horizonte dividido con retorno envenenado.
2.9 EJEMPLO RIP
A modo de ejemplo y para retener los procedimientos vistos anteriormente
que usa el protocolo RIP, se propone un ejemplo de una red RIP, ilustrado en
la Fig. 21.
Fig. 21
Se trata de un conjunto de 4 redes y 3 routers dispuestos en serie. Cada
router tiene dos interfaces y se han asignado direcciones IP respetando la
singularidad en la red.
Inicialmente los routers tienen en sus tablas de encaminamiento las redes
a las que están directamente conectadas. Cada 30 segundos, los routers
envían sus tablas por sus interfaces a todos sus vecinos. Para ello utilizan la
dirección de broadcast.
Router A
Destino
Máscara
Gateway IF
Métrica
192.168.0.0 255.255.255.0 0.0.0.0
eth0 0
192.168.1.0 255.255.255.0 0.0.0.0
eth1 0
37
Router B
Métrica
Destino
Máscara
Gateway IF
192.168.1.0 255.255.255.0 0.0.0.0
eth0 0
192.168.2.0 255.255.255.0 0.0.0.0
eth1 0
Router C
Destino
Máscara
Gateway IF
Métrica
192.168.2.0 255.255.255.0 0.0.0.0
eth0 0
192.168.3.0 255.255.255.0 0.0.0.0
eth1 0
Supóngase que los routers acaban de encenderse. En este caso, envían
un mensaje de petición de la tabla de encaminamiento a sus vecinos. El
formato de este mensaje es de una sola entrada, con un identificador de la
familia de la dirección de 0 y una métrica al infinito, es decir, a 16.
0
7 8
1 (Request)
0 (Cero)
15
16
1 (Versión)
31
0
0
0
0
0
16 (Métrica)
Supóngase que el router B recibe una petición de la tabla del router A. El
router B construye su vector de distancia y lo envía al router A. El router A
recibirá el siguiente datagrama:
0
7
2 (Response)
8
15
16
1 (Versión)
31
0
0
2
192.168.2.0
0
0
1 (Métrica)
Como se puede observar, en el datagrama enviado, no se incluye la ruta a
la red 192.168.1.0. ya que se esta utilizando ‘horizonte dividido’.
El router A actualiza su tabla de encaminamiento:
Router A
Destino
192.168.0.0
192.168.1.0
192.168.2.0
Máscara
255.255.255.0
255.255.255.0
255.255.255.0
Gateway
0.0.0.0
0.0.0.0
192.168.1.2
IF
eth0
eth1
eth1
Métrica
0
0
1
38
De forma similar el resto de routers del sistema también aprenderán las rutas.
Router B
Destino
192.168.1.0
192.168.2.0
192.168.3.0
192.168.0.0
Máscara
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Gateway
0.0.0.0
0.0.0.0
192.168.2.2
192.168.1.1
IF
eth0
eth1
eth1
eth0
Métrica
0
0
1
1
Máscara
255.255.255.0
255.255.255.0
255.255.255.0
Gateway
0.0.0.0
0.0.0.0
192.168.2.2
IF
eth0
eth1
eth0
Métrica
0
0
1
Router C
Destino
192.168.2.0
192.168.3.0
192.168.1.0
Debido a las ‘Trigger Updates’, cuando se realiza un cambio en la tabla de
encaminamiento de cada router se genera automáticamente una
actualización.
Router A
Destino
192.168.0.0
192.168.1.0
192.168.2.0
192.168.2.0
Máscara
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Gateway
0.0.0.0
0.0.0.0
192.168.1.2
192.168.1.2
IF
eth0
eth1
eth1
eth1
Métrica
0
0
1
2
Máscara
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Gateway
0.0.0.0
0.0.0.0
192.168.2.2
192.168.1.1
IF
eth0
eth1
eth1
eth0
Métrica
0
0
1
1
Máscara
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Gateway
0.0.0.0
0.0.0.0
192.168.2.2
192.168.2.2
IF
eth0
eth1
eth0
eth0
Métrica
0
0
1
2
Router B
Destino
192.168.1.0
192.168.2.0
192.168.3.0
192.168.0.0
Router C
Destino
192.168.2.0
192.168.3.0
192.168.1.0
192.168.0.0
Con esto, los routers aprenden todas las rutas del sistema, y la red llega a
su equilibrio con rapidez.
39
2.10 RIP VERSION 2
En este apartado se pretende describir las mejoras que ofrece RIP v2
respecto a su versión anterior.
2.10.1
FORMATO MENSAJE RIP VERSION 2
RIP v2 también usa el puerto 520 UDP para enviar y recibir datagramas. El
formato de RIP v2 permite que los routers compartan información adicional
importante. La cabecera del mensaje es el mismo para los RIP v1 y los RIP
v2. En cambio el resto del mensaje cambia sustancialmente:
0
7 8
15 16
COMANDO (1)
VERSIÓN (1)
0 (2)
ADDRESS FAMILY IDENTIFIER
ETIQUETA DE RUTA (2)
CABECERA EXTRA (20)
IP ADDRESS (4)
MÁSCARA DE SUBRED (4)
SIGUIENTE SALTO (4)
MÉTRICA (4)
31
Para especificar que se trata de RIP v2 se pone el número 2 en el campo
versión. Campos que en la versión 1 del protocolo se dejaban a 0, ahora en la
versión 2 se utilizan. Los campos añadidos son:
- Etiqueta de ruta:
El campo de etiqueta de ruta proporciona un método para separar las rutas
‘internas’ de RIP, es decir, rutas para las redes dentro del dominio de
encaminamiento RIP, y las rutas ‘externas’ de RIP, aprendidas por un EGP o
de otro IGP.
Los routers que utilizan otros protocolos a parte de RIP se deben
configurar con la etiqueta de ruta para importar rutas de otras fuentes. Las
rutas importadas de un EGP deben marcarse con una etiqueta fijada
arbitrariamente.
Serían posibles otras aplicaciones a la etiqueta de ruta, mientras todos los
routers del dominio RIP las usen.
- Cabecera extra para autenticación:
En la versión dos, el protocolo tiene una nueva funcionalidad de
autentificación. RIP utiliza una entrada completa para realizar esta función. Si
el identificador de la familia de la dirección de la primera y solamente de la
primera entrada de un mensaje es 0xFFFF, el resto de la entrada contiene
información de autentificación. Esto significa que como máximo habrá 24
entradas RIP en el resto del mensaje. Si no usamos autentificación en un
mensaje, la secuencia 0xFFFF no debe aparecer en ningún identificador de la
familia de dirección en ninguna entrada. Un mensaje con autentificación
comenzaría como sigue:
40
0
7 8
15
COMANDO (1)
VERSIÓN (1)
0XFFFF
16
31
SIN USO (2)
TIPO DE AUTENTIFICACIÓN (2)
AUTENTIFICACIÓN (16)
Actualmente, el único tipo de autentificación es una contraseña simple y
corresponde al tipo 2. Los 16 octetos contienen la contraseña en texto plano.
Si la contraseña ocupa menos de 16 octetos, se rellena con ceros a la
izquierda.
Si un router no se configura para autentificar mensajes RIP v2, los
mensajes RIP v1 y los RIP v2 no autentificados serán aceptados. Los
mensajes RIP v2 autentificados serán rechazados. Si el router se configura
para autentificar mensajes RIP v2, los mensajes RIP v1 y los RIP v2 que
pasen la autentificación serán aceptados. Los no autentificados y los
mensajes no válidos de RIP v2 serán rechazados. Para una seguridad
máxima, los mensajes RIP v1 deben ser ignorados cuando se esta
autentificando, si no, la información de encaminamiento de mensajes
autentificados sería propagada por routers RIP v1 de forma no autentificada.
Como los mensajes que utilizan autentificación están marcados con una
familia de dirección 0xFFFF, un sistema RIP v1 ignoraría este mensaje.
- Máscara de Subred:
El campo de máscara de subred contiene la máscara de subred que se
aplica a la dirección IP. Si este campo es cero, entonces quiere decir que no
se ha incluido la máscara para esa entrada.
En un interfaz donde un router RIP v1 puede oír la información de otro RIP
v2 las reglas que se aplican son las siguientes:
- La información interna de una red nunca debe ser anunciada en otra red.
- La información sobre una subred en particular no se puede anunciar donde
los routers son RIP v1, donde se puede considerar una ruta de host.
- Siguiente salto:
Es la siguiente dirección IP a la cual deben ser enviados los paquetes de
una ruta. Un valor de 0.0.0.0 en este campo indica que el siguiente salto es
vía el autor del anuncio RIP. Una dirección de salto siguiente, forzosamente,
debe ser accesible directamente.
El propósito de este campo es eliminar los paquetes que son encaminados
a través de saltos adicionales del sistema. Es especialmente útil para redes
donde RIP no esta funcionando en todos los routers.
41
Fig. 22
En la Fig. 22, se muestra un ejemplo de aplicación del campo ‘Siguiente
salto’. En este ejemplo se están usando dos protocolos de encaminamiento
diferentes. Por una parte se esta utilizando RIPv2, y por otra, se esta
utilizando el protocolo OSPF. Como A y C utilizan un protocolo de
encaminamiento diferente no se entienden y entonces A no puede aprender
nuevas rutas a través de C. Por tanto todas las rutas las debe aprender a
través de B. No obstante, B puede utilizar el campo ‘Siguiente salto’ para
indicar al router A que reencamine directamente sus paquetes al router C, y
de esta forma conseguir un encaminamiento más óptimo.
Obsérvese que el salto siguiente es un campo de consulta. Es decir, si se
ignora la información proporcionada, se puede encaminar pero es posible que
no de la forma óptima. Si el salto siguiente recibido no es directamente
accesible, debe ser tratado como 0.0.0.0.
2.10.2 CONSIDERACIONES Y COMPATIBILIDADES
Para reducir la carga innecesaria, se usa una dirección multicast en las
actualizaciones periódicas. La dirección multicast es 224.0.0.9.
Si un router RIP v2 recibe una petición RIP v1, debe responder con una
respuesta RIP v1. Si el router se configura para enviar solamente mensajes
RIP v2, no debe responder la petición de RIP v1.
La versión 1 del protocolo específica que los mensajes RIP de la versión 0
son ignorados, que las de versión 1 son ignorados cuando se encuentre un
campo definido como 0 y es diferente a cero, y que los mensajes RIP de
versión mayor a 1 no deben ser descartados si no se encuentra un campo
definido como 0 con valor diferente de cero. Por tanto la versión 2 de RIP es
totalmente compatible con la versión antigua.
Un router compatible es necesario por dos razones. Primero, en
implementaciones de RIP v1 no se siguen algunas reglas propias de RIP v2.
En segundo lugar, el uso de multicasting evitaría que los sistemas RIP v1
recibieran las actualizaciones RIP v2. Por consiguiente un router debe ser
configurado interfaz a interfaz según corresponda.
Un router tiene cuatro configuraciones:
42
-
RIP v1, en el cual solamente se envían los mensajes RIP v1
Compatibilidad RIP v1, en el cual los mensajes RIP v2 son broadcast.
RIP v2, en el cual los mensajes RIP v2 son multicast
‘Ninguno’, que inhabilita enviar mensajes RIP.
Se recomienda fijar por defecto RIP v1 o RIP v2, pero nunca
Compatibilidad RIP v1. Esto es así debido a los problemas potenciales que
pueden ocurrir en algunas topologías.
Los routers deben también configurarse, para aceptar RIP v1 solamente,
RIP v2 solamente, o ninguno. Debe configurarse por interfaz. Se recomienda
que por defecto se escoja el elegido para enviar actualizaciones.
Como los paquetes de la versión 1 no contienen información de subred, la
semántica empleada por los routers en las redes que contienen la versión 1 y
las redes de la versión 2 se debe limitar al de la versión 1.
2.11 LIMITACIONES DEL PROTOCOLO
El protocolo RIP no soluciona todos los problemas del encaminamiento.
Según lo mencionado en la introducción, está previsto para el uso como IGP,
en redes razonablemente homogéneas y de tamaño moderado. A
continuación se enumeran algunas limitaciones específicas del protocolo:
El protocolo esta limitado para redes que no superen los 15 saltos en sus
rutas. Los diseñadores pensaron que el diseño básico del protocolo era
inapropiado para redes más grandes. Nótese que este límite asume un coste
unitario para cada salto. Esta es la manera que RIP se configura
normalmente. Si el administrador del sistema elige utilizar costes más
grandes, el límite superior de 15 puede convertirse en un problema.
Otro limitación es la ‘cuenta al infinito’ en ciertas situaciones inusuales. Si
en un sistema, una ruta de encaminamiento implicará a todos los routers, la
resolución de la ruta requeriría mucho tiempo (si la frecuencia de las
actualizaciones de la información de encaminamiento es limitada) o ancho de
banda (si las actualizaciones fueran enviadas siempre que los cambios fueran
detectados). Tal ruta consumiría una cantidad grande de ancho de banda de
la red antes de que la ruta fuera corregida. Creemos que en casos realistas,
esto no será un problema excepto en líneas lentas. Incluso entonces, el
problema será bastante inusual, puesto que se toman varias precauciones
para prevenir estos problemas.
Este protocolo usa ‘métrica’ fija para comparar rutas alternativas. Esto no
es apropiado para situaciones donde se requiere un servicio a tiempo real,
fiabilidad, o balanceo de carga.
43
Hasta aquí llega la descripción del protocolo RIP. En el siguiente bloque se
presenta el diseño de ataque utilizado para vulnerar la seguridad del
protocolo, y provocar de esta forma una denegación del servicio en una red
cualquiera.
44
3. DISEÑO DE ATAQUE
3.1 INTRODUCCIÓN
Una vez se tienen todos los detalles del funcionamiento del protocolo RIP,
descritos en el apartado anterior, ya se está en condiciones para iniciar el
diseño de una estrategia para provocar una denegación de servicio en una
red conmutada que utilice este protocolo para enrutar.
Se parte de la idea de que se dispone de una entidad o PC, dentro de la
red, la cual se controla completamente. La red podrá ser cualquier topología
posible, por lo tanto, se debe determinar cuando será posible y cuando no una
denegación de servicio utilizando la estrategia de ataque que se define en
este apartado.
La definición de la estrategia de ataque presentada en este apartado es
teórica. Esto quiere decir que hace falta una puesta a la práctica para
confirmar el correcto funcionamiento.
3.2 CONOCIMIENTO DE LA RED
La primera condición para realizar un buen ataque, es conocer la red a la
que se esta atacando. No obstante, se ha mencionado como premisa que la
red atacada puede presentar cualquier topología. Por tanto se debe buscar un
mecanismo que permita conocer la red, sea cual sea la topología de la misma.
Supóngase que tenemos control de una entidad dentro de una red
cualquiera donde se utiliza el protocolo RIP. Si se actuara como un sistema
silencioso o pasivo, es decir, sin participar en las actualizaciones de las tablas,
llegarían actualizaciones de los vecinos por lo menos cada 30 segundos. Por
consiguiente, el primer paso para realizar el ataque será aprender de los
vecinos el estado de la red. Y que mejor forma para conocer el estado de la
red que realizando una petición de vector de distancia directamente a los
routers que se encuentran en nuestro segmento de red.
Como ya se vio en la definición del protocolo, para realizar una petición de
toda la tabla se construye un datagrama con el campo comando ‘01’, y una
sola entrada. El identificador de la familia de esta entrada será 0 (sin
especificar), y con métrica 16.
0
7
8
01
15
16
VERSIÓN (1)
0
31
0 (2)
0 (2)
IP ADDRESS (4)
0 (4)
0 (4)
16
45
Si se encuentran routers conectados directamente a nuestra entidad
controlada, se recibirá como mínimo un vector de encaminamiento de cada
uno.
3.3 MENSAJERIA FALSA
Gracias a la información recibida por la petición de las tablas de
encaminamiento la entidad controlada tendrá conocimiento de las LANs que
hay interconectadas en el sistema que tiene que atacar.
Para provocar una denegación de servicio en una red, hay que provocar
que los routers de la red no reencaminen bien los datos. Para conseguir esto,
se debe conseguir que las tablas de encaminamiento de los routers no sean
correctas, es decir, las rutas no sean las adecuadas para encaminar.
El parámetro métrica es el utilizado para determinar si una ruta es mejor
que otra, y por tanto, es el parámetro que utilizan los routers para actualizar
sus rutas, el parámetro que es capaz de cambiar una ruta de las tablas de
encaminamiento. Aprovecharemos este aspecto para modificar las tablas de
encaminamiento de los routers de forma fraudulenta.
Por consiguiente, la entidad controlada tiene que ser capaz de forzar a los
routers de la red a reencaminar mal los datos. Para ello, puede enviar
vectores de distancia con métricas falsas, especialmente escogidas, que
hagan cambiar las rutas que estos tienen almacenadas en sus tablas de
encaminamiento.
Fig. 23
Supóngase que el ordenador A de la Fig. 23 es la entidad controlada
dentro de un sistema RIP. El ordenador B presentaría la siguiente tabla de
encaminamiento:
Destino
1.0.0.0
2.0.0.0
3.0.0.0
4.0.0.0
5.0.0.0
6.0.0.0
Máscara
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
Gateway
0.0.0.0
0.0.0.0
2.0.0.2
2.0.0.2
2.0.0.2
2.0.0.2
IF
eth0
eth1
eth1
eth1
eth1
eth1
Métrica
0
0
1
2
3
4
46
Con el fin de cambiar las tablas de encaminamiento del ordenador B, la
entidad controlada A debe proporcionar rutas mejores a las que tiene B
almacenadas. Para proporcionar una ruta mejor debe tener una métrica
menor. La menor métrica permitida en el protocolo RIP es 1. Por tanto, la
entidad controlada debe construir un vector falso de actualización con las
métricas a 1:
0
7
8
02
15
16
VERSIÓN (1)
2
31
0 (2)
0 (2)
1.0.0.0
0 (4)
0 (4)
1
2
0 (2)
2.0.0.0
0 (4)
0 (4)
1
2
0 (2)
3.0.0.0
0 (4)
0 (4)
1
2
0 (2)
4.0.0.0
0 (4)
0 (4)
1
2
0 (2)
5.0.0.0
0 (4)
0 (4)
1
2
0 (2)
6.0.0.0
0 (4)
0 (4)
1
Cuando el ordenador B reciba este vector, mirará si hay alguna ruta mejor
que las que tiene almacenadas en su tabla de encaminamiento. En este caso,
encontrará que la ruta a la red 4.0.0.0 es mejor, ya que la entidad controlada
le esta proporcionando una alternativa con métrica 1 y el ordenador B tiene
esta ruta con métrica 2. Por tanto el ordenador B actualizara su tabla de
encaminamiento. Por el mismo motivo, la ruta a la red 5.0.0.0 y la red 6.0.0.0
también cambiaran:
47
Destino
1.0.0.0
2.0.0.0
3.0.0.0
4.0.0.0
5.0.0.0
6.0.0.0
Máscara
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
Gateway
0.0.0.0
0.0.0.0
2.0.0.2
1.0.0.1
1.0.0.1
1.0.0.1
IF
eth0
eth1
eth1
eth0
eth0
eth0
Métrica
0
0
1
1
1
1
A partir de este momento los datos que el ordenador B quiera enviar a la
red 4.0.0.0 a la red 5.0.0.0 o a la red 6.0.0.0, los enviará por su interfaz eth0
vía 1.0.0.1, y como es de esperar, los datos no llegarán nunca, es decir, se ha
provocado una denegación de servicio entre el ordenador B y la red 4.0.0.0,
5.0.0.0 y 6.0.0.0. A efectos de B la topología de red es como la de la Fig. 24:
Fig. 24
El ordenador B no ha actualizado más rutas porque las alternativas que le
daba la entidad controlada A eran a igual de condiciones o peores. Por tanto,
por ahora se puede concluir que es posible provocar una denegación a los
vecinos de la entidad controlada enviando métricas 1, pero solo en las redes
que se encuentren como mínimo a dos saltos de los ordenadores atacados.
3.4 EXPANSIÓN DE LA MENSAJERIA FALSA
Como ya se vio anteriormente, el protocolo RIP implementa ‘Triggered
Update’. Esta técnica consiste en enviar actualizaciones inmediatamente
después de sufrir un cambio de rutas. En el caso que nos ocupa en el ejemplo
anterior, cuando el ordenador B sufre un cambio de sus rutas informará a sus
vecinos de dichos cambios:
Fig. 25
48
Como el protocolo también implementa horizonte dividido solo enviara la
actualización a su ordenador vecino C. Las rutas que cambiaron en el
ordenador B eran las rutas con destinación a la red 4.0.0.0, a la red 5.0.0.0, y
a la red 6.0.0.0. Con la actualización enviada, C recibirá estas tres rutas
nuevas con métrica 2. Antes de la actualización C tenía la siguiente tabla de
encaminamiento:
Destino
1.0.0.0
2.0.0.0
3.0.0.0
4.0.0.0
5.0.0.0
6.0.0.0
Máscara
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
Gateway
2.0.0.1
0.0.0.0
0.0.0.0
3.0.0.2
3.0.0.2
3.0.0.2
IF
eth0
eth0
eth1
eth1
eth1
eth1
Métrica
1
0
0
1
2
3
El ordenador C compara sus rutas almacenadas con las rutas recibidas en
la actualización, y realiza los cambios cuando encuentra una ruta mejor:
Destino
1.0.0.0
2.0.0.0
3.0.0.0
4.0.0.0
5.0.0.0
6.0.0.0
Máscara
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
Gateway
2.0.0.1
0.0.0.0
0.0.0.0
3.0.0.2
3.0.0.2
2.0.0.1
IF
eth0
eth0
eth1
eth1
eth1
eth0
Métrica
1
0
0
1
2
2
Como era de esperar el ordenador C ha cambiado su ruta a la red 6.0.0.0
puesto que el ordenador B le ofrecía una alternativa mejor, aunque falsa, ya
que esta información ha sido transmitida mediante el ataque iniciado por la
entidad controlada A. En este caso se provoca una denegación de servicio
entre el ordenador C y la red 6.0.0.0. El resto de rutas no se han visto
afectadas, ya que el ordenador B no puede ofrecer una ruta mejor al
ordenador atacado C.
Con este ejemplo, se puede concluir que los mensajes falsos enviados por
una entidad controlada dentro de un sistema RIP se extenderán por la red y
pueden provocar cambios en las rutas y por tanto denegación del servicio,
siempre y cuando la ruta que ofrece el vecino sea mejor que la ruta que tiene
almacenada el ordenador atacado en cada caso.
3.5 PROVOCAR CANCELACIÓN DE RUTAS
Como se vio anteriormente en la definición del protocolo, el proceso de
cancelación de una ruta se puede dar en los siguientes casos:
-
No se recibe actualización de una ruta y esta caduca
Se recibe una actualización de la ruta con métrica 16.
49
Si se recibe un vector de distancia cuyas rutas tienen métrica 16 se inicia
el proceso de cancelación de las rutas, y estas no son utilizadas por la tabla
de encaminamiento hasta que se consiga una ruta alternativa.
Retómese el ejemplo de la Fig. 23. La tabla de encaminamiento de B seria:
Destino
1.0.0.0
2.0.0.0
3.0.0.0
4.0.0.0
5.0.0.0
6.0.0.0
Máscara
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
255.0.0.0
Gateway
0.0.0.0
0.0.0.0
2.0.0.2
2.0.0.2
2.0.0.2
2.0.0.2
IF
eth0
eth1
eth1
eth1
eth1
eth1
Métrica
0
0
1
2
3
4
Supóngase que el ordenador controlado A envía un vector cuyas rutas
tienen métrica 16 al ordenador B:
0
7
8
02
15
16
VERSIÓN (1)
2
31
0 (2)
0 (2)
1.0.0.0
0 (4)
0 (4)
16
2
0 (2)
2.0.0.0
0 (4)
0 (4)
16
2
0 (2)
3.0.0.0
0 (4)
0 (4)
16
2
0 (2)
4.0.0.0
0 (4)
0 (4)
16
2
0 (2)
5.0.0.0
0 (4)
0 (4)
1
2
0 (2)
6.0.0.0
0 (4)
0 (4)
16
Debido a este vector, el ordenador B iniciaría el proceso de cancelación de
las rutas:
50
Destino Máscara Gateway IF
Métrica
1.0.0.0 255.0.0.0 0.0.0.0
eth0 0
2.0.0.0 255.0.0.0 0.0.0.0
eth1 0
Por tanto las rutas desaparecen de la tabla de encaminamiento hasta que
se encuentra una alternativa. Se ha provocado una denegación de servicio
entre el ordenador B y las redes 3.0.0.0, 4.0.0.0, 5.0.0.0 y 6.0.0.0.
Se puede ver, que enviando vectores con métrica 16 es posible provocar
una denegación de servicio entre un vecino y una red, siempre y cuando la
red no este directamente conectada a este vecino.
La expansión de la mensajería falsa sería similar a la descrita en el
apartado anterior.
3.6 PERSISTENCIA
Hasta el momento se ha visto que es posible realizar una denegación de
servicio enviando mensajería falsa, y provocando la actualización de las tablas
de encaminamiento de nuestros vecinos.
No obstante, para conservar la denegación de servicio es necesario enviar
mensajes falsos periódicamente. Esto es así, ya que en RIP las rutas tienen
una caducidad. Por tanto, para conservar la denegación de servicio, la entidad
controlada dentro del sistema RIP debe enviar mensajeria falsa
periodicamente.
51
4. DESARROLLO
4.1 INTRODUCCION
Tomando como punto de partida la estrategia de ataque definida en el
bloque anterior, ha llegado la hora de implementar una aplicación que ayude a
demostrar la base teórica de la estrategia de ataque, y provoque una
denegación de servicio en una red RIP.
Como lenguaje de programación se ha escogido Java. Para ello se ha
instalado un kit de desarrollo y el programa IDE NetBeans como apoyo. El kit
de desarrollo java utilizado es el ‘JAVA 2 SDK’ en su versión 1.3.1. Java 2
SDK incluye herramientas útiles para desarrollar y probar programas escritos
en el lenguaje de programación Java y que se ejecutan en la plataforma Java.
Estas herramientas están diseñadas para que se utilicen desde la línea de
comandos. Para desarrollar de una manera más cómoda se ha utilizado el
programa Netbeans. NetBeans es una plataforma para el desarrollo de
aplicaciones usando Java y un Entorno integrado de desarrollo (IDE)
desarrollado por la Plataforma NetBeans.
Para simplificar la implementación se ha considerado que la entidad
controlada dentro del sistema RIP tiene una única interfaz. Esto es así porque
se entiende que la entidad controlada será un ordenador personal.
La aplicación dispone, por una parte, de una interfaz gráfica donde se
informa de los eventos y de los posibles errores, y por otra parte, la lógica que
trata los datagramas o paquetes de datos RIP que se reciben y se envían a la
red atacada. Recuérdese que el protocolo RIP utiliza el puerto UDP 520. Por
lo tanto, para recibir y enviar datagramas se utilizan ‘sockets’ UDP
configurados en el puerto 520. Este puerto es posible que este ocupado por
alguna otra aplicación a la hora de ejecutar la aplicación. Si es así, se debe
‘matar’ el proceso para dejar libre el puerto 520.
4.2 ANÁLISIS FUNCIONAL
En este apartado se describen los aspectos funcionales que reúne la
aplicación de ataque al protocolo RIP.
Infraestructura Técnica: La aplicación de ataque al protocolo RIP esta
programada íntegramente en JAVA.
Definición funcional: La aplicación debe provocar una denegación de servicio
enviando mensajería RIP falsa de forma persistente. Las entradas a la
aplicación serán la versión RIP utilizada (RIPv1 o RIPv2) y la métrica falsa
utilizada (métrica 1 o métrica 16). El programa mostrará los resultados que va
obteniendo del ataque por pantalla.
52
RIPv1 / RIPv2: Según la versión escogida por el usuario, la forma de enviar
los datagramas cambia. En el caso de RIP versión 1, se utilizará la dirección
broadcast. En cambio, si se utiliza RIP versión 2, se utilizará la dirección
multicast (224.0.0.9). Por otra parte se debe tener en cuenta el formato de los
mensajes descritos en la definición del protocolo según la versión escogida.
Interfaz gráfica: La interfaz gráfica es el mecanismo que se utiliza para
interactuar con el usuario de la aplicación. Consta de dos botones: Uno para
iniciar el ataque: ‘Conectar’ y otro para pararlo: ‘Stop’. Además el usuario
puede escoger que tipo de ataque quiere realizar: vectores con métrica 1, o
vectores con métrica 16, y si la red a la que quiere atacar utiliza RIPv1 o
RIPv2. También dispone de una pantalla donde se informa de los eventos que
se suceden en el transcurso del ataque o posibles errores que puedan
ocasionarse.
La elección de la versión RIP, así como el tipo de ataque que se desea
realizar se escogen mediante listas desplegables.
Fig. 26
Es posible realizar cualquier tipo de configuración:
RIP1
RIP2
Ataque Métrica 0
RIP1 + Ataque Métrica 1
RIP2 + Ataque Métrica 1
Ataque Métrica 16
RIP1 + Ataque Métrica 16
RIP2 + Ataque Métrica 16
En la pantalla se informa, mediante mensajes, de todos los eventos que se
produzcan a lo largo del ataque. En todos los mensajes se incluye la hora. La
pantalla también sirve para informar de posibles fallos o errores y que
opciones tiene el usuario para solventarlos.
A continuación se muestra un esquema de la interacción entre el usuario y
la aplicación:
53
Fig. 27
El programa finaliza cuando se produce un error o cuando el usuario
presiona el botón ‘Stop’.
Diagrama funcional de actividades: El usuario indica los parámetros de
entrada e inicia el ataque. La aplicación hace una petición de la tabla de
encaminamiento según el parámetro de entrada V (versión RIP). Cuando la
aplicación obtiene la tabla de encaminamiento, informa al usuario por pantalla
del estado de la red. Acto seguido envía la mensajería falsa dependiendo de
los parámetros de entrada V (versión RIP) y M (Métrica).
A continuación se muestra un esquema de la interacción entre el usuario,
la aplicación y la red RIP atacada.
54
Fig. 28
Este esquema representa un ciclo de ejecución. Esto quiere decir que la
petición de la tabla de encaminamiento y el ataque se hará indefinidamente
hasta que se pare la ejecución de la aplicación, ya sea debido a un error o a la
finalización manual por parte del usuario.
Excepciones controladas: Se controlan las excepciones que puedan surgir
informando al usuario a través de la pantalla de la interfaz gráfica. Las
excepciones pueden ser de formato RIP, de red, de código...
Una excepción, implicará la parada automática del proceso de ataque y
por tanto de la ejecución del programa, dando la posibilidad al usuario de
iniciar un nuevo ataque cuando lo desee.
Riesgos: Se pueden encontrar problemas de comunicación con el router
vecino, ocasionados por:
- Problemas a nivel de IP.
- Problemas de sincronismo al enviar y recibir datagramas.
4.3 ANÁLISIS TÉCNICO
En este apartado se describen los aspectos técnicos que debe reunir la
aplicación de ataque al protocolo RIP.
55
Classes JAVA: La aplicación consta de tres classes bien diferenciadas. La
primera clase, ‘atac.class’, se trata de la clase principal. Se encarga de la
interfaz gráfica y la gestión del hilo de ejecución del ataque. ‘recibirUDP.class’,
se encarga de la comunicación en red mediante sockets UDP. Además en
esta clase se implementarán las actividades del ataque. ‘entrada.class’, se
trata de una clase que almacena de forma ordenada las datos de una entrada
RIP. La clase ‘atac.class’, contiene además una lista o vector de ‘entradas’.
56
Diagrama técnico de actividades:
Fig. 29
57
Excepciones controladas: Los errores más comunes en la aplicación, o mejor
dicho las excepciones, son las de comunicación. Todas las excepciones se
controlan con try – catch en el código Java. En caso de producirse
excepciones se procede siempre de la misma manera:
- Se reporta el mensaje de error a la pantalla de la interfaz gráfica.
- Se para el hilo de ejecución del ataque RIP.
Para hacerlo más inteligible, no se muestran los mensajes de error que
reporta Java, sino que se controla para mostrar por pantalla un mensaje más
claro, para que el usuario lo entienda. Sin embargo, si un error no se ha tenido
en cuenta, se mostrará el mensaje de error que proporciona Java.
A continuación se enumeran las excepciones java que se controlan:
SocketException:
Exception Java
Address already in use: Cannot bind
No route to host: Datagram send
failed
socket closed
Mensaje mostrado
Socket: El puerto 520 lo esta usando
otra aplicación, ciérrela para poder
iniciar el ataque
Socket: No se ha podido enviar la
petición. Revise las conexiones de red
Socket: Socket cerrado
IOException
Exception Java
Receive timed out
Mensaje mostrado
E/S: Los vecinos no están
contestando a la petición RIP
4.4 PRUEBAS
Un plan de pruebas es necesario para demostrar el correcto
funcionamiento de la aplicación. Se definen tres entornos de pruebas:
- ST (SystemTest): Abarca el proceso de desarrollo y programación de la
aplicación. Se ha comprobado la compilación del programa y el buen
funcionamiento a nivel local.
- IT (Integración): Abarca la comunicación del programa con la red. Se han
hecho pruebas de comunicación con un router.
- PR (Producción): Se ha escogido un caso real para probar el ataque.
58
4.4.1 PRUEBAS ST
Las pruebas ST, consisten en comprobar el buen funcionamiento del
código de la aplicación a nivel local. Estas pruebas se reducen a que el código
compile correctamente, y se comporte según lo descrito en el análisis
funcional y análisis técnico. Se han realizado las siguientes comprobaciones:
- Botones de ‘conectar’ y ‘stop’: Se ha comprobado que se inicie el hilo de
ejecución al hacer clic a ‘conectar’, y que finalice al hacer clic en ‘stop’.
- Desplegables: Se ha comprobado que se recoge la versión y el tipo de
ataque de forma correcta, desde la interfaz gráfica.
- Formato mensajes: Se ha comprobado que los mensajes que salen por la
pantalla tengan el formato deseado, en especial, los retornos de carro y la
hora que se produjo el evento.
- Datagramas: Se ha comprobado que la confección de los datagramas sea
la correcta, para prevenir posibles errores en las pruebas IT.
4.4.2 PRUEBAS IT
Las pruebas IT, consisten en comprobar la correcta comunicación entre la
entidad controlada y el router vecino, verificando que se están realizando las
actividades esperadas.
Para ello es necesario disponer de un router que disponga de RIP, tanto la
versión 1 como la versión 2. En este caso, se ha utilizado un ordenador Linux
del laboratorio, instalando la aplicación routed.
Routed es una implementación en código libre del protocolo RIP. En los
ordenadores de laboratorio no viene instalado por defecto en el SO Linux.
Pero no es difícil de conseguir e instalar.
Para la instalación se realizan los siguientes pasos:
./configure –with-c-compiler=cc
make
make install
Una vez instalado se ubica en "/usr/sbin". Ejecutarlo es tan fácil como:
/usr/sbin/routed
Una vez el ordenador esta configurado para que utilice RIP, enviará un
mensaje de actualización de sus tablas de encaminamiento cada 30
segundos. Lo podemos comprobar mediante un análisis con el programa
Wireshark.
59
Fig. 30
El programa Wireshark es un analizador de protocolos utilizado para
realizar análisis y solucionar problemas en redes de comunicaciones para
desarrollo de software y protocolos, y como una herramienta didáctica para
educación. Cuenta con todas las características estándar de un analizador de
protocolos.
Como otros analizadores de protocolos, Wireshark soporta la utilización de
filtros. En este caso, para capturar solo el tráfico del protocolo RIP se ha
utilizado el siguiente filtro:
- udp port 520
Con este filtro solo se captura el tráfico UDP que venga del puerto 520, el
utilizado por el protocolo RIP.
Para comprobar el buen funcionamiento del programa se han testeado los
siguientes temas:
- Comprobar que se envía el datagrama de petición de la tabla de
encaminamiento y se recibe una respuesta correcta por parte del router.
- Comprobar el formateo de la tabla de encaminamiento, y la correcta
inserción en la lista de entradas.
- Comprobar el buen funcionamiento del programa en la confección de los
datagramas de ataque, prestando atención en la versión y el tipo de ataque
que se debe realizar en cada caso.
- Comprobar que los datagramas falsos de ataque se envían correctamente.
Para realizar las pruebas se han utilizado trazas en el código, para mostrar
por consola las actividades que se realizaban, y se ha utilizado el programa
Wireshark para ver la comunicación entre la entidad controlada que ejecuta la
aplicación y el router.
60
4.4.3 PRUEBAS PR
Se ha configurado una red de pruebas:
Fig. 31
Se trata de una topología de red constituido por 5 ordenadores. La entidad
controlada es un portátil con sistema operativo windowsXP, que tiene
instalado el programa de ataque. Todos los ordenadores tienen sistema
operativo linux, con tres interfaces de red, y el demonio routed instalado. En
este caso solo necesitaremos 2 interfaces de red para los ordenadores A, B y
C, y una interfaz para el ordenador D.
Con esta topología se consigue la entidad atacada A obtenga mediante
aprendizaje dinámico de rutas una ruta de métrica 2, la ruta a la red
192.168.4.0. Esto es útil para realizar pruebas con mensajes falsos de métrica
1 desde la entidad controlada.
Se han asignado direcciones IP en las interfaces de red de cada ordenador
respetando la singularidad en cada red. De esta forma, en la red 192.168.3.0,
el ordenador B tiene la dirección 192.168.3.1 asignada en su interfaz, y el
ordenador C tiene la dirección 192.168.3.2.
Para configurar cada ordenador se ha utilizado la siguiente metodología:
#Deshabilitamos las interfaces que se están utilizando
ifconfig eth2 down
#Habilitamos la redirección de paquetes
echo 1 > /proc/sys/net/ipv4/ip_forward
#Configuramos las interfaces
ifconfig eth0 192.168.1.2 up
ifconfig eth1 192.168.2.1 up
61
Esto es un guión de ejemplo para el ordenador A. Se ha configurado de
forma similar el resto de ordenadores.
Para configurar el portátil, la entidad controlada, se le ha asignado la IP
192.168.1.1 desde el panel de control de windows.
Antes de arrancar routed la tabla de encaminamiento de A tenia la
siguiente pinta:
Kernel IP routing table
Destination
Gateway
192.168.2.0
0.0.0.0
192.168.1.0
0.0.0.0
Genmask
255.255.255.0
255.255.255.0
Flags Metric Ref
U
0
0
U
0
0
Use Iface
0 eth0
0 eth1
Flags Metric Ref
U
0
0
U
0
0
Use Iface
0 eth0
0 eth1
Flags Metric Ref
U
0
0
U
0
0
Use Iface
0 eth0
0 eth1
Flags Metric Ref
U
0
0
Use Iface
0 eth1
La tabla de encaminamiento de B:
Kernel IP routing table
Destination
Gateway
192.168.3.0
0.0.0.0
192.168.2.0
0.0.0.0
Genmask
255.255.255.0
255.255.255.0
La tabla de encaminamiento de C:
Kernel IP routing table
Destination
Gateway
192.168.4.0
0.0.0.0
192.168.3.0
0.0.0.0
Genmask
255.255.255.0
255.255.255.0
La tabla de encaminamiento de D:
Kernel IP routing table
Destination
Gateway
192.168.4.0
0.0.0.0
Genmask
255.255.255.0
Se arranca routed y se obtiene lo siguiente en el ordenador A:
Kernel IP routing table
Destination
Gateway
192.168.4.0
192.168.2.2
192.168.3.0
192.168.2.2
192.168.2.0
192.168.2.1
192.168.2.0
0.0.0.0
192.168.1.0
192.168.1.2
192.168.1.0
0.0.0.0
Genmask
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Flags
UG
UG
UG
U
UG
U
Metric
2
1
0
0
0
0
Ref
0
0
0
0
0
0
Use
0
0
0
0
0
0
Iface
eth0
eth0
eth0
eth0
eth1
eth1
Genmask
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Flags
UG
UG
U
UG
U
UG
Metric
1
0
0
0
0
1
Ref
0
0
0
0
0
0
Use
0
0
0
0
0
0
Iface
eth0
eth0
eth0
eth1
eth1
eth1
Genmask
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Flags
UG
U
UG
U
UG
Metric
0
0
0
0
1
Ref
0
0
0
0
0
Use
0
0
0
0
0
Iface
eth0
eth0
eth1
eth1
eth1
En el ordenador B:
Kernel IP routing table
Destination
Gateway
192.168.4.0
192.168.3.2
192.168.3.0
192.168.3.1
192.168.3.0
0.0.0.0
192.168.2.0
192.168.2.2
192.168.2.0
0.0.0.0
192.168.1.0
192.168.2.1
En el ordenador C:
Kernel IP routing table
Destination
Gateway
192.168.4.0
192.168.4.1
192.168.4.0
0.0.0.0
192.168.3.0
192.168.3.2
192.168.3.0
0.0.0.0
192.168.2.0
192.168.3.1
62
192.168.1.0
192.168.3.1
255.255.255.0
UG
2
0
Genmask
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Flags
UG
U
UG
UG
UG
Metric
0
0
1
2
3
Ref
0
0
0
0
0
0 eth1
En el ordenador D:
Kernel IP routing table
Destination
Gateway
192.168.4.0
192.168.4.2
192.168.4.0
0.0.0.0
192.168.3.0
192.168.4.1
192.168.2.0
192.168.4.1
192.168.1.0
192.168.4.1
Use
0
0
0
0
0
Iface
eth1
eth1
eth1
eth1
eth1
Se observa que se han aprendido rutas nuevas vía RIP. Además, en el
ordenador A se ha obtenido una ruta con métrica 2.
Iniciamos el ataque utilizando mensajes falsos con métrica 1. Se observa
lo siguiente en la tabla de encaminamiento del ordenador A:
Kernel IP routing table
Destination
Gateway
192.168.4.0
192.168.1.1
192.168.3.0
192.168.2.2
192.168.2.0
192.168.2.1
192.168.2.0
0.0.0.0
192.168.1.0
192.168.1.2
192.168.1.0
0.0.0.0
Genmask
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Flags
UG
UG
UG
U
UG
U
Metric
1
1
0
0
0
0
Ref
0
0
0
0
0
0
Use
0
0
0
0
0
0
Iface
eth1
eth0
eth0
eth0
eth1
eth1
La ruta con métrica 2 ha sido atacada. Ahora cada vez que A se quiera
comunicar con la red 192.168.4.0 enviara los paquetes hacia nuestra entidad
controlada. Según este experimento se puede afirmar que la estrategia de
ataque enviando mensajes falsos con métrica 1 es efectiva para atacar rutas
con métricas igual o mayor de 2.
El ataque tiene que ser persistente. Si no lo fuera el ordenador A vuelve a
tomar la ruta correcta.
Una posible aplicación, aparte de denegar el servicio, con este tipo de
ataque es poder ‘escuchar’ datos de una red que en cualquier otro caso no
tenemos acceso. Según este caso se puede capturar el tráfico que el
ordenador A envía a la red 192.168.4.0, y luego redireccionar los paquetes
otra vez a su destinación real.
Iniciamos el ataque enviando mensajes con métrica 16. Obtenemos lo
siguiente:
Kernel IP routing table
Destination
Gateway
192.168.2.0
192.168.2.1
192.168.2.0
0.0.0.0
192.168.1.0
192.168.1.2
192.168.1.0
0.0.0.0
Genmask
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
Flags
UG
U
UG
U
Metric
0
0
0
0
Ref
0
0
0
0
Use
0
0
0
0
Iface
eth0
eth0
eth1
eth1
Se observa que las rutas que se aprendieron vía RIP han desaparecido de
la tabla de encaminamiento. Han sido añadidas en el proceso de cancelación
y ya no se usan para encaminar.
63
5. CONCLUSIONES
Tras realizar las pruebas, se puede observar que el protocolo RIP es
vulnerable tanto utilizando el ataque de métrica 16 como utilizando el ataque
de métrica 1.
No obstante, en las pruebas se han configurado los routers para que utilice
RIP en todas las redes que tiene directamente conectadas. Esto, en un caso
real no seria necesario. Retomemos el caso de pruebas:
Fig. 32
El protocolo RIP participa en todas las interfaces. Pero se puede ver que
en la interfaz Ethernet, que conecta con la red donde se encuentra la entidad
controlada no sería necesario configurar RIP. Esto es así porque no hay
ningún router que le pueda interesar la información que envía RIP. Además,
en el caso que el administrador de la red le interesase que la red Ethernet
utilizará RIP, puede configurarlo de forma pasiva, de esta forma los mensajes
de respuesta que reciba el ordenador A por esa interfaz son rechazados
directamente.
Por lo tanto, se puede concluir que RIP, aunque es vulnerable, es útil en
un entorno de confianza, y hay que prestar especial atención a la hora de
configurarlo y no utilizarlo en las interfaces donde no haga falta.
6. RECURSOS UTILIZADOS
Para desarrollar el presente proyecto se han utilizado diferentes tipos de
recursos. Por una parte, se ha hecho uso de recursos bibliográficos para la
documentación sobre el protocolo RIP. Para ello se han consultado los RFCs
(Request For Comments) número 1058 y 2453. Internet también ha sido en
diversas ocasiones una fuente de inspiración.
64
En cuanto a los programas empleados, se ha utilizado el kit de desarrollo
java SDK 1.3.1_13. Además se ha utilizado el IDE NetBeans. Por otro lado, ha
sido de mucha utilidad la aplicación Wireshark, para el estudio de los
datagramas UDP RIP. También ha sido de gran apoyo la aplicación cports,
para matar puertos cuando ha sido necesario.
Para las pruebas de Integración y Producción, se ha utilizado cuatro PC’s
con Linux, un portátil con Windows XP y el programa ‘routed’. El programa
routed, es una implementación del protocolo RIP en código abierto.
65
7. MANUAL
7.1 INTRODUCCIÓN
Este documento recoge la guía de usuario de la aplicación Java de ataque
al protocolo de encaminamiento RIP.
Mediante esta herramienta, el usuario puede realizar un ataque a una red
conmutada que utilice RIP como protocolo de encaminamiento, desde un
ordenador conectado a dicha red.
7.2 REQUISITOS
Para al ejecución correcta de la aplicación se debe disponer de la máquina
virtual java instalada en el ordenador que vaya a realizar el ataque. Además
se debe disponer de acceso a la red atacada.
7.3 CARACTERÍSTICAS
La principal característica de la aplicación de ataque al protocolo RIP, es
la capacidad para realizar un ataque de red sin necesidad de tener
conocimientos técnicos del protocolo, simplemente utilizando una sencilla
interfaz gráfica. El ataque es posible en cualquier topología de red, desde un
ordenador conectado a la red.
Además la aplicación soporta tanto RIP en su versión 1, como la versión
2. El tipo de ataque que se consigue es una denegación de servicio en la red,
y es posible realizarlo siguiendo dos estrategias diferentes.
66
7.4 DESCRIPCIÓN DE LA APLICACIÓN
Elementos de la aplicación:
Fig. 33
1.- Conectar: Mediante este botón iniciamos un ataque
2.- Stop: Mediante este botón paramos un ataque
3.- Selección de versión: Selección de la versión del protocolo RIP que utiliza
la red que queremos atacar.
RIP1: Selección de la versión 1 del protocolo RIP
RIP2: Selección de la versión 2 del protocolo RIP
4.- Selección de tipo de ataque: Selección del tipo de ataque que deseamos
realizar.
- Ataque métrica 16: La aplicación enviará mensajes falsos con el campo
métrica 16.
- Ataque métrica 1: La aplicación enviará mensajes falsos con el campo
métrica 1.
5.- Pantalla: Se muestra mediante mensajes el proceso del ataque y los
mensajes de error.
Inicio del ataque:
Para iniciar un ataque presionar el botón conectar. Se mostrará por
pantalla el siguiente mensaje:
67
Fig. 34
-Intentando crear Socket UDP 520...: La aplicación intenta iniciar una conexión
por el puerto 520, utilizado por el protocolo RIP.
-Versión escogida: Se muestra la versión que se ha escogido.
-Ataque escogido: Se muestra el tipo de ataque escogido.
-Socket creado con éxito: Indica que la aplicación ha conseguido iniciar la
conexión.
-Ejecutando rutina: Petición de tabla de encaminamiento: La aplicación envía
un mensaje RIP solicitando al router la tabla de encaminamiento. El formato
del mensaje dependerá de la versión escogida antes de conectar.
Fig. 35
68
- Datagrama request enviado: Informa de que el datagrama de petición de la
tabla de encaminamiento ha sido enviada con éxito.
- Datagrama recibido: Informa de que el router ha contestado y se ha recibido
la tabla de encaminamiento con éxito.
- Red RIP: Tabla de encaminamiento recibida: Informa de que se ha recibido
una tabla de encaminamiento con el formato correcto.
- Entrada aprendida: x.x.x.x – Métrica: x: Indica que una nueva ruta ha sido
aprendida, especificando la dirección IP y la métrica.
- Ejecutando rutina: Enviar datagrama falso: Envío de un datagrama falso.
Con las rutas aprendidas se construye un datagrama falso según el tipo de
ataque y la versión RIP escogida, para ser enviado a la red atacada.
- Datagrama falso enviado: Indica que el datagrama falso ha sido enviado con
éxito.
7.5 MENSAJES DE ERROR
Mensaje
Socket: El puerto 520 lo esta usando
otra aplicación, ciérrela para poder
iniciar el ataque
Socket: No se ha podido enviar la
petición. Revise las conexiones de
red.
Socket: Socket cerrado
E/S: Los vecinos no están
contestando a la petición RIP
Error comando: No se ha recibido un
datagrama response
Error versión: La red no es
compatible con RIP1
Error versión: La red no es
compatible con RIP2
Descripción
El programa no se puede
ejecutar porque el puerto 520,
que utiliza RIP, esta ocupado
por otra aplicación.
Se ha producido un problema
de comunicación con la red.
El socket se ha cerrado.
Normalmente cuando se clica
en el botón stop.
Si los vecinos tardan más de
30 segundos en contestar una
petición
Si se recibe un datagrama que
no es de respuesta.
La red que se esta intentando
atacar no utiliza RIP1
La red que se esta intentando
atacar no utiliza RIP2
69