Episode Details

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:

1. Secuestro de prefijos.
2. Fugas de ruta.
3. 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:

1. Validación: Publicar información de routing en lugares que se puedan validar por cualquiera.
2. Filtrado: Filtrar para anunciar con exactitud los prefijos propios y de sus clientes, filtrando el resto.
3. Antisuplantación: Impedir el tráfico desde IPs suplantadas.
4. 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 abuse@tecnocratica.net
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