Autenticación de ruta BGP
Descripción de la autenticación de enrutador para BGP
El uso de la autenticación de enrutador y ruta y la integridad de la ruta mitiga en gran medida el riesgo de ser atacado por una máquina o enrutador que ha sido configurado para compartir información de enrutamiento incorrecta con otro enrutador. En este tipo de ataque, el enrutador atacado puede ser engañado para crear un bucle de enrutamiento, o la tabla de enrutamiento del enrutador atacado puede aumentarse considerablemente, lo que afecta el rendimiento, o la información de enrutamiento puede redirigirse a un lugar de la red para que el atacante la analice. Se pueden enviar anuncios de ruta falsos en un segmento. Estas actualizaciones se pueden aceptar en las tablas de enrutamiento de los enrutadores vecinos, a menos que exista un mecanismo de autenticación para verificar el origen de las rutas.
La autenticación de enrutador y ruta permite que los enrutadores compartan información solo si pueden verificar que están hablando con una fuente confiable, según una contraseña (clave). En este método, se envía una clave hash junto con la ruta que se envía a otro enrutador. El enrutador receptor compara la clave enviada con su propia clave configurada. Si son iguales, acepta la ruta. Mediante el uso de un algoritmo hash, la clave no se envía a través del cable en texto sin formato. En su lugar, se calcula un hash utilizando la clave configurada. La actualización de enrutamiento se utiliza como texto de entrada, junto con la clave, en la función hash. Este hash se envía junto con la actualización de la ruta al enrutador receptor. El enrutador receptor compara el hash recibido con un hash que genera en la actualización de ruta utilizando la clave previamente compartida configurada en él. Si los dos hashes son iguales, se supone que la ruta procede de una fuente de confianza. La clave sólo la conocen los enrutadores emisores y receptores.
Para reforzar aún más la seguridad, puede configurar una serie de claves de autenticación (un llavero). Cada llave tiene una hora de inicio única dentro del llavero. La autenticación de llavero le permite cambiar la información de la contraseña periódicamente sin interrumpir las sesiones de emparejamiento. Este método de autenticación de llavero se denomina sin visitas porque las claves se transfieren de una a otra sin restablecer ninguna sesión de emparejamiento ni interrumpir el protocolo de enrutamiento.
El par remitente utiliza las siguientes reglas para identificar la clave de autenticación activa:
La hora de inicio es menor o igual que la hora actual (en otras palabras, no en el futuro).
La hora de inicio es mayor que la de todas las demás claves de la cadena cuya hora de inicio es menor que la hora actual (en otras palabras, la más cercana a la hora actual).
El par receptor determina la clave con la que se autentica en función del identificador de clave entrante.
El par remitente identifica la clave de autenticación actual en función de una hora de inicio configurada y, a continuación, genera un valor hash con la clave actual. A continuación, el par remitente inserta un objeto de opción de autenticación mejorada TCP en el mensaje de actualización del BGP. El objeto contiene un ID de objeto (asignado por la IANA), la longitud del objeto, la clave actual y un valor hash.
El par receptor examina la opción de autenticación mejorada TCP entrante, busca la clave de autenticación recibida y determina si la clave es aceptable en función de la hora de inicio, la hora del sistema y el parámetro de tolerancia. Si se acepta la clave, el par receptor calcula un hash y autentica el mensaje de actualización.
La aplicación inicial de un llavero a una sesión TCP hace que la sesión se reinicie. Sin embargo, una vez que se aplica el llavero, la adición o eliminación de una contraseña del llavero no hace que se restablezca la sesión TCP. Además, la sesión TCP no se restablece cuando el llavero cambia de un algoritmo de autenticación a otro.
Consulte también
Autenticación TCP
Normalmente, la autenticación TCP se configura en los siguientes niveles de jerarquía:
-
[edit protocols bgp]
-
[edit protocols bgp group group-name]
-
[edit protocols bgp group group-name neighbor address]
Subredes de autenticación TCP y prefijo
Los dispositivos Junos admiten la autenticación TCP para pares BGP que se detectan a través de subredes de prefijos permitidos configuradas en un grupo BGP.
Para configurar la autenticación basada en prefijos para TCP-AO o TCP MD5 para sesiones BGP, puede configurar la allow (all | prefix-list)
instrucción en las siguientes jerarquías:
-
[edit protocols bgp group group-name]
-
[edit protocols bgp group group-name dynamic-neighbor dyn-name]
Para obtener más información acerca de la autenticación TCP, consulte TCP.
Ejemplo: Configuración de la autenticación de enrutador para BGP
Se pueden autenticar todos los intercambios de protocolos del BGP para garantizar que solo dispositivos de enrutamiento de confianza participen en las actualizaciones de enrutamiento del sistema autónomo (AS). De forma predeterminada, la autenticación está deshabilitada.
Requisitos
Antes de empezar:
Configure las interfaces del enrutador.
Configure un protocolo de puerta de enlace interior (IGP).
Descripción general
Cuando se configura la autenticación, el algoritmo crea una suma de comprobación codificada que se incluye en el paquete transmitido. El dispositivo de enrutamiento receptor utiliza una clave de autenticación (contraseña) para comprobar la suma de comprobación del paquete.
En este ejemplo se incluyen las siguientes instrucciones para configurar y aplicar el llavero:
key
—Un llavero puede tener varias llaves. Cada clave dentro de un llavero debe identificarse mediante un valor entero único. El intervalo de valores de identificador válidos es de 0 a 63.La clave puede tener hasta 126 caracteres. Los caracteres pueden incluir cualquier cadena ASCII. Si incluye espacios, escriba todos los caracteres entre comillas (" ").
tolerance
—(Opcional) Para cada llavero, puede configurar un valor de tolerancia sesgado del reloj en segundos. La tolerancia de sesgo de reloj es aplicable al receptor que acepta claves para actualizaciones de BGP. El rango configurable es de 0 a 999.999.999 segundos. Durante el período de tolerancia, se acepta la contraseña actual o la anterior.key-chain
—Para cada llavero, debe especificar un nombre. En este ejemplo se define un llavero:bgp-auth
. Puede tener varios llaveros en un dispositivo de enrutamiento. Por ejemplo, puede tener un llavero para BGP, un llavero para OSPF y un llavero para LDP.secret
—Para cada clave del llavero, debe establecer una contraseña secreta. Esta contraseña se puede introducir en formato cifrado o de texto sin formato en lasecret
instrucción. Siempre se muestra en formato cifrado.start-time
—Cada clave debe especificar una hora de inicio en formato UTC. El control se pasa de una clave a la siguiente. Cuando llega una hora de inicio configurada (según el reloj del dispositivo de enrutamiento), la clave con esa hora de inicio se activa. Las horas de inicio se especifican en la zona horaria local de un dispositivo de enrutamiento y deben ser únicas dentro del llavero.authentication-key-chain
: le permite aplicar un llavero en el nivel global de BGP para todos los pares, para un grupo o para un vecino. En este ejemplo se aplica el llavero a los pares definidos en el grupo BGP externo (EBGP) denominadoext
.authentication-algorithm
: para cada llavero, puede especificar un algoritmo hash. El algoritmo puede ser AES-128, MD5 o SHA-1.Asociar un llavero y un algoritmo de autenticación con una sesión vecina BGP.
En este ejemplo se configura un llavero denominado bgp-auth
. La clave 0 se enviará y aceptará a partir del 2011-6-23.20:19:33 -0700, y dejará de enviarse y aceptarse cuando se active la siguiente clave del llavero (clave 1). La clave 1 se activa un año después, en 2012-6-23.20:19:33 -0700, y no dejará de enviarse y aceptarse a menos que se configure otra clave con una hora de inicio posterior a la hora de inicio de la clave 1. Se aplica una tolerancia de sesgo de reloj de 30 segundos al receptor que acepta las llaves. Durante el período de tolerancia, se acepta la clave actual o la anterior. Las claves son contraseñas secretas compartidas. Esto significa que los vecinos que reciben las actualizaciones de enrutamiento autenticado deben tener la misma configuración de llavero de autenticación, incluidas las mismas claves (contraseñas). Por lo tanto, el enrutador R0 y el enrutador R1 deben tener la misma configuración de cadena de claves de autenticación si están configurados como pares. En este ejemplo se muestra la configuración en solo uno de los dispositivos de enrutamiento.
Diagrama de topología
Figura 1muestra la topología utilizada en este ejemplo.
Configuración
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit]
jerarquía.
set protocols bgp group ext type external set protocols bgp group ext peer-as 65530 set protocols bgp group ext neighbor 172.16.2.1 set routing-options autonomous-system 65533 set protocols bgp group ext authentication-key-chain bgp-auth set protocols bgp group ext authentication-algorithm md5 set security authentication-key-chains key-chain bgp-auth tolerance 30 set security authentication-key-chains key-chain bgp-auth key 0 secret this-is-the-secret-password set security authentication-key-chains key-chain bgp-auth key 0 start-time 2011-6-23.20:19:33-0700 set security authentication-key-chains key-chain bgp-auth key 1 secret this-is-another-secret-password set security authentication-key-chains key-chain bgp-auth key 1 start-time 2012-6-23.20:19:33-0700
Procedimiento
Procedimiento paso a paso
El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI de Junos OS.
Para configurar el enrutador R1 para que acepte filtros de ruta del dispositivo CE1 y realice un filtrado de rutas salientes con los filtros recibidos:
Configurar el sistema autónomo local.
[edit routing-options] user@R1# set autonomous-system 65533
Configure uno o varios grupos BGP.
[edit protocols bgp group ext] user@R1# set type external user@R1# set peer-as 65530 user@R1# set neighbor 172.16.2.1
Configure la autenticación con varias claves.
[edit security authentication-key-chains key-chain bgp-auth] user@R1# set key 0 secret this-is-the-secret-password user@R1# set key 0 start-time 2011-6-23.20:19:33-0700 user@R1# set key 1 secret this-is-another-secret-password user@R1# set key 1 start-time 2012-6-23.20:19:33-0700
La hora de inicio de cada llave debe ser única dentro del llavero.
Aplique el llavero de autenticación al BGP y establezca el algoritmo hash.
[edit protocols bgp group ext] user@R1# set authentication-key-chain bgp-auth user@R1# set authentication-algorithm md5
(Opcional) Aplique un valor de tolerancia de sesgo de reloj en segundos.
[edit security authentication-key-chains key-chain bgp-auth] user@R1# set tolerance 30
Resultados
Desde el modo de configuración, escriba los comandos , y show security
para confirmar la show protocols
configuración. show routing-options
Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@R1# show protocols bgp { group ext { type external; peer-as 65530; neighbor 172.16.2.1; authentication-key-chain bgp-auth; authentication-algorithm md5; } }
user@R1# show routing-options autonomous-system 65533;
user@R1# show security authentication-key-chains { key-chain bgp-auth { tolerance 30; key 0 { secret $ABC123$ABC123 start-time “2011-6-23.20:19:33 -0700”; } key 1 { secret $ABC123$ABC123 start-time “2012-6-23.20:19:33 -0700”; } } }
Cuando termine de configurar el dispositivo, ingrese commit
en el modo de configuración.
Repita el procedimiento para cada dispositivo habilitado para BGP de la red, utilizando los nombres de interfaz y las direcciones adecuados para cada dispositivo habilitado para BGP.
Verificación
Confirme que la configuración funcione correctamente.
- Comprobación de la autenticación para el vecino
- Comprobar que se envían mensajes de autorización
- Comprobación de errores de autenticación
- Verificación del funcionamiento del llavero
Comprobación de la autenticación para el vecino
Propósito
Asegúrese de que la AutheKeyChain
opción aparece en la salida del show bgp neighbor
comando.
Acción
Desde el modo operativo, ingrese el comando show bgp neighbor
.
user@R1> show bgp neighbor Peer: 172.16.2.1+179 AS 65530 Local: 172.16.2.2+1222 AS 65533 Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ direct-lo0 ] Options: <Preference PeerAS Refresh> Options: <AutheKeyChain> Authentication key is configured Authentication key chain: jni Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 172.16.2.1 Local ID: 10.255.124.35 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 Local Interface: fe-0/0/1.0 NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 2 Received prefixes: 2 Suppressed due to damping: 0 Advertised prefixes: 1 Last traffic (seconds): Received 2 Sent 2 Checked 2 Input messages: Total 21 Updates 2 Refreshes 0 Octets 477 Output messages: Total 22 Updates 1 Refreshes 0 Octets 471 Output Queue[0]: 0
Comprobar que se envían mensajes de autorización
Propósito
Confirme que BGP tiene la opción de autorización mejorada.
Acción
Desde el modo operativo, ingrese el comando monitor traffic interface fe-0/0/1
.
user@R1> monitor traffic interface fe-0/0/1 verbose output suppressed, use <detail> or <extensive> for full protocol decode Listening on fe-0/0/1, capture size 96 bytes 13:08:00.618402 In arp who-has 172.16.2.66 tell 172.16.2.69 13:08:02.408249 Out IP 172.16.2.2.1122 > 172.16.2.1.646: P 1889289217:1889289235(18) ack 2215740969 win 58486 <nop,nop,timestamp 167557 1465469,nop,Enhanced Auth keyid 0 diglen 12 digest: fe3366001f45767165f17037>: 13:08:02.418396 In IP 172.16.2.1.646 > 172.16.2.2.1122: P 1:19(18) ack 18 win 57100 <nop,nop,timestamp 1466460 167557,nop,Enhanced Auth keyid 0 diglen 12 digest: a18c31eda1b14b2900921675>: 13:08:02.518146 Out IP 172.16.2.2.1122 > 172.16.2.1.646: . ack 19 win 58468 <nop,nop,timestamp 167568 1466460,nop,Enhanced Auth keyid 0 diglen 12 digest: c3b6422eb6bd3fd9cf79742b> 13:08:28.199557 Out IP 172.16.2.2.nerv > 172.16.2.1.bgp: P 286842489:286842508(19) ack 931203976 win 57200 <nop,Enhanced Auth keyid 0 diglen 12 digest: fc0e42900a73736bcc07c1a4>: BGP, length: 19 13:08:28.209661 In IP 172.16.2.1.bgp > 172.16.2.2.nerv: P 1:20(19) ack 19 win 56835 <nop,Enhanced Auth keyid 0 diglen 12 digest: 0fc8578c489fabce63aeb2c3>: BGP, length: 19 13:08:28.309525 Out IP 172.16.2.2.nerv > 172.16.2.1.bgp: . ack 20 win 57181 <nop,Enhanced Auth keyid 0 diglen 12 digest: ef03f282fb2ece0039491df8> 13:08:32.439708 Out IP 172.16.2.2.1122 > 172.16.2.1.646: P 54:72(18) ack 55 win 58432 <nop,nop,timestamp 170560 1468472,nop,Enhanced Auth keyid 0 diglen 12 digest: 76e0cf926f348b726c631944>: 13:08:32.449795 In IP 172.16.2.1.646 > 172.16.2.2.1122: P 55:73(18) ack 72 win 57046 <nop,nop,timestamp 1469463 170560,nop,Enhanced Auth keyid 0 diglen 12 digest: dae3eec390d18a114431f4d8>: 13:08:32.549726 Out IP 172.16.2.2.1122 > 172.16.2.1.646: . ack 73 win 58414 <nop,nop,timestamp 170571 1469463,nop,Enhanced Auth keyid 0 diglen 12 digest: 851df771aee2ea7a43a0c46c> 13:08:33.719880 In arp who-has 172.16.2.66 tell 172.16.2.69 ^C 35 packets received by filter 0 packets dropped by kernel
Comprobación de errores de autenticación
Propósito
Compruebe el número de paquetes caídos por TCP debido a errores de autenticación.
Acción
Desde el modo operativo, ingrese el comando show system statistics tcp | match auth
.
user@R1> show system statistics tcp | match auth 0 send packets dropped by TCP due to auth errors 58 rcv packets dropped by TCP due to auth errors
Verificación del funcionamiento del llavero
Propósito
Compruebe el número de paquetes caídos por TCP debido a errores de autenticación.
Acción
Desde el modo operativo, ingrese el comando show security keychain detail
.
user@R1> show security keychain detail keychain Active-ID Next-ID Transition Tolerance Send Receive Send Receive bgp-auth 3 3 1 1 1d 23:58 30 Id 3, Algorithm hmac-md5, State send-receive, Option basic Start-time Wed Aug 11 16:28:00 2010, Mode send-receive Id 1, Algorithm hmac-md5, State inactive, Option basic Start-time Fri Aug 20 11:30:57 2010, Mode send-receive
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.