Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP authentification des itinéraires

Understanding Router Authentication for BGP

L’utilisation d’un routeur, de l’authentification du routeur et de l’intégrité du routage réduit fortement le risque d’être attaqué par une machine ou un routeur qui a été configuré pour partager des informations de routage incorrectes avec un autre routeur. Dans ce type d’attaque, le routeur attaqué peut créer une boucle de routage, ou la table de routage du routeur attaqué peut être considérablement augmentée, ce qui impacte les performances, ou les informations de routage peuvent être redirigées vers un endroit sur le réseau pour que le pirate informatique puisse l’analyser. Des publicités de route fausses peuvent être envoyées sur un segment. Ces mises à jour peuvent être acceptées dans les tables de routage des routeurs voisins, sauf si un mécanisme d’authentification est en place pour vérifier la source des routes.

L’authentification du routeur et du routeur permet aux routeurs de partager des informations uniquement s’ils peuvent vérifier qu’ils parlent à une source fiable, sur la base d’un mot de passe (clé). Cette méthode envoie une clé de hachage à un autre routeur. Le routeur qui reçoit compare la clé envoyée avec sa propre clé configurée. Si elles sont les mêmes, elle accepte le chemin. L’utilisation d’un algorithme de hachage ne permet pas d’envoyer la clé via le câble en texte clair. Un hachage est alors calculé à l’aide de la clé configurée. La mise à jour du routage est utilisée comme texte d’entrée, ainsi que la clé, dans la fonction de hachage. Ce hachage est envoyé avec la mise à jour de route vers le routeur de réception. Le routeur qui reçoit compare le hachage reçu avec un hachage généré lors de la mise à jour de route à l’aide de la clé préprodée configurée sur ce dernier. Si les deux hèses sont les mêmes, le chemin est supposé être issu d’une source fiable. La clé est connue uniquement pour les routeurs d’envoi et de réception.

Pour renforcer davantage la sécurité, vous pouvez configurer une série de clés d’authentification (une clé). Chaque clé dispose d’un temps de début unique au sein de la clé de clés. L’authentification Keychain vous permet de modifier les informations de mot de passe périodiquement sans avoir à mettre en place des sessions d’peering. Cette méthode d’authentification par clé est appelée « hitless » (sans faute), car les clés sont déversables d’une à une autre sans réinitialiser les sessions d’peering ou interrompre le protocole de routage.

L’pair qui envoie des données utilise les règles suivantes pour identifier la clé d’authentification active:

  • L’heure de début est inférieure ou égale à l’heure actuelle (en d’autres termes, pas à l’avenir).

  • L’heure de début est supérieure à celle de toutes les autres clés de la chaîne dont l’heure de début est inférieure à l’heure actuelle (c’est-à-dire la plus proche de l’heure actuelle).

L’pair reçu détermine la clé à laquelle il s’authentifier en fonction de l’identifiant de clé entrant.

L’pair d’envoi identifie la clé d’authentification actuelle en fonction de l’heure de début configurée, puis génère une valeur de hachage à l’aide de la clé actuelle. L’pair d’envoi insère ensuite un objet d’authentification améliorée TCP dans BGP message de mise à jour. L’objet contient un ID d’objet (attribué par IANA), la longueur de l’objet, la clé actuelle et une valeur de hachage.

L’pair qui reçoit examine l’option d’authentification améliorée par TCP entrante, examine la clé d’authentification reçue et détermine si la clé est acceptable en fonction de l’heure de début, de l’heure du système et du paramètre de tolérance. Si la clé est acceptée, l’pair qui reçoit calcule un hachage et authentifier le message de mise à jour.

L’application initiale d’une chaîne de clés à une session TCP provoque la réinitialisation de la session. Cependant, une fois la clé de clés appliquée, l’ajout ou la suppression d’un mot de passe dans la chaîne de clés ne provoque pas la réinitialisation de la session TCP. En outre, la session TCP ne se réinitialise pas lorsque la clé passe d’un algorithme d’authentification à un autre.

Remarque :

Dans la version 19.1R1, Junos OS étend la prise en charge de l’authentification TCP aux pairs BGP découverts via des sous-réseaux de préfixe autorisés configurés BGP groupe d’utilisateurs. Dans les communiqués avant Junos OS version 19.1, BGP prend en charge l’authentification TCP aux niveaux [edit protocols bgp group group-name neighbor address][edit protocols bgp group group-name] hiérarchiques et inférieurs. À partir Junos OS version 19.1, vous pouvez configurer l’authentification TCP en suivant les instructions au niveau de [edit protocols bgp group group-name dynamic-neighbor dyn-name] la hiérarchie.

Exemple: Configuration de l’authentification des routeurs pour les BGP

Tous BGP protocoles d’échange de protocoles peuvent être authentifiés afin de garantir que seuls les équipements de routage fiables participent aux mises à jour de routage du système autonome (AS). Par défaut, l’authentification est désactivée.

Conditions préalables

Avant de commencer:

  • Configurez les interfaces du routeur.

  • Configurez un protocole de passerelle intérieure (IGP).

Présentation

Lorsque vous configurez l’authentification, l’algorithme crée une base de contrôle encodée incluse dans le paquet transmis. L’équipement de routage qui reçoit utilise une clé d’authentification (mot de passe) pour vérifier la base de contrôle du paquet.

Cet exemple comprend les instructions suivantes pour la configuration et l’application de la clé de clés:

  • key—Une clé peut avoir plusieurs clés. Chaque clé d’une chaîne de clés doit être identifiée par une valeur d’identification unique. La plage de valeurs d’identification valides est de 0 à 63.

    La clé peut être de 126 caractères. Les caractères peuvent inclure des chaînes ASCII. Si vous inclut des espaces, joindre tous les caractères dans des guillemets ( » « ).

  • tolerance—(Facultatif) Pour chaque chaîne de clés, vous pouvez configurer une valeur de tolérance d’horloge en quelques secondes. La tolérance de biais d’horloge s’applique au récepteur qui accepte les clés pour BGP mises à jour. La plage configurable est de 0 à 999 999 999 secondes. Pendant la période de tolérance, le mot de passe actuel ou précédent est acceptable.

  • key-chain—Pour chaque clé de clés, vous devez spécifier un nom. Cet exemple définit une clé: bgp-auth. Vous pouvez avoir plusieurs keychains sur un équipement de routage. Par exemple, vous pouvez avoir une clé de BGP, une clé de OSPF et une clé pour LDP.

  • secret—Pour chaque clé de la clé, vous devez définir un mot de passe secret. Ce mot de passe peut être saisi au format chiffré ou en texte clair dans secret l’énoncé. Il est toujours chiffré.

  • start-time—Chaque clé doit spécifier une heure de début dans le format UTC. Le contrôle est transmis d’une clé à l’autre. Lorsqu’une heure de début configurée arrive (en fonction de l’horloge de l’équipement de routage), la clé de cet heure de début devient active. Les heures de début sont spécifiées dans le fuseau horaire local pour un équipement de routage et doivent être uniques dans la clé de clés.

  • authentication-key-chain— Permet d’appliquer une clé au niveau mondial BGP tous les pairs, pour un groupe ou un voisin. Cet exemple applique la clé de clés aux pairs définis dans le groupe de BGP externe (EBGP) appelé ext .

  • authentication-algorithm—Pour chaque clé, vous pouvez spécifier un algorithme de hachage. L’algorithme peut être AES-128, MD5 ou SHA-1.

    Vous associez une clé de clés et un algorithme d’authentification à BGP session de voisinage.

Cet exemple configure une clé nommée bgp-auth . La clé 0 sera envoyée et acceptée à partir de 2011-6-23.20:19:33-0700 et cessera d’être envoyée et acceptée lorsque la clé suivante de la clé de clés (clé 1) sera active. La clé 1 devient active un an plus tard au cours de l’année 2012-6-23.20:19:33 -0700. Elle n’est plus envoyée et acceptée sauf si une autre clé est configurée avec un temps de début plus tard que l’heure de début de la clé 1. Une tolérance de biais d’horloge de 30 secondes s’applique au récepteur qui accepte les clés. Pendant la période de tolérance, la clé actuelle ou antérieure est acceptable. Les clés sont des mots de passe secret partagés. Cela signifie que les voisins qui reçoivent les mises à jour de routage authentifiées doivent avoir la même configuration de clé d’authentification, y compris les mêmes clés (mots de passe). Le routeur R0 et le routeur R1 doivent donc avoir la même configuration de chaîne de clés d’authentification s’ils sont configurés comme pairs. Cet exemple illustre la configuration sur un seul équipement de routage.

Schéma de topologie

Figure 1 montre la topologie utilisée dans cet exemple.

Figure 1 : Authentification des BGPAuthentification des BGP

Configuration

CLI configuration rapide

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, puis copiez/collez les commandes dans le CLI au niveau de la [edit] hiérarchie.

Procédure

Procédure étape par étape

L’exemple suivant nécessite de naviguer dans différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la CLI, consultez le manuel Using the CLI Editor in Configuration Mode dans le Junos OS CLI User Guide.

Pour configurer le routeur R1 afin d’accepter les filtres de route de l’équipement CE1 et d’effectuer le filtrage de route sortant à l’aide des filtres reçus:

  1. Configurez le système autonome local.

  2. Configurez un ou plusieurs groupes d BGP de sécurité.

  3. Configurez l’authentification avec plusieurs clés.

    L’heure de début de chaque clé doit être unique au sein de la clé de clés.

  4. Appliquez la clé de clé d’authentification BGP et définissez l’algorithme de hachage.

  5. (Facultatif) Appliquez une valeur de tolérance d’horloge en quelques secondes.

Résultats

Depuis le mode de configuration, confirmez votre configuration en entrant les show protocolsshow routing-options commandes et les . show security Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé la configuration de l’équipement, commit saisissez-le en mode de configuration.

Répétez la procédure pour chaque BGP du réseau, en utilisant les noms et adresses d’interface appropriés pour chaque BGP’équipement connecté.

Vérification

Vérifier que la configuration fonctionne correctement.

Vérification de l’authentification du voisin

But

Assurez-vous que AutheKeyChain l’option apparaît dans la sortie de la show bgp neighbor commande.

Action

À partir du mode opérationnel, saisissez la show bgp neighbor commande.

Vérification de l’envoi de messages d’autorisation

But

Confirmez que votre BGP dispose de l’option d’autorisation améliorée.

Action

À partir du mode opérationnel, saisissez la monitor traffic interface fe-0/0/1 commande.

Vérification des erreurs d’authentification

But

Vérifiez le nombre de paquets abandonnés par TCP en raison d’erreurs d’authentification.

Action

À partir du mode opérationnel, saisissez la show system statistics tcp | match auth commande.

Vérification du fonctionnement de la keychain

But

Vérifiez le nombre de paquets abandonnés par TCP en raison d’erreurs d’authentification.

Action

À partir du mode opérationnel, saisissez la show security keychain detail commande.