Xombra.

com|| Sitio de Seguridad Informatica

Seguridad en protocolos de enrutamiento dinámico

Interesante artículo de la gente de blog.s21sec.com sobre la seguridad de enrutamiento
dinámico. A continuación texto completo:

En la vorágine de la seguridad de Internet muchas veces olvidamos que no todo es XSS,

SQL Injection, Directory Traversal, NMAP, Nessus o cualquier otra herramienta de seguridad
o vulnerabilidad a nivel de host que se nos pueda ocurrir. No debemos olvidar que también
hay que garantizar la disponibilidad, confidencialidad e integridad en las comunicaciones
para lo cual los <a href="http://en.wikipedia.org/wiki/Routing_protocols"
target="_blank">protocolos de enrutamiento dinámico</a> juegan un papel fundamental en
el mundo IP. Sin embargo, mucha gente desconoce si estos protocolos implementan algún
mecanismo de seguridad, o de hacerlo, cuál es exactamente.
Uno de los posible ataques contra este tipo de protocolos es evitar que se envíen los
mensajes legítimos de actualización de rutas con el objetivo de generar una denegación de
servicio de la red (parte de la red dejaría de estar disponible). Sin embargo, los ataques más
dañinos son aquellos que buscan modificar la <a
href="http://en.wikipedia.org/wiki/Routing_table" target="_blank">tabla de rutas</a> con un
objetivo determinado, a través del envío de mensajes de actualización generados
artificialmente. La corrupción de esta tabla permite a un atacante lograr una denegación del
uso de la red, bien a través de generación de congestión, limitando la visibilidad entre partes
de ésta, o generando bucles de enrutamiento. Además incluso, el atacante en cuestión
podría lograr una denegación de servicio contra un host en particular, al poder desviar todo
el tráfico en circulación contra él, o también acceder a información confidencial si logramos
encaminar un determinado flujo de tráfico hacia un sniffer instalado en la red.
¿Realmente esto resulta tan sencillo como parece? ¿No existen mecanismos de seguridad
en estos protocolos que permitan evitarlo?
En realidad sí que existen, aunque no en todas las versiones de los distintos protocolos.
Además, algunos de estos mecanismos ofrecen una falsa sensación de seguridad, mientras
que los más avanzados no son del todo seguros o no se implementan por aspectos de
rendimiento.
Comenzando con éste, dedicaré los próximos post en este blog a analizar algunos de los
mecanismos de seguridad comunes a varios protocolos de enrutamiento dinámico. También
trataré algunos aspectos más particulares a cada protocolo e intentaré transmitiros en qué
consisten algunas de las técnicas más novedosas que se están tratando de aplicar para
mejorar la seguridad de estos protocolos. Así pues, comencemos …
Una manera sencilla de evitar que un router ajeno a una red e introducido en ésta de manera
clandestina altere los mensajes de enrutamiento, es la autenticación de los mensajes de
actualización de rutas. <a href="http://en.wikipedia.org/wiki/Routing_Information_Protocol"
target="_blank">RIP</a> y <a href="http://en.wikipedia.org/wiki/OSPF"
target="_self">OSPF</a> ofrecen dos mecanismos de autenticación.
 El primero de ellos, conocido como autenticación de texto plano (“plaintext authentication”),
se basa en que los routers de un mismo segmento de red comparten una clave “secreta” que
se incluye en la cabecera de los mensajes del protocolo. El router que recibe el mensaje de
actualización compara esta clave incluida en la cabecera con la que tiene en memoria, y si
coinciden acepta el paquete. En caso contrario lo rechaza. Este mecanismo de seguridad es
sencillamente inútil ya que basta con instalar un sniffer en la red para obtener la clave
“secreta” compartida por todos los routers.
El segundo mecanismo también se basa en una clave secreta compartida previamente por
los routers de la red pero en este caso se firma el mensaje aplicando una función de
resumen o hash de tipo M<a href="http://en.wikipedia.org/wiki/MD5" target="_blank">D5</a>
al mensaje de actualización. En el caso particular de OSPF, a cada paquete se introduce el
identificador de la clave secreta, la clave secreta en sí misma y también un número de
secuencia de 32 bits que garantiza la protección contra ataques por repetición.
Posteriormente se calcula su MD5 y se inserta en el campo en el que previamente se había
añadido la clave compartida. En la siguiente figura se muestra este proceso:
<a
href="http://bp2.blogger.com/_QUsiOTimAdQ/SA9hBC2p_gI/AAAAAAAAAWU/nM5JHpTSAzA
/s1600-h/OSPF-MD5.PNG" target="_blank"><img
src="http://bp2.blogger.com/_QUsiOTimAdQ/SA9hBC2p_gI/AAAAAAAAAWU/nM5JHpTSAzA/
s200/OSPF-MD5.PNG" alt="MD5" width="200" height="176" border="0"></a>
Este mecanismo, aún mejorando mucho la seguridad en la autenticación de los mensajes de
actualización, resulta inútil cuando uno de los routers legítimos resulta comprometido ya
que sólo garantizan la integridad salto a salto. Así, el router comprometido podría falsear la
información de los mensajes de actualización de rutas procedentes de los routers vecinos al
generar los <a href="http://es.wikipedia.org/wiki/Vector_de_distancias"
target="_blank">vectores de distancias</a> o los <a
href="http://es.wikipedia.org/wiki/Estado_de_enlace" target="_blank">estados de los
enlaces</a>, consiguiendo el atacante su objetivo de modificar la tabla de rutas de los
demás routers a su gusto.
Como ya sabéis <a href="http://es.wikipedia.org/wiki/Border_Gateway_Protocol"
target="_blank">BGP</a> (en concreto la versión 4) es un protocolo de enrutamiento
dinámico, de hecho el único, que se utiliza como EGP entre los distintos <a
href="http://es.wikipedia.org/wiki/Sistema_autónomo" target="_blank">sistemas
autónomos</a> (AS) que conforman Internet.
<a
href="http://bp0.blogger.com/_QUsiOTimAdQ/SFujaCqX32I/AAAAAAAAAZ8/Re-u00RQuKU/s
1600-h/BGP.PNG" target="_blank"><img
src="http://bp0.blogger.com/_QUsiOTimAdQ/SFujaCqX32I/AAAAAAAAAZ8/Re-u00RQuKU/s3
20/BGP.PNG" alt="bgp" width="320" height="120" border="0"></a>

A continuación listo a modo de repaso los aspectos más importantes del protocolo:
<blockquote>
Es un protocolo vector-camino (muy similar a los protocolos vector-distancia)
Por lo tanto, el cálculo de las rutas que conforman la tabla de enrutamiento se hace de
manera distribuida (el conocimiento del camino está distribuido)
Para ello, los nodos informan a sus vecinos de las redes que alcanzan {red, siguiente
salto, [lista AS]}. Véase figura.
Los mensajes de protocolo se envían sobre conexiones TCP al puerto 179
Finalmente, notar que permite el intercambio de información de subredes classless (<a
href="http://es.wikipedia.org/wiki/CIDR" target="_blank">CIDR</a>)
</blockquote>
Un primer sistema para proporcionar seguridad en el intercambio de mensajes BGP es la
autenticación de los mismos. Como ya se ha mencionado, BGP hace uso de sesiones TCP
para el intercambio de mensajes. La solución viene de la mano de la <a
href="http://www.ietf.org/rfc/rfc2385.txt" target="_blank">RFC 2385: “Protection of BGP
Sessions via the TCP MD5 Signature</a>” que propone utilizar el campo de opciones de la
cabecera TCP, para incluir en cada segmento de este protocolo un hash MD5 que complique
los ataques de spoofing y man-in-the-middle. Este MD5 se calcula utilizando una clave
previamente compartida entre los nodos finales de la conexión TCP.
Con el objetivo de minimizar los ataques de redirección de tráfico, de secuestro de prefijos
mediante publicación malintencionada de los mismos, y de DoS de los routers BGP, resulta
de vital importancia realizar un filtrado de prefijos adecuado en los routers BGP del AS, para
lo que muchas veces basta aplicar el sentido común. A continuación listo algunos aspectos
a tener en cuenta, aunque existen más:
<blockquote>
Evitar la publicación hacia otro AS de prefijos de red asociados con el espacio de IP
privadas, cualquier otro de propósito especial o incluso no asignadas aún por la <a
href="http://es.wikipedia.org/wiki/IANA" target="_blank">IANA</a>.
Los prefijos de red utilizados para direccionamiento interno del AS nunca deberían ser
publicados hacia otros AS aún cuando estén dentro del rango de IP públicas.
En caso de que el AS sea un ISP, éste no debería publicar rutas hacia redes de las que no
sea responsable.
Todo ISP debería descartar como mínimo prefijos de red mayores de 24 bits de longitud
puesto que éste es el tamaño mínimo asignado por las <a
href="http://es.wikipedia.org/wiki/Registro_Regional_de_Internet" target="_blank">entidades
de registros de Internet</a>.
</blockquote>
Con esto me despido hasta el próximo post, en el que probablemente os hablaré de las
nuevas líneas de I+D que se están llevando a cabo para mejorar la seguridad de nuestros
queridos protocolos de enrutamiento.
Fuente:
Elyoenai Egozcue
S21sec labs
<a href="http://blog.s21sec.com" target="_blank">http://blog.s21sec.com</a>

15/11/2009 : 07:50

http://www.xombra.com/go_news.php?articulo=3624