Nota: Esto es un post que esta publicado en el portal de ISCO-Dominicana, he decidido publicarlo aqui tambien y asi poder relacionarlo con otros proyectos que tengo en lista.
Seguridad de Enrutamiento, como estamos y como debemos estar.
Cada día la infraestructura de Internet es atacada de formas que no imaginamos, en los últimos años hemos visto como personas y/o organizaciones buscan la manera de lucrarse aprovechando las debilidades en la infraestructura de Internet ya sea apoderándose de recursos o haciendo que estos recursos no estén disponibles para los usuarios.
Muchos sabemos el origen de Internet, en sus primeros años nadie imagino que esta plataforma seria lo que es hoy y por esto, muchos de los protocolos que son pilares de Internet no cuentan con la seguridad necesaria para prevenir que un atacante pueda causar daños a la infraestructura que lo forma. Aunque en sus inicios estos protocolos no tenían esa seguridad que deseamos no quiere decir que no se han creado las medidas para protegerlos.
En este caso nos enfocaremos en BGP (Border Gateway Protocol) Protocolo de ruteo de borde.
Este es uno de esos protocolos que se creó para resolver un problema específico, es un protocolo mediante el cual se intercambia información de encaminamiento entre sistemas autónomos. Por ejemplo, los proveedores de servicio registrados en Internet suelen componerse de varios sistemas autónomos y para este caso es necesario un protocolo como BGP.
¿Que podemos hacer para ayudar a proteger la Internet?
Existen varios proyectos que nos brindan las herramientas y pasos necesarios para colaborar con el aseguramiento de la infraestructura de Internet. En esta ocasión estaremos hablando sobre MANRS.
¿Qué es MANRS?
MANRS (por sus siglas en inglés) son Normas Mutuamente Acordadas para la Seguridad del Enrutamiento.
Es una iniciativa de la Internet Society que provee pasos específicos los cuales nos ayudaran a asegurar la información de enrutamiento en nuestros equipos gracias a las cuatro normas sugeridas.
- Filtros
- Anti-spoofing
- Coordinación
- Validación Global
Las acciones anteriores son especificas para operadores de red que cuentan con ASN y tienen infraestructura BGP.
En nuestro caso estaremos trabajando en base a las acciones desarrolladas para los IXP.
La primera acción será el filtrado de rutas, con esta acción se logra prevenir la propagación de información de enrutamiento incorrecta hacia los participantes, para cumplir con dicha acción debemos hacer cambios en el Servidor de Rutas (routeserver).
Primero debemos entender que hace un routeserver antes de proceder con el aseguramiento de este.
El routeserver en una red de Peering juega un papel importante ya que simplifica la cantidad de configuraciones de los participantes y ayuda con el Peering unilateral, si todos hacen Peering con el routeserver, todos tendrán visibilidad de las rutas de cada participante. En los últimos años a incrementado la tendencia de usar implementaciones basadas en software para así eliminar equipos físicos que a veces no eran lo suficientemente rápidos para distribuir la información de Peering entre todos los participantes.
¿Como funciona un routeserver?
Las sesiones BGP se realizan a RS1 y RS2, sin embargo, estos servidores no intervienen en el tráfico entre los participantes.
- Trafico de Control-Plane es manejado por los routeserver, este es el tráfico con información de prefijos y números autónomos.
- Trafico de Data-plane fluye directamente entre los participantes.
Los routeserver son el punto donde debemos aplicar seguridad para proteger la información distribuida entre los participantes, estas son las ventajas que recibimos si aplicamos filtros en los routeservers:
- Forzamos a participantes maliciosos a dejar rastros en los IRR, si no existen registro IRR los prefijos son denegados.
- Reforzamiento de higiene básica en la red de Peering: no se permiten bogon ASN o prefijos bogon.
La buena noticia es que, para realizar las acciones recomendadas por MANRS en los IXP, existen plataformas OpenSource que facilitan dichas configuraciones en los routeserver. IXP Manager es la plataforma en la que basaremos las recomendaciones a continuación.
IXP Manager soporta RPKI, esto significa que al instalar y configurar esta plataforma en nuestro IXP y por supuesto activar la opción de RPKI, estamos más cerca de cumplir con la primera recomendación de MANRS.
Activar RPKI en los routeserver no resuelve nuestro problema de manera inmediata ya que primero debemos iniciar una campaña de concientización para que todos los participantes con direcciones IP (v4 o v6) usen esta opción la cual LACNIC tiene disponible desde hace varios años, mientras tanto nos apoyaremos en IRR.
Habilitemos RPKI en nuestros prefijos.
Tener RPKI en un prefijo (IPv4 o IPv6) es tan fácil como ir al portal de RPKI de LACNIC y generar el certificado.
Una vez generado el certificado de RPKI, tendremos información parecida a:
Usando la aplicación whois en el terminal de un equipo Linux, podremos hacer una petición para validar que esta firma RPKI esta siendo distribuida en Internet.
¿Qué pasa si no tengo RPKI y planeo habilitarlo más adelante?
En ese caso usaremos IRR para validar que los prefijos anunciados por un participante corresponden a este, este método no es tan seguro como RPKI, sin embargo, aporta seguridad a la información de enrutamiento que se distribuye.
IRR (Internet Routing Registry), es una herramienta con más tiempo y con mejor adopción que RPKI, actualmente existen varios registros de este tipo, algunos libre para usar y otros de pago. La siguiente imagen muestra información registrada en RADB para el prefijo 200.1.154.0/24.
¿Qué significan estos valores?
- route: hace referencia al bloque en cuestión.
- descr: una descripción enviada por la persona o sistema que registro la información en el IRR.
- origin: el Numero Autónomo que esta permitido a originar rutas relacionadas a este prefijo.
- notify: dato de contacto en caso de anomalías.
- changed: último cambio realizado (por quien y cuando).
- source: el IRR de donde salió esta información.
Actualmente LACNIC no cuenta con IRR, en varias ocasiones se ha hablado del tema y se espera que se habilite dicha opción y que esté disponible para los miembros como un servicio agregado a la membresía. Por esta razón estaremos usando RADB (de pago) o ALTDB (gratuito).
En nuestro caso, veremos como hacerlo con ALTDB. Esta es una plataforma de IRR administrada por la comunidad de operadores de redes, en su mayoría ubicados en Estados Unidos. Administrar prefijos en un IRR es un tema con mucha información y por esta razón prefiero dejar un documento desarrollado específicamente para ALTDB, en este documento se explica como mantener nuestros recursos en este IRR.
A Quickstart Guide to Documenting Your Prefixes with IRR
https://fcix.net/whitepaper/2018/07/14/intro-to-irr-rpsl.html
¿Qué sucede cuando prefijos no son aceptados por RPKI inválidos o IRR incorrectos?
En estos casos se pretende marcar estos prefijos con comunidades informativas para que los participantes puedan determinar la razón y actuar en base a esta información.
Usando IXP Manager se puede consultar esta información en el portal de usuario, en este portal tendremos acceso a plataforma de Looking Glass.
Un Looking Glass no es más que una herramienta con la cual podemos ver información desde el punto de vista de los routeserver y que pasa con los prefijos que los routeserver reciben de los participantes.
Los beneficios de tener una infraestructura de IXP organizada y segura van desde un Internet seguro a mejor infraestructura como país. Internet es una plataforma de la cual todos dependemos y si creamos mecanismos no solo de seguridad si no también de transparencia y comunicación, podremos lograr que nuestra infraestructura apoye proyectos como el trabajo remoto y telemedicina por mencionar solo dos.
Debemos formar un grupo de operadores de red que velemos por la estabilidad de nuestro Internet y lograr que la comunicación entre los miembros de nuestro IXP sea transparente para impedir que personas maliciosas puedan vulnerar los servicios en red que usamos día a día.