ON THIS PAGE
Configurando RPKI: Infraestructura de claves públicas de recursos
En el capítulo Introducción a la Introducing Routing Security , vio cómo el RPKI proporciona seguridad de enrutamiento mediante la validación de anuncios de prefijos de as. También debe haber creado ROAs para sus propios prefijos IP. Ahora es’hora de iniciar sesión en el enrutador y configurar RPKI! Este capítulo crea un equipo que ejecuta un validador RPKI y configura su red para que se comunique con él, asegurándose de que sus enrutadores pueden utilizar RPKI para validar los anuncios de prefijos.
Instalar el validador RPKI
Su enrutador no realiza realmente la comprobación criptográfica de los certificados. En su lugar, lo ejecuta en un equipo de su propia red que descarga el ROAs desde los anclajes de veracidad y proporciona un servicio para que los enrutadores hablen. La historia se inicia mediante la instalación de un validador en algún lugar dentro de su propia red.
En el momento de redactar este escrito, hay dos validadores RPKI preparados para la producción disponibles. A medida que cada vez más redes implementan RPKI, es probable que aparezcan más validadores en el futuro. Para ayudarle’a comenzar a abordar uno de los validadores, uno desarrollado y mantenido por el NCC RIPE.
El otro validador de categoría de producción ha sido desarrollado y es mantenido por NLnet Labs. Encontrará más información sobre este validador en: https://nlnetlabs.nl/projects/rpki/routinator/. (No’es la intención de los autores que adopten una de las dos direcciones – a las que acabamos de elegir un validador para el ejemplo.)
El validador de RPKI RIPE está escrito en Java y requiere un equipo (físico o virtual) con al menos 2 GB de RAM, 1 CPU y OpenJDK 8 instalados. Asegúrese de que el equipo puede conectarse a Internet (para sincronizar ROAs con los anclajes de veracidad) y que el equipo es alcanzable desde sus enrutadores.
Por razones de seguridad, debe aplicar reglas de seguridad distintas y estrictas en su servidor de seguridad para asegurarse de que solo se puede llegar a las partes adecuadas del equipo, especialmente la cara expuesta a Internet, que obviamente necesita atención especial.
El proyecto Validator RPKI madurable consta de dos unidades que se implementan por separado:
El propio validador RPKI: de este modo, se descargarán y procesarán todos los objetos como certificados, manifiestos, CRL, ROAs, certificados de enrutador y registros de Ghostbuster; almacena en caché los datos de RPKI y tiene una interfaz de usuario (Web) para la resolución de problemas y permitir la inscripción.
El servidor RPKI-RTR: Este es el elemento al que se conectan realmente los enrutadores.
El servidor RPKI-RTR está configurado como una instancia independiente ya que no todos los usuarios necesitan ejecutarlo y, lo que es más importante, si necesita ejecutarlo, el demonio independiente le permite ejecutar más de una instancia para redundancia (mantiene el estado incluso cuando el validador está inactivo).
La ejecución de validadores redundantes en la red es, al igual que los enrutadores redundantes, una buena estrategia. Dado que hay varios validadores disponibles, también es posible ejecutar una configuración de varios proveedores. Lo bueno es que si no hay un validador disponible, todas las rutas de la tabla de enrutamiento se marcarán como desconocida para que solo pueda perder el estado de validación y que no haya información de enrutamiento real.
En esquema, este es el modo en que los flujos de comunicación:
Para instalar el validador de NCC RIPE V3, siga las instrucciones de instalación en: https://github.com/RIPE-NCC/rpki-validator-3/wiki/RIPE-NCC-RPKI-Validator-3-Production.
De forma predeterminada, el validador solo escuchará en localhost. Para poder tener acceso a la interfaz web (donde puede comprobar el estado de las rutas, así como aplicar AllowList entradas), edite el archivo de configuración del validador:
# vi /etc/rpki-validator-3/application.properties
Y asegúrese de que el servidor no tiene comentarios ni cambia. línea de dirección a:
server.address= <ip address>
Esto hace que el sitio web del validador esté disponible globalmente en su servidor’s dirección IP pública, que puede no ser lo que desea. Por lo tanto, puede usar iptables para cerrar Access asegurándose de que tiene las líneas siguientes en la ventana Config:
iptables -A INPUT -s <management-prefix> -p tcp -m tcp --dport 8080 -j ACCEPT iptables -A INPUT -p tcp -m tcp --dport 8080 -j REJECT --reject-with icmp-port-unreachable
Sustitui <management-prefix> con un prefijo que puede alcanzar la interfaz Web.
El localizador de anclaje de veracidad (TAL) de todos los RIRs se incluye en la distribución de software, con una excepción: ARIN. Por desgracia, se deben tomar algunos complicados pasos adicionales para incluir su anclaje de veracidad en el proceso de verificación. Para obtener el TAL ARIN, vaya a su página web en https://www.arin.net/Resources/RPKI/tal.html, asegúrese de estar de acuerdo con los términos establecidos y descargue el tal en el formato de validador de NCC RIPE. Coloque el archivo TAL en su directorio principal en el validador Server.
Por último, utilice el upload-tal.sh secuencia de comandos para cargar el TAL ARIN en el validador:
# /usr/bin/upload-tal.sh arin-ripevalidator.tal http://localhost:8080/
A continuación, reinicie el validador:
# systemctl restart rpki-validator-3
Ahora puede buscar la dirección IP pública del validador, el puerto 8080, y verá una página web que enumera los anclajes de veracidad configurados, tal Figure 2y como se muestra en la.
Ahora es necesario llevar a cabo el mismo ejercicio para el software RPKI-RTR. Esta es la parte que se comunica con los enrutadores y les permite crear su base de datos de validación. Después de la instalación, edit /etc/rpki-rtr-server/application.properties para quitar los comentarios de las líneas que indican a la aplicación en qué dirección IP se debe escuchar para la interfaz web (futura) y el servicio RTR:
server.address= rtr.server.address=<your server’s public IP>
Por último, si utiliza iptables para limitar el acceso a los puertos 8081 (interfaz web RTR) y 8323 (servicio RTR), es probable que el acceso a la interfaz web sea el mismo que para el software validador que acaba de explicar; el acceso al servicio RTR debe limitarse a las direcciones IP desde las que los enrutadores tendrán acceso al validador (normalmente será la dirección de lo0 o la dirección de la interfaz “más cercana” al servidor y, por lo tanto, utilizada para el tráfico saliente al servidor):
iptables -A INPUT -s <management-prefix> -p tcp -m tcp --dport 8081 -j ACCEPT iptables -A INPUT -p tcp -m tcp --dport 8081 -j REJECT --reject-with icmp-port-unreachable iptables -A INPUT -s <router-prefix> -p tcp -m tcp --dport 8323 -j ACCEPT iptables -A INPUT -p tcp -m tcp --dport 8323 -j REJECT --reject-with icmp-port-unreachable
Reinicie el servidor RPKI-RTR:
# systemctl restart rpki-rtr-server
Conectar los enrutadores al validador
El primer paso para utilizar los datos de validación de origen de su enrutador Juniper Networks es configurar la comunicación con el validador. En este ejemplo, el validador tiene IPv6 Address 2001: db8:: F00: BAA y la dirección de los enrutadores es 2001: db8:: 1. Esto también funcionará con IPv4.
Obviamente, ambos’no tienen que estar en la misma subred. Pero deben poder comunicarse entre sí en el puerto RTR (en la configuración estándar, es decir, el puerto TCP 8323). Asegúrese de que ha abierto este puerto en los firewalls intermedios y’no se olvide de ajustar el filtro de firewall en la’interfaz de bucle s de enrutador para permitir la comunicación con el validador. Se utilizan los términos caché y validador ; la caché forma parte del validador y contiene la información de ROA. En este contexto, usamos el Term Validator para identificar ambos, y no distinguiremos entre cache y el Validator:
Los comandos para conseguir esta configuración son:
Después de confirmar la configuración del candidato, su enrutador configurará una sesión de validación. Puede ver el estado de la sesión con:
user@router> show validation session Session State Flaps Uptime #IPv4/IPv6 records 2001:db8::f00:baa Up 0 00:00:47 0/0
Si la sesión no se enciende, solucione los problemas de conectividad entre el enrutador y el equipo que ejecuta el validador. No olvide ajustar los enrutadores filtro de Firewall de bucle y/o cualquier iptables o firewall en la ruta de acceso o un firewall en el validador. Asegúrese de tener en cuenta la dirección de origen utilizada en el enrutador.
Configure los enrutadores para etiquetar RPKI rutas válidas
La base de datos de validación es una entidad independiente’en la memoria del enrutador. Las entradas de la base de datos de validación no lo convierten automáticamente en la tabla de enrutamiento (lo que sólo se encuentra en la tabla de reenvío). Si hace RPKI trabajo para su red significa que tiene que configurar una directiva que examinará el estado de cada uno de los prefijos y que etiquete la ruta correspondiente en la tabla de enrutamiento. Ahora, el estado RPKI de las rutas de la tabla de enrutamiento se adjuntará a estas rutas. El último paso consiste en usar el estado RPKI para aceptar o rechazar rutas (o bien, tomar otra AC sobre ellas si es necesario) tal y Figure 3como se muestra en la.
Aceptar y rechazar anuncios comprobados RPKI
Dado que el validador RPKI se ha instalado y está disponible en los enrutadores, aún no ha ocurrido nada en la tabla de enrutamiento. Ahora es’hora de actualizar sus políticas de enrutamiento y de hecho algo con la información de RPKI.
La base de datos de validación contiene prefijos, longitudes de prefijo y números de sistema autónomos. La Directiva de enrutamiento usa esta información para decidir qué rutas tomar de la base de información de enrutamiento (RIB) e instalar en la base de información de reenvío (FIB).
Hay tres Estados RPKI posibles en la base de datos de validación: válido, no válido y desconocido. Dado que la mayoría de las redes del mundo solo están en la fase de inicio de la implementación de RPKI, la mayoría de las rutas serán de estado desconocido. Su tarea consiste en aceptar las rutas desconocidas y válidas, y rechazar las rutas no válidas. Además, agregue una marca a BGP – comunidad que lleve conteniendo cada ruta. Esto hará que la solución de problemas sea más fácil y permitirá que los clientes vean también la información de su RPKI.
En el fragmento de configuración siguiente, creamos una directiva a la que puede llamar desde otras políticas de enrutamiento. Toma el estado RPKI en la base de datos de validación y, a continuación, establece el estado de validación correspondiente a medida que la ruta pasa al nervio. Además, la Directiva establece una BGP comunidad como un indicador que muestra el estado RPKI del prefijo. Tenga en cuenta que ninguno de los términos de esta directiva aceptan ni rechazan realmente la ruta; la política es únicamente para etiquetar los prefijos que van al saliente.
Puede especificar esta directiva cortando y pegando las siguientes líneas:
Además, definir las comunidades utilizadas:
Estas comunidades son conocidas, grandes comunidades para etiquetar rutas con su estado RPKI, tal y como se ve desde su red. Las comunidades para RPKI rutas desconocidas y RPKI válidas se agregan solo para fines de informidad. Sin embargo, más tarde usará la comunidad para RPKI rutas no válidas para rechazar estas RPKI rutas no válidas.
La política RPKI-CHECK realmente no acepta ni rechaza rutas. Solo examina la base de datos de validación de cada ruta que la pasa y establece el estado RPKI para estas rutas en el nervio, así como la adición de la comunidad informativa BGP.
Ahora, agregará la Directiva RPKI-CHECK al principio de cada directiva de importación en la red, lo que significa que en el BGP sesiones con:
proveedores de tránsito
pares
a
Las prácticas recomendadas son agregar el RPKI-CHECK Stanza a todas sus políticas de importación. Por ejemplo, debe agregar al principio de cada directiva de importación del enrutador:
De nuevo, observe que esto no rechaza en realidad RPKI rutas no válidas. Por lo tanto, el último paso en una tabla de enrutamiento protegida por RPKI es agregar (en algún lugar después del término RPKI-CHECK) como el término:
Si confirma estos cambios ahora, los’ll empezarán a rechazar RPKI rutas no válidas. En el momento de redactar este punto (temprano 2019)’que s unos 6000 prefijos no válidos que no estarán presentes en la tabla de enrutamiento. Puede comprobar las rutas mediante comandos como:
Ninguna de las rutas no válidas debe estar activa en la tabla de enrutamiento.
Siga leyendo’si no está seguro de cómo se encajan todas las políticas en el esquema general de elementos. En la sección configuración de directivas’de Configuring Routing Policies , suponemos que presenta una directiva de importación unificada que constituye la base de su tabla de enrutamiento segura.
Soporte de’proveedor de enrutador para RPKI
Este manual, que forma parte de Junipers Day One series, explica las técnicas y recetas para implementar RPKI en enrutadores de Juniper.’ Sin embargo, para que funcione la validación de RPKI, todos los enrutadores (de borde) tendrán que implementarlo. Deben validarse todas las rutas que aprenda de otras partes (clientes, colegas, tránsitos). En caso de que los enrutadores (de borde) no admitan RPKI, seguirán aceptando rutas no válidas’e instalarlas en la tabla de enrutamiento de la red.
Para facilitarle la averiguación de cómo se realizará correctamente su implementación de RPKI, compilamos una lista de software de enrutamiento que admite RPKI:
Juniper Networks ha admitido el software de enrutamiento que se enumera a continuación desde la Junos OS versión 12,2 (se recomienda tener en cuenta PR1309944).
Cisco
XR 4.2.1 (CRS-x, ASR9000, c12K)/XR 5.1.1 (NCS6000, XRv)
XE 3,5 (C7200, C7600, ASR1K, CSR1Kv, ASR9k, ME3600…)
IOS 15.2 (1) S
Alcatel Lucent ha tenido soporte desde el SR-OS 12,0 R4.
Nokia (R 12.0 R4):
7210 SAS
7750 SR
7950 XRS
VSR
Quagga admite a través de la BGP: SrX o RTRLib.
PÁJARO es compatible con ROA y admite RPKI-RTR de la versión 2,0 o Via RTRLib
GoBGP
FRRouting
OpenBGPD (compatibilidad con validación de origen mediante configuración estática)
Conclusión
Ya ha configurado un validador de RPKI y el enrutador se está comunicando con él. El enrutador ahora tiene una base de datos de validación y para cada prefijo, sabe si es válida, no es válida o no se ha comprobado. Esta información la ha convertido en la tabla de enrutamiento y RPKI se rechazan las rutas no válidas. Por si es todo lo que quería conseguir, enhorabuena y puede saltarse el capítulo 4 y pasar directamente al capítulo 5, donde trataremos la solución de problemas de RPKI. Sin embargo, esperamos que solo siga leyendo.
En el capítulo sobre la Configuring Routing Policies ,’continuará con el servicio de seguridad y aplique’políticas de enrutamiento a las rutas que haya aprendido de los traspasos, de los interlocutores y de los clientes.