Autenticación de ruta BGP
Descripción de la autenticación de enrutador para BGP
El uso de autenticación de enrutador y ruta e integridad de ruta mitiga en gran medida el riesgo de ser atacado por una máquina o enrutador que se ha configurado para compartir información de enrutamiento incorrecta con otro enrutador. En este tipo de ataque, se puede engañar al enrutador atacado para crear un bucle de enrutamiento, o se puede aumentar en gran medida la tabla de enrutamiento del enrutador atacado, lo que afecta el rendimiento, o la información de enrutamiento se puede redirigir a un lugar de la red para que el atacante la analice. Anuncios de ruta falsa se pueden enviar en un segmento. Estas actualizaciones se pueden aceptar en las tablas de enrutamiento de enrutadores vecinos, a menos que haya un mecanismo de autenticación para verificar el origen de las rutas.
La autenticación de enrutador y ruta permite a los enrutadores compartir información solo si pueden verificar que están hablando con una fuente de confianza, 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 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 con 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 ruta al enrutador receptor. El enrutador receptor compara el hash recibido con un hash que genera en la actualización de ruta mediante la clave previamente compartida configurada en ella. Si los dos hash son los mismos, se da por sentado que la ruta proviene de un origen de confianza. La clave solo la conocen los enrutadores de envío y recepción.
Para reforzar aún más la seguridad, puede configurar una serie de claves de autenticación (un llavero). Cada clave tiene una hora de inicio única dentro del llavero. La autenticación de llavero le permite cambiar la información de contraseña periódicamente sin desactivar las sesiones de emparejamiento. Este método de autenticación de llavero se conoce como sin golpe porque las claves se pasan de una a otra sin restablecer ninguna sesión de emparejamiento ni interrumpir el protocolo de enrutamiento.
El par de envío 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 (es decir, la más cercana a la hora actual).
El par de recepción determina la clave con la que se autentica según el identificador de clave entrante.
El par de envío identifica la clave de autenticación actual según un tiempo de inicio configurado y, a continuación, genera un valor hash mediante la clave actual. A continuación, el par de envío inserta un objeto de opción de autenticación mejorado por TCP en el mensaje de actualización del BGP. El objeto contiene un ID de objeto (asignado por IANA), la longitud del objeto, la clave actual y un valor hash.
El par de recepción examina la opción de autenticación entrante mejorada por TCP, busca la clave de autenticación recibida y determina si la clave es aceptable según 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 restablezca. Sin embargo, una vez que se aplica el llavero, la adición o eliminación de una contraseña del llavero no hace que la sesión TCP se restablezca. 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, se configura la autenticación TCP en los siguientes niveles jerárquicos:
-
[edit protocols bgp] -
[edit protocols bgp group group-name] -
[edit protocols bgp group group-name neighbor address]
Subredes de prefijo y autenticación TCP
Los dispositivos Junos admiten la autenticación TCP a los pares del BGP que se descubren mediante subredes de prefijo permitidas configuradas en un grupo de BGP.
Para configurar la autenticación basada en prefijos para TCP-AO o TCP MD5 para sesiones de 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 los 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 configure la autenticación, el algoritmo crea una suma de comprobación codificada que se incluye en el paquete transmitido. El dispositivo de enrutamiento de recepción usa 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 claves. Cada clave de un llavero debe identificarse por un valor entero único. El intervalo de valores de identificador válidos es del 0 al 63.La clave puede tener una longitud de hasta 126 caracteres. Los caracteres pueden incluir cualquier cadena ASCII. Si incluye espacios, encierre todos los caracteres entre comillas (" ").
tolerance—(Opcional) Para cada llavero, puede configurar un valor de tolerancia de desviación de reloj en segundos. La tolerancia a la desviación del reloj es aplicable a que el receptor acepte claves para las actualizaciones del BGP. El rango configurable es de 0 a 999,999,999 segundos. Durante el período de tolerancia, la contraseña actual o anterior es aceptable.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 de texto cifrado o sin formato en lasecretinstrucció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. Los tiempos de inicio se especifican en la zona horaria local para un dispositivo de enrutamiento y deben ser únicos dentro del llavero.authentication-key-chain— Le permite aplicar un llavero a nivel global del 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.Asocia un llavero y un algoritmo de autenticación con una sesión vecina del BGP.
En este ejemplo, se configura un llavero denominado bgp-auth. La clave 0 será enviada y aceptada a partir de 2011-6-23.20:19:33 -0700, y dejará de ser enviada y aceptada cuando la siguiente clave en el llavero (clave 1) se active. 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 otra clave esté configurada con una hora de inicio posterior a la hora de inicio de la clave 1. Se aplica una tolerancia a la desviación del reloj de 30 segundos para que el receptor acepte las claves. Durante el período de tolerancia, la clave actual o anterior es aceptable. Las claves son contraseñas compartidas y secretas. 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 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 1 muestra 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, luego, copie y pegue los comandos en la CLI en el [edit] nivel de 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 siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.
Para configurar el enrutador R1 para que acepte filtros de ruta del dispositivo CE1 y realice el filtrado de ruta saliente con los filtros recibidos:
Configure el sistema autónomo local.
[edit routing-options] user@R1# set autonomous-system 65533
Configure uno o varios grupos de 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 clave 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 desviación del reloj en segundos.
[edit security authentication-key-chains key-chain bgp-auth] user@R1# set tolerance 30
Resultados
Desde el modo de configuración, ingrese los comandos , show routing-optionsy show security para confirmar la show protocolsconfiguración. 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”;
}
}
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Repita el procedimiento para cada dispositivo habilitado para el BGP de la red, utilizando los nombres y direcciones de interfaz adecuados para cada dispositivo habilitado para BGP.
Verificación
Confirme que la configuración funciona correctamente.
- Verificar la autenticación para el vecino
- Verificar que se envíen mensajes de autorización
- Comprobar errores de autenticación
- Verificar el funcionamiento del llavero
Verificar la autenticación para el vecino
Propósito
Asegúrese de que la AutheKeyChain opción aparece en el resultado del show bgp neighbor comando.
Acción
Desde el modo operativo, ingrese el show bgp neighbor comando.
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]: 0Verificar que se envíen mensajes de autorización
Propósito
Confirme que el BGP tiene la opción de autorización mejorada.
Acción
Desde el modo operativo, ingrese el monitor traffic interface fe-0/0/1 comando.
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
Comprobar 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 show system statistics tcp | match auth comando.
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 errorsVerificar el 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 show security keychain detail comando.
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
