MANRS (Normas mutuamente acordadas para en encaminamiento seguro) son un conjunto de normas a las que puedes adherirte voluntariamente después de demostrar que cumples todos los requisitos. MANRS persigue eliminar las amenazas de encaminamiento más comunes:

Aquí vamos a centrarnos en MANRS para proveedores de servicios, pero también se puede aplicar MANRS para IXP, redes de distribución de contenidos, proveedores en la nube o incluso fabricantes.

En cuanto a los proveedores de servicios de Internet (ISP) los beneficios de adherirse a MANRS son varios como por ejemplo:

Las fases para cumplir MANRS son cuatro:

Antes de nada contar que Internet se divide en 5 regiones, cada una de ellas funciona de forma similar, pero no exacta en cuanto a procedimientos y yo voy a centrarme en los que a mi zona respecta que comprende Europa, Oriente Medio, lo que era la Unión Soviética y Mongolia y su RIR (Registro Regional de Internet) que se llama RIPE (del francés Réseaux IP Européens) y el punto de coordinación es RIPE NCC.

Para realizar las tareas de validación es necesario que los operadores publiquen la información de su red en varios repositorios públicos:

La información para mantener un estándar se sube utilizando el Lenguaje de especificación de políticas de enrutamiento (RPSL).

El RPSL nos sirva para almacenar la información relativa a los objetos como INETNUM, ROUTE / ROUTE6 o AS-SET dentro de la base de datos de un IRR (Registro de Routing de Internet):

Un objeto route de Tecnocrática

Un objeto inetnum de Tecnocrática

Un objeto inet6num de Tecnocrática

Pero con agregar los objetos al IRR que nos corresponda nos es suficiente además necesitaremos objetos ROA (Autorización de Origen de Ruta) para asegurar que esas rutas son realmente nuestras. Para asegurar esto firmaremos critográficamente esa información y la depositaremos en un repositorio RPKI.

Y por último tenemos a PeeringDB que es donde podemos poner otra información, como por ejemplo los IXPs a los que estamos conectados, la velocidad de nuestros puertos de intercambio y otra información.

Con la información del IRR podemos obtener por cada Sistema Autónomo la lista de ASs con los que comparte información tanto entrante como saliente y con eso podemos construir unos filtros que impidan que un AS anuncie algo que no deba.

Por poner un ejemplo, si nos conectamos contra el AS65555 (es privado) y ese AS le da tránsito al 65554 podemos deducir que vamos a recibir prefijos del 65555 y del 65554, así que si recibimos prefijos del AS23454 significa que algo está mal porque ese AS no puede anunciar prefijos de ese AS pues no está conectado y no nos proporciona tránsito.

Esa información está en el objeto aut-num que se obtiene simplemente poniendo en la consola:

$ whois as65555

En el caso de Tecnocrática podemos obtener el siguiente:

Ahí lo que podemos ver es de quien se hace import, a quien se le hace export y qué es lo qué se espera recibir y transmitir. Por poner un ejemplo de lo que podemos ver ahí:

Estas de arriba serían las políticas entre Google y  nosotros, por un lado tenemos los import y export, que sólo son para IPv4 y el mp-import y mp-export que sirven para todo. Están duplicadas porque todavía hay gente no soporta los mp-import y mp-export, así que ante la duda duplicas y ya te quitas problemas, pero relamente con el mp-import y  mp-export debería de servir.

Ahí lo que decimos es que aceptamos lo que vvena en el as-set AS-GOOGLE  y nosotros le anunciamos lkoq ue venga en el as-set AS-Tecnocratica.

Para generar esos filtros podemos hacerlo a mano, pero no os lo aconsejo porque hay que ser un campeón y lo normal es que se te pasen cosas constantemente, así que lo mejor es usar una herramienta para ello como son: IRRToolset, BGPQ3, BGPQ4, IRRPT. Esas herramientas nos darán la configuración para copiar y pegar, muy facilito todo.

Todo lo que no esté debidamente documentado en el IRR debería de ser descartado y en un mundo ideal todo lo que no esté en RPKI también, pero es más complicado ya que por desgracia no está totalmente implementado por mucha gente por desconocimiento y por limitaciones del hardware que utilizan.

Para evitar la suplantación de direcciones IP podemos hacer básicamente dos cosas:

El uRPF simplemente sería habilitar ip verify unicast reachable-via rx y ipv6 verify unicast reachable-via rx.

En cuanot al bloqueo de IPs en interfaces es simplemente aplicar un access list que no se acepta nada con la ip de origen fuera del rango del interfaz.