Commande cable source-verify et sécurité d'adresse IP

Introduction

Cisco a mis en oeuvre des améliorations dans les produits CMTS (Cable Modem Termination System) de Cisco qui empêchent certains types d'attaques par déni de service basées sur l'usurpation d'adresse IP et le vol d'adresse IP dans les systèmes câblés DOCSIS (Data-over-Cable Service Interface Specifications). Le guide de référence des commandes du câble Cisco CMTS décrit la suite de commandes cable source-verify qui font partie de ces améliorations de la sécurité des adresses IP.

Avant de commencer

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, consultez Conventions relatives aux conseils techniques Cisco.

Conditions préalables

Aucune condition préalable spécifique n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

L'environnement DOCSIS non protégé

Un domaine MAC (Media Access Control) DOCSIS est de nature similaire à un segment Ethernet. S’ils ne sont pas protégés, les utilisateurs du segment sont vulnérables à de nombreux types d’attaques de déni de service basées sur l’adressage des couches 2 et 3. En outre, il est possible que les utilisateurs souffrent d'un niveau de service dégradé en raison de la mauvaise configuration de l'adressage sur l'équipement d'autres utilisateurs. En voici quelques exemples :

• Configuration d'adresses IP dupliquées sur différents noeuds.

• Configuration d'adresses MAC dupliquées sur différents noeuds.

• Utilisation non autorisée d'adresses IP statiques plutôt que d'adresses IP attribuées par le protocole DHCP (Dynamic Host Configuration Protocol).

• Utilisation non autorisée de différents numéros de réseau dans un segment.

• Configuration incorrecte des noeuds d’extrémité pour répondre aux requêtes ARP au nom d’une partie du sous-réseau IP du segment.

Bien que ces types de problèmes soient faciles à contrôler et à atténuer dans un environnement de réseau local Ethernet en traquant et déconnectant physiquement l’équipement en cause, de tels problèmes dans les réseaux DOCSIS peuvent être plus difficiles à isoler, à résoudre et à prévenir en raison de la taille potentiellement importante du réseau. En outre, les utilisateurs finaux qui contrôlent et configurent l'équipement client (CPE) peuvent ne pas bénéficier de l'assistance d'un service d'assistance informatique local pour s'assurer que leurs stations de travail et leurs PC ne sont pas malconfigurés, intentionnellement ou non.

Base de données CMTS CPE

La suite Cisco de produits CMTS gère une base de données interne remplie de manière dynamique d'adresses IP et MAC CPE connectées. La base de données CPE contient également des détails sur les modems câble correspondants auxquels ces périphériques CPE appartiennent.

Une vue partielle de la base de données CPE correspondant à un modem câble particulier peut être visualisée en exécutant la commande cachée CMTS show interface cable X/Y modem Z. Ici, X est le numéro de carte de ligne, Y est le numéro de port en aval et Z est l'identificateur de service (SID) du modem câble. Z peut être défini sur 0 pour afficher les détails de tous les modems câble et de l’équipement d’abonné sur une interface en aval particulière. Voir l'exemple ci-dessous d'une sortie type générée par cette commande.

CMTS# show interface cable 3/0 modem 0
SID   Priv bits  Type      State     IP address    method    MAC address
1     00         host      unknown   192.168.1.77  static    000C.422c.54d0
1     00         modem     up        10.1.1.30     dhcp      0001.9659.4447
2     00         host      unknown   192.168.1.90  dhcp      00a1.52c9.75ad
2     00         modem     up        10.1.1.44     dhcp      0090.9607.3831

Remarque : étant donné que cette commande est masquée, elle est sujette à modification et n'est pas garantie d'être disponible dans toutes les versions du logiciel Cisco IOS®.

Dans l'exemple ci-dessus, la colonne method de l'hôte avec l'adresse IP 192.168.1.90 est répertoriée comme dhcp. Cela signifie que le CMTS a pris connaissance de cet hôte en observant les transactions DHCP entre l'hôte et le serveur DHCP du fournisseur de services.

L’hôte dont l’adresse IP est 192.168.1.77 est répertorié avec la méthode static. Cela signifie que le CMTS n'a pas appris l'existence de cet hôte par le biais d'une transaction DHCP entre ce périphérique et un serveur DHCP. Au lieu de cela, le CMTS a d’abord vu d’autres types de trafic IP provenant de cet hôte. Ce trafic peut avoir été la navigation sur le Web, les e-mails ou les paquets « ping ».

Bien qu'il puisse sembler que 192.168.1.77 a été configuré avec une adresse IP statique, il se peut que cet hôte ait en fait acquis un bail DHCP, mais le CMTS a peut-être été redémarré depuis l'événement et par conséquent il ne se souvient pas de la transaction.

La base de données CPE est normalement alimentée par les informations de nettoyage CMTS provenant des transactions DHCP entre les périphériques CPE et le serveur DHCP du fournisseur de services. En outre, le CMTS peut écouter d'autres trafics IP provenant de périphériques CPE pour déterminer quelles adresses IP et MAC CPE appartiennent à quels modems câble.

Commande Cable Source-Verify

Cisco a mis en oeuvre la commande d'interface de câble cable source-verify [dhcp]. Cette commande permet au CMTS d'utiliser la base de données CPE pour vérifier la validité des paquets IP qu'il reçoit sur ses interfaces Cable et lui permet de prendre des décisions intelligentes quant à leur transfert ou non.

L'organigramme ci-dessous montre le traitement supplémentaire qu'un paquet IP reçu sur une interface de câble doit effectuer avant d'être autorisé à passer par le CMTS.

Organigramme 1

L'organigramme commence par la réception d'un paquet par un port en amont sur le CMTS et se termine par l'autorisation de poursuivre le traitement ou par l'abandon du paquet.

Exemple 1 : scénario avec des adresses IP dupliquées

Le premier scénario de déni de service que nous allons aborder est la situation impliquant des adresses IP en double. Supposons que le client A est connecté à son fournisseur de services et a obtenu un bail DHCP valide pour son PC. L'adresse IP obtenue par le client A sera appelée X.

Quelque temps après l'acquisition de son bail DHCP par A, le client B décide de configurer son PC avec une adresse IP statique identique à celle actuellement utilisée par l'équipement du client A. Les informations de la base de données CPE relatives à l’adresse IP X varient en fonction du périphérique CPE qui a envoyé la dernière requête ARP pour le compte de X.

Dans un réseau DOCSIS non protégé, le client B peut être en mesure de convaincre le routeur de tronçon suivant (dans la plupart des cas, le CMTS) qu’il a le droit d’utiliser l’adresse IP X en envoyant simplement une requête ARP pour le compte de X au CMTS ou au routeur de tronçon suivant. Cela empêcherait le trafic provenant du fournisseur de services d'être transféré au client A.

En activant la vérification de la source du câble, le CMTS serait en mesure de voir que les paquets IP et ARP pour l'adresse IP X proviennent du mauvais modem câble et donc, ces paquets seraient abandonnés, voir l'organigramme 2. Cela inclut tous les paquets IP avec l'adresse source X et les requêtes ARP pour le compte de X. Les journaux CMTS afficheraient un message comme suit :

%UBR7200-3-BADIPSOURCE : Câble d’interface 3/0, paquet IP provenant d’une source non valide. IP=192.168.1.10, MAC=0001.422c.54d0, SID attendu=10, SID réel=11

Organigramme 2

Ces informations permettent d'identifier les deux clients et de désactiver le modem câble avec l'adresse IP dupliquée connectée.

Exemple 2 - Scénario avec des adresses IP en double - Utilisation d'une adresse IP qui n'est pas encore utilisée

Un autre scénario consiste pour un utilisateur à attribuer de manière statique à son PC une adresse IP inutilisée qui se situe dans la plage légitime des adresses d’équipement d’abonné. Ce scénario n'entraîne aucune interruption des services pour quiconque sur le réseau. Supposons que le client B a attribué l'adresse Y à son PC.

Le problème suivant qui peut se poser est que le client C peut connecter sa station de travail au réseau du fournisseur de services et acquérir un bail DHCP pour l'adresse IP Y. La base de données CPE marquerait temporairement l'adresse IP Y comme appartenant au modem câble du client C. Cependant, il se peut qu'il ne soit pas long avant que le client B n'envoie la séquence appropriée de trafic ARP pour convaincre le tronçon suivant qu'il était le propriétaire légitime de l'adresse IP Y, provoquant ainsi une interruption du service du client C.

De même, le second problème peut être résolu en activant la fonction cable source-verify. Lorsque cable source-verify est activé, une entrée de base de données CPE qui a été générée en glanant des détails d'une transaction DHCP ne peut pas être déplacée par d'autres types de trafic IP. Seule une autre transaction DHCP pour cette adresse IP ou l'entrée ARP sur le délai d'expiration CMTS pour cette adresse IP peut remplacer l'entrée. Cela garantit que si un utilisateur final obtient un bail DHCP pour une adresse IP donnée, il n'aura pas à s'inquiéter de la confusion du CMTS et du fait que son adresse IP appartient à un autre utilisateur.

Le premier problème d'empêcher les utilisateurs d'utiliser des adresses IP non encore utilisées peut être résolu avec cable source-verify dhcp. En ajoutant le paramètre dhcp à la fin de cette commande, le CMTS peut vérifier la validité de chaque nouvelle adresse IP source dont il entend parler en émettant un type spécial de message DHCP appelé LEASEQUERY au serveur DHCP. Voir Organigramme 3.

Organigramme 3

Pour une adresse IP CPE donnée, le message LEASEQUERY demande quelle est l'adresse MAC et le modem câble correspondants.

Dans ce cas, si le client B connecte sa station de travail au réseau câblé avec l'adresse statique Y, le CMTS enverra une requête de bail au serveur DHCP pour vérifier si l'adresse Y a été louée au PC du client B. Le serveur DHCP peut informer le CMTS qu'aucun bail n'a été accordé pour l'adresse IP Y et que l'accès sera donc refusé au client B.

Exemple 3 : utilisation d'un numéro de réseau non fourni par le fournisseur de services

Les utilisateurs peuvent avoir des stations de travail configurées derrière leurs modems câble avec des adresses IP statiques qui ne peuvent pas entrer en conflit avec les numéros de réseau actuels du fournisseur de services, mais qui peuvent causer des problèmes à l'avenir. Par conséquent, à l'aide de la commande cable source-verify, un CMTS peut filtrer les paquets provenant des adresses IP source qui ne sont pas de la plage configurée sur l'interface de câble du CMTS.

Remarque : pour que cela fonctionne correctement, vous devez également configurer la commande ip verify unicast reverse-path afin d'empêcher les adresses IP source usurpées. Référez-vous à Commandes de câble : s câble pour plus d'informations.

Certains clients peuvent disposer d’un routeur en tant que périphérique CPE et faire en sorte que le fournisseur de services achemine le trafic vers ce routeur. Si le CMTS reçoit du trafic IP du routeur CPE avec une adresse IP source de Z, la commande cable source-verify laisse passer ce paquet si le CMTS a une route vers le réseau auquel Z appartient via ce périphérique CPE. Reportez-vous à Organigramme 3.

Prenons maintenant l'exemple suivant :

Sur le CMTS, nous avons la configuration suivante :

interface cable 3/0
 ip verify unicast reverse-path
 ip address 10.1.1.1 255.255.255.0
 ip address 24.1.1.1 255.255.255.0 secondary
 cable source-verify
!
ip route 24.2.2.0 255.255.255.0 24.1.1.2

Note: This configuration shows only what is
relevant for this example

En supposant qu'un paquet avec l'adresse IP source 172.16.1.10 est arrivé au CMTS à partir du modem câble 24.2.2.10, le CMTS verrait que 24.2.2.10 ne réside pas dans la base de données CPE, show int cable x/y modem 0, cependant ip verify unicast reverse-path active Unicast Reverse Path Forwarding (Unicast RPF), qui vérifie chaque paquet reçu sur une interface afin de vérifier que l'adresse IP source du paquet apparaît dans les tables de routage qui appartiennent à cette interface. La commande cable source-verify vérifie le prochain saut pour 24.2.2.10. Dans la configuration ci-dessus, nous avons ip route 24.2.2.0 255.255.255.0 24.1.1.2, ce qui signifie que le saut suivant est 24.1.1.2. Maintenant en supposant que 24.1.1.2 est une entrée valide dans la base de données CPE, le CMTS conclut que le paquet est OK et traite donc le paquet comme indiqué dans l'organigramme 4.

Organigramme 4

Configuration de la source du câble - Vérification

La configuration de cable source-verify implique simplement l'ajout de la commande cable source-verify à l'interface de câble sur laquelle vous souhaitez activer la fonction. Si vous utilisez le regroupement d'interfaces de câble, alors vous devez ajouter cable source-verify à la configuration de l'interface principale.

Comment configurer cable source-verify dhcp

Remarque :  cable source-verify a été introduit pour la première fois dans le logiciel Cisco IOS Version 12.0(7)T et est pris en charge dans les versions du logiciel Cisco IOS 12.0SC, 12.1EC et 12.1T.

La configuration de cable source-verify dhcp nécessite quelques étapes.

Assurez-vous que votre serveur DHCP prend en charge le message spécial DHCP LEASEQUERY.

Afin d'utiliser la fonctionnalité cable source-verify dhcp, votre serveur DHCP doit répondre aux messages comme spécifié par draft-ietf-dhcp-leasequery-XX.txt. Cisco Network Registrar versions 3.5 et ultérieures est en mesure de répondre à ce message.

Assurez-vous que votre serveur DHCP prend en charge le traitement de l'option Relay Agent Information. Reportez-vous à la section Agent de relais.

Le traitement de l'option d'information de relais DHCP est une autre fonctionnalité qui doit être prise en charge par votre serveur DHCP. Ce processus est également appelé traitement de l'option 82. Cette option est décrite dans le document DHCP Relay Information Option (RFC 3046). Les versions 3.5 et ultérieures de Cisco Network Registrar prennent en charge le traitement de l'option Relay Agent Information. Toutefois, il doit être activé via l'utilitaire de ligne de commande nrcmd de Cisco Network Registrar avec la séquence de commandes suivante :

nrcmd -U admin -P changeme -C 127.0.0.1 dhcp enable save-relay-agent-data

nrcmd -U admin -P changeme -C 127.0.0.1 save

nrcmd -U admin -P changeme -C 127.0.0.1 rechargement DHCP

Vous devrez peut-être remplacer le nom d'utilisateur, le mot de passe et l'adresse IP du serveur appropriés. Les valeurs par défaut sont indiquées ci-dessus. Sinon, si vous êtes à l'invite nrcmd, >nrcmd, tapez simplement ce qui suit :

dhcp enable save-relay-agent-data

sauvegarde

rechargement dhcp

Activez le traitement des informations de relais DHCP sur le CMTS.

Agent De Relais

Le CMTS doit marquer les requêtes DHCP des modems câble et du CPE avec l'option Relay Agent Information Option afin que cable source-verify dhcp soit efficace. Les commandes suivantes doivent être entrées en mode de configuration globale sur un CMTS exécutant les versions 12.1EC, 12.1T ou ultérieures du logiciel Cisco IOS.

ip dhcp relay information option

Si votre CMTS exécute le logiciel Cisco IOS Versions 12.0SC train Cisco IOS, utilisez alors la commande cable relay-agent-option cable interface à la place.

Veillez à utiliser les commandes appropriées, en fonction de la version de Cisco IOS que vous exécutez. Veillez à mettre à jour votre configuration si vous modifiez les catégories de Cisco IOS.

Les commandes relay information option ajoutent une option spéciale appelée Option 82, ou l'option relay information, au paquet DHCP relayé lorsque le CMTS relaie des paquets DHCP.

L'option 82 est remplie avec une sous-option, l'ID de circuit de l'agent, qui fait référence à l'interface physique sur le CMTS sur lequel la requête DHCP a été entendue. En outre, une autre sous-option, l'ID distant de l'agent, est renseignée avec l'adresse MAC à 6 octets du modem câble à partir duquel ou via lequel la requête DHCP a été reçue.

Ainsi, par exemple, si un PC avec l'adresse MAC 99:88:77:66:55:44 qui est derrière le modem câble aa:bb:cc:dd:ee:ff envoie une requête DHCP, le CMTS transfère la requête DHCP en définissant la sous-option ID distant de l'agent de l'option 82 à l'adresse MAC du modem câble, aa:bb:cc:dd:ee:ff.

En incluant l'option Relay Information Option dans la requête DHCP d'un périphérique CPE, le serveur DHCP peut stocker des informations sur quel CPE appartient derrière quels modems câble. Cela devient particulièrement utile lorsque cable source-verify dhcp est configuré sur le CMTS, car le serveur DHCP est capable d'informer le CMTS de manière fiable non seulement sur quelle adresse MAC un client particulier doit avoir, mais sur quel modem câble un client particulier est censé être connecté.

Activez la commande cable source-verify dhcp sous l’interface de câble appropriée.

La dernière étape consiste à entrer la commande cable source-verify dhcp sous l'interface de câble sur laquelle vous souhaitez activer la fonctionnalité. Si le CMTS utilise le regroupement d'interfaces de câble, vous devez entrer la commande sous l'interface principale du regroupement.

Conclusion

Les suites de commandes cable source-verify permettent à un fournisseur de services de protéger le réseau câblé contre les utilisateurs ayant des adresses IP non autorisées à utiliser le réseau.

La commande cable source-verify est en elle-même un moyen efficace et facile de mettre en oeuvre la sécurité des adresses IP. Bien qu'il ne couvre pas tous les scénarios, il s'assure que les clients ayant le droit d'utiliser des adresses IP attribuées, ne rencontreront pas de perturbations en ayant leur adresse IP utilisée par quelqu'un d'autre.

Dans sa forme la plus simple décrite dans ce document, un périphérique CPE non configuré via DHCP ne peut pas obtenir d'accès réseau. C'est la meilleure façon de sécuriser l'espace d'adressage IP et d'augmenter la stabilité et la fiabilité d'un service de données sur câble.  Cependant, plusieurs opérateurs de services (MSO) qui ont des services commerciaux qui les obligeaient à utiliser des adresses statiques voulaient mettre en oeuvre une sécurité stricte de la commande cable source-verify dhcp.

Cisco Network Registrar version 5.5 offre une nouvelle capacité de réponse à la requête de bail pour les adresses « réservées », même si l'adresse IP n'a pas été obtenue via DHCP.  Le serveur DHCP inclut des données de réservation de bail dans les réponses DHCPLEASEQUERY. Dans les versions précédentes de Network Registrar, les réponses DHCPLEASEQUERY étaient possibles uniquement pour les clients loués ou précédemment loués pour lesquels l'adresse MAC était stockée. Les agents de relais Cisco uBR, par exemple, rejettent les datagrammes DHCPLEASEQUERY qui n'ont pas d'adresse MAC et de durée de bail (option dhcp-lease-time).

Network Registrar renvoie une durée de bail par défaut d’un an (31536000 secondes) pour les baux réservés dans une réponse DHCPLEASEQUERY. Si l'adresse est réellement louée, Network Registrar renvoie la durée de bail restante.

Informations connexes

• Option DHCP Relay Information (RFC 3046)
• Assistance et documentation techniques - Cisco Systems