MANRS

Podcast de Redes de Eduardo Collado

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: Secuestro de prefijos. Fugas de ruta. Suplantación de direccionamiento IP. 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: Reconocimiento por la comunidad como buenos ciudadanos de la red y contribuidores de la estabilidad en Internet. Demostrar competencia en seguridad y compromiso con clientes. Ofrecer un servicio de conectividad acorde a los estándares más altos. Contribuir a reducir los problemas de seguridad de routing. Las fases para cumplir MANRS son cuatro: Validación: Publicar información de routing en lugares que se puedan validar por cualquiera. Filtrado: Filtrar para anunciar con exactitud los prefijos propios y de sus clientes, filtrando el resto. Antisuplantación: Impedir el tráfico desde IPs suplantadas. Coordinación: Mantener información de contacto actualizada. Validación 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: IRR (Registros de Encaminamiento de Internet): En mi caso RIPE NCC RPKI (Infraestructura de clave pública de recursos) PeeringDB 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 route: 31.47.72.0/21 descr: Tecnocratica Centro de Datos IPv4 network origin: AS15954 mnt-by: TECNOCRATICA-MNT created: 2018-05-22T14:48:50Z last-modified: 2018-05-22T14:51:19Z source: RIPE Un objeto inetnum de Tecnocrática inetnum: 31.47.77.0 - 31.47.77.255 netname: Neodigit-Managed-Hosting-4 descr: Managed Hosting Group 4 country: ES admin-c: TECN2-RIPE tech-c: TECN3-RIPE status: ASSIGNED PA mnt-by: TECNOCRATICA-MNT created: 2019-06-25T10:27:56Z last-modified: 2019-06-25T10:27:56Z source: RIPE # Filtered Un objeto inet6num de Tecnocrática inet6num: 2a01:a940::/31 netname: ES-TECNOCRATICA-20120822 country: ES org: ORG-NS101-RIPE admin-c: TECN2-RIPE tech-c: TECN3-RIPE status: ALLOCATED-BY-RIR remarks: For abuse/spam related issues please contact [e-mail] mnt-by: RIPE-NCC-HM-MNT mnt-by: TECNOCRATICA-MNT mnt-lower: TECNOCRATICA-MNT mnt-routes: TECNOCRATICA-MNT created: 2019-07-25T13:02:27Z last-modified: 2019-07-25T13:02:27Z source: RIPE # Filtered 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. Filtrado Con la información del IRR podemos obtener por cada...