Seguridad MPLS (I)

Explicar la tecnología MPLS podría llevarnos varias entradas. Por ello simplemente voy a realizar un breve resumen de algunos de los aspectos más importantes para refrescar la memoria a quienes ya la conocen. Para el resto os recomiendo que os leáis alguna de las siguientes referencias:

• MPLS Fundamentals: A comprehensive Introduction to MPLS Theory and Practice. Luc De Ghein. Cisco Press.
• Advanced MPLS Design and Implementation. Vivek Alwayn. Cisco Press.

La tecnología MPLS (RFC 3031) es un estándar abierto del IETF que básicamente adapta la tecnología “tag switching”, sistema propietario de Cisco y que destacó frente al IP Switching, tecnología similar propuesta por Ipsilon Networks pero restringida a la arquitectura ATM.

Se trata de una tecnología para el transporte de datos a nivel de red MAN y WAN perteneciente a la familia de tecnologías basadas en la conmutación de paquetes. Además proporciona un servicio de transporte de datos orientado a conexión a través de la creación de circuitos virtuales, previa al transporte de la información. A nivel del modelo OSI de comunicaciones se localiza entre el nivel de enlace y el nivel de red, por lo que podemos hablar de un nivel ficticio 2.5. El aspecto fundamental de esta tecnología es que el reenvío de paquetes se hace en base a unas etiquetas que se incluyen en la cabecera del protocolo. Estas etiquetas van cambiando de salto a salto y definen un camino (LSP) que ha sido calculado con carácter previo por los nodos de la red y en base a algún criterio predefinido llamado FEC (Ej. tráfico destinado a un cierto rango de red con unos requisitos de calidad de servicio elevados). Nótese la diferencia con el transporte tradicional IP, en el que el plano de control y el plano de datos se encuentran entrelazados. Las etiquetas definen el camino y se distribuyen en base a algún protocolo de intercambio de etiquetas (LDP, RSVP-TE, MP-BGP, etc.).

La tecnología MPLS está siendo adoptada por la mayoría de los proveedores de servicios de Internet (ISP) ya que les permite reducir costes en la operación de la red y ofrecer a sus clientes SLAs con compromisos reales de QoS, lo cual se está convirtiendo en una auténtica necesidad con la introducción en las empresas de la VoIP. La reducción en los costes de operación se explica porque MPLS permite ofrecer múltiples servicios de transporte de manera virtual (Ethernet, ATM, FR, HDLC, PPP, etc.) con una única red, por lo que ya no es necesario mantener equipamiento y configurar distintas redes, con la correspondiente reducción en personal especialista que esto implica. A esta funcionalidad de MPLS se le conoce por AToM (Any Transport Over MPLS). No obstante, en la actualidad su mayor auge viene de la mano de otro servicio, el de redes privadas virtuales (VPN), y será en la seguridad de este servicio en la que centraremos esta entrada.

Algunos términos que resultan fundamentales para poder comprender lo que se contará se listan a continuación. Cada uno de ellos contiene un hiperenlace a la definición del mismo.

• Router PE (Provider Edge Router) o E-LSR (Edge Label Switching Router)
• Router P (Provider Router) o LSR (Label Switching Router)
• Label Switched Path (LSP)
• Forwarding Equivalent Class (FEC)
• Virtual Routing and Forwarding Instance (VRF)
• Route Distinguiser (RD)

Antes de tratar la seguridad de las redes privadas virtuales basadas en la tecnología MPLS resulta fundamental tener una visión de alto nivel de cómo se ofrece este servicio.

Cada router PE puede estar comunicado con varios routers CE pertenecientes al mismo, o a diferentes clientes. Los routers CE son aquéllos que interactúan directamente a nivel tres con los routers PE del ISP, los cuales dan acceso a la red MPLS. Por lo tanto son ajenos a la existencia de una red MPLS y no entienden de etiquetas, LSP, LDP, VRF, etc. Cada router PE mantiene una tabla de rutas independiente por cada VPN además de una global. Es decir, si un PE da soporte a las delegaciones de dos empresas distintas mantendrá dos tablas de rutas independientes, una por cada empresa, y la tabla de rutas global, en la que se mantienen las rutas internas del propio core MPLS. La interfaz del router PE que conecta con un CE debe tener una dirección IP dentro del rango de direccionamiento de la VPN a la que pertenece dicho CE, de tal manera que el ISP participa en el direccionamiento de la empresa a la que da servicio. Esta falta de transparencia es probablemente la única desventaja del servicio de VPNs de MPLS. Siguiendo con la explicación, cada CE propaga las rutas (información de alcanzabilidad) de su tabla de rutas hacia el PE (bien mediante un IGP o mediante eBGP) y éste a su vez propaga hacia el CE las rutas que le llegan desde otros PE, comunicados a su vez por sus CE vecinos. La comunicación de rutas PE-PE requiere una explicación más detallada. Ésta se realiza mediante iBGP puesto que las rutas intercambiadas son las de todas las VPNs a las que el ISP da servicio. Puesto que dos VPN pertenecientes a empresas distintas pueden optar por un mismo espacio de direcciones privadas, es necesario buscar un mecanismo que permita distinguirlas. Este es el objetivo del RD, que no es más que una extensión de BGP, que se emplea cuando éste propaga las rutas entre routers PE. Es importante notar que los routers P, que conforman el núcleo de la red MPLS, no participan en el intercambio de las rutas de las VPN. Éstos únicamente ejecutan un protocolo de enrutamiento IGP entre sí y con los PE para intercambiar la información de alcanzabilidad del core MPLS; información que se empleará para distribuir las etiquetas que permiten el reenvío de paquetes dentro del core (ver más adelante).



Ahora que ya sabemos cómo se construyen las tablas de rutas, falta saber cómo se propagan los paquetes de distintas VPN por la red. Cuando un paquete llega a un PE desde un CE con destino un host que se encuentra en una delegación remota, se encapsula con la correspondiente cabecera MPLS. Esta cabecera incluye además dos etiquetas MPLS anidadas, la más profunda identifica la VPN a la que pertenece el paquete y la más externa permite a la red MPLS realizar el reenvío del paquete hasta el PE de destino. Una vez el paquete llega al PE correcto, éste elimina la etiqueta exterior y se fija en la etiqueta más profunda, la cual le dice a qué VPN pertenece el paquete, y por ende a través de qué interfaz (y por consiguiente hacia qué CE) debe reenviar el paquete. Finalmente, el CE asociado se encargará de hacer llegar el paquete hasta el host de destino.

Finalizada ya esta “breve” introducción a la tecnología MPLS nos encontramos en condiciones de analizar los aspectos fundamentales de la seguridad del servicio de VPN. Suponiendo que no tenemos acceso al equipamiento del core de la red MPLS (routers PE y P), y desde el punto de vista de un atacante, lo que más nos puede interesar es ver cómo desde una VPN a la qué sí tenemos acceso (Ej. somos trabajadores de una empresa que tiene contratado un servicio de VPN basado en MPLS) podemos o bien interceptar el tráfico y acceder a equipos pertenecientes a otra VPN, o bien generar una denegación de servicio en las otras VPN.

Como se puede deducir de las explicaciones anteriores, si el atacante si sitúa en una delegación dentro de una VPN concreta, cuando quiera acceder a otra delegación simplemente verá que su tráfico sigue una ruta que a nivel IP pasa como mínimo por cuatro saltos distintos (CE-PE-PE-CE), siendo el primer salto su GW por defecto. Este GW por defecto es en realidad el CE de su delegación que se comunica con un router virtual, conocido por VRF en la terminología MPLS, y que no es más que la tabla de rutas asociada a la VPN y la instancia de reenvío de paquetes asociada. Como ya sabemos, ambas se incluyen en el router PE.

Así, una primera opción que se nos puede ocurrir para intentar acceder a una VPN distinta sería enviar paquetes encapsulados con una cabecera MPLS que incorporare a su vez las etiquetas adecuadas. Estas etiquetas, debido a que no son conocidas a priori, podrían determinarse a base de prueba y error. De este modo, si no estuviéramos interesados en un objetivo concreto sino en alcanzar de manera indiscriminada una VPN de otro cliente del ISP, podría servirnos perfectamente. Sin embargo, la RFC estipula que cuando llegue un paquete MPLS por una interfaz asociada a un CE, éste se descarte automáticamente. Enno Rey, en una presentación que realizó en la Blackhat hace un par de años, afirmó que lo habían comprobado con routers CISCO y que en todos los casos se había verificado la conformidad con la RFC.

Otro posible ataque consistiría en aprovechar una incorrecta implementación de las conexiones a nivel CE-PE. Imaginemos por un instante que dos CE pertenecientes a VPNs diferentes se conectan a sendas interfaces virtuales que en realidad son una misma interfaz física. Supongamos además que los enlaces procedentes de los PE se concentran en un switch antes de conectarse contra el PE utilizando tecnología de VLAN. ¿Acaso no podríamos realizar un ataque a las VLANs (por ejemplo con Yersinia) si comprometemos el router CE para así terminar accediendo a la VPN de otro cliente del ISP? En estos casos lo mejor es implementar enlaces físicos independientes PE-CE.

Igualmente sería deseable que en las interfaces del PE que se conectan contra routers CE se incorporaran ACLs que únicamente permitieran tráfico de enrutamiento. Todo servicio adicional podría ser aprovechado por un atacante para ganar acceso al router PE (login remoto, tft para la carga de configuraciones, etc.)

Respecto a las denegaciones de servicio, qué mejor manera para dejar aislada una delegación que dejar fuera de combate al PE que le permite comunicarse con el resto de delegaciones. Cómo hacerlo, pues aprovechando el único servicio que debería ser accesible, el de algún protocolo de enrutamiento dinámico que corra entre el nuestro CE y el PE. Imaginemos que inundamos al PE con infinidad de rutas inventadas y que van cambiando cada poco tiempo. Si el router no está correctamente configurado, lograremos saturar su memoria y llevar la CPU al 100% dejándolo inutilizado para el resto de VPNs a las que dé servicio.

Fuente: http://blog.s21sec.com