RPKI en MikroTik – Routinator en RouterOS v7 Container

routinator-logo

RPKI en MikroTik usando Container RouterOS v7

¿Qué es RPKI?

En este artículo vamos a explicar como utilizar Routinator en un Container en MikroTik RouterOS v7. Pero antes de ello se hace imprescindible explicar que es RPKI.

Imagina que el mundo de internet es como una gran ciudad llena de edificios (routers) donde cada uno tiene su propia identidad. A veces, las «carreteras» (anuncios de rutas BGP) que conectan estos edificios pueden ser falsas, lo que lleva a problemas y confusión. Aquí es donde entra en juego RPKI, un sistema de seguridad inteligente diseñado para verificar esas conexiones y hacer que todo sea más confiable.

RPKI, que significa Resource Public Key Infrastructure, utiliza un conjunto de reglas y directrices establecidas en el RFC 6480, que es básicamente como su manual de operaciones. Este documento te dice cómo funciona RPKI y cómo se comunican sus componentes entre sí.

En este sistema de seguridad, los sistemas autónomos (AS) son como los barrios de la ciudad que agrupan a los edificios. Cada sistema autónomo tiene un número único y es responsable de ciertas partes de internet. Para asegurarse de que estos sistemas autónomos se comuniquen de manera auténtica, RPKI emite lo que se llaman Certificados de Recurso, que son los identificaciones digitales para estos sistemas. Cada sistema autónomo obtiene su propio certificado.

Pero aquí viene lo interesante: para verificar que un sistema autónomo está autorizado para anunciar ciertas rutas (caminos de tráfico) en internet, se utilizan ROAs (Anotaciones de Origen de Ruta). Estas ROAs son como contratos digitales que establecen qué sistema autónomo tiene permiso para manejar que rutas. Es como si cada edificio tuviera un permiso específico para construir una carretera en la ciudad.

Cuando se anuncian rutas mediante eBGP, RPKI entra en acción. Verifica si estas rutas coinciden con las ROAs, lo que garantiza que solo las rutas autorizadas sean utilizadas y que no haya «rutas falsas» que puedan llevar a problemas de seguridad o rendimiento.

En resumen, RPKI, el RFC6480 y en su desarrollo el RFC8210 son como los árbitros de confianza en el mundo de interconexión de redes mediante eBGP. Establecen reglas para que los sistemas autónomos se identifiquen de manera segura y usen rutas autorizadas mediante certificados, ROAs y verificaciones BGP. Esto reduce el riesgo de anuncios de rutas falsas y ayuda a mantener una experiencia en línea más segura y confiable para todos nosotros.

routinator-rocket

Descripción

MikroTik desde la version 7.0beta7 implementa la funcionalidad RPKI y desde la versión 7.4beta4 se introdujo la característica para poder utilizar containers alojados en la propia RouterBoard. Los contenedores ofrecen eficiencia, velocidad, portabilidad y administración simplificada en comparación con las máquinas virtuales tradicionales. Son ideales para aplicaciones que necesitan una implementación ágil, escalabilidad rápida y un uso eficiente de recursos.

Routinator es un paquete de software RPKI Relying Party, diseñado por los amigos de NLnetLabs, que se ejecuta como un servicio que descarga y verifica periódicamente los datos RPKI. Los routers pueden conectarse a una máquina ejecutando Routinator para obtener datos verificados mediante el protocolo RPKI-to-Router (RTR) RFC 8210 El servidor HTTP integrado ofrece una interfaz de usuario y puntos finales API para los distintos formatos de archivo, así como registro, estado y métricas Prometheus.

Descripción del Laboratorio

En este laboratorio, prepararemos un escenario donde instalaremos Routinator en un container alojado en el propio MikroTik.

Objetivos de la práctica

  • Conocer el funcionamiento de RPKI
  • Establecer una conexión entre un router y un sistema RTR
  • Verificar la configuración realizada.

Configuración paso a paso

Antes de comenzar con la configuración, un detalle muy importante a resaltar: vamos a hacer una configuración que es altamente exigente con los recursos del equipo anfitrión, vigila la cantidad disponible de memoria RAM y de espacio de almacenamiento o podrás tener errores asociados a la carencia de los mismos.

Cuestiones importantes referida a los containers:

  • Se necesita acceso físico al router para activar la función de contenedor, que está desactivada por defecto;
  • Una vez habilitada la función de contenedor, los contenedores pueden ser añadidos/configurados/iniciados/parados/eliminados remotamente.
  • Si el router se ve comprometido, los contenedores pueden utilizarse para instalar fácilmente software malicioso en su router y a través de la red;
  • Tu router es tan seguro como cualquier cosa que ejecutes en contenedor;
  • Si ejecutas contenedores, no hay garantía de seguridad de ningún tipo;
  • Ejecutar una imagen de contenedor de terceros en tu router podría abrir un agujero de seguridad/vector de ataque/superficie de ataque;
  • Un experto con conocimientos de cómo construir exploits será capaz de jailbreak o elevar a root;

Para poder utilizar esta práctica necesitamos equipos con arquitectura ARM, ARM64 o x86

Este laboratorio da por supuesto que tu RouterBoard tiene comunicación con internet, DNS, etc con una configuración básica y que el firewall está configurado de manera que permita conexiones entrantes por la interfaz WAN.

1. Configurar el MikroTik para poder utilizar containers.

Necesitamos la versión de RouterOS v7.4beta o superior. Instalamos el paquete extra container con cualquier método conocido, por ejemplo picar y arrastrar el archivo hasta la carpeta Files de nuestro MikroTik.

[admin@RouterOS] > /system/device-mode/update container=yes

Nos aparecerá un mensaje y un contador con una cuenta atrás para activar la funcionalidad. Para esto necesitamos manipular físicamente el dispositivo, quitándole directamente la alimentación de corriente eléctrica o pulsando el botón de reset una vez. Cuándo el router se reinicie, tendremos la característica de Containers activada.

2. Conexión con los containers

Ahora configuraremos una interfaz ethernet virtual, con su dirección IP en un bridge, donde se produzca la conectividad de los containers y creamos las reglas de NAT para que nuestro container se pueda comunicar con internet en los puertos necesarios.

[admin@RouterOS] > /interface/veth add address=172.16.72.5/24 gateway=172.16.72.1 name=veth5
[admin@RouterOS] > /interface/bridge add name=bridge_containers
[admin@RouterOS] > /interface/bridge/port add bridge=bridge_containers interface=veth5
[admin@RouterOS] > /ip/address add address=172.16.72.1/24 interface=bridge_containers
[admin@RouterOS] > /ip/firewall/nat add action=dst-nat chain=dstnat dst-port=3323 in-interface=wan protocol=tcp to-addresses=172.16.72.5 to-ports=3323
[admin@RouterOS] > /ip/firewall/nat add action=dst-nat chain=dstnat dst-port=8323 in-interface=wan protocol=tcp to-addresses=172.16.72.5 to-ports=8323
[admin@RouterOS] > /ip/firewall/nat add action=dst-nat chain=dstnat dst-port=9556 in-interface=wan protocol=tcp to-addresses=172.16.72.5 to-ports=9556

3. Instalar Routinator

A continuación procederemos a utilizar las repos de DockerHub donde se encuentra Routinator, descargamos la imagen y creamos el container.

[admin@RouterOS] > /container/config set registry-url=https://registry-1.docker.io tmpdir=pull
[admin@RouterOS] > /container/add remote-image=nlnetlabs/routinator:latest interface=veth5 root-dir=disk1 logging=yes start-on-boot=yes

4. Iniciar el container y conexión por consola

[admin@RouterOS] > /container/start 0
[admin@RouterOS] > /container/shell 0

5. Configuración Routinator

Utilizaremos la configuración básica de Routinator por defecto para simplificar este laboratorio. Es recomendable iniciar un test una vez funcionando, para eso utilizaremos el siguiente comando:

/ # routinator -vv vrps

Podemos comprobar ahora como Routinator se conecta a los Trust Anchor RPKI, se descarga el contenido de los repositorios, lo verifica y produce una lista de VRP (validated ROA payload).

[INFO] Using the following TALs:
[INFO]   * afrinic
[INFO]   * apnic
[INFO]   * arin
[INFO]   * lacnic
[INFO]   * ripe
[DEBUG] Found valid trust anchor https://rpki.ripe.net/ta/ripe-ncc-ta.cer. Processing.
[DEBUG] Found valid trust anchor https://rrdp.lacnic.net/ta/rta-lacnic-rpki.cer. Processing.
[DEBUG] Found valid trust anchor https://rpki.afrinic.net/repository/AfriNIC.cer. Processing.
[DEBUG] Found valid trust anchor https://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer. Processing.
[DEBUG] Found valid trust anchor https://rrdp.arin.net/arin-rpki-ta.cer. Processing.
[DEBUG] RRDP https://rrdp.ripe.net/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.lacnic.net/rrdp/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.apnic.net/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.afrinic.net/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.arin.net/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.apnic.net/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rpki-rrdp.us-east-2.amazonaws.com/rrdp/08c2f264-23f9-49fb-9d43-f8b50bec9261/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rpki-rrdp.us-east-2.amazonaws.com/rrdp/08c2f264-23f9-49fb-9d43-f8b50bec9261/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rpki.akrn.net/rrdp/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rpki.akrn.net/rrdp/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rpki.admin.freerangecloud.com/rrdp/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rpki.admin.freerangecloud.com/rrdp/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rpki.cnnic.cn/rrdp/notify.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.ripe.net/notification.xml: snapshot update completed.
[DEBUG] RRDP https://0.sb/rrdp/notification.xml: updating from snapshot.
[DEBUG] RRDP https://0.sb/rrdp/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rrdp.sub.apnic.net/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.sub.apnic.net/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rpki.roa.net/rrdp/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rpki.roa.net/rrdp/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rrdp.rp.ki/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rpki.cnnic.cn/rrdp/notify.xml: snapshot update completed.
...
ASN,IP Prefix,Max Length,Trust Anchor
AS137884,103.116.116.0/23,23,apnic
AS9003,91.151.112.0/20,20,ripe
AS38553,120.72.19.0/24,24,apnic
AS58045,37.209.242.0/24,24,ripe
AS9583,202.177.175.0/24,24,apnic
AS50629,2a0f:ba80::/29,29,ripe
AS398085,2602:801:a008::/48,48,arin
AS21050,83.96.22.0/24,24,ripe
AS55577,183.82.223.0/24,24,apnic
AS44444,157.167.73.0/24,24,ripe
AS197695,194.67.97.0/24,24,ripe
...

6. Configuración en RouterOS para utilizar RPKI

Una vez configurado Routinator, necesitamos crear las reglas para que BGP utilice los filtros adecuados y se produzca la validación correctamente, en caso contrario, rechazamos ese prefijo. En este Lab de ejemplo utilizaremos IPs de Loopback genéricas y AS de documentación.

[admin@RouterOS] > /routing/rpki add address=172.16.72.5 group=RPKI-Group port=3323
[admin@RouterOS] > /routing/filter/rule add chain=BGP-In rule="rpki-verify RPKI-Group"
[admin@RouterOS] > /routing/filter/rule add chain=BGP-In disabled=no rule="if (rpki invalid) { reject } else { accept }"
[admin@RouterOS] > /routing/bgp/connection add name=bgp-ISP1 as=65001 connect=yes listen=yes disabled=no input.filter=BGP-In local.address=10.0.0.1
local.role=ebgp remote.address=10.0.0.2/32 remote.as=65002 router-id=10.0.0.1

7. Comprobación

Ahora comprobaremos mensajes válidos, inválidos y desconocidos usando diferentes AS y diferentes prefijos.

[admin@RouterOS] > /routing/rpki/rpki-check origin-as=15169 prefix=8.8.8.0/24 group=RPKI-Group

Este laboratorio es una prueba de concepto acerca de estas tecnologías y estándares. En caso de querer realizar estas configuraciones en producción, la recomendación es liberar de recursos a nuestra RouterBoard para su principal cometido (en este caso eBGP y RPKI) y que sea un servidor dedicado el que gestione propiamente los containers o máquinas virtuales.

En el Máster en Arquitectura de Redes de Operadores de Telecomunicaciones, y en las certificaciones oficiales de MikroTik impartidas en loopback0 (MTCINE), explicamos en profundidad los diferentes tipos de configuraciones BGP, explicando en profundidad filtros, así como los métodos de configuración, características, pros y contras.

/por