IP : Services d'adressage IP

Guide Cisco pour renforcer les périphériques Cisco IOS

30 juillet 2013 - Traduction automatique
Autres versions: PDFpdf | Anglais (7 juin 2011) | Commentaires


Contenu


Introduction

Ce document contient les informations pour vous aider à sécuriser vos périphériques du système de Cisco IOS®, qui augmente la Sécurité globale de votre réseau. Structuré autour des trois plans dans lesquels des fonctions d'un périphérique réseau peuvent être classées par catégorie, ce document fournit un aperçu de chaque fonctionnalité incluse et des références à la documentation apparentée.

Les trois plans fonctionnels d´un réseau, le plan de gestion, le plan de contrôle, et le plan de données, fournissent chacun une fonctionnalité différente qui doit être protégée.

  • Plan de gestion - Le plan de gestion gère le trafic qui est envoyé à l'équipement Cisco IOS et se compose des applications et des protocoles tels que le SSH et SNMP.

  • Plan de contrôle - Le plan de contrôle d'un équipement réseau traite le trafic qui est primordial à mettre à jour la fonctionnalité de l'infrastructure réseau. Le plan de contrôle se compose des applications et des protocoles entre les périphériques réseau, qui inclut le Border Gateway Protocol (BGP), ainsi que les Interior Gateway Protocols (IGP) comme l'Enhanced Interior Gateway Routing Protocol (EIGRP) et l'Open Shortest Path First (OSPF).

  • Plan de données - Le plan de données transmet les données par un périphérique réseau. Le plan de données n'inclut pas le trafic qui est envoyé au périphérique Cisco IOS local.

La couverture des fonctions de sécurité dans ce document fournit souvent assez de détails pour que vous configuriez la fonctionnalité. Cependant, dans les cas où elle ne le fait pas, la fonctionnalité est expliquée de telle manière que vous puissiez évaluer si une attention supplémentaire à la fonctionnalité est requise. Si possible et approprié, ce document contient des recommandations qui, si mises en application, aident à sécuriser un réseau.

Conditions préalables

Conditions requises

Aucune spécification déterminée 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.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco. Quelques exemples de ligne de commande dans ce document sont inclus pour améliorer la lisibilité.

Opérations sécurisées

Les opérations sécurisées du réseau sont un sujet substantiel. Bien que la majeure partie de ce document soit consacrée à la configuration sécurisée d'un périphérique Cisco IOS, les configurations à elles seules ne sécurisent pas complètement un réseau. Les procédures opérationnelles en service sur le réseau contribuent autant à la sécurité que la configuration des périphériques sous-jacents.

Ces sujets contiennent les recommandations opérationnelles que vous êtes avisé de mettre en application. Ces sujets mettent en valeur des domaines critiques spécifiques des fonctionnements du réseau et ne sont pas complets.

Surveiller les avis et les réponses de la sécurité Cisco

L'équipe de résolution d´incidents de sécurité des produits Cisco (PSIRT) crée et maintient des publications, généralement désignées sous le nom d´Avis PSIRT, pour les problèmes liés à la sécurité des Produits Cisco. La méthode utilisée pour la transmission des questions moins graves est Cisco Security Response. Les avis et les réponses de sécurité sont disponibles à http://www.cisco.com/go/psirt .

Des informations supplémentaires au sujet de ces véhicules de transmission sont disponibles dans Politique de vulnérabilité de la sécurité Cisco.

Afin de maintenir un réseau sécurisé, vous devez être au courant des avis et réponses de la sécurité Cisco qui ont été publiés. Vous devez avoir la connaissance d'une vulnérabilité avant que la menace qu'elle peut constituer au réseau puisse être évaluée. Référez-vous au Triage du risque pour des annonces de vulnérabilité de sécurité pour assistance dans cette évaluation.

Exploiter Authentication, Authorization, and Accounting (AAA)

Le cadre Authentication, Authorization, and Accounting (AAA) est essentiel pour sécuriser les périphériques réseau. Le cadre AAA fournit l'authentification des sessions de gestion et peut également limiter les utilisateurs à des commandes spécifiques définies par l´administrateur et enregistrer toutes les commandes saisies par tous les utilisateurs. Voir la section Authentication, Authorization, and Accounting de ce document pour plus d'informations sur l´exploitation du protocole AAA.

Centraliser la collection et la surveillance du journal

Afin de mieux comprendre les événements existant, émergeant et historiques associés aux incidents de sécurité, votre organisation doit avoir une stratégie unifiée pour la journalisation et la corrélation des événements. Cette stratégie doit exploiter la journalisation de tous les périphériques réseau et utiliser les capacités de corrélation pré-packaged et personnalisables.

Après que la journalisation centralisée soit mise en application, vous devez développer une approche structurée pour l'analyse du journal et le suivi des incidents. Basé sur les besoins de votre organisation, cette approche peut aller d'un examen diligent simple des données de journal jusqu´à l'analyse avancée basée sur des règles.

Voir la section Meilleures pratiques de journalisation de ce document pour plus d'informations sur la façon mettre en application la journalisation sur les périphériques réseau Cisco IOS.

Utiliser les protocoles sécurisés quand c'est possible

Beaucoup de protocoles sont utilisés afin de transporter des données sensibles de gestion de réseau. Vous devez utiliser des protocoles sécurisés chaque fois que c´est possible. Un choix de protocole sécurisé inclut l'utilisation de SSH au lieu de Telnet de sorte que les données d'authentification et les informations de gestion soient chiffrées. En outre, vous devez utiliser des protocoles de transfert de fichiers sécurisés quand vous copiez des données de configuration. Un exemple est l'utilisation du Secure Copy Protocol (SCP) au lieu de FTP ou TFTP.

Voir la section Sécurisation des sessions de gestion interactive de ce document pour plus d'informations sur la gestion sécurisée des périphériques Cisco IOS.

Obtenir la visibilité du trafic avec Netflow

Netflow vous permet de surveiller les flux de trafic du réseau. Initialement destiné à exporter les informations de trafic vers des applications de gestion de réseau, Netflow peut également être utilisé afin de montrer les informations de flux sur un routeur. Cette capacité vous permet de voir quel trafic traverse le réseau en temps réel. Que les informations de flux soient exportées ou non vers un collecteur distant, vous êtes avisés de configurer les périphériques de réseau pour Netflow de sorte qu'il puisse être utilisé réactivement si nécessaire.

D´autres informations sur cette fonctionnalité sont disponibles dans la section Identification du trafic et retour arrière de ce document et à http://www.cisco.com/en/US/products/ps6601/products_ios_protocol_group_home.html (clients enregistrés seulement).

Gestion de la configuration

La gestion de la configuration est un processus par lequel des modifications de configuration sont proposées, passées en revue, approuvées et déployées. Dans le contexte de configuration de périphérique Cisco IOS, deux aspects supplémentaires de gestion de la configuration sont critiques : archivage et sécurité de la configuration.

Vous pouvez employer les archives de configuration pour abandonner les modifications qui sont apportées aux périphériques de réseau. Dans un contexte de sécurité, les archives de configuration peuvent également être utilisées afin de déterminer quelles modifications de la sécurité ont été apportées et quand ces modifications se sont produites. En même temps que les données du journal de l'AAA, ces informations peuvent aider aux audits de sécurité des périphériques de réseau.

La configuration d'un périphérique Cisco IOS contient beaucoup de détails sensibles. Les noms d'utilisateur, les mots de passe et le contenu des listes de contrôle d'accès sont des exemples de ce type d'information. Le référentiel que vous utilisez pour archiver des configurations de périphérique Cisco IOS doit être sécurisé. Un accès non sécurisé à ces informations peut nuire à la sécurité de tout le réseau.

Plan de gestion

Le plan de gestion se compose de fonctions qui accomplissent les buts de gestion du réseau. Ceci inclut les sessions de gestion interactive utilisant le protocole SSH, ainsi que la collecte de statistiques avec SNMP ou Netflow. Quand vous considérez la sécurité d'un périphérique de réseau, il est critique que le plan de gestion soit protégé. Si un incident lié à la sécurité peut miner les fonctions du plan de gestion, il peut vous être impossible de rétablir ou de stabiliser le réseau.

Ces sections de ce document détaillent les fonctions et les configurations de sécurité disponibles dans le logiciel Cisco IOS, qui aident à renforcer le plan de gestion.

Durcissement général du plan de gestion

Le plan de gestion est utilisé afin d'accéder, configurer et gérer un périphérique, ainsi que pour surveiller ses opérations et le réseau sur lequel il est déployé. Le plan de gestion est le plan qui reçoit et envoie le trafic pour les opérations de ces fonctions. Vous devez sécuriser le plan de gestion et le plan de contrôle d'un périphérique, car les opérations du plan de contrôle affectent directement les opérations du plan de gestion. Cette liste des protocoles est utilisée par le plan de gestion :

  • Protocole SNMP

  • Telnet

  • Secure Shell Protocol

  • Protocole de transfert de fichiers

  • Trivial File Transfer Protocol

  • Secure Copy Protocol

  • TACACS+

  • RAYON

  • NetFlow

  • Network Time Protocol

  • Syslog

Des mesures doivent être prises pour assurer la survie des plans de gestion et de contrôle pendant les incidents liés à la sécurité. Si un de ces plans est exploité avec succès, tous les plans peuvent être compromis.

Gestion des mots de passe

Accès par contrôle de mots de passe aux ressources ou aux périphériques. Ceci est accompli par la définition d´un mot de passe ou secret qui est utilisé afin d'authentifier les demandes. Quand une demande est reçue pour l'accès à une ressource ou à un périphérique, la demande est contestée pour la vérification du mot de passe et de l'identité, et l'accès peut être accordé, refusé ou limité basé sur le résultat. Comme meilleure pratique de sécurité, les mots de passe doivent être gérés avec un serveur d'authentification TACACS+ ou RADIUS. Cependant, notez qu´un mot de passe localement configuré pour l'accès privilégié est toujours nécessaire en cas de la panne du TACACS+ ou des services Radius. Un périphérique peut également avoir d'autres informations relatives au mot de passe présentes dans sa configuration, comme une clé NTP, la chaîne de communauté SNMP ou la clé du protocole de routage.

La commande enable secret est utilisée pour définir le mot de passe qui accorde l'accès administratif privilégié au système Cisco IOS. La commande enable secret doit être utilisée, plutôt que la commande plus ancienne enable password. La commande enable password utilise un algorithme de chiffrement faible.

Si aucune enable secret n'est défini et un mot de passe est configuré pour la ligne tty de la console, le mot de passe de la console peut être utilisé afin de recevoir l'accès privilégié, même d'une session du téléscripteur virtuel distant (vty). Cette action est presque certainement non désirée et est une autre raison d'assurer la configuration d'une enable secret.

La commande de configuration globale service password-encryption instruit le logiciel Cisco IOS de chiffrer les mots de passe, les secrets du protocole d'authentification CHAP (Challenge Handshake Authentication Protocol), et les données semblables qui sont enregistrées dans son fichier de configuration. Un tel chiffrement est utile afin d'empêcher les observateurs occasionnels de lire les mots de passe, comme lorsqu´ils regardent l'écran au-dessus du rassemblement d'un administrateur. Cependant, l'algorithme utilisé par la commande service password-encryption est un simple chiffre de Vigenère. L'algorithme n'est pas conçu pour protéger les fichiers de configuration contre une analyse sérieuse par même des attaquants légèrement sophistiqués et ne doit pas être utilisé à cet effet. N'importe quel fichier de configuration de Cisco IOS qui contient des mots de passe chiffrés doit être traité avec le même soin qui est utilisé pour une liste en libellé de ces mêmes mots de passe.

Bien que cet algorithme de chiffrement faible ne soit pas utilisé par la commande enable secret, il est utilisé par la commande de configuration globale enable password, ainsi que par la commande password line configuration. On doit éliminer les mots de passe de ce type et la commande enable secret ou la fonctionnalité Enhanced Password Security doivent être utilisées.

La commande enable secret et la fonctionnalité Enhanced Password Security utilisent Message Digest 5 (MD5) pour le hachage du mot de passe. Cet algorithme a eu une revue publique considérable et n'est pas connu pour être réversible. Cependant, l'algorithme est sujet à des attaques de dictionnaire. Dans une attaque de dictionnaire, un attaquant essaye chaque mot d´un dictionnaire ou autre liste de mots de passe candidats afin de rechercher une correspondance. Par conséquent, les fichiers de configuration doivent être stockés de manière sécurisée et seulement partagés avec des personnes de confiance.

Enhanced Password Security

La fonctionnalité Enhanced Password Security, introduite dans le Logiciel Cisco IOS Version 12.2(8)T, permet à un administrateur de configurer le hachage MD5 des mots de passe pour la commande username. Avant cette fonctionnalité, il y avait deux types de mots de passe : Type 0, qui est un mot de passe libellé, et Type 7, qui utilise l'algorithme du chiffre de Vigenère. La fonctionnalité Enhanced Password Security ne peut pas être utilisée avec les protocoles qui exigent du mot de passe libellé d'être recouvrable, comme le protocole CHAP.

Afin de chiffrer un mot de passe utilisateur avec le hachage MD5, émettez la commande de configuration globale username secret.


!

username <name> secret <password>

!

Référez-vous à Enhanced Password Security pour plus d'informations sur cette fonctionnalité.

Login Password Retry Lockout

La fonctionnalité Login Password Retry Lockout, ajoutée dans le Logiciel Cisco IOS Version 12.3(14)T, vous permet de verrouiller un compte d'utilisateur local après un nombre configuré de tentatives de connexion infructueuses. Une fois qu'un utilisateur est bloqué, son compte est verrouillé jusqu'à ce que vous le déverrouilliez. Un utilisateur autorisé qui est configuré avec le niveau de privilège 15 ne peut pas être verrouillé avec cette fonction. Le nombre d'utilisateurs avec le niveau de privilège 15 doit être maintenu à un minimum.

Notez que les utilisateurs autorisés peuvent se verrouiller eux-mêmes en dehors d'un périphérique si le nombre de tentatives de connexion infructueuses est atteint. En outre, un utilisateur malveillant peut créer un état de déni de service (DoS) avec des tentatives répétées d'authentification avec un nom d'utilisateur valide.

Cet exemple montre comment activer la fonctionnalité Login Password Retry Lockout :


!

aaa new-model
aaa local authentication attempts max-fail <max-attempts>
aaa authentication login default local

!

username <name> secret <password>

!

Cette fonctionnalité s'applique également aux méthodes d´authentification telles que les protocoles CHAP et PAP (Password Authentication Protocol).

Référez-vous à Login Password Retry Lockout pour plus d'informations sur cette fonctionnalité.

Aucune récupération de mot de passe de service

Dans le Logiciel Cisco IOS Versions 12.3(14)T et ultérieure, la fonctionnalité No Service Password-Recovery empêche quiconque avec accès par console d´accéder de façon non sécurisée à la configuration du périphérique et d´effacer le mot de passe. Elle également ne permet pas aux utilisateurs malveillants de changer la valeur du registre de configuration et d'accéder NVRAM.


!

no service password-recovery

!

Le logiciel Cisco IOS fournit une procédure de récupération de mot de passe qui repose sur l'accès au mode ROMMON en utilisant la touche d´interruption pendant le démarrage du système. Dans le mode ROMMON, le logiciel de périphérique peut être rechargé pour inviter une nouvelle configuration système qui inclut un nouveau mot de passe.

La procédure de récupération de mot de passe actuelle permet à n'importe qui avec l'accès par console pour accéder au périphérique et son réseau. La fonctionnalité No Service Password-Recovery empêche l'achèvement de la séquence de touche d'interruption et d´entrer en mode ROMMON pendant le démarrage du système.

Si no service password-recovery est activé sur un périphérique, il est recommandé qu'une copie hors ligne de la configuration du périphérique soit enregistrée et qu'une solution d´archivage de configuration soit mise en application. S'il est nécessaire de récupérer le mot de passe d'un périphérique Cisco IOS une fois que cette fonctionnalité est activée, la configuration entière est supprimée.

Référez-vous à No Service Password-Recovery et Exemple de configuration ROMMON sécurisée pour plus d'informations sur cette fonctionnalité.

Désactiver les services inutilisés

Comme meilleure pratique de sécurité, n'importe quel service inutile doit être désactivé. Ces services inutiles, particulièrement ceux qui utilisent UDP (User Datagram Protocol), sont rarement utilisés pour les buts légitimes, mais peuvent être utilisés afin de lancer DOS et d'autres attaques qui sont autrement empêchées par filtrage des paquets.

Les petits services TCP et UDP doivent être désactivés. Ces services incluent :

  • écho (numéro de port 7)

  • jeter (numéro de port 9)

  • journée (numéro de port 13)

  • chargen (numéro de port 19)

Bien que l'abus des petits services puisse être évité ou être rendu moins dangereux par des listes d'accès anti-spoofing, les services doivent être désactivés sur n'importe quel périphérique accessible dans le réseau. Les petits services sont désactivés par défaut dans le logiciel Cisco IOS versions 12.0 et ultérieures. Dans les logiciels antérieurs, les commandes de configuration globale no service tcp-small-servers et no service udp-small-servers peuvent être émis afin de les désactiver.

Ceci est une liste des services supplémentaires qui doivent être désactivés si pas en service :

  • Émettez la commande de configuration globale no ip finger afin de désactiver le service Finger. Les versions ultérieures à 12.1(5) et 12.1(5)T du logiciel Cisco IOS désactivent ce service par défaut.

  • Émettez la commande de configuration globale no ip bootp server afin de désactiver le protocole Bootstrap (BOOTP).

  • Dans les versions 12.2(8)T et ultérieures du logiciel Cisco IOS, émettez la commande en mode de configuration globale ip dhcp bootp ignore afin de désactiver BOOTP. Ceci laisse activés les services DHCP (Dynamic Host Configuration Protocol).

  • Les services DHCP peuvent être désactivés si les services de relais DHCP ne sont pas requis. Émettez la commande no service dhcp dans le mode de configuration globale.

  • Émettez la commande no mop enabled dans le mode de configuration de l'interface afin de désactiver le service MOP (Maintenance Operation Protocol).

  • Émettez la commande de configuration globale no ip domain-lookup afin de désactiver les services de résolution DNS (Domain Name System).

  • Émettez la commande de configuration globale no service pad afin de désactiver le service PAD (Packet Assembler/Disassembler), qui est utilisé pour des réseaux X.25.

  • Le serveur HTTP peut être désactivé avec la commande en mode de configuration globale no ip http server, et le serveur HTTPS (Secure HTTP) peut être désactivé avec la commande de configuration globale no ip http secure-server.

  • À moins que les périphériques Cisco IOS récupèrent des configurations du réseau pendant le démarrage, la commande de configuration globale no service config doit être utilisée. Ceci empêche le périphérique Cisco IOS d'essayer de localiser un fichier de configuration sur le réseau utilisant TFTP.

  • Le protocole CDP (Cisco Discovery Protocol) est un protocole de réseau qui est utilisé pour découvrir d'autres périphériques activés par CDP pour la contiguïté de voisins et la topologie du réseau. Le CDP peut être utilisé par NMS (Network Management Systems) ou pendant le dépannage. Le CDP doit être désactivé sur toutes les interfaces qui sont connectées aux réseaux non sécurisés. Ceci est accompli avec la commande d´interface no cdp enable. Alternativement, CDP peut être désactivé globalement avec la commande de configuration globale no cdp run. Notez que le CDP peut être utilisé par un utilisateur malveillant pour la reconnaissance et le mappage de réseau.

  • Le protocole LLDP (Link Layer Discovery Protocol) est un protocole IEEE qui est défini dans 802.1AB. Le LLDP est semblable à CDP. Cependant, ce protocole permet l'interopérabilité entre d'autres périphériques qui ne supportent pas CDP. Le LLDP doit être traité de la même manière que le CDP et être désactivé sur toutes les interfaces qui se connectent aux réseaux non sécurisés. Afin d'accomplir ceci, émettez les commandes de configuration d'interface no lldp transmettent et no lldp receive. Émettez la commande de configuration globale no lldp run afin de désactiver le LLDP globalement. Le LLDP peut également être utilisé par un utilisateur malveillant pour la reconnaissance et le mappage d´un réseau.

EXEC Timeout

Afin de définir l'intervalle que l'interpréteur de commande EXEC attend pour une entrée de l´utilisateur avant de terminer la session, émettez la commande de configuration de ligne exec-timeout. La commande exec-timeout doit être utilisée afin de fermer des sessions sur les lignes vty ou tty qui sont inactives. Par défaut, les sessions sont déconnectées après 10 minutes d'inactivité.


!

line con 0
 exec-timeout <minutes> [seconds]
line vty 0 4
 exec-timeout <minutes> [seconds]

!

Keepalives pour les sessions TCP

Les commandes de configuration globale service tcp-keepalive-in et service tcp-keepalive-out permettent à un périphérique d´envoyer des TCP keepalives pour les sessions TCP. Cette configuration doit être utilisée afin d'activer des TCP keepalives sur des connexions en entrée au périphérique et aux connexions en partance du périphérique. Ceci assure que le périphérique à l´extrémité distante de la connexion est encore accessible et que les connexions semi-ouvertes ou orphelines sont supprimées du périphérique local Cisco IOS.


!

service tcp-keepalive-in
service tcp-keepalive-out

!

Utilisation des interfaces de gestion

Le plan de gestion d'un périphérique est accédé intrabande ou hors bande sur une interface de gestion physique ou logique. Dans le meilleur des cas, l'accès de gestion in-band et out-of-band existe pour chaque périphérique réseau de sorte que le plan de gestion puisse être accédé pendant les pannes du réseau.

Une des interfaces les plus communes qui est utilisée pour l'accès in-band à un périphérique est l'interface de bouclage logique. Les interfaces de bouclage sont toujours actives, tandis que les interfaces physiques peuvent changer d'état, et l´interface peut ne pas être accessible. Il est recommandé d'ajouter une interface de bouclage à chaque périphérique comme interface de gestion et qu´elle soit utilisée exclusivement pour le plan de gestion. Ceci permet à l'administrateur d'appliquer les politiques dans tout le réseau pour le plan de gestion. Une fois que l'interface de bouclage est configurée sur un périphérique, elle peut être utilisée par les protocoles du plan de gestion, tels que SSH, SNMP et Syslog, afin d'envoyer et de recevoir du trafic.

Memory Threshold Notifications

La fonctionnalité Memory Threshold Notification, ajoutée au logiciel Cisco IOS Version 12.3(4)T, vous permet d´atténuer les états de mémoire saturée sur un périphérique. Cette fonctionnalité emploie deux méthodes pour accomplir ceci : Memory Threshold Notification et Memory Reservation.

Memory Threshold Notification produit un message du journal afin d'indiquer que la mémoire libre sur un périphérique est tombée plus bas qu´un seuil configuré. Cet exemple de configuration montre comment activer cette fonctionnalité avec la commande de configuration globale memory free low-watermark. Ceci permet à un périphérique de produire une notification quand la mémoire libre disponible tombe plus bas qu´un seuil spécifié, et de nouveau quand la mémoire libre disponible remonte à cinq pour cent du seuil spécifié.


!

memory free low-watermark processor <threshold>
memory free low-watermark io <threshold>

!

Memory Reservation est utilisé de sorte que la mémoire suffisante soit disponible pour des notifications critiques. Cet exemple de configuration explique comment activer cette fonctionnalité. Ceci s'assure que les processus de gestion continuent à fonctionner quand la mémoire du périphérique est épuisée.


!

memory reserve critical <value>

!

Référez-vous à Memory Threshold Notifications pour plus d'informations sur cette fonctionnalité.

CPU Thresholding Notification

Introduit dans le Logiciel Cisco IOS Version 12.3(4)T, la fonctionnalité CPU Thresholding Notification vous permet de détecter et d´être notifié quand la charge CPU sur un périphérique dépasse un seuil configuré. Quand le seuil est franchi, le périphérique produit et envoie un message de déroutement SNMP. Deux méthodes de seuillage d'utilisation du CPU sont supportées sur le logiciel Cisco IOS : Rising Threshold et Falling Threshold.

Cet exemple de configuration montre comment activer les Rising et Falling Thresholds qui déclenchent un message de notification de seuil CPU :


!

snmp-server enable traps cpu threshold

!

snmp-server host <host-address> <community-string> cpu 

!

process cpu threshold type <type> rising <percentage> interval <seconds> 
     [falling <percentage> interval <seconds>]
process cpu statistics limit entry-percentage <number> [size <seconds>]

!

Référez-vous à CPU Thresholding Notification pour plus d'informations sur cette fonctionnalité.

Reserve Memory for Console Access

Dans le Logiciel Cisco IOS Versions 12.4(15)T et ultérieure, la fonctionnalité Reserve Memory for Console Access peut être utilisée afin de réserver assez de mémoire pour assurer l'accès par console à un périphérique Cisco IOS pour des buts administratifs et de dépannage. Cette fonctionnalité est particulièrement bénéfique quand le périphérique fonctionne sur mémoire basse. Vous pouvez émettre la commande de configuration globale memory reserve console afin d'activer cette fonctionnalité. Cet exemple configure un périphérique Cisco IOS pour réserver 4096 kilo-octets à cet effet.


!

memory reserve console 4096

!

Référez-vous à Reserve Memory for Console Access pour plus d'informations sur cette fonctionnalité.

Memory Leak Detector

Introduite dans le logiciel Cisco IOS version 12.3(8)T1, la fonctionnalité Memory Leak Detector vous permet de détecter les fuites de mémoire sur un périphérique. Memory Leak Detector peut rechercher des fuites dans tous les pools de mémoire, tampons de paquets et blocs. Les fuites de mémoire sont des affectations statiques ou dynamiques de la mémoire qui n'atteignent aucun objectif utile. Cette fonctionnalité se concentre sur les allocations de mémoire qui sont dynamiques. Vous pouvez employer la commande EXEC show memory debug leaks afin de détecter si une fuite de mémoire existe.

Référez-vous à Memory Leak Detector pour plus d'informations sur cette fonctionnalité.

Buffer Overflow : Détection et correction de la corruption de Redzone

Dans le logiciel Cisco IOS Versions 12.3(7)T et ultérieure, le Buffer Overflow : La détection et la correction de la fonctionnalité Redzone Corruption peut être activée sur un périphérique afin de détecter et corriger un débordement de bloc mémoire et de continuer les opérations.

Ces commandes de configuration globale peuvent être utilisées afin d'activer cette fonctionnalité. Une fois configurée, la commande show memory overflow peut être utilisée afin d'afficher les statistiques de détection et de correction d´un dépassement de mémoire tampon.


!

exception memory ignore overflow io
exception memory ignore overflow processor

!

Référez-vous à Buffer Overflow : Détection et correction de Redzone Corruption pour plus d'informations sur cette fonctionnalité.

Enhanced Crashinfo File Collection

La fonctionnalité Enhanced Crashinfo File Collection supprime automatiquement les vieux fichiers crashinfo. Cette fonctionnalité, ajoutée dans le logiciel Cisco IOS Version 12.3(11)T, permet à un périphérique de reprendre l'espace pour créer de nouveaux fichiers crashinfo quand le périphérique tombe en panne. Cette fonctionnalité autorise également la configuration du nombre de fichiers crashinfo à enregistrer.


!

exception crashinfo maximum files <number-of-files>

!

Référez-vous à Enhanced Crashinfo File Collection pour plus d'informations sur cette fonctionnalité.

Network Time Protocol

Le Network Time Protocol (NTP) n'est pas un service particulièrement dangereux, mais n'importe quel service inutile peut représenter un vecteur d'attaque. Si le NTP est utilisé, il est important de configurer explicitement une source temporelle de confiance et d'utiliser l'authentification appropriée. Une heure précise et fiable est requise pour Syslog, comme pendant les investigations légales d´attaques potentielles, ainsi que pour la connectivité réussie de VPN en cas de dépendance sur les certificats pour l´authentification de phase 1.

  • Fuseau horaire de NTP - En configurant NTP, le fuseau horaire doit être configuré de sorte que les horodatages puissent être corrélés avec précision. Il y a habituellement deux approches pour configurer le fuseau horaire pour des périphériques dans un réseau avec une présence internationale. Une méthode est de configurer tous les périphériques réseau avec l´UTC (Coordinated Universal Time) (précédemment heure GMT (Greenwich Mean Time)). L'autre approche est de configurer les périphériques réseau avec le fuseau horaire local. Plus d'informations sur cette fonctionnalité peuvent être trouvées dans « clock timezone » dans la documentation du produit Cisco.

  • Authentification de NTP - Configurer l'authentification de NTP fournit l'assurance que les messages NTP sont échangés entre les homologues de confiance de NTP. Référez-vous à ntp authenticate et ntp authentication-key pour plus d'informations sur la façon de configurer l'authentification de NTP.

Limitation de l'accès au réseau avec des ACL d'infrastructure

Conçu pour empêcher la communication directe non autorisée aux équipements réseau, les listes de contrôle d'accès d'infrastructure (iACL) sont l'un des contrôles de sécurité les plus critiques qui peuvent être mis en application dans les réseaux. Les ACL d'infrastructure exploitent l'idée que presque tout le trafic sur le réseau traverse le réseau et n'est pas destiné au réseau lui-même.

Un iACL est construit et appliqué pour spécifier les connexions des hôtes ou des réseaux qui doivent être permises aux équipements réseau. Des exemples communs de ces types de connexions sont eBGP, SSH et SNMP. Après avoir permis les connexions requises, tout autre trafic à l'infrastructure est explicitement refusé. Tout trafic de transit qui croise le réseau et n'est pas destiné aux périphériques d'infrastructure est alors explicitement autorisé.

Les protections fournies par les iACL sont pertinentes aux plans de gestion et de contrôle. La mise en place des iACL peut être facilitée par l'utilisation de l'adressage distinct pour des périphériques d'infrastructure réseau. Référez-vous à Une approche orientée sécurité de l'adressage IP pour plus d'informations sur les implications en matière de sécurité de l'adressage IP.

Cet exemple de configuration d´iACL illustre la structure qui doit être utilisée comme point de départ quand vous commencez le processus d'implémentation d'iACL :


!

ip access-list extended ACL-INFRASTRUCTURE-IN

!
!--- Permit required connections for routing protocols and
!--- network management
!

 permit tcp host <trusted-ebgp-peer> host <local-ebgp-address> eq 179
 permit tcp host <trusted-ebgp-peer> eq 179 host <local-ebgp-address>
 permit tcp host <trusted-management-stations> any eq 22
 permit udp host <trusted-netmgmt-servers> any eq 161

!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>

!
!--- Permit transit traffic
!

 permit ip any any

!

Une fois créé, l'iACL doit être appliqué à toutes les interfaces qui font face à des périphériques de non-infrastructure. Ceci inclut les interfaces qui se connectent à d'autres organismes, les segments d'accès à distance, les segments utilisateur et les segments aux centres de données.

Reportez-vous à Protection de votre noyau : Listes de contrôle d'accès de protection d'infrastructure pour plus d'informations sur les ACL d'infrastructure.

Filtrage des paquets ICMP

L'ICMP (Internet Control Message Protocol) est conçu comme protocole de contrôle IP. En tant que tels, les messages qu´il transporte peuvent avoir des ramifications de grande envergure pour les protocoles TCP et IP en général. Tandis que les outils de dépannage de réseau ping et traceroute utilisent ICMP, la connectivité externe d'ICMP est nécessaire rarement pour l'opération appropriée d'un réseau.

Le logiciel Cisco IOS fournit la fonctionnalité pour filtrer spécifiquement des messages ICMP par nom ou type et code. Cet exemple d´ACL, qui doit être utilisé avec les entrées de contrôle d'accès (ACE) des exemples précédents, permet des pings des stations de gestion et serveurs NMS de confiance et bloque tous les autres paquets ICMP :


!

ip access-list extended ACL-INFRASTRUCTURE-IN

!
!--- Permit ICMP Echo (ping) from trusted management stations and servers
!

 permit icmp host <trusted-management-stations> any echo
 permit icmp host <trusted-netmgmt-servers> any echo

!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>

!
!--- Permit transit traffic
!

 permit ip any any

!

Filtrage des fragments IP

Le filtrage de paquets IP fragmentés peut lancer un défi aux dispositifs de sécurité. C'est parce que l'information de couche 4 qui est utilisée afin de filtrer les paquets TCP et UDP est seulement présente dans le fragment initial. Le logiciel Cisco IOS emploie une méthode spécifique pour contrôler les fragments non initiaux contre les listes d'accès configurées. Le logiciel Cisco IOS évalue ces fragments non initiaux contre l'ACL et ignore n'importe quelle information de filtrage de la couche 4. Ceci cause des fragments non initiaux d'être évalués seulement sur la portion couche 3 de tout ACE configuré.

Dans cet exemple de configuration, si un paquet TCP destiné à 192.168.1.1 sur le port 22 est réduit en fragments en transit, le fragment initial est abandonné comme prévu par le second ACE basé sur l'information de la couche 4 dans le paquet. Cependant, tous les fragments restant (non-initiaux) sont autorisés par le premier ACE basé complètement sur l'information de la couche 3 dans le paquet et l´ACE. Ce scénario est montré dans cette configuration :


!

ip access-list extended ACL-FRAGMENT-EXAMPLE
 permit tcp any host 192.168.1.1 eq 80
 deny tcp any host 192.168.1.1 eq 22

!

En raison de la nature non intuitive du traitement des fragments, les fragments IP sont souvent autorisés par mégarde par les ACL. La fragmentation est également souvent employée dans les tentatives d'éluder la détection par les systèmes de détection des intrusions. C'est pour ces raisons que les fragments IP sont employés souvent dans les attaques, et pourquoi ils doivent être explicitement filtrés en tête de tous les iACL configurés. Cet exemple d´ACL inclut le filtrage complet des fragments d'IP. La fonctionnalité de cet exemple doit être utilisée en même temps que la fonctionnalité des exemples précédents.


!

ip access-list extended ACL-INFRASTRUCTURE-IN

!
!--- Deny IP fragments using protocol-specific ACEs to aid in
!--- classification of attack traffic
!

 deny tcp any any fragments
 deny udp any any fragments
 deny icmp any any fragments
 deny ip any any fragments

!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>

!
!--- Permit transit traffic
!

 permit ip any any

!

Référez-vous à Listes de contrôle d'accès et fragments d'IP pour plus d'informations sur le traitement d'ACL de paquets d´IP fragmentés.

Support d'ACL pour le filtrage des options IP

Le logiciel Cisco IOS Version 12.3(4)T a ajouté le support pour l'utilisation des ACL pour filtrer les paquets IP basé sur les options d'IP qui sont contenues dans le paquet. Les options IP présentent un défi de sécurité pour les équipements réseau parce que ces options doivent être traitées comme des paquets d´exception. Ceci exige un niveau d'effort du CPU qui n'est pas requis pour les paquets typiques qui traversent le réseau. La présence des options d'IP dans un paquet peut également indiquer une tentative de corrompre les contrôles de sécurité dans le réseau ou de modifier autrement les caractéristiques de transit d'un paquet. C´est pour ces raisons que les paquets avec des options d'IP doivent être filtrés à la frontière du réseau.

Cet exemple doit être utilisé avec les ACE des exemples précédents afin d'inclure le filtrage complet des paquets IP qui contiennent des options IP :


!

ip access-list extended ACL-INFRASTRUCTURE-IN

!
!--- Deny IP packets containing IP options
!

 deny ip any any option any-options

!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>

!
!--- Permit transit traffic
!

 permit ip any any

!

Référez-vous à Support d'ACL pour le filtrage des options IP pour plus d'informations sur cette fonction.

Support d´ACL pour le filtrage sur la valeur de TTL

Le logiciel Cisco IOS Version 12.4(2)T a ajouté le support d'ACL pour le filtrage des paquets IP, basé sur la valeur de TTL (Time to Live). La valeur de TTL d'un datagramme IP est décrémentée par chaque périphérique réseau lorsqu´un paquet passe de la source à la destination. Bien que les valeurs initiales varient par le système d'exploitation, quand le TTL d'un paquet atteint zéro, le paquet doit être abandonné. Le périphérique qui décrémente le TTL à zéro, et abandonne donc le paquet, est requis de produire et d´envoyer un message de temps expiré de l´ICMP à la source du paquet.

La production et la transmission de ces messages est un processus d'exception. Les routeurs peuvent remplir cette fonction quand le nombre de paquets IP expirant est faible, mais si le nombre de paquets IP expirant est élevé, la production et la transmission de ces messages peut consommer toutes les ressources CPU disponibles. Ceci présente un vecteur d'attaque DoS. C'est pour cette raison que des périphériques doivent être durcis contre les attaques DoS qui utilisent un débit élevé de paquets IP expirant.

Il est recommandé que les organismes filtrent les paquets IP avec des valeurs basses de TTL à la périphérie du réseau. Un filtrage complet des paquets avec des valeurs de TTL insuffisantes pour traverser le réseau atténue la menace des attaques basées sur TTL.

Cet exemple d´ACL filtre les paquets avec des valeurs de TTL inférieures à six. Ceci assure la protection contre les attaques d'échéance de TTL pour des réseaux jusqu'à cinq sauts de largeur.


!

ip access-list extended ACL-INFRASTRUCTURE-IN

!
!--- Deny IP packets with TTL values insufficient to traverse the network
!

 deny ip any any ttl lt 6

!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>

!
!--- Permit transit traffic
!

 permit ip any any

!

Notez que quelques protocoles font une utilisation légitime de paquets avec des valeurs de TTL basses. L'eBGP est l´un de tels protocoles. Référez-vous à TTL Expiry Attack Identification and Mitigation pour plus d'informations sur l´atténuation des attaques basées sur l´échéance de TTL.

Référez-vous à Support d´ACL pour le filtrage sur la valeur de TTL pour plus d'informations sur cette fonction.

Sécurisation des sessions interactives de gestion

Les sessions de gestion de périphériques vous permettent d'afficher et collecter des informations au sujet d'un périphérique et de ses opérations. Si ces informations sont révélées à un utilisateur malveillant, le périphérique peut devenir la cible d'une attaque, compromis, et utilisé afin d'exécuter des attaques supplémentaires. N'importe qui avec l'accès privilégié à un périphérique a la capacité de plein contrôle administratif de ce périphérique. La sécurisation des sessions de gestion est impérative pour empêcher la révélation d'informations et l'accès non autorisé.

Protection du plan de gestion

Commençant avec le Logiciel Cisco IOS Version 12.4(6)T, la fonctionnalité MPP (Management Plane Protection) permet à un administrateur de restreindre sur quelles interfaces le trafic de gestion peut être reçu par un périphérique. Ceci permet à l'administrateur le contrôle supplémentaire d'un périphérique et comment le périphérique est accédé.

Cet exemple montre comment activer MPP pour permettre seulement SSH et HTTPS sur l´interface GigabitEthernet0/1 :


!

control-plane host
  management-interface GigabitEthernet 0/1 allow ssh https

!

Référez-vous à Protection du plan de gestion pour plus d'informations sur le MPP.

Protection du plan de contrôle

CPPr (Control Plane Protection) se base sur la fonctionnalité de Surveillance du panneau de contrôle afin de restreindre et de contrôler le trafic du plan de contrôle qui est destiné au processeur de routage du périphérique IOS. CPPr, ajouté dans le Logiciel Cisco IOS Version 12.4(4)T, divise le plan de contrôle en catégories distinctes du plan de contrôle qui sont connues comme sous-interfaces. Trois sous-interfaces de plan de contrôle existent : Hôte, Transit et CEF-Exception. En outre, CPPr inclut ces fonctionnalités de protection supplémentaires du plan de contrôle :

  • Fonctionnalité Port-filtering - Cette fonctionnalité fournit le contrôle ou le rejet de paquets allant vers des ports TCP et UDP fermés ou pas à l´écoute.

  • Fonctionnalité Queue-threshold policy - Cette fonctionnalité limite le nombre de paquets pour un protocole donné qui sont permis dans la file d'attente d'entrée du plan de contrôle IP.

CPPr permet à un administrateur de classifier, contrôler et restreindre le trafic qui est envoyé à un périphérique pour la gestion en utilisant la sous-interface de l´hôte. Des exemples de paquets qui sont classifiés pour la catégorie de sous-interface de l´hôte incluent le trafic de gestion tel que SSH ou Telnet et les protocoles de routage.

Notez que CPPr ne supporte pas IPv6 et est limité au chemin d'entrée d'IPv4.

Référez-vous à Guide de la fonctionnalité Protection du plan de contrôle - 12.4T et Comprendre la Protection du plan de contrôle pour plus d'informations sur la fonctionnalité CPPr de Cisco.

Sessions de gestion de chiffrement

Puisque l'information peut être révélée pendant une gestion interactive session, ce trafic doit être chiffré de sorte qu'un utilisateur malveillant ne puisse pas accéder aux données étant transmises. Le chiffrement du trafic permet une connexion sécurisée d´accès à distance au périphérique. Si trafic pour une gestion session est envoyé au-dessus du réseau en libellé, un attaquant peut obtenir des informations confidentielles au sujet du périphérique et du réseau.

Un administrateur peut établir une connexion chiffré et d'accès distant sécurisé de Gestion à un périphérique à l'aide des caractéristiques de SSH ou HTTPS (protocole de transfert hypertexte sécurisé). Version SSH 1,0 (SSHv1) de supports logiciels de Cisco IOS, version SSH 2,0 (SSHv2), et HTTPS qui utilise Secure Sockets Layer (SSL) et le Transport Layer Security (TLS) pour l'authentification et le chiffrement de données. Notez que SSHv1 et SSHv2 ne sont pas compatibles.

Le logiciel Cisco IOS supporte également Secure Copy Protocol (SCP), qui permet une connexion chiffrée et sécurisée pour copier des configurations ou des images logicielles de périphérique. SCP se fonde sur SSH. Cet exemple de configuration active SSH sur un périphérique Cisco IOS :


!

ip domain-name example.com

!

crypto key generate rsa modulus 2048

!

ip ssh time-out 60
ip ssh authentication-retries 3
ip ssh source-interface GigabitEthernet 0/1

!

line vty 0 4
 transport input ssh

!

Cet exemple de configuration active les services SCP :


!

ip scp server enable

!

C'est un exemple de configuration pour les services HTTPS :


!

crypto key generate rsa modulus 2048

!

ip http secure-server

!

Référez-vous à FAQ sur la configuration de Secure Shell sur routeurs et commutateurs exécutant Cisco IOS et Secure Shell (SSH) pour plus d'informations sur la fonctionnalité SSH du logiciel Cisco IOS.

Référez-vous à HTTPS - HTTP Server and Client with SSL 3.0 Feature Guide - 12.2T et Cisco Tech Note Secure HTTP (HTTPS) Feature Guide - 12.1E pour plus d'informations sur la fonctionnalité HTTPS du logiciel Cisco IOS.

Référez-vous à Cisco Secure Copy (SCP) Feature Guide - 12.2T pour plus d'informations sur la fonctionnalité SCP du logiciel Cisco IOS.

SSHv2

La fonctionnalité introduite du support SSHv2 dans le Logiciel Cisco IOS version 12.3(4)T permet à un utilisateur pour configurer SSHv2. (Le support SSHv1 a été mis en application dans une version antérieure de logiciel de Cisco IOS.) les passages de SSH sur un transport fiable posent et fournissent des capacités d'authentification poussée et de cryptage. Le seul transport fiable qui est défini pour le SSH est TCP. Le SSH fournit des moyens d'accéder à sécurisé et exécuter sécurisé des commandes sur un ordinateur ou un périphérique différent au-dessus d'un réseau. La caractéristique de Secure Copy Protocol (SCP) qui est percée un tunnel au-dessus du SSH tient compte du transfert sécurisé des fichiers.

L'exemple de configuration suivant active SSHv2 (le SSHv1 étant désactivé) sur un périphérique de Cisco IOS :


!
    
hostname router

!

ip domain-name example.com    

!
    
crypto key generate rsa modulus 2048

!

ip ssh time-out 60  
ip ssh authentication-retries 3  
ip ssh source-interface GigabitEthernet 0/1    

!
    
ip ssh version 2

!

line vty 0 4   
transport input ssh    

!
 

Référez-vous au support sécurisé de version 2 de shell pour plus d'informations sur l'utilisation de SSHv2.

Améliorations SSHv2 pour des clés RSA

Le Cisco IOS SSHv2 prend en charge des méthodes d'authentification clavier-interactives et basées sur mot de passe. Les améliorations SSHv2 pour la caractéristique de clés RSA prend en charge également l'authentification basée sur RSA de clé publique pour le client et serveur.

Pour l'authentification de l'utilisateur, l'authentification de l'utilisateur basée sur RSA utilise paire de clés privée/publique associée avec chaque utilisateur pour l'authentification. L'utilisateur doit générer paire de clés privée/publique sur le client et configurer une clé publique sur le serveur de SSH de Cisco IOS pour se terminer l'authentification.

Un utilisateur de SSH essayant d'établir les qualifications fournit une signature chiffrée utilisant la clé privée. La signature et la clé publique de l'utilisateur sont envoyées au serveur de SSH pour l'authentification. Le serveur de SSH calcule des informations parasites au-dessus de la clé publique fournie par l'utilisateur. Les informations parasites sont utilisées pour déterminer si le serveur a une entrée assortie. Si une correspondance est trouvée, la vérification basée sur RSA de message est exécutée utilisant la clé publique. Par conséquent, l'utilisateur est authentifié ou accès basé sur refusé sur la signature chiffrée.

Pour l'authentification de serveur, le client SSH de Cisco IOS doit assigner une clé de hôte pour chaque serveur. Quand les essais de client pour établir une session de SSH avec un serveur, il reçoit la signature du serveur en tant qu'élément du message d'échange principal. Si la clé de hôte stricte vérifiant l'indicateur est activée sur le client, le client vérifie s'il a l'entrée de clé de hôte correspondant au serveur préconfiguré. Si une correspondance est trouvée, les essais de client pour valider la signature utilisant la clé d'hôte de serveur. Si le serveur est avec succès authentifié, l'établissement de session continue ; autrement il est terminé et affiche un message « d'échec de l'authentification de serveur ».

L'exemple de configuration suivant active l'utilisation des clés RSA avec SSHv2 sur un périphérique de Cisco IOS :


!
! Configure a hostname for the device
!

hostname router

!
! Configure a domain name
!

ip domain-name cisco.com

!
! Specify the name of the RSA key pair (in this case, "sshkeys") to use for SSH
!

 ip ssh rsa keypair-name sshkeys

!
! Enable the SSH server for local and remote authentication on the router using 
! the "crypto key generate" command
! For SSH version 2, the modulus size must be at least 768 bits 
!

 crypto key generate rsa usage-keys label sshkeys modulus 2048

!
! Configure an ssh timeout (in seconds) 
!
! The following enables a timeout of 120 seconds for SSH connections
!

ip ssh time-out 120

!
! Configure a limit of five (5) authentication retries
!

ip ssh authentication-retries 5

!
! Configure SSH version 2
!

ip ssh version 2 

!

Référez-vous aux améliorations sécurisées de version 2 de shell pour des clés RSA pour plus d'informations sur l'utilisation des clés RSA avec SSHv2.

L'exemple de configuration suivant permet au serveur de SSH de Cisco IOS d'exécuter l'authentification de l'utilisateur basée sur RSA. L'authentification de l'utilisateur est réussie si la clé publique RSA enregistrée sur le serveur est vérifiée avec le public ou la paire de clés privée enregistrée sur le client.


!
! Configure a hostname for the device
!

hostname router

!
! Configure a domain name
!

ip domain-name cisco.com

!
! Generate RSA key pairs using a modulus of 2048 bits
!

crypto key generate rsa modulus 2048

!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain

!
! Configure the SSH username
!

        username ssh-user

!
! Specify the RSA public key of the remote peer
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the 
! key-hash command (followed by the SSH key type and version.)
!

Référez-vous à configurer le serveur de SSH de Cisco IOS pour exécuter l'authentification de l'utilisateur basée sur RSA pour plus d'informations sur l'utilisation des clés RSA avec SSHv2.

L'exemple de configuration suivant permet au client SSH de Cisco IOS d'exécuter l'authentification de serveur basée sur RSA.

	 

!
!

hostname router

!
ip domain-name cisco.c
!
! Generate RSA key pairs
!

crypto key generate rsa

!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain

!
! Enable the SSH server for public-key authentication on the router 
!

        server SSH-server-name

!
! Specify the RSA public-key of the remote peer 
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the 
! key-hash <key-type> <key-name> command (followed by the SSH key 
! type and version.)
!
! Ensure that server authentication takes place - The connection will be 
! terminated on a failure
!

ip ssh stricthostkeycheck 

!

Référez-vous à configurer le client SSH de Cisco IOS pour exécuter l'authentification de serveur basée sur RSA pour plus d'informations sur l'utilisation des clés RSA avec SSHv2.

Console et ports AUX

Dans les périphériques Cisco IOS, console et ports auxiliaires (AUX) sont des lignes asynchrones qui peuvent être utilisées pour l'accès local et à distance à un périphérique. Vous devez vous rendre compte que les ports de console sur les périphériques Cisco IOS ont des privilèges spéciaux. En particulier, ces privilèges permettent à un administrateur d´exécuter la procédure de récupération de mot de passe. Afin d'exécuter la récupération de mot de passe, un attaquant non authentifié devrait avoir accès au port de console et la capacité d'interrompre l´alimentation du périphérique ou de faire tomber en panne le périphérique.

N'importe quelle méthode utilisée afin d'accéder au port de console d'un périphérique doit être sécurisée d´une manière qui est égale à la sécurité qui est imposée pour l'accès privilégié à un périphérique. Les méthodes utilisées afin de sécuriser l'accès doivent inclure l'utilisation de l'AAA, de l´exec-timeout et des mots de passe du modem si un modem est attaché à la console.

Si la récupération de mot de passe n'est pas requise, alors un administrateur peut retirer la capacité d'exécuter la procédure de récupération de mot de passe en utilisant la commande de configuration globale no service password-recovery ; cependant, une fois que la commande no service password-recovery a été activée, un administrateur ne peut plus exécuter la récupération de mot de passe sur un périphérique.

Dans la plupart des situations, le port AUX d'un périphérique doit être désactivé pour empêcher l'accès non autorisé. Un port AUX peut être désactivé en utilisant ces commandes :


!

line aux 0
 transport input none
 transport output none
 no exec
 exec-timeout 0 1
 no password

!

Contrôle des lignes vty et tty

Les sessions de gestion interactive dans le logiciel Cisco IOS utilisent un téléscripteur ou téléscripteur virtuel (vty). Un téléscripteur est une ligne locale asynchrone à laquelle un terminal peut être attaché pour l'accès local au périphérique ou un modem pour l'accès commuté au périphérique. Notez que des téléscripteurs peuvent être utilisés pour des connexions aux ports de console d'autres périphériques. Cette fonction permet à un périphérique avec des lignes tty d´agir en tant que serveur de console où des connexions peuvent être établies à travers le réseau aux ports de console des périphériques connectés aux lignes tty. Les lignes tty pour ces connexions inversées sur le réseau doivent également être contrôlées.

Une ligne vty est utilisée pour toutes les autres connexions réseau à distance supportées par le périphérique, indépendamment du protocole (SSH, SCP ou Telnet sont des exemples). Afin de s'assurer qu'un périphérique peut être accédé par l'intermédiaire d'une session de gestion locale ou à distance, des contrôles appropriés doivent être imposés sur les lignes vty et tty. Les périphériques Cisco IOS ont un nombre limité de lignes vty ; le nombre de lignes disponibles peut être déterminé à l'aide de la commande show line EXEC. Quand toutes les lignes vty sont en service, des nouvelles sessions de gestion ne peuvent pas être établies, créant une condition DoS pour l'accès au périphérique.

La forme la plus simple du contrôle d'accès à un vty ou un téléscripteur d'un périphérique est par l'utilisation de l'authentification sur toutes les lignes, indépendamment de l´emplacement du périphérique dans le réseau. C'est critique pour les lignes vty parce qu'elles sont accessibles par l'intermédiaire du réseau. Une ligne tty qui est connectée à un modem étant utilisé pour l'accès à distance au périphérique, ou une ligne tty qui est connectée au port de console d'autres périphériques sont également accessibles par l'intermédiaire du réseau. D'autres formes des contrôles d'accès vty et téléscripteur peuvent être imposées à l'aide des commandes de configuration transport input ou access-class, utilisant les fonctionnalités CoPP et CPPr, ou en appliquant des listes d'accès aux interfaces sur le périphérique.

L'authentification peut être imposée par l'utilisation de l'AAA, qui est la méthode recommandée pour l'accès authentifié à un périphérique, à l'aide de la base de données locale des utilisateurs, ou par simple authentification de mot de passe configurée directement sur la ligne vty ou tty.

La commande exec-timeout doit être utilisée afin de fermer des sessions sur les lignes vty ou tty qui sont inactives. La commande service tcp-keepalive-in doit également être utilisée afin d'activer les TCP keepalives sur les connexions entrantes au périphérique. Ceci assure que le périphérique à l´extrémité distante de la connexion est encore accessible et que les connexions semi-ouvertes ou orphelines sont supprimées du périphérique IOS local.

Contrôle du transport pour les lignes vty et tty

Un vty et un téléscripteur devraient être configurés pour accepter seulement des connexions chiffrées et sécurisées de gestion d'accès à distance au périphérique, ou par le périphérique s'il est utilisé comme serveur de console. Ce section a trait aux téléscripteurs parce que de telles lignes peuvent être connectées aux ports de console sur d'autres périphériques, qui permettent au téléscripteur d´être accessible sur le réseau. Dans un effort d'empêcher la révélation d'informations ou l'accès non autorisé aux données qui sont transmises entre l'administrateur et le périphérique, transport input ssh devrait être utilisé au lieu des protocoles en libellé, tels que Telnet et rlogin. La configuration transport input none peut être activée sur un téléscripteur, qui en fait empêche la ligne tty d'être utilisée pour des connexions d'inverse-console.

Les lignes vty et tty permettent toutes les deux à un administrateur de se connecter à d'autres périphériques. Afin de limiter le type de transport qu'un administrateur peut utiliser pour les connexions sortantes, utilisez la commande de configuration de ligne transport output. Si les connexions sortantes ne sont pas nécessaires, alors transport output none devrait être utilisé. Cependant, si les connexions sortantes sont permises, une méthode d'accès à distance chiffrée et sécurisée pour la connexion devrait alors être imposée par l'utilisation de transport output ssh.

Notez qu'IPSec peut être utilisé pour des connexions d'accès à distance chiffrées et sécurisées à un périphérique, si supporté. Si vous utilisez IPSec, il provoque une charge supplémentaire du CPU au périphérique. Cependant, SSH doit encore être imposé comme transport même lorsqu'IPSec est utilisé.

Messages d'avertissement

Dans certaines juridictions, il peut être impossible de poursuivre et illégal de surveiller les utilisateurs malveillants à moins qu'ils aient été notifiés qu'ils ne sont pas permis pour utiliser le système. Une méthode pour donner cette notification est de placer cette information dans un message de bannière qui est configuré avec la commande banner login du logiciel Cisco IOS.

Les exigences de notification légale sont complexes, varient par juridiction et situation, et devraient être discutées avec le conseiller juridique. Même dans des juridictions, les avis juridiques peuvent différer. En coopération avec l'avocat-conseil, une bannière peut fournir certaines ou toutes ces informations :

  • Notice qu´il faut se connecter au système ou qu´il soit utilisé seulement par un personnel spécifiquement autorisé et peut-être des informations sur qui peut autoriser l'utilisation.

  • Notez que n'importe quelle utilisation non autorisée du système est illégale et peut être sujette à des pénalités civiles et criminelles.

  • Notez que n'importe quelle utilisation du système peut être enregistrée ou surveillée sans autre communication préalable et que les journaux en résultant peuvent être utilisés comme preuves devant le tribunal.

  • Avis spécifiques requis par les lois locales.

D'un point de vue de la sécurité, plutôt que juridique, une bannière d'ouverture de connexion ne devrait contenir aucune information spécifique sur le nom du routeur, le modèle, le logiciel ou la propriété. Ces informations peuvent être abusées par des utilisateurs malveillants.

Utilisation de Authentication, Authorization, and Accounting (AAA)

Le cadre AAA (Authentication, Authorization, and Accounting) est critique pour sécuriser l'accès interactif aux périphériques du réseau. Le cadre AAA fournit un environnement fortement configurable qui peut être adapté aux besoins du réseau.

Authentification TACACS+

TACACS+ (Terminal Access Controller Access Control System Plus) est un protocole d'authentification que les périphériques Cisco IOS peuvent utiliser pour l'authentification des utilisateurs de gestion contre un serveur AAA distant. Ces utilisateurs de gestion peuvent accéder au périphérique IOS par l'intermédiaire de SSH, HTTPS, Telnet ou HTTP.

L'authentification TACACS+, ou plus généralement l´authentification AAA, fournit la capacité d'utiliser les comptes d'utilisateurs individuels pour chaque administrateur réseau. En enlevant la dépendance à l'égard un simple mot de passe partagé, la sécurité du réseau est améliorée et votre imputabilité est renforcée.

RADIUS (Remote Access Dial-In User Service) est un protocole à objectif semblable à TACACS+, mais il ne chiffre que le mot de passe envoyé à travers le réseau. En revanche, TACACS+ chiffre la charge utile entière de TCP, y compris le nom utilisateur et le mot de passe. Pour cette raison, TACACS+ devrait être utilisé de préférence à RADIUS quand TACACS+ est supporté par le serveur AAA. Référez-vous à Comparaison de TACACS+ et RADIUS pour une comparaison plus détaillée de ces deux protocoles.

L'authentification TACACS+ peut être activée sur un périphérique Cisco IOS utilisant une configuration semblable à cet exemple :


!

aaa new-model
aaa authentication login default group tacacs+

!

tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>

!

La configuration précédente peut être utilisée comme point de départ pour un modèle d´authentification AAA spécifique à une organisation. Référez-vous au protocole Authentication, Authorization, and Accounting pour plus d´informations sur la configuration d'AAA.

Une liste de méthodes est une liste séquentielle décrivant les méthodes d´authentification à requérir afin d'authentifier un utilisateur. Les listes de méthodes vous permettent de désigner un ou plusieurs protocoles de sécurité à utiliser pour l'authentification, de ce fait assurant un système de secours pour l'authentification au cas où la méthode initiale échouerait. Le logiciel Cisco IOS utilisera la première méthode listée qui accepte avec succès ou rejette un utilisateur. Les méthodes subséquentes sont seulement essayées dans les cas où les méthodes précédentes échouent en raison de l'indisponibilité ou de la configuration incorrecte du serveur. Référez-vous à Listes de méthodes nommées pour authentification pour plus d'informations sur configuration des listes de méthodes nommées.

Authentification de secours

Si tous les serveurs TACACS+ configurés deviennent indisponibles, alors un périphérique Cisco IOS peut se fonder sur des protocoles d'authentification secondaires. Les configurations typiques incluent l'utilisation de l'authentification locale ou activée si tous les serveurs TACACS+ configurés sont indisponibles.

La liste complète d'options pour l'authentification sur périphérique inclut activée, locale et ligne. Chacune de ces options a des avantages. L'utilisation de enable secret est préférée parce que le secret est haché en utilisant un algorithme à sens unique qui est en soi plus sécuritaire que l'algorithme de chiffrement qui est utilisé avec les mots de passe de type 7 pour l'authentification locale ou ligne.

Cependant, sur les versions du logiciel Cisco IOS qui supportent l'utilisation de mots de passe secrets pour les utilisateurs localement définis, un recours à l'authentification locale peut être desirable. Ceci permet de créer un utilisateur localement défini pour un ou plusieurs administrateurs réseau. Si TACACS+ devenait complètement indisponible, chaque administrateur peut utiliser son nom d'utilisateur local et son mot de passe. Bien que cette action améliore l'imputabilité des administrateurs réseau pendant les pannes du TACACS+, elle augmente de manière significative la charge d'administration parce que les comptes d'utilisateurs locaux sur tous les périphériques du réseau doivent être maintenus.

Cet exemple de configuration repose sur l´exemple précédent d'authentification TACACS+ pour inclure l'authentification de recours au mot de passe qui est configuré localement avec la commande enable secret :


!

enable secret <password>

!

aaa new-model
aaa authentication login default group tacacs+ enable

!

tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>

!

Référez-vous à Configuration de l´authentification pour plus d'informations sur l'utilisation de l'authentification de secours avec AAA.

Utilisation des mots de passe de type 7

Initialement conçu pour permettre le déchiffrement rapide des mots de passe stockés, les mots de passe de type 7 ne sont pas une forme sécurisée de stockage de mot de passe. Il y a beaucoup d'outils disponibles qui peuvent facilement déchiffrer ces mots de passe. L'utilisation des mots de passe du type 7 devrait être évitée à moins que requise par une fonctionnalité qui est en service sur un périphérique Cisco IOS.

La suppression des mots de passe de ce type peut être facilitée par l'authentification AAA et l'utilisation de la fonctionnalité Enhanced Password Security, qui permet d´utiliser des mots de passe secrets avec les utilisateurs qui sont localement définis par l'intermédiaire de la commande de configuration globale username. Si vous ne pouvez pas entièrement empêcher l'utilisation des mots de passe du type 7, considérez ces mots de passe brouillés mais non chiffrés.

Voir la section Durcissement général du plan de gestion de ce document pour plus d'informations sur la suppression des mots de passe du type 7.

Autorisation de commande avec TACACS+

L´autorisation de commande avec TACACS+ et AAA fournit un mécanisme qui accepte ou refuse chaque commande qui est entrée par un utilisateur administratif. Quand l'utilisateur entre des commandes EXEC, Cisco IOS envoie chaque commande au serveur AAA configuré. Le serveur AAA utilise alors ses politiques configurées afin d´accepter ou refuser la commande pour cet utilisateur particulier.

Cette configuration peut être ajoutée à l'exemple précédent d´authentification AAA afin de mettre en application l´autorisation de commande :


!

aaa authorization exec default group tacacs none
aaa authorization commands 0 default group tacacs none
aaa authorization commands 1 default group tacacs none 
aaa authorization commands 15 default group tacacs none

!

Référez-vous à Autorisation de configuration pour plus d'informations sur l´autorisation de commande.

Comptabilité de commandes TACACS+

Une fois configurée, la comptabilité des commandes AAA envoie des informations sur chaque commande EXEC qui est entrée aux serveurs TACACS+ configurés. L'information envoyée au serveur TACACS+ inclut la commande exécutée, la date elle a été exécutée et le nom utilisateur de l'utilisateur saisissant la commande. La comptabilité des commandes n'est pas supportée en utilisant RADIUS.

Cet exemple de configuration active la comptabilité des commandes AAA pour les commandes EXEC entrées aux niveaux de privilège zéro, un et 15. Cette configuration se base sur les exemples précédents qui incluent la configuration des serveurs TACACS.


!

aaa accounting exec default start-stop group tacacs 
aaa accounting commands 0 default start-stop group tacacs
aaa accounting commands 1 default start-stop group tacacs
aaa accounting commands 15 default start-stop group tacacs

!

Référez-vous à Configuration de la comptabilité pour plus d'informations concernant la configuration de la comptabilité AAA.

Serveurs AAA redondants

Les serveurs AAA qui sont exploités dans un environnement devraient être redondants et déployés d'une façon insensible aux défaillances. Ceci aide à s'assurer que l'accès à la gestion interactive, tel que SSH, est possible si un serveur AAA est indisponible.

Quand vous concevez ou mettez en application une solution de serveur AAA redondant, maintenez ces considérations dans l'esprit :

  • Disponibilité des serveurs AAA pendant les pannes de réseau potentielles

  • Emplacement géographiquement dispersé des serveurs AAA

  • Charge sur différents serveurs AAA lors de conditions d´équilibre et de panne

  • Latence de réseau entre les serveurs d'accès au réseau et les serveurs AAA

  • Synchronisation des bases de données de serveur AAA

Référez-vous à Déployer les serveurs de contrôle d'accès pour plus d'informations.

Enrichissement du Simple Network Management Protocol

Cette section met en valeur plusieurs méthodes qui peuvent être utilisées afin de sécuriser le déploiement de SNMP dans des périphériques IOS. Il est critique que SNMP soit correctement sécurisé pour protéger la confidentialité, l'intégrité, et la disponibilité des données du réseau et des périphériques réseau par lesquels ces données transitent. SNMP vous fournit une grande quantité d'informations sur la santé des périphériques réseau. Ces informations doivent être protégées des utilisateurs malveillants qui veulent exploiter ces données pour exécuter des attaques contre le réseau.

Chaînes de caractères de la communauté SNMP

Les chaînes de caractères de la communauté sont des mots de passe qui sont appliqués à un périphérique IOS pour limiter l'accès, en lecture seule et en lecture-écriture, aux données SNMP sur le périphérique. Ces chaînes de caractères de la communauté, comme avec tous les mots de passe, devraient être soigneusement choisies pour assurer qu'elles ne sont pas insignifiantes. Les chaînes de caractères de la communauté devraient être changées à intervalles réguliers et conformément aux stratégies de sécurité du réseau. Par exemple, les chaînes de caractères devraient être changées quand un administrateur réseau change des rôles ou quitte la société.

Ces lignes de configuration configurent une chaîne de caractères de la communauté en lecture seule READONLY, et une chaîne de caractères de la communauté en lecture-écriture READWRITE :


!

snmp-server community READONLY RO
snmp-server community READWRITE RW  

!

Notez que les exemples précédents de chaînes de caractères de la communauté ont été choisis pour expliquer clairement l'utilisation de ces chaînes de caractères. Pour des environnements de production, les chaînes de caractères de la communauté devraient être choisies avec prudence et devraient se composer d'une série de symboles alphabétiques, numériques et non-alphanumériques. Référez-vous à Recommandations pour la création de mots de passe forts pour plus d'informations sur la sélection de mots de passe non triviaux.

Référez-vous à Guide de référence des commandes pour IOS SNMP pour plus d'informations sur cette fonctionnalité.

Chaînes de caractères de la communauté SNMP avec ACL

En plus de la chaîne de caractères de la communauté, il faut appliquer une ACL qui limite encore plus l'accès SNMP à un groupe choisi d´adresses IP source. Cette configuration limite l'accès SNMP en lecture seule aux périphériques d'hôte qui résident dans l'espace d'adresses 192.168.100.0/24 et limite l'accès SNMP en lecture-écriture seulement au périphérique d'hôte d'extrémité à 192.168.100.1.

Notez que les périphériques qui sont permis par ces ACL exigent de la chaîne de caractères appropriée de la communauté d'accéder aux informations SNMP demandées.


!

access-list 98 permit 192.168.100.0 0.0.0.255
access-list 99 permit 192.168.100.1

!

snmp-server community READONLY RO 98
snmp-server community READWRITE RW 99

!

Référez-vous à snmp-server community dans la référence de commandes de la gestion de réseau de Cisco IOS pour plus d´informations sur cette fonctionnalité.

Les ACL d´infrastructure

Les ACL d´infrastructure (iACL) peuvent être déployés pour assurer que seuls les hôtes d'extrémité avec des adresses IP de confiance puissent envoyer le trafic SNMP à un périphérique IOS. Une iACL devrait contenir une politique qui refuse les paquets SNMP non autorisés sur le port UDP 161.

Voir la section Limitation de l'accès au réseau avec ACL d'infrastructure de ce document pour plus d'informations sur l'utilisation des iACL.

SNMP Views

SNMP Views est une fonctionnalité de sécurité qui peut permettre ou refuser l'accès à certains MIB SNMP. Une fois qu´un affichage est créé et appliqué à une chaîne de caractères de la communauté avec les commandes de configuration globale snmp-server community community-string view, si vous accédez à des données MIB, vous êtes limité aux autorisations qui sont définies par l'affichage. Quand approprié, vous êtes informé d´employer des affichages pour limiter les utilisateurs de SNMP aux données dont ils ont besoin.

Cet exemple de configuration limite l'accès SNMP avec la chaîne de caractères de la communauté LIMITED aux données MIB qui sont situées dans le groupe system :


!

snmp-server view VIEW-SYSTEM-ONLY system include

!

snmp-server community LIMITED view VIEW-SYSTEM-ONLY RO

!

Référez-vous à Configuration du support SNMP pour plus d'informations.

SNMP Version 3

SNMP version 3 (SNMPv3) est défini par RFC3410 , RFC3411 , RFC3412 , RFC3413 , RFC3414 et RFC3415 et est un protocole basé sur des normes interopérables pour la gestion de réseau.leavingcisco.com leavingcisco.com leavingcisco.com leavingcisco.com leavingcisco.com leavingcisco.com SNMPv3 fournit un accès sécurisé aux périphériques en authentifiant et, optionnellement, en chiffrant les paquets sur le réseau. Là où il est supporté, SNMPv3 peut être utilisé afin d'ajouter une autre couche de sécurité lors du déploiement de SNMP. SNMPv3 se compose de trois options principales de configuration :

  • no auth - Ce mode n'exige aucune authentification ni aucun chiffrement des paquets SNMP

  • auth - Ce mode exige l'authentification des paquets SNMP sans chiffrement

  • priv - Ce mode exige l'authentification et le chiffrement (confidentialité) de chaque paquet SNMP

L'ID d'un moteur principal doit exister pour utiliser les mécanismes de sécurité de SNMPv3 - authentification ou authentification et chiffrement - pour traiter les paquets SNMP ; par défaut, l'ID du moteur est produite localement. L'ID du moteur peut être affichée avec la commande show snmp engineID comme illustré dans cet exemple :

router#show snmp engineID 
   Local SNMP engineID: 80000009030000152BD35496
   Remote Engine ID          IP-addr    Port

Notez que si l'engineID est changé, tous les comptes d'utilisateur SNMP doivent être modifiés.

L'étape suivante est de configurer un groupe SNMPv3. Cette commande configure un périphérique Cisco IOS pour SNMPv3 avec un groupe de serveurs SNMP AUTHGROUP et active seulement l'authentification pour ce groupe à l'aide du mot clé d'auth :


!

snmp-server group AUTHGROUP v3 auth

!

Cette commande configure un périphérique Cisco IOS pour SNMPv3 avec un groupe de serveurs SNMP PRIVGROUP et active l'authentification et le chiffrement pour ce groupe à l'aide du mot clé de priv :


!

snmp-server group PRIVGROUP v3 priv

!

Cette commande configure un utilisateur SNMPv3 snmpv3user avec un mot de passe d'authentification MD5 de authpassword et le chiffrement 3DES du mot de passe de privpassword :


!

snmp-server user snmpv3user PRIVGROUP v3 auth md5 authpassword priv 3des 
     privpassword

!

Notez que les commandes de configuration snmp-server user ne sont pas affichées dans la sortie de configuration du périphérique selon les exigences de RFC 3414 ; donc, le mot de passe utilisateur n'est pas visualisable dans la configuration. Afin d'afficher les utilisateurs configurés, saisissez la commande show snmp user comme illustré dans cet exemple :

router#show snmp user 
User name: snmpv3user
Engine ID: 80000009030000152BD35496
storage-type: nonvolatile        active
Authentication Protocol: MD5
Privacy Protocol: 3DES
Group-name: PRIVGROUP

Référez-vous à Configuration du support SNMP pour plus d'informations sur cette fonctionnalité.

Protection du plan de gestion

La fonctionnalité Management Plane Protection (MPP) dans le logiciel Cisco IOS peut être utilisée afin de sécuriser SNMP en limitant les interfaces par lesquelles le trafic SNMP peut se terminer sur le périphérique. La fonctionnalité MPP permet à un administrateur de désigner une ou plusieurs interfaces comme interfaces de gestion. La gestion du trafic est autorisée à entrer dans un périphérique seulement par ces interfaces de gestion. Après que MPP soit activé, aucune interface, sauf les interfaces de gestion désignées, n'accepte de trafic de gestion du réseau qui est destiné au périphérique.

Notez que MPP est un sous-ensemble de la fonctionnalité Control Plane Protection (CPPr) et exige une version d´IOS qui supporte CPPr. Référez-vous à Comprendre la Protection du plan de contrôle pour plus d'informations sur CPPr.

Dans cet exemple, MPP est utilisé afin de limiter l´accès SNMP et SSH à seulement l´interface FastEthernet 0/0 :


!

control-plane host
 management-interface FastEthernet0/0 allow ssh snmp 

!

Référez-vous au Guide de la fonctionnalité Gestion du plan de contrôle pour plus d´informations.

Les meilleures pratiques de journalisation

La journalisation des événements vous fournit la visibilité dans le fonctionnement d'un périphérique Cisco IOS et du réseau dans lequel il est déployé. Le logiciel Cisco IOS fournit plusieurs options flexibles de journalisation qui peuvent aider à atteindre les buts de gestion du réseau et de visibilité d'une organisation.

Ces sections fournissent quelques meilleures pratiques de journalisation de base qui peuvent aider un administrateur à exploiter la journalisation avec succès tout en réduisant au minimum son incidence sur un périphérique Cisco IOS.

Envoyer les journaux à un emplacement central

Vous êtes informé d´envoyer les informations de journalisation à un serveur Syslog distant. En faisant ainsi, il devient possible de corréler et d´auditer plus efficacement les événements et la sécurité du réseau à travers les périphériques réseau. Notez que les messages Syslog sont transmis de manière peu fiable par UDP et en libellé. Pour cette raison, toutes les protections qu´un réseau offre au trafic de gestion (par exemple, chiffrement ou accès hors bande) devraient être étendues pour inclure le trafic Syslog.

Cet exemple de configuration configure un périphérique Cisco IOS pour envoyer les informations de journalisation à un serveur Syslog distant :


!

logging host <ip-address>

!

Référez-vous à Identification des incidents à l´aide de pare-feu et des événements Syslog du routeur IOS pour plus d'informations sur la corrélation de journal.

Intégré dans 12.4(15)T et initialement introduit dans 12.0(26)S, se connecter aux messages locaux de journalisation système d'enables de caractéristique de mémoire permanente (disque ATA) à enregistrer sur un disque Flash de la connexion de technologie avancée (ATA). Les messages enregistrés sur un lecteur ATA persistent après qu'un routeur soit redémarré.

Les lignes suivantes de configuration configurent 134.217.728 octets (128 Mo) de messages de journalisation au répertoire de Syslog de l'éclair ATA (disk0), spécifiant une taille de fichier de 16.384 octets :

logging buffered	
logging persistent url disk0:/syslog size 134217728 filesize 16384

Avant que des messages de journalisation soient écrits à un fichier sur le disque ATA, le logiciel de Cisco IOS vérifie pour voir s'il y a suffisamment d'espace disque. Sinon, le fichier le plus ancien des messages de journalisation (par l'horodateur) est supprimé, et le fichier en cours est enregistré. Le format de nom du fichier est log_month : jour : année : : temps. Notez qu'un lecteur flash ATA a limité l'espace disque et ainsi les besoins d'être mis à jour pour éviter de remplacer des données stockées. L'exemple suivant affiche comment copier des messages de journalisation à partir du disque Flash ATA du routeur sur un disque externe sur 192.168.1.129 serveur ftp en tant qu'élément des procédures de maintenance :

copy disk0:/syslog ftp://myuser/mypass@192.168.1.129/syslog

Référez-vous à se connecter à la mémoire permanente locale (disque ATA) pour plus d'informations sur cette caractéristique.

Niveau de journalisation

Chaque message du journal qui est produit par un périphérique Cisco IOS est assigné une de huit gravités qui vont du niveau 0, urgences, jusqu´au niveau 7, débogage. À moins que spécifiquement requis, vous êtes informé éviter de se connecter au niveau 7. se connectant au niveau 7 produit un chargement élevé CPU sur le périphérique qui peut mener au périphérique et à l'instabilité de réseau.

La commande de configuration globale logging trap level est utilisée afin de spécifier quels messages de journalisation sont envoyés aux serveurs Syslog distants. Le niveau spécifié indique le message de plus basse gravité qui est envoyé. Pour une journalisation mise en mémoire tampon, la commande logging buffered level est utilisée.

Cet exemple de configuration limite les messages du journal qui sont envoyés aux serveurs Syslog distants et à la mémoire tampon locale du journal aux gravités allant de 6 (informationnelles) à 0 (urgences) :


!

logging trap 6
logging buffered 6

!

Référez-vous à Dépannage, gestion des pannes et journalisation pour plus d'informations.

N´enregistrez pas à la console ou aux sessions de surveillance

Avec le logiciel Cisco IOS, il est possible d'envoyer des messages du journal aux sessions de surveillance - les sessions de surveillance sont des sessions interactive de gestion dans lesquelles la commande EXEC de surveillance de terminal a été émise - et à la console. Cependant, faire ainsi peut élever la charge CPU d'un périphérique IOS et n'est donc pas recommandé. Au lieu de cela, vous êtes conseillé d´envoyer les informations de journalisation à la mémoire tampon du journal local, qui peuvent être affichées en utilisant la commande show logging.

Utilisez les commandes de configuration globale no logging console et no logging monitor pour désactiver la journalisation à la console et aux sessions de surveillance. Cet exemple de configuration montre l'utilisation de ces commandes :


!

no logging console
no logging monitor

!

Référez-vous à Référence des commandes de gestion de réseau Cisco IOS pour plus d'informations sur les commandes de configuration globale.

Utiliser la journalisation mise en mémoire

Le logiciel Cisco IOS supporte l'utilisation d'une mémoire tampon locale du journal, de sorte qu'un administrateur puisse afficher les messages du journal localement produits. L'utilisation de mettre en mémoire tampon la journalisation est fortement recommandée contre la journalisation à la console ou aux sessions de surveillance.

Il y a deux configuration options qui sont pertinentes en configurant la journalisation mise en mémoire tampon : la taille de tampon de journalisation et les gravités des messages qui sont stockées dans la mémoire tampon. La taille du tampon de journalisation est configurée avec la commande de configuration globale logging buffered size. La plus basse gravité incluse dans la mémoire tampon est configurée en utilisant la commande logging buffered severity. Un administrateur peut afficher le contenu du tampon de journalisation au moyen de la commande show logging exec.

Cet exemple de configuration inclut la configuration d'un tampon de journalisation de 16384 octets, ainsi qu´une gravité de 6, informationnel, indiquant que les messages de niveaux 0 (urgences) à 6 (informationnel) sont stockés :


!

logging buffered 16384 6

!

Référez-vous à Référence de commandes de gestion de réseau Cisco IOS pour plus d'informations sur la journalisation mise en mémoire tampon.

Configurer l´interface de la source de journalisation

Afin de fournir un plus grand niveau de cohérence lors de la collecte et de la revue des messages du journal, il est recommandé de configurer statiquement une interface de la source de journalisation. Accompli par l'intermédiaire de la commande d´interface logging source-interface, configurer statiquement une interface de source de journalisation assure que la même adresse IP apparaît dans tous les messages de journalisation qui sont envoyés d'un périphérique Cisco IOS individuel. Pour plus de stabilité, il est recommandé d´utiliser une interface de bouclage comme source de journalisation.

Cet exemple de configuration montre l'utilisation de la commande de configuration globale logging source-interface interface pour spécifier que l'adresse IP de l´interface de bouclage 0 soit utilisée pour tous les messages du journal :


!

logging source-interface Loopback 0

!

Pour plus d'informations, référez-vous à Référence des commandes Cisco IOS.

Configurer les horodatages des journalisations

La configuration des horodatages des journalisations vous aide à corréler des événements à travers les périphériques réseau. Il est important de mettre en application une configuration d´horodatage correct et cohérent des journalisations pour assurer que vous pouvez corréler les données de journalisation. Les horodatages des journalisations devraient être configurés pour inclure la date et l´heure avec une précision de milliseconde et pour inclure le fuseau horaire en service sur le périphérique.

Cet exemple inclut la configuration de l´horodatage des journalisations avec une précision de milliseconde dans la zone UTC (Coordinated Universal Time) :


!

service timestamps log datetime msec show-timezone

!

Si vous préférez ne pas enregistrer les heures relativement à l´UTC, vous pouvez configurer un fuseau horaire local spécifique et configurer cette information pour être présente dans les messages du journal produits. Cet exemple montre une configuration de périphérique pour la zone Heure standard du Pacifique (PST) :


!

clock timezone PST -8
service timestamps log datetime msec localtime show-timezone

!

Référez-vous à service timestamps et clock timezone pour plus d'informations sur ces commandes.

Gestion de la configuration du logiciel Cisco IOS

Le logiciel Cisco IOS inclut plusieurs fonctionnalités qui peuvent activer une forme de gestion de configuration sur un périphérique Cisco IOS. De telles fonctions incluent une fonctionnalité pour archiver des configurations et retourner la configuration à une précédente version ainsi que pour créer un journal détaillé des modifications de configuration.

Configuration Replace et Configuration Rollback

Commençant avec le logiciel Cisco IOS Version 12.3(7)T, les fonctionnalités Configuration Replace et Configuration Rollback permettent l'archivage de la configuration d´un périphérique Cisco IOS sur le périphérique. Stockées manuellement ou automatiquement, les configurations dans cette archive peuvent être utilisées afin de remplacer la configuration en cours en utilisant la commande configure replace filename. Ceci contraste avec la commande copy filename running-config. La commande configure replace filename remplace la configuration en cours par opposition à la fusion exécutée par la commande copy.

Il est recommandé d´activer cette fonctionnalité sur tous les périphériques Cisco IOS du réseau. Une fois activée, un administrateur peut faire ajouter la configuration en cours à l'archive à l'aide de la commande EXEC privilégiée archive config. Les configurations archivées peuvent être affichées en utilisant la commande EXEC show archive.

Cet exemple illustre la configuration de l'archivage automatique de configuration. Cet exemple instruit le périphérique Cisco IOS de stocker les configurations archivées en tant que fichiers nommés archived-config-N sur le disk0 : système de fichier, pour maintenir un maximum de 14 copies de sauvegarde, et pour l'archiver une fois par jour (1440 minutes) et quand un administrateur émet la commande EXEC write memory.


!

archive
 path disk0:archived-config
 maximum 14
 time-period 1440
 write-memory

!

Bien que la fonction d´archivage de configuration puisse enregistrer jusqu'à 14 configurations de secours, il est recommandé de considérer l´espace requis avant d'utiliser la commande maximum.

Référez-vous à Configuration Replace and Configuration Rollback pour plus d'informations.

Exclusive Configuration Change Access

Ajouté au Logiciel Cisco IOS Version 12.3(14)T, la fonctionnalité Exclusive Configuration Change Access assure que seulement un administrateur apporte des modifications de configuration à un périphérique Cisco IOS à un moment donné. Cette fonctionnalité aide à éliminer l'incidence indésirable de modifications simultanées apportées à des composants de configuration apparentés. Cette fonctionnalité est configurée en utilisant la commande de configuration globale configuration mode exclusive mode et fonctionne dans l´un de deux modes : auto et manuel. En mode automatique, la configuration se verrouille automatiquement quand un administrateur émet la commande EXEC configure terminal. En mode manuel, l'administrateur utilise la commande configure terminal lock pour verrouiller la configuration lors de l´entrée en mode configuration.

Cet exemple illustre la configuration de cette fonctionnalité pour le verrouillage automatique de la configuration :


!

configuration mode exclusive auto

!

Référez-vous à Exclusive Configuration Change Access (Config Lock) pour plus d'informations.

Cisco IOS Software Resilient Configuration

Ajoutée dans le logiciel Cisco IOS Version 12.3(8)T, la fonctionnalité Resilient Configuration permet de stocker sécuritairement une copie de l'image du logiciel Cisco IOS et de la configuration de périphérique qui est actuellement utilisée par un périphérique Cisco IOS. Quand cette fonctionnalité est activée, il n´est pas possible de modifier ou supprimer ces fichiers de sauvegarde. Il est recommandé d´activer cette fonctionnalité pour empêcher des tentatives négligentes et malveillantes de supprimer ces fichiers.


!

secure boot-image
secure boot-config

!

Une fois que cette fonctionnalité est activée, il est possible de rétablir une configuration supprimée ou l´image du logiciel Cisco IOS. L'état d´exécution actuel de cette fonctionnalité peut être affiché en utilisant la commande EXEC show secure boot.

Référez-vous à Cisco IOS Resilient Configuration pour plus d'informations sur cette fonctionnalité.

Logiciel de Cisco signé par Digital

Ajouté dans le Logiciel Cisco IOS version 15.0(1)M pour Cisco 1900, 2900, et des Routeurs de gamme 3900, la caractéristique de logiciel signée par Digital de Cisco facilite l'utilisation du logiciel de Cisco IOS qui est digitalement signé et fait confiance ainsi, utilisant le chiffrement asymétrique sécurisé (de public-clé).

Une image digitalement signée porte (avec une clé privée) des informations parasites chiffrées de elle-même. Sur le contrôle, le périphérique déchiffre les informations parasites utilisant la clé publique correspondante des clés qu'elle a dans sa mémoire principale et calcule également ses propres informations parasites de l'image. Si les informations parasites déchiffrées apparient les informations parasites calculées d'image, l'image n'a pas été trifouillée et peut sont de confiance.

Des clés de logiciel de Cisco signées par Digital sont identifiées par le type et la version de la clé. Une clé peut être une offre spéciale, une production, ou un type principal inversé. Les types de clé de production et d'offre spéciale ont une version principale associée qui incrémente alphabétiquement toutes les fois que la clé est retirée et remplacée. ROMmon et images régulières de Cisco IOS sont signés avec une clé d'offre spéciale ou de production en utilisant la caractéristique de logiciel signée par Digital de Cisco. L'image ROMmon est évolutive et doit être signée avec la même clé que l'image d'offre spéciale ou de production qui sera chargée.

La commande suivante vérifiera l'intégrité de l'image c3900-universalk9-mz.SSA dans l'éclair utilisant les clés dans la mémoire de clé de périphérique :

show software authenticity file flash0:c3900-universalk9-mz.SSA

La caractéristique de logiciel signée par Digital de Cisco a été également intégrée dans la release 3.1.0.SG de Cisco IOS XE pour les Commutateurs de gamme E de Cisco Catalyst 4500.

Référez-vous au logiciel de Cisco signé par Digital pour plus d'informations sur cette caractéristique.

Commençant dans le Logiciel Cisco IOS version 15.1(1)T, le remplacement principal pour le logiciel de Cisco signé par Digital a été introduit. Le remplacement et la révocation principaux remplace et retire une clé qui est utilisée pour un chèque signé par Digital de logiciel de Cisco de la mémoire principale d'une plate-forme. Seulement des clés spéciales et de production peuvent être retirées en cas d'une compromission principale.

Une nouvelle (offre spéciale ou production) clé pour l'image a (offre spéciale ou production) est livré dans l'image a (production ou révocation) qui est utilisée pour retirer la clé précédente d'offre spéciale ou de production. L'intégrité d'image de révocation est vérifiée utilisant une clé inversée qui est livré préenregistré sur la plate-forme. Une clé inversée ne change pas. En retirant une clé de production, après que l'image de révocation soit chargée, la nouvelle clé qu'elle porte est ajouté à la mémoire principale et la vieille clé correspondante peut être retirée tant que l'image ROMmon est mise à jour et la nouvelle image de production est amorcée. En retirant une clé spéciale, une image de production est chargée. Cette image ajoute la nouvelle clé spéciale et peut retirer la vieille clé spéciale. Après évolution de ROMmon, la nouvelle image spéciale peut être amorcée.

L'exemple suivant décrit la révocation d'une clé spéciale. Ces commandes ajouteront la nouvelle clé spéciale à la mémoire principale de l'image courante de production, copient une nouvelle image ROMmon (C3900_rom-monitor.srec.SSB) sur la zone de stockage (usbflash0 :), améliorent le fichier de ROMmon, et retirent la vieille clé spéciale :

software authenticity key add special
copy tftp://192.168.1.129/C3900_rom-monitor.srec.SSB usbflash0:
upgrade rom-monitor file usbflash0:C3900_PRIV_RM2.srec.SSB
software authenticity key revoke special

Une nouvelle image spéciale (c3900-universalk9-mz.SSB) peut alors être copiée pour flasher pour être chargée et la signature de l'image est vérifiée utilisant la clé spéciale nouvellement ajoutée (.SSB) :

copy /verify tftp://192.168.1.129/c3900-universalk9-mz.SSB flash:

La révocation et le remplacement principaux n'est pas prise en charge sur le Catalyst des Commutateurs de 4500 gamme E exécutant le Logiciel Cisco IOS XE version 2, bien que ces Commutateurs prennent en charge la caractéristique de logiciel signée par Digital de Cisco.

Référez-vous à la section de révocation et de rechange de clé de logiciel de Cisco signée par Digital du guide de logiciel de Cisco signé par Digital pour plus d'informations sur cette caractéristique.

Configuration Change Notification and Logging

La fonctionnalité Configuration Change Notification and Logging, ajoutée dans le logiciel Cisco IOS Version 12.3(4)T, permet d´enregistrer les modifications de configuration apportées à un périphérique Cisco IOS. Le journal est mis à jour sur le périphérique Cisco IOS et contient les informations utilisateur de la personne qui a effectué la modification, la commande de configuration entrée et l´heure à laquelle la modification a été apportée. Cette fonctionnalité est activée en utilisant la commande logging enable change logger configuration mode. Les commandes facultatives hidekeys et logging size entries sont utilisées afin d'améliorer la configuration par défaut en empêchant la journalisation des données de mot de passe et en augmentant la longueur du journal de modification.

Il est recommandé d´activer cette fonctionnalité de sorte que l'historique de modification de configuration d'un périphérique Cisco IOS puisse être plus facilement compréhensible. En outre, il est recommandé d´utiliser la commande de configuration notify syslog pour activer la génération de messages Syslog quand une modification de configuration est effectuée.


!

archive
 log config
  logging enable
  logging size 200
  hidekeys
  notify syslog

!

Après que la fonctionnalité Configuration Change Notification and Logging ait été activée, la commande EXEC privilégiée show archive log config all peut être utilisée afin d'afficher le journal de configuration.

Référez-vous à Configuration Change Notification and Logging pour plus d'informations sur cette fonctionnalité.

Plan de contrôle

Les fonctions Plan de contrôle comprennent les protocoles et les processus qui communiquent entre les périphériques réseau pour transmettre des données de la source à la destination. Ceci inclut les protocoles de routage tels que Border Gateway Protocol, ainsi que des protocoles comme ICMP et Resource Reservation Protocol (RSVP).

Il est important que les événements dans les plans de gestion et de données ne compromettent pas le plan de contrôle. Si un événement de plan de données comme une attaque DoS affecte le plan de contrôle, l´ensemble du réseau peut devenir instable. Ces informations sur les fonctionnalités et les configurations du logiciel Cisco IOS peuvent aider à assurer la résilience du plan de contrôle.

Durcissement général du plan de contrôle

La protection du plan de contrôle d'un équipement réseau est critique parce que le plan de contrôle assure que les plans de gestion et de données sont mis à jour et opérationnels. Si le plan de contrôle devenait instable pendant un incident lié à la sécurité, il peut vous être impossible de rétablir la stabilité du réseau.

Dans de nombreux cas, désactiver la réception et la transmission de certains types de messages sur une interface peut réduire au minimum la charge CPU requise pour traiter des paquets inutiles.

Redirections ICMP IP

Un message de redirection ICMP peut être produit par un routeur quand un paquet est reçu et transmis sur la même interface. Dans cette situation, le routeur expédie le paquet et envoie un message de redirection ICMP à l'expéditeur du paquet original. Ce comportement permet à l'expéditeur de contourner le routeur et d´expédier les paquets futurs directement à la destination (ou à un routeur plus près de la destination). Dans un réseau IP fonctionnant correctement, un routeur envoie des redirections seulement aux hôtes sur ses propres sous-réseaux locaux. En d'autres termes, les redirections ICMP ne devraient jamais dépasser une limite de couche 3.

Il y a deux types de messages de redirection ICMP : redirection pour une adresse d´hôte et redirection pour un sous-réseau entier. Un utilisateur malveillant peut exploiter la capacité du routeur à envoyer des redirections ICMP en envoyant continuellement des paquets au routeur, forçant le routeur à répondre avec des messages de redirection ICMP, ayant pour résultat une incidence défavorable sur le CPU et la performance du routeur. Afin d'empêcher le routeur d'envoyer des redirections ICMP, utilisez la commande de configuration d'interface no ip redirects.

Référez-vous à Redirections ICMP IP pour plus d'informations sur des redirections ICMP.

ICMP inaccessibles

Le filtrage avec une liste d´accès d´interface provoque la retransmission des messages ICMP inaccessibles à la source du trafic filtré. Produire ces messages peut augmenter l'utilisation du CPU sur le périphérique. Dans le logiciel Cisco IOS, la génération d´ICMP inaccessible est limitée à un paquet toutes les 500 millisecondes par défaut. La génération de message d'ICMP inaccessible peut être désactivée en utilisant la commande de configuration d'interface no ip unreachables. La limitation de débit d´ICMP inaccessible peut être changée de la valeur par défaut en utilisant la commande de configuration globale ip icmp rate-limit unreachable interval-in-ms.

ARP Proxy

Le proxy ARP est la technique selon laquelle un périphérique, habituellement un routeur, répond aux requêtes ARP qui sont destinées à un autre périphérique. En « truquant » son identité, le routeur accepte la responsabilité du routage de paquets vers la destination « réelle ». Le proxy ARP peut aider des machines sur un sous-réseau d´atteindre des sous-réseaux distants sans configurer le routage ou la passerelle par défaut. Le proxy ARP est défini dans RFC 1027 .leavingcisco.com

Il y a plusieurs inconvénients à utiliser le proxy ARP. L'utilisation du proxy ARP peut avoir comme conséquence une augmentation de la quantité du trafic ARP sur le segment du réseau et l'épuisement des ressources et des attaques de l´homme du milieu. Le proxy ARP présente un vecteur d'attaque d'épuisement de ressource parce que chaque requête de proxy ARP consomme une petite quantité de mémoire. Un attaquant peut épuiser toute la mémoire disponible en envoyant un grand nombre de requêtes ARP.

Les attaques de l´homme du milieu permettent à un hôte sur le réseau d'usurper l´adresse MAC du routeur, ayant pour résultat que les hôtes sans méfiance envoient le trafic à l'attaquant. Le proxy ARP peut être désactivé utilisant la commande de configuration d'interface no ip proxy-arp.

Référez-vous à Activer le proxy ARP pour plus d'informations sur cette fonctionnalité.

Limitation de l´impact sur le CPU du trafic du plan de contrôle

La protection du plan de contrôle est critique. Puisque la performance de l'application et l'expérience de l'utilisateur peuvent souffrir sans la présence de données et du trafic de gestion, l'aptitude à la survie du plan de contrôle assure que les deux autres plans sont mis à jour et opérationnels.

Comprendre le trafic du plan de contrôle

Afin de protéger correctement le plan de contrôle du périphérique Cisco IOS, il est essentiel de comprendre les types du trafic qui est commuté par processus par le CPU. Le trafic commuté par processus se compose normalement de deux types différents de trafic. Le premier type de trafic est dirigé vers le périphérique Cisco IOS et doit être traité directement par le CPU du périphérique Cisco IOS. Ce trafic se compose de cette catégorie :

  • Receive adjacency traffic - Ce trafic contient une entrée dans le tableau Cisco Express Forwarding (CEF) par lequel le saut de routeur suivant est le périphérique lui-même, qui est indiqué par le terme reçu dans la sortie de l´Interface de ligne de commande (CLI) de show ip cef. Cette indication est le cas pour toute adresse IP qui exige un traitement direct par le CPU du périphérique Cisco IOS, qui inclut l´interface des adresses IP, l´espace d´adressage de multicast et l´espace d'adressage de diffusion.

Le deuxième type de trafic qui est traité par le CPU est le trafic du plan de données - trafic avec une destination au delà du périphérique Cisco IOS lui-même - qui exige un traitement spécial par le CPU. Bien que n´étant pas une liste exhaustive du CPU ayant un impact sur le trafic du plan de données, ces types de trafic sont commutés par processus et peuvent donc affecter le fonctionnement du plan de contrôle :

  • Journalisation de la liste de contrôle d'accès - Le trafic de journalisation de l'ACL se compose de paquets qui sont produits en raison d´une correspondance (permet ou refuse) d'un ACE sur lequel le mot-clé du journal est utilisé.

  • Retransmission par le chemin inverse d'Unicast (Unicast RPF) - L´Unicast RPF, utilisé en même temps qu'une ACL, peut avoir comme conséquence la commutation par processus de certain paquets.

  • Options IP - Tout paquet IP avec options incluses doit être traité par le CPU.

  • Fragmentation - Tout paquet IP qui exige la fragmentation doit être passé au CPU pour traitement.

  • Échéance de Time to Live (TTL) - Les paquets qui ont une valeur de TTL inférieure ou égale à 1 exigent que les messages de temps dépassé de l'Internet Control Message Protocol (ICMP type 11, code 0) soient envoyés, ce qui entraîne un traitement par le CPU.

  • ICMP inaccessibles - Les paquets qui ont comme conséquence des messages ICMP inaccessibles en raison du routage, du MTU ou du filtrage sont traités par le CPU.

  • Trafic exigeant une requête ARP - Les destinations pour lesquelles une entrée ARP n'existe pas nécessitent un traitement par le CPU.

  • Trafic non-IP - Tout le trafic non-IP est traité par le CPU.

Cette liste détaille plusieurs méthodes pour déterminer quels types de trafic sont traités par le CPU du périphérique Cisco IOS :

  • La commande show ip cef fournit les informations de saut suivant pour chaque préfixe IP qui est contenu dans le tableau CEF. Comme indiqué précédemment, les entrées qui contiennent receive comme « Next Hop » sont considérées comme des contiguïtés de receive et indiquent que le trafic doit être envoyé directement au CPU.

  • La commande show interface switching fournit des informations sur le nombre de paquets commutés par processus par un périphérique.

  • La commande show ip traffic fournit des informations sur le nombre de paquets IP :

    • avec une destination locale (c'est-à-dire, recevoir la juxtaposition trafic)

    • avec des options

    • qui exigent la fragmentation

    • qui sont envoyés pour diffuser l'espace d'adressage

    • qui sont envoyés à l'espace d'adressage multicast

  • Recevoir la juxtaposition trafic peut être identifié à l´aide de la commande show ip cache flow . Tous les flux qui sont destinés au périphérique Cisco IOS ont une interface de destination (DstIf) locale.

  • Surveillance du plan de contrôle peut être utilisé afin d'identifier le type et le débit du trafic qui atteint le plan de contrôle du périphérique Cisco IOS. La Surveillance du plan de contrôle peut être effectuée par l'utilisation des ACL de classification granulaire, de la journalisation et de la commande show policy-map control-plane .

Les ACL d´infrastructure

Les ACL d'infrastructure (iACL) limitent la communication externe aux périphériques du réseau. Les ACL d'infrastructure sont intensivement couverts dans la section Limitation de l'accès au réseau avec ACL d'infrastructure de ce document.

Il est recommandé de mettre en application des iACL pour protéger le plan de contrôle de tous les périphériques réseau.

Listes de contrôle d'accès de réception

Pour les plates-formes distribuées, les ACL de réception (rACL) peuvent être une option pour le logiciel Cisco IOS Versions 12.0(21)S2 pour le 12000 (GSR), 12.0(24)S pour le 7500 et 12.0(31)S pour le 10720. Le rACL protège le périphérique du trafic néfaste avant que le trafic n´affecte le processeur de routage. Les ACL de réception sont conçus pour protéger seulement les périphériques sur lesquels ils sont configurés et le trafic de transit n'est pas affecté par un rACL. En conséquence, l´adresse IP de destination qui est utilisée dans l´exemple d´ACL ci-dessous se rapporte seulement aux adresses IP physiques ou virtuelles du routeur. Les ACL de réception sont également considérées comme une meilleure pratique de sécurité du réseau et devraient être considérées comme un ajout à long terme à une bonne sécurité du réseau.

C'est l'ACL du chemin de réception qui est écrit pour autoriser le trafic SSH (port TCP 22) des serveurs de confiance sur le réseau 192.168.100.0/24 :


!
!--- Permit SSH from trusted hosts allowed to the device.
!

access-list 151 permit tcp 192.168.100.0 0.0.0.255 any eq 22

!
!--- Deny SSH from all other sources to the RP.
!

access-list 151 deny tcp any any eq 22

!
!--- Permit all other traffic to the device.
!--- according to security policy and configurations.
!

access-list 151 permit ip any any

!
!--- Apply this access list to the receive path.
!

ip receive access-list 151

!

Reportez-vous à GSR : Listes de contrôle d'accès de réception afin d´aider à identifier et permettre un trafic légitime à un périphérique et refuser tous les paquets non désirés.

Surveillance du plan de contrôle

La fonctionnalité Control Plane Policing (CoPP) peut également être utilisée pour limiter les paquets IP qui sont destinés au périphérique d'infrastructure. Dans cet exemple, seul le trafic SSH d´hôtes de confiance est autorisé à atteindre le CPU du périphérique Cisco IOS.

Notez que la perte de trafic d´adresses IP inconnues ou non sécurisés peut empêcher les hôtes avec des adresses IP attribuées dynamiquement de se connecter au périphérique Cisco IOS.


!

access-list 152 deny tcp <trusted-addresses> <mask> any eq 22
access-list 152 permit tcp any any eq 22
access-list 152 deny ip any any

!

class-map match-all COPP-KNOWN-UNDESIRABLE
 match access-group 152

!

policy-map COPP-INPUT-POLICY
 class COPP-KNOWN-UNDESIRABLE
  drop

!

control-plane
 service-policy input COPP-INPUT-POLICY

!

Dans l´exemple précédent de CoPP, les entrées de l´ACL qui correspondent à des paquets non autorisés avec l'action Permit a pour résultat le rejet de ces paquets par la fonction de policy-map Drop , alors que les paquets qui correspondent à l'action Deny ne sont pas affectés par la fonction de policy-map Drop.

CoPP est disponible dans le logiciel Cisco IOS séries de versions 12.0S, 12.2SX, 12.2S, 12.3T, 12,4 et 12.4T.

Référez-vous à Déploiement de la surveillance du panneau de contrôle pour plus d'informations sur la configuration et l'utilisation de la fonctionnalité CoPP.

Protection du plan de contrôle

Control Plane Protection (CPPr), introduit dans le logiciel Cisco IOS Version 12.4(4)T, peut être utilisé pour limiter ou surveiller le trafic du plan de contrôle qui est destiné au CPU du périphérique Cisco IOS. Bien que semblable à CoPP, CPPr a la capacité de limiter le trafic avec une granularité plus fine. CPPr divise le plan de contrôle global en trois catégories distinctes de plan de contrôle connues sous le nom de sous-interfaces. Les sous-interfaces existent pour les catégories de trafic hôte, transit et CEF-Exception. En outre, CPPr inclut ces fonctionnalités de protection du plan de contrôle :

  • Fonctionnalité Port-filtering - Cette fonctionnalité fournit le contrôle ou la perte de paquets qui sont envoyés à des ports TCP et UDP fermés ou pas à l´écoute.

  • Fonctionnalité Queue-thresholding - Cette fonctionnalité limite le nombre de paquets pour un protocole donné qui sont permis dans la file d'attente d'entrée du plan de contrôle IP.

Référez-vous à Protection du plan de contrôle et à Comprendre la Protection du plan de contrôle (CPPr) pour plus d'informations sur la configuration et l'utilisation de la fonctionnalité CPPr.

Limiteurs matériels de débit

Les Supervisor Engine 32 et 720 de la gamme Cisco Catalyst 6500 assurent l'assistance de limiteurs matériels de débit (HWRL) spécifiques à une plate-forme pour les scénarios particuliers de réseautique. Ces limiteurs matériels de débit sont désignés comme cas spécial de limiteurs de débit parce qu'ils recouvrent un ensemble prédéfini spécifique de scénarios DoS d´ipv4, IPv6, unicast et multicast. Les HWRL peuvent protéger le périphérique Cisco IOS d'un grand choix d'attaques qui exigent que les paquets soient traités par le CPU.

Il y a plusieurs HWRL qui sont activés par défaut. Référez-vous à Configurations par défaut des limiteurs matériels de débit PFC3 pour plus d'informations.

Référez-vous à Limiteurs matériels de débit sur PFC3 pour plus d'informations sur les HWRL.

Sécurisation du protocole BGP

Le protocole Border Gateway Protocol (BGP) est la base du routage d´Internet. En tant que tel, n'importe quelle organisation avec des exigences de connectivité plus que modestes se trouve souvent être un utilisateur du BGP. Le BGP est souvent visé par les attaquants en raison de son ubiquité et de la nature « configurer et oublier » des configurations de BGP dans les plus petites organisations. Cependant, il y a beaucoup de fonctions de sécurité spécifiques au BGP qui peuvent être exploitées pour augmenter la sécurité de la configuration d´un BGP.

Ceci fournit un aperçu des fonctions de sécurité du BGP les plus importantes. Le cas échéant, des recommandations de configuration sont faites.

Protections de sécurité basées sur TTL

Chaque paquet IP contient un champ de 1 octet connu sous le nom de Time to Live (TTL). Chaque périphérique qu'un paquet IP traverse décrémente cette valeur de un. La valeur de départ varie par le système d'exploitation et s'étend typiquement de 64 à 255. Un paquet est lâché quand sa valeur de TTL atteint zéro.

Connus à la fois comme Mécanisme de sécurité GTSM (Generalized TTL-based Security Mechanism) et BTSH (BGP TTL Security Hack), une protection de sécurité basée sur TTL exploite la valeur de TTL des paquets IP pour assurer que les paquets BGP qui sont reçus proviennent directement d´un homologue connecté. Cette fonctionnalité exige souvent la coordination des routeurs d´appairage ; cependant, une fois activée, elle peut complètement annihiler beaucoup d'attaques basées sur TCP contre le BGP.

GTSM pour BGP est activé en utilisant l´option ttl-security pour la commande neighbor de configuration du routeur BGP. Cet exemple illustre la configuration de cette fonctionnalité :


!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> ttl-security hops <hop-count>

!

À mesure que les paquets BGP sont reçus, la valeur de TTL est vérifiée et doit être supérieure ou égale à 255, moins le nombre de sauts spécifiés.

Référez-vous à Support de BGP pour le contrôle de sécurité de TTL pour plus d'informations.

Authentification d´homologue de BGP avec MD5

L'authentification d´homologue utilisant MD5 crée un condensé MD5 de chaque paquet envoyé en tant qu'élément d'une session BGP. Spécifiquement, des portions des en-têtes d'IP et de TCP, de la charge utile de TCP, et une clé secrète sont utilisées afin de produire le condensé.

Le condensé créé est alors stocké dans l´option TCP Kind 19, qui a été créée spécifiquement à cet effet par RFC 2385. Le speaker BGP de réception emploie le même algorithme et la même clé secrète pour régénérer le condensé de message. Si les condensés reçus et calculés ne sont pas identiques, le paquet est rejeté.

L'authentification d´homologue avec MD5 est configurée à l'aide de l'option password de la commande neighbor de configuration du routeur BGP. L'utilisation de cette commande est illustrée comme suit :


!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> password <secret>

!

Référez-vous à Authentification du routeur voisin pour plus d'informations sur l'authentification d´homologue BGP avec MD5.

Configurer le maximum de préfixes

Les préfixes BGP sont stockés en mémoire par a routeur. Plus un routeur doit contenir de préfixes, plus BGP consomme de mémoire. Dans quelques configurations, un sous-ensemble de tous les préfixes d'Internet peut être stocké, comme dans les configurations qui exploitent seulement une ou plusieurs routes par défaut pour les réseaux du client d'un fournisseur.

Afin d'empêcher l'épuisement de la mémoire, il est important de configurer le nombre maximal de préfixes qui est accepté par homologue. On lui recommande qu'une limite soit configurée pour chaque homologue BGP.

En configurant cette fonctionnalité à l´aide de la commande neighbor maximum-prefix de configuration du routeur BGP, un argument est requis : le nombre maximal de préfixes qui sont acceptés avant qu'un homologue soit arrêté. Sur option, un chiffre de 1 à 100 peut également être saisi. Ce chiffre représente le pourcentage de la valeur maximale de préfixes auquel un message du journal est envoyé.


!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> maximum-prefix <shutdown-threshold> <log-percent>

!

Référez-vous à Configurer la fonctionnalité maximum-prefix de BGP pour plus d'informations sur le maximum de préfixes par homologue.

Filtrage des préfixes BGP avec des listes de préfixes

Les listes de préfixes permettent à un administrateur réseau d´accepter ou de refuser des préfixes spécifiques qui sont envoyés ou reçus par l'intermédiaire de BGP. Les listes de préfixes devraient être utilisées si possible pour s'assurer que le trafic sur le réseau est envoyé par les chemins prévus. Les listes de préfixes devraient être appliquées à chaque eBGP homologue dans les directions entrantes et sortantes.

Les listes de préfixes configurées limitent les préfixes qui sont envoyés ou reçus à ceux spécifiquement permis par la politique de routage d'un réseau. Si ce n'est pas faisable en raison du grand nombre de préfixes reçus, une liste de préfixes devrait être configurée pour bloquer spécifiquement les mauvais préfixes connus. Ces mauvais préfixes connus incluent l'espace d'adressage IP non affecté et les réseaux qui sont réservés à des fins internes ou de tests par RFC 3330. Les listes de préfixes sortants devraient être configurées pour permettre spécifiquement seulement les préfixes qu'une organisation a l´intention d´annoncer.

Cet exemple de configuration emploie des listes de préfixes pour limiter les routes qui sont apprises et annoncées. Spécifiquement, seulement une route par défaut est permise en entrée par la liste de préfixes BGP-PL-INBOUND, et le préfixe 192.168.2.0/24 est la seule route permise d´être annoncée par BGP-PL-OUTBOUND.


!

ip prefix-list BGP-PL-INBOUND seq 5 permit 0.0.0.0/0
ip prefix-list BGP-PL-OUTBOUND seq 5 permit 192.168.2.0/24

!

router bgp <asn>
 neighbor <ip-address> prefix-list BGP-PL-INBOUND in
 neighbor <ip-address> prefix-list BGP-PL-OUTBOUND out

!

Référez-vous à Connexion à un prestataire de services à l´aide de BGP externe pour la couverture complète du filtrage des préfixes BGP.

Filtrage des préfixes BGP avec des listes d'accès au chemin de système autonome

Les listes d'accès BGP au chemin du système autonome (AS) permettent à l'utilisateur de filtrer les préfixes reçus et annoncés en fonction de l'attribut AS-path d'un préfixe. Ceci peut être utilisé en même temps que les listes de préfixes pour établir un ensemble robuste de filtres.

Cet exemple de configuration utilise les listes d'accès de chemin AS afin de limiter les préfixes entrants à ceux qui ont l´AS distant pour origine et les préfixes sortants à ceux qui ont le système autonome local pour origine. Les préfixes qui sont originaires de tout autre système autonome sont filtrés et ne sont pas installés dans le tableau de routage.


!

ip as-path access-list 1 permit ^65501$
ip as-path access-list 2 permit ^$

!

router bgp <asn>
 neighbor <ip-address> remote-as 65501
 neighbor <ip-address> filter-list 1 in
 neighbor <ip-address> filter-list 2 out

!

Sécurisation des Interior Gateway Protocols

La capacité d'un réseau à expédier correctement le trafic et à se rétablir à la suite de modifications ou d´erreurs de topologie dépend d'une vue précise de la topologie. L'exécution d'un Interior Gateway Protocol (IGP) peut souvent fournir cette vue. Par défaut, les IGP sont dynamiques et découvrent des routeurs supplémentaires qui communiquent avec l'IGP en service. Les IGP découvrent également des routes qui peuvent être utilisées pendant une panne de liaison réseau.

Ces sous-sections fournissent un aperçu des fonctions de sécurité les plus importantes de l'IGP. Des recommandations et des exemples qui recouvrent le Routing Information Protocol Version 2 (RIPv2), l'Enhanced Interior Gateway Routing Protocol (EIGRP), et l'Open Shortest Path First (OSPF) sont fournis selon besoins.

Authentification et vérification du protocole de routage avec Message Digest 5

Le manque de sécuriser l'échange des informations de routage permet à un attaquant d´introduire des informations de routage fausses dans le réseau. À l'aide de l´authentification de mot de passe avec des protocoles de routage entre les routeurs, vous pouvez renforcer la sécurité du réseau. Cependant, parce que cette authentification est envoyée en libellé, il peut être simple pour un attaquant de corrompre ce contrôle de sécurité.

En ajoutant des capacités de hachage MD5 au processus d'authentification, les mises à jour du routage ne contiennent plus de mots de passe en libellé, et le contenu entier de la mise à jour du routage est plus résistant aux falsifications. Cependant, l'authentification MD5 est encore susceptible aux attaques de force brute et par dictionnaire si des mots de passe faibles sont choisis. Il est recommandé d´utiliser des mots de passe avec une randomisation suffisante. Puisque l'authentification MD5 est beaucoup plus sécurisée par comparaison à l´authentification par mot de passe, ces exemples sont spécifiques à l'authentification MD5. IPSec peut également être utilisé afin de valider et sécuriser les protocoles de routage, mais ces exemples ne détaillent pas son utilisation.

EIGRP et RIPv2 utilisent des clés en tant qu'élément de la configuration. Référez-vous à key pour plus d'informations sur la configuration et l'utilisation des clés.

Ceci est un exemple de configuration pour l'authentification de routeur EIGRP utilisant MD5 :


!

key chain <key-name>
 key <key-identifier>
 key-string <password> 

!

interface <interface>
 ip authentication mode eigrp <as-number> md5
 ip authentication key-chain eigrp <as-number> <key-name>

!

Référez-vous à Configuration pour l'authentification de route EIGRP pour plus d'informations.

Ceci est un exemple de configuration pour l´authentification de routeur MD5 pour RIPv2. RIPv1 ne prend pas en charge l'authentification.


!

key chain <key-name>
 key <key-identifier>
 key-string <password> 

!

interface <interface>
 ip rip authentication mode md5
 ip rip authentication key-chain <key-name>

!

Référez-vous à Activation de l'authentification RIP pour plus d'informations.

Ceci est un exemple de configuration pour l'authentification de routeur OSPF utilisant MD5. OSPF n'utilise pas de clés.


!

interface <interface>
 ip ospf message-digest-key <key-id> md5 <password>

!

router ospf <process-id>
 network 10.0.0.0 0.255.255.255 area 0
 area 0 authentication message-digest

!

Référez-vous à Configuration du protocole OSPF pour plus d'informations.

Commandes Passive-Interface

Les fuites d'information, ou l'introduction d'informations fausses dans un IGP, peuvent être atténuées par l'utilisation de la commande passive-interface qui aide à contrôler l´annonce des informations de routage. Il est recommandé de ne pas annoncer d´informations aux réseaux qui sont en dehors de votre contrôle administratif.

Cet exemple démontre l'utilisation de cette fonctionnalité :


!

router eigrp <as-number> 
 passive-interface default
 no passive-interface <interface>

!

Référez-vous à fonctionnalité passive interface par défaut pour plus d'informations sur la fonctionnalité passive-interface.

Filtrage de route

Afin de réduire la possibilité d'introduire des informations de routage fausses dans le réseau, vous devez utiliser le filtrage de route. À la différence de la commande passive-interface de configuration de routeur, le routage se produit sur des interfaces une fois que le filtrage de routeur est activé, mais les informations qui sont annoncées ou traitées sont limitées.

Pour EIGRP et RIP, l´utilisation de la commande distribute-list avec le mot-clé out limite quelles informations sont annoncées, alors que l'utilisation du mot clé in limite quelles mises à jour sont traitées. La commande distribute-list est disponible pour OSPF, mais elle n'empêche pas un routeur de propager des routes filtrées. Au lieu de cela, la commande area filter-list peut être utilisée.

Cet exemple d´EIGRP filtre les annonces sortantes avec la commande distribute-list et une liste de préfixes :


!

ip prefix-list <list-name> seq 10 permit <prefix> 

!

router eigrp <as-number>
 passive-interface default
 no passive-interface <interface>
 distribute-list prefix <list-name> out <interface>

!

Cet exemple d´EIGRP filtre les mises à jour entrantes avec une liste de préfixes :


!

ip prefix-list <list-name> seq 10 permit <prefix> 

!

router eigrp <as-number>
 passive-interface default
 no passive-interface <interface>
 distribute-list prefix <list-name> in <interface>

!

Référez-vous à Configuration de protocole de routage IP - Fonctionnalités indépendantes pour plus d'informations sur le contrôle de l´annonce et du traitement des mises à jour du routage.

Cet exemple d'OSPF utilise une liste de préfixes avec la commande spécifique OSPF area filter-list :


!

ip prefix-list <list-name> seq 10 permit <prefix> 

!

router ospf <process-id>
 area <area-id> filter-list prefix <list-name> in 

!

Référez-vous à Filtrage LSA type 3 d'OSPF ABR pour plus d'informations sur le filtrage d'annonces de l'état des liaisons OSPF Area Border Router (ABR) Type 3.

Consommation des ressources liées au processus de routage

Les préfixes du protocole de routage sont enregistrés en mémoire par un routeur, et la consommation des ressources augmente avec les préfixes supplémentaires que le routeur doit contenir. Afin d'empêcher l'épuisement des ressources, il est important de configurer le protocole de routage pour limiter la consommation des ressources. C'est possible avec OSPF en utilisant la fonctionnalité Protection de surcharge de la base de données d'état de liaison.

Cet exemple démontre la configuration de la fonctionnalité OSPF Protection de surcharge de la base de données d'état de liaison :


!

router ospf <process-id>
 max-lsa <maximum-number> 

!

Référez-vous à Limitation du nombre de LSA autogénérateurs pour un processus d'OSPF pour plus d'informations sur l´OSPF Protection de surcharge de la base de données d'état de liaison.

Sécurisation des First Hop Redundancy Protocols

Les protocoles de redondance du first hop (FHRP) fournissent la résilience et la redondance pour les périphériques qui agissent en tant que passerelles par défaut. Cette situation et ces protocoles sont courants dans les environnements où une paire de périphériques de couche 3 fournit la fonctionnalité de passerelle par défaut pour un segment de réseau ou définit des VLAN qui contiennent des serveurs ou des postes de travail.

Le Gateway Load-Balancing Protocol (GLBP), le Hot Standby Router Protocol (HSRP) et le Virtual Router Redundancy Protocol (VRRP) sont tous des FHRP. Par défaut, ces protocoles communiquent utilisant des transmissions non authentifiées. Ce genre de transmission peut permettre à un attaquant de poser comme périphérique de FHRP-parler pour assumer le rôle de passerelle par défaut sur le réseau. Cette prise de contrôle permettrait à un attaquant d´exécuter une attaque homme du milieu et d´intercepter tout le trafic utilisateur qui quitte le réseau.

Afin d'empêcher ce type d'attaque, tous les FHRP qui sont supportés par le logiciel Cisco IOS incluent une capacité d'authentification utilisant MD5 ou des chaînes de caractères. En raison de la menace constituée par les FHRP non authentifiés, il est recommandé que les instances de ces protocoles utilisent l'authentification MD5. Cet exemple de configuration démontre l'utilisation de l´authentification MD5 GLBP, HSRP et VRRP :


!

interface FastEthernet 1
 description *** GLBP Authentication ***
 glbp 1 authentication md5 key-string <glbp-secret>
 glbp 1 ip 10.1.1.1

!

interface FastEthernet 2
 description *** HSRP Authentication ***
 standby 1 authentication md5 key-string <hsrp-secret>
 standby 1 ip 10.2.2.1

!

interface FastEthernet 3
 description *** VRRP Authentication ***
 vrrp 1 authentication md5 key-string <vrrp-secret> 
 vrrp 1 ip 10.3.3.1

!

Référez-vous à Configuration du protocole GLBP, Configuration du protocole HSRP, et Configuration du protocole VRRP pour plus d'informations sur la configuration de l'authentification avec les FHRP.

Plan de données

Bien que le plan de données soit responsable du transport des données de source à la destination, dans le contexte de la sécurité, le plan de données est le moins important des trois plans. C'est pour cette raison qu'en sécurisant un périphérique réseau, il est important de protéger les plans de gestion et de contrôle de préférence au-plan de données.

Cependant, dans le plan de données lui-même, il y a beaucoup de fonctionnalités et d'options de configuration qui peuvent aider à sécuriser le trafic. Ces sections précisent ces fonctionnalités et options afin que vous puissiez plus facilement sécuriser votre réseau.

Durcissement général du plan de données

La grande majorité du trafic des plans de données passe à travers le réseau tel que déterminé par la configuration de routage du réseau. Cependant, la fonctionnalité du réseau IP existe pour modifier le chemin des paquets à travers le réseau. Les fonctionnalités telles que les options IP, spécifiquement l'option de routage de la source, constituent un défi de sécurité dans les réseaux actuels.

L'utilisation des ACL de transit est également pertinente au durcissement du plan de données. Voyez la section Filtrage du trafic de transit avec les ACL de transit de ce document pour plus d'informations.

Options IP de rejet sélectif

Il y a deux préoccupations en matière de sécurité présentées par les options d'IP. Le trafic qui contient des options IP doit être changé par processus par les périphériques Cisco IOS, ce qui peut mener à une élévation de la charge du CPU. Les options IP incluent également une fonctionnalité pour modifier le chemin que prend le trafic à travers le réseau, lui permettant potentiellement de corrompre les contrôles de sécurité.

En raison de ces préoccupations, la commande de configuration globale ip options {drop | ignore} a été ajoutée au logiciel Cisco IOS Versions 12.3(4)T, 12.0(22)S et 12.2(25)S. Sous la première forme de cette commande, ip options drop, tous les paquets IP contenant des options IP qui sont reçus par le périphérique Cisco IOS sont rejetés. Ceci empêche d´élever la charge CPU et la subversion possible des contrôles de sécurité que les options IP peuvent activer.

La deuxième forme de cette commande, ip options ignore, configure le périphérique Cisco IOS pour ignorer les options IP qui sont contenues dans les paquets reçus. Tandis que ceci atténue les menaces liées aux options IP pour le périphérique local, il est possible que des périphériques en aval puissent être affectés par la présence des options IP. C'est pour cette raison que la forme drop de cette commande est fortement recommandée. Ceci est démontré dans l'exemple de configuration :


!

ip options drop

!

Notez que quelques protocoles, par exemple RSVP, font un usage légitime des options IP. La fonctionnalité de ces protocoles est affectée par cette commande.

Une fois qu´Options IP de rejet sélectif a été activée, la commande EXEC show ip traffic peut être utilisé afin de déterminer le nombre de paquets qui sont rejetés en raison de la présence des options IP. Cette information est présente dans le compteur rejet obligatoire.

Référez-vous à Rejet sélectif des options IP ACL pour plus d'informations sur cette fonction.

Désactiver le routage de la source IP

Le routage de la source IP exploite les options Loose Source Route et Record Route en tandem ou la Strict Source Route avec l´option Record Route, afin d'activer la source du datagramme IP pour spécifier le chemin de réseau pris par un paquet. Cette fonctionnalité peut être utilisée dans les tentatives de router le trafic autour des contrôles de sécurité dans le réseau.

Si les options IP n'ont pas été complètement F6485désactivées par l'intermédiaire de la fonctionnalité Options IP de rejet sélectif, il est important que le routage de la source IP soit désactivé. Le routage de la source IP, qui est activé par défaut dans toutes les versions du logiciel Cisco IOS, est désactivé par l'intermédiaire de la commande de configuration globale no ip source-route. Cet exemple de configuration illustre l'utilisation de cette commande :


!

no ip source-route

!

Référez-vous à Référence des commandes de Cisco IOS pour plus d'informations sur la commande ip source-route.

Désactiver les redirections ICMP

Les redirections ICMP sont utilisées afin d'informer un périphérique réseau d'un meilleur chemin à une destination IP. Par défaut, le logiciel Cisco IOS envoie une redirection s'il reçoit un paquet qui doit être routé par l´interface selon laquelle il a été reçu.

Dans quelques situations, il peut être possible qu'un attaquant fasse envoyer par le périphérique Cisco IOS beaucoup de messages de redirection ICMP, ayant pour résultat une élévation de la charge CPU. Pour cette raison, il est recommandé que la transmission des redirections d'ICMP soit désactivée. Les redirections ICMP sont désactivées en utilisant la commande de configuration d'interface no ip redirects, comme montré dans l'exemple de configuration :


!

interface FastEthernet 0
 no ip redirects

!

Référez-vous à Commandes Cisco IOS pour plus d'informations sur la commande de configuration d'interface ip redirects.

Désactiver ou limiter les diffusions dirigées par IP

Les diffusions dirigées par IP rendent possible d´envoyer un paquet de diffusion IP à un sous-réseau IP distant. Une fois qu'il atteint le réseau distant, le périphérique IP d'expédition envoie le paquet comme diffusion de couche 2 à toutes les stations sur le sous-réseau. Ceci fonctionnalité de diffusion dirigée a été exploitée comme une aide d'amplification et de réflexion dans plusieurs attaques, y compris l'attaque smurf.

Les versions actuelles du logiciel Cisco IOS ont cette fonctionnalité désactivée par défaut ; cependant, elle peut être activée par l'intermédiaire de la commande de configuration d'interface ip directed-broadcast. Les versions du logiciel Cisco IOS antérieures à 12.0 ont cette fonctionnalité activée par défaut.

Si un réseau exige absolument la fonctionnalité de diffusion dirigée, son utilisation devrait être contrôlée. Ceci est possible en utilisant une liste de contrôle d'accès comme option de la commande ip directed-broadcast . Cet exemple de configuration limite les diffusions dirigées aux paquets UDP originaires d´un réseau de confiance, 192.168.1.0/24 :


!

access-list 100 permit udp 192.168.1.0 0.0.0.255 any

!

interface FastEthernet 0
 ip directed-broadcast 100

!

Référez-vous à Commande des services d'adressage IP pour plus d'informations sur la commande ip directed-broadcast.

Filtrage du trafic de transit avec les ACL de transit

Il est possible de contrôler quel trafic transite le réseau à l'aide des ACL de transit (tACL). Ceci contraste avec les ACL d'infrastructure qui recherchent à filtrer le trafic qui est destiné au réseau lui-même. Le filtrage fourni par les tACL est bénéfique quand il est désirable de filtrer le trafic à un groupe donné de périphériques ou le trafic qui transite le réseau.

Ce type de filtrage est traditionnellement exécuté par les pare-feux. Cependant, il y a des instances où il peut être avantageux d'exécuter ce filtrage sur un périphérique Cisco IOS dans le réseau, par exemple, là où le filtrage doit être exécuté mais aucun pare-feu n'est présent.

Les ACL de transit sont également un endroit approprié dans lequel mettre en application des protections anti-spoofing statiques. Voyez la section Protections anti-spoofing de ce document pour plus d'informations.

Reportez-vous à Listes de contrôle d'accès de transit : Filtrage au niveau de votre périphérie pour plus d'informations sur les tACL.

Filtrage des paquets ICMP

L'Internet Control Message Protocol (ICMP) a été conçu comme protocole de contrôle pour IP. En tant que tels, les messages qu´il transporte peuvent avoir des ramifications de grande envergure sur les protocoles TCP et IP en général. L'ICMP est utilisé par les outils de dépannage réseau ping et traceroute, ainsi que par la découverte de MTU de la voie d'accès ; cependant, la connectivité externe d'ICMP est nécessaire rarement pour l'opération appropriée d'un réseau.

Le logiciel Cisco IOS fournit la fonctionnalité pour filtrer spécifiquement des messages ICMP par nom ou type et code. Cet exemple d´ACL autorise ICMP des réseaux de confiance tout en bloquant tous les paquets ICMP d'autres sources :


!

ip access-list extended ACL-TRANSIT-IN

!
!--- Permit ICMP packets from trusted networks only
!

 permit icmp host <trusted-networks> any 

!
!--- Deny all other IP traffic to any network device
!

 deny icmp any any

!

Filtrage des fragments IP

Comme détaillé précédemment dans la section Limitation de l'accès au réseau avec ACL d'infrastructure de ce document, le filtrage de paquets IP fragmentés peut poser un défi aux périphériques de sécurité.

En raison de la nature non intuitive du traitement des fragments, les fragments IP sont souvent autorisés par mégarde par les ACL. La fragmentation est également souvent employée dans les tentatives d'éluder la détection par les systèmes de détection des intrusions. C'est pour ces raisons que les fragments IP sont employés souvent dans les attaques, et pourquoi ils doivent être explicitement filtrés en tête de tous les tACL configurés. L'ACL ci-dessous inclut le filtrage complet des fragments d'IP. La fonctionnalité illustrée dans cet exemple doit être utilisée en même temps que la fonctionnalité des exemples précédents :


!

ip access-list extended ACL-TRANSIT-IN

!
!--- Deny IP fragments using protocol-specific ACEs to aid in 
!--- classification of attack traffic
!

 deny tcp any any fragments
 deny udp any any fragments
 deny icmp any any fragments
 deny ip any any fragments

!

Référez-vous à Listes de contrôle d'accès et fragments d'IP pour plus d'informations sur le traitement d'ACL de paquets d´IP fragmentés.

Support d'ACL pour le filtrage des options IP

Commençant dans le Logiciel Cisco IOS Version 12.3(4)T, le logiciel Cisco IOS supporte l'utilisation des ACL pour filtrer les paquets IP basé sur les options d'IP qui sont contenues dans le paquet. La présence des options d'IP dans un paquet peut également indiquer une tentative de corrompre les contrôles de sécurité dans le réseau ou de modifier autrement les caractéristiques de transit d'un paquet. C´est pour ces raisons que les paquets avec des options d'IP doivent être filtrés au bord du réseau.

Cet exemple doit être utilisé avec le contenu des exemples précédents afin d'inclure le filtrage complet des paquets IP qui contiennent des options IP :


!

ip access-list extended ACL-TRANSIT-IN

!
!--- Deny IP packets containing IP options
!

 deny ip any any option any-options

!

Référez-vous à Support d'ACL pour le filtrage des options IP pour plus d'informations.

Protections anti-spoofing

Beaucoup d'attaques utilisent le spoofing de l'adresse IP de la source pour être efficaces ou pour cacher la vraie source d'une attaque et entraver un retour arrière précis. Le logiciel Cisco IOS fournit Unicast RPF et Protection de la source IP (IPSG) pour décourager les attaques qui se fondent sur la mystification de l'adresse IP de la source. En outre, les ACL et le routage null sont souvent déployés en tant que moyens manuels de prévention du spoofing.

La Protection de la source IP est efficace pour minimiser la mystification dans les réseaux qui sont sous contrôle administratif direct, en effectuant la vérification du port de commutation, de l´adresse MAC et de l´adresse source. Unicast RPF fournit la vérification du réseau source et peut réduire les attaques de spoofing dans les réseaux qui ne sont pas sous contrôle administratif direct. La Sécurité de port peut être utilisée afin de valider les adresses MAC à la couche d'accès. L'inspection dynamique (DAI) du Protocole de résolution d'adresse (ARP) atténue les vecteurs d'attaque qui utilisent l'empoisonnement ARP sur des segments locaux.

Unicast RPF

Unicast RPF permet à un périphérique de vérifier que l´adresse source d'un paquet expédié peut être atteinte par l´interface qui a reçu le paquet. Vous ne devez pas compter sur Unicast RPF comme seule protection contre la spoofing. Les paquets usurpés pourraient entrer dans le réseau par une interface activée par Unicast RPF si une route de retour appropriée à l'adresse IP de la source existe. Unicast RPF se fonde sur vous pour activer Cisco Express Forwarding sur chaque périphérique, et est configuré selon l´interface.

Unicast RPF peut être configuré dans l´un de deux modes : lâche ou strict. Dans les cas de routage asymétrique, le mode lâche est préféré parce que le mode strict est connu pour rejeter des paquets dans ces situations. Pendant la configuration de la commande de configuration d'interface ip verify, le mot clé any configure le mode lâche tandis que le mot clé rx configure le mode strict.

Cet exemple illustre la configuration de cette fonctionnalité :


!

ip cef

!

interface <interface>
  ip verify unicast source reachable-via <mode>

!

Référez-vous à Comprendre la retransmission par le chemin inverse d'Unicast pour plus d'informations sur configuration et l'utilisation d'Unicast RPF.

Référez-vous à Mode lâche de retransmission par le chemin inverse d'Unicast pour plus d'informations sur cette fonctionnalité.

Protection de la source IP

La Protection de la source IP est un moyen efficace de prévention du spoofing qui peut être utilisé si vous avez le contrôle des interfaces de couche 2. La Protection de la source IP utilise des informations d´espionnage DHCP pour configurer dynamiquement une liste de contrôle d'accès de port (PACL) sur l'interface de couche 2, refusant tout trafic des adresses IP qui ne sont pas associées dans la table de liaison de la source ip.

La Protection de la source IP peut être appliqué aux interface de couche 2 appartenant aux VLAN activés par l´espionnage DHCP. Ces commandes activent le snooping DHCP :


!

ip dhcp snooping
ip dhcp snooping vlan <vlan-range>

!

Après que le spoofing DHCP soit activé, ces commandes activent IPSG :


!

interface <interface-id>
   ip verify source 

!

La sécurité de port peut être activée avec la commande de configuration d'interface ip verify source port security. Ceci exige la commande de configuration globale ip dhcp snooping information option ; en outre, le serveur DHCP doit prendre en charge l'option 82 de DHCP.

Référez-vous à Configuration des fonctionnalités DHCP et protection de la source IP pour plus d'information sur cette fonctionnalité.

Sécurité de port

La Sécurité de port est utilisée afin d'atténuer le spoofing des adresses MAC à l'interface d'accès. La Sécurité de port peut utiliser les adresses MAC apprises dynamiquement (rémanent) pour faciliter la configuration initiale. Une fois que la sécurité de port a déterminé une violation MAC, elle peut utiliser l´un de quatre modes de violation. Ces modes sont protect, restrict, shutdown et shutdown VLAN. Dans les instances où un port fournit l'accès à un seul poste de travail en utilisant des protocoles standard, un nombre maximal de un peut être suffisant. Les protocoles qui exploitent les adresses virtuelles MAC, tel que HSRP, ne fonctionnent pas quand le nombre maximal est égal à un.


!

interface <interface> 
  switchport
  switchport mode access 
  switchport port-security
  switchport port-security mac-address sticky
  switchport port-security maximum <number>
  switchport port-security violation <violation-mode>

!

Référez-vous à Configuration de la sécurité de port pour plus d'informations sur la configuration de la sécurité de port.

Inspection dynamique d'ARP

L'inspection dynamique d'ARP (DAI) peut être utilisée pour atténuer les attaques d´empoisonnement d´ARP sur des segments locaux. Une attaque d'empoisonnement d'ARP est une méthode dans laquelle un attaquant envoie des informations ARP falsifiées à un segment local. Cette information est conçue pour altérer le cache ARP d'autres périphériques. Souvent, un attaquant utilise l'empoisonnement d´ARP afin d'exécuter une attaque de l´homme du milieu.

DAI intercepte et valide le rapport IP à adresse MAC de tous les paquets ARP sur les ports non sécurisés. Dans les environnements DHCP, DAI utilise les données qui sont produites par la fonctionnalité de spoofing DHCP. Les paquets ARP qui sont reçus sur des interfaces de confiance ne sont pas validés et les paquets non valides sur des interfaces non sécurisées sont rejetés. Dans les environnements non-DHCP, l'utilisation des ACL d'ARP est requis.

Ces commandes activent le snooping DHCP :


!

ip dhcp snooping
ip dhcp snooping vlan <vlan-range>

!

Une fois que le spoofing DHCP a été activé, ces commandes activent DAI :


!

ip arp inspection vlan <vlan-range> 

!

Dans les environnements non DHCP, les ACL ARP sont requis d'activer DAI. Cet exemple démontre la configuration de base de DAI avec les ACL ARP :


!

arp access-list <acl-name>
 permit ip host <sender-ip> mac host <sender-mac>

!

ip arp inspection filter <arp-acl-name> vlan <vlan-range>

!

Référez-vous à Configuration de l'inspection dynamique d'ARP pour plus d'informations sur la façon de configurer DAI.

ACL anti-spoofing

Les ACL manuellement configurées peuvent assurer la protection anti-spoofing statique contre les attaques qui utilisent un espace d'adressage connu inutilisé et non sécurisé. Généralement, ces ACL anti-spoofing sont appliquées au trafic entrant aux frontières du réseau comme composants d'une plus grande ACL. Les ACL anti-spoofing exigent une surveillance régulière car elles peuvent fréquemment changer. Le spoofing peut être réduit au minimum pour le trafic provenant du réseau local en appliquant les ACL sortantes qui limitent le trafic aux adresses locales valides.

Cet exemple démontre comment les ACL peut être utilisées afin de limiter l'usurpation d'adresse IP. Cette ACL est appliquée dans la direction entrante sur l´interface désirée. Les ACE qui composent cette ACL ne sont pas exhaustives. Si vous configurez ces types d'ACL, recherchez une référence à jour qui est concluante.


!

ip access-list extended ACL-ANTISPOOF-IN
 deny	ip 10.0.0.0 0.255.255.255 any
 deny	ip 192.168.0.0 0.0.255.255 any

!

interface <interface>
 ip access-group ACL-ANTISPOOF-IN in

!

Référez-vous à Configuration des ACL IP fréquemment utilisées pour plus d'informations sur la façon de configurer les listes de contrôle d'accès.

La liste officielle des adresses Internet non affectées est mise à jour par l'équipe Cymru. Des informations supplémentaires au sujet du filtrage d´adresses inutilisées sont disponibles à la page de référence de Bogon.leavingcisco.com

Limitation de l´impact sur le CPU du trafic du plan de données

L'objectif principal des routeurs et des commutateurs est de transférer les paquets et trames par le périphérique vers les destinations finales. Ces paquets, qui transitent les périphériques déployées dans tout le réseau, peuvent affecter le fonctionnement du CPU d'un périphérique. Le plan de données, qui se compose du trafic transitant le périphérique réseau, devrait être sécurisé pour assurer le fonctionnement des plans de gestion et de contrôle. Si le trafic de transit peut faire traiter le trafic de commutateur par un périphérique, le plan de contrôle d'un périphérique peut être affecté, ce qui peut mener à une interruption opérationnelle.

Fonctionnalités et types de trafic qui affectent le CPU

Bien que non exhaustive, cette liste inclut les types de trafic de plans de données qui exigent un traitement CPU spécial et qui sont commutés par processus par le CPU :

  • Journalisation de l'ACL - Le trafic de journalisation de l'ACL se compose de paquets qui sont produits en raison d´une correspondance (permettre ou refuser) d'une ACE sur laquelle le mot-clé de journal est utilisé.

  • Unicast RPF - Unicast RPF utilisé en même temps qu'une ACL peut avoir comme conséquence la commutation par processus de certains paquets.

  • Options IP - Tout paquet IP avec options incluses doit être traité par le CPU.

  • Fragmentation - Tout paquet IP qui exige la fragmentation doit être passé au CPU pour traitement.

  • Échéance de Time to Live (TTL) - Les paquets qui ont une valeur de TTL inférieure ou égale à 1 exigent que les messages de temps dépassé de l'Internet Control Message Protocol (ICMP type 11, code 0) soient envoyés, ce qui entraîne un traitement par le CPU.

  • ICMP inaccessibles - Les paquets qui ont comme conséquence des messages d´ICMP inaccessibles en raison du routage, du MTU ou du filtrage sont traités par le CPU.

  • Trafic exigeant une requête ARP - Les destinations pour lesquelles une entrée ARP n'existe pas nécessitent un traitement par le CPU.

  • Trafic non-IP - Tout le trafic non-IP est traité par le CPU.

Voir la section Durcissement général du plan de données de ce document pour plus d'informations sur le durcissement du plan de données.

Filtrage sur la valeur de TTL

Vous pouvez utiliser le soutien ACL pour le filtrage sur la fonctionnalité Valeur de TTL, introduit dans le Logiciel Cisco IOS Version 12.4(2)T, dans une liste d'accès IP étendue pour filtrer les paquets basés sur la valeur de TTL. Cette fonctionnalité peut être utilisée afin de protéger un périphérique recevant le trafic de transit où la valeur de TTL est zéro ou un. Le filtrage de paquets basé sur les valeurs de TTL peut également être utilisé afin d'assurer que la valeur de TTL ne soit pas inférieure au diamètre du réseau, de ce fait protégeant le plan de contrôle des périphériques d'infrastructure en aval contre les attaques d'échéance de TTL.

Notez que certaines applications et outils tels que traceroute utilisent l'échéance TTL de paquets dans des buts de tests et de diagnostiques. Quelques protocoles, tels qu'IGMP, utilisent légitimement une valeur de TTL égale à un.

Cet exemple d´ACL crée une politique qui filtre les paquets IP où la valeur de TTL est inférieure à 6.


!
!--- Create ACL policy that filters IP packets with a TTL value
!--- less than 6
!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any ttl lt 6
 permit ip any any

!
!--- Apply access-list to interface in the ingress direction
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 

!

Référez-vous à Identification et atténuation d'attaques d'échéance TTL pour plus d'informations sur le filtrage de paquets basé sur la valeur de TTL.

Référez-vous à Support d´ACL pour le filtrage sur la valeur de TTL pour plus d'informations sur cette fonctionnalité.

Commençant avec le Logiciel Cisco IOS Version 12.4(4)T, Flexible Packet Matching (FPM) permet à un administrateur d´établir une correspondance sur les bits arbitraires d'un paquet. Cette politique de FPM rejette les paquets avec une valeur de TTL inférieure à six.


!

load protocol flash:ip.phdf

!

class-map type access-control match-all FPM-TTL-LT-6-CLASS
 match field IP ttl lt 6

!

policy-map type access-control FPM-TTL-LT-6-DROP-POLICY
 class  FPM-TTL-LT-6-CLASS
  drop

!

interface FastEthernet0
 service-policy type access-control input FPM-TTL-LT-6-DROP-POLICY

!

Référez-vous à Flexible Packet Matching, situé sur la page d'accueil Cisco IOS Flexible Packet Matching, pour plus d'informations sur la fonctionnalité.

Filtrage sur la présence des options d'IP

Dans le Logiciel Cisco IOS Version 12.3(4)T et ultérieure, vous pouvez utiliser la fonctionnalité ACL Support for the Filtering IP Options dans une liste d'accès IP nommée et étendue pour filtrer les paquets IP avec présence d´options IP. Le filtrage de paquets IP qui est basé sur la présence d´options IP peut également être utilisé afin d'empêcher le plan de contrôle des périphériques d'infrastructure de devoir traiter ces paquets au niveau du CPU.

Notez que le soutien ACL pour la fonctionnalité Filtrage des options IP peut seulement être utilisé avec des ACL nommées et étendues. Il faut également noter que RSVP, Ingénierie de trafic de commutation multiprotocole par étiquette, les versions 2 et 3 d'IGMP et d'autres protocoles qui utilisent des paquets avec options IP peuvent ne pas pouvoir fonctionner correctement si des paquets pour ces protocoles sont rejetés. Si ces protocoles sont en service dans le réseau, alors le soutien ACL pour le filtrage des options IP peut être utilisé ; cependant, la fonctionnalité Rejet sélectif des options IP ACL pourrait rejeter ce trafic et ces protocoles peuvent ne pas fonctionner correctement. S'il n'y a aucun protocole en service qui exige des options IP, le Rejet sélectif des options IP ACL est la méthode préférée pour rejeter ces paquets.

Cet exemple d´ACL crée une politique qui filtre les paquets IP qui contiennent des options IP :


!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any option any-options
 permit ip any any

!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 

!

Cet exemple d´ACL démontre une politique qui filtre les paquets IP avec cinq options IP spécifiques. Les paquets qui contiennent ces options sont refusés :

  • 0 Fin de la liste d´options (eool)

  • 7 Enregistrement de route (record-route)

  • 68 Horodatage

  • 131 - Route source lâche (lsr)

  • 137 - Route source stricte (ssr)


!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any option eool
 deny ip any any option record-route
 deny ip any any option timestamp
 deny ip any any option lsr
 deny ip any any option ssr
 permit ip any any

!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 

!

Référez-vous à Support d'ACL pour le filtrage des options IP pour plus d'informations sur cette fonctionnalité. Voir la section Durcissement général du plan de données de ce document pour plus d'informations sur le Rejet sélectif des options IP ACL.

Reportez-vous à Listes de contrôle d'accès de transit : Filtrage au niveau de votre périphérie pour plus d'informations sur le filtrage du trafic de transit et du trafic périphérique.

Une autre fonctionnalité du logiciel Cisco IOS qui peut être utilisée afin de filtrer les paquets avec options IP est CoPP. Commençant avec le Logiciel Cisco IOS Version 12.3(4)T, CoPP permet à un administrateur de filtrer le flux de trafic des paquets du plan de contrôle. Un périphérique qui prend en charge CoPP et le soutien d'ACL pour le filtrage des options IP, introduit dans le Logiciel Cisco IOS Version 12.3(4)T, peut employer une politique de liste d´accès pour filtrer les paquets qui contiennent des options IP.

Cette politique de CoPP rejette les paquets de transit qui sont reçus par un périphérique quand des options IP sont présentes :


!

ip access-list extended ACL-IP-OPTIONS-ANY
 permit ip any any option any-options

!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS-ANY

!

policy-map COPP-POLICY
 class ACL-IP-OPTIONS-CLASS
  drop

!

control-plane
 service-policy input COPP-POLICY

!

Cette politique de CoPP rejette les paquets de transit qui sont reçus par un périphérique quand ces options IP sont présentes :

  • 0 Fin de la liste d´options (eool)

  • 7 Enregistrement de route (record-route)

  • 68 Horodatage

  • 131 - Route source+F7461 lâche (lsr)

  • 137 - Route source stricte (ssr)


!

ip access-list extended ACL-IP-OPTIONS
 permit ip any any option eool
 permit ip any any option record-route
 permit ip any any option timestamp
 permit ip any any option lsr
 permit ip any any option ssr

!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS

!

policy-map COPP-POLICY
 class ACL-IP-OPTIONS-CLASS
  drop

!

control-plane
 service-policy input COPP-POLICY

!

Dans les politiques précédentes de CoPP, les entrées de la liste de contrôle d'accès (ACE) qui correspondent aux paquets avec l'action permettre ont pour résultat le rejet de ces paquets par la fonction policy-map rejeter, tandis que les paquets qui correspondent à l'action refuser (non montrée) ne sont pas affectés par la fonction de policy-map rejeter.

Référez-vous à Support d'ACL pour le filtrage des options IP pour plus d'informations.

Référez-vous à Déploiement de la surveillance du panneau de contrôle et Surveillance du plan de contrôle pour plus d'informations sur la fonction CoPP.

Protection du plan de contrôle

En commençant avec le Logiciel Cisco IOS Version 12.4(4)T, Control Plane Protection (CPPr) peut être utilisé pour limiter ou contrôler le trafic du plan de contrôle par le CPU d'un périphérique Cisco IOS. Tandis que semblable à CoPP, CPPr a la capacité de limiter ou contrôler le trafic avec une granularité plus fine que CoPP. CPPr divise le plan de contrôle global en trois catégories distinctes de plan de contrôle connues sous le nom de sous-interfaces : Des sous-interfaces d´hôte, de transit et de CEF-Exception existent.

Cette politique de CPPr rejette les paquets en transit reçus par un périphérique où la valeur de TTL est moins de 6 et les paquets en transit ou non reçus par un périphérique où la valeur de TTL est zéro ou un. La politique de CPPr rejette également les paquets avec options IP sélectionnées reçus par le périphérique.


!

ip access-list extended ACL-IP-TTL-0/1
 permit ip any any ttl eq 0 1

!

class-map ACL-IP-TTL-0/1-CLASS
 match access-group name ACL-IP-TTL-0/1

!

ip access-list extended ACL-IP-TTL-LOW
 permit ip any any ttl lt 6

!

class-map ACL-IP-TTL-LOW-CLASS
 match access-group name ACL-IP-TTL-LOW

!

ip access-list extended ACL-IP-OPTIONS
 permit ip any any option eool
 permit ip any any option record-route
 permit ip any any option timestamp
 permit ip any any option lsr
 permit ip any any option ssr

!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS

!

policy-map CPPR-CEF-EXCEPTION-POLICY
 class ACL-IP-TTL-0/1-CLASS
  drop
 class ACL-IP-OPTIONS-CLASS
  drop

!


!-- Apply CPPr CEF-Exception policy CPPR-CEF-EXCEPTION-POLICY to
!-- the CEF-Exception CPPr sub-interface of the device


!

control-plane cef-exception
 service-policy input CPPR-CEF-EXCEPTION-POLICY

!

policy-map CPPR-TRANSIT-POLICY
 class ACL-IP-TTL-LOW-CLASS
  drop

!

control-plane transit
 service-policy input CPPR-TRANSIT-POLICY

!

Dans la politique précédente de CPPr, les entrées de la liste de contrôle d'accès qui correspondent aux paquets avec l'action permettre ont pour résultat le rejet de ces paquets par la fonction policy-map rejeter, tandis que les paquets qui correspondent à l'action refuser (non montrée) ne sont pas affectés par la fonction de policy-map rejeter.

Référez-vous à Comprendre la Protection du plan de contrôle et Protection du plan de contrôle pour plus d'informations sur la fonctionnalité CPPr.

Identification du trafic et retour arrière

Parfois, vous pouvez devoir identifier rapidement le trafic sur le réseau et revenir en arrière, particulièrement pendant une réponse d'incident ou des mauvaises performances du réseau. Le Netflow et la classification des ACL sont les deux méthodes principales pour accomplir ceci en utilisant le logiciel Cisco IOS. Le Netflow peut fournir la visibilité dans tout le trafic du réseau. En outre, le Netflow peut être mis en application avec des collecteurs qui peuvent fournir les tendances à long terme et une analyse automatisée. Les ACL de classification sont un composant des ACL qui exigent une pré-planification pour identifier un trafic donné et une intervention manuelle pendant l'analyse. Ces sections fournissent une brève présentation générale de chaque fonctionnalité.

NetFlow

Netflow identifie l'activité réseau anormale et liée à la sécurité en suivant les débits du réseau. Les données Netflow peuvent être affichées et analysées par l'intermédiaire de l´interface de ligne de commande (CLI), ou les données peuvent être exportées vers un collecteur Netflow commercial ou logiciel gratuit pour agrégation et analyse. Les collecteurs Netflow, par tendance à long terme, peuvent fournir le comportement du réseau et l'analyse de l'utilisation. Netflow fonctionne en exécutant l'analyse sur des attributs spécifiques dans les paquets IP et en créant des flux. Version 5 est la version la plus utilisée généralement du Netflow ; cependant, le version 9 est plus extensible. Les flux de Netflow peuvent être créés en utilisant des données de trafic échantillonnées dans des environnements à gros volume.

Cisco Express Forwarding (CEF), ou CEF distribué, est une condition préalable à l´activation de Netflow. Netflow peut être configuré sur des routeurs et des commutateurs.

Cet exemple illustre la configuration de base de cette fonctionnalité. Dans les versions précédentes du logiciel Cisco IOS, la commande pour activer Netflow sur une interface est ip route-cache flow au lieu de ip flow {ingress | de sortie}.


!

ip flow-export destination <ip-address> <udp-port>
ip flow-export version <version>

!

interface <interface> 
 ip flow <ingess|egress> 

!

Ceci est un exemple de sortie Netflow du CLI. L'attribut SrcIf peut faciliter le retour arrière.

router#show ip cache flow
IP packet size distribution (26662860 total packets):
   1-32   64   96  128	160  192  224  256  288  320  352  384	416  448  480
   .741 .124 .047 .006 .005 .005 .002 .008 .000 .000 .003 .000 .001 .000 .000

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
   .000 .000 .001 .007 .039 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 4456704 bytes
  55 active, 65481 inactive, 1014683 added
  41000680 ager polls, 0 flow alloc failures
  Active flows timeout in 2 minutes
  Inactive flows timeout in 60 seconds
IP Sub Flow Cache, 336520 bytes
  110 active, 16274 inactive, 2029366 added, 1014683 added to flow
  0 alloc failures, 0 force free
  1 chunk, 15 chunks added
  last clearing of statistics never
Protocol	 Total	  Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)
--------	 Flows	   /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow
TCP-Telnet	 11512	    0.0        15    42      0.2      33.8      44.8
TCP-FTP 	  5606	    0.0 	3    45      0.0      59.5      47.1
TCP-FTPD	  1075	    0.0        13    52      0.0       1.2      61.1
TCP-WWW 	 77155	    0.0        11   530      1.0      13.9      31.5
TCP-SMTP	  8913	    0.0 	2    43      0.0      74.2      44.4
TCP-X		   351	    0.0 	2    40      0.0       0.0      60.8
TCP-BGP 	   114	    0.0 	1    40      0.0       0.0      62.4
TCP-NNTP	   120	    0.0 	1    42      0.0       0.7      61.4
TCP-other	556070	    0.6 	8   318      6.0       8.2      38.3
UDP-DNS 	130909	    0.1 	2    55      0.3      24.0      53.1
UDP-NTP 	116213	    0.1 	1    75      0.1       5.0      58.6
UDP-TFTP	   169	    0.0 	3    51      0.0      15.3      64.2
UDP-Frag	     1	    0.0 	1  1405      0.0       0.0      86.8
UDP-other	 86247	    0.1       226    29     24.0      31.4      54.3
ICMP		 19989	    0.0        37    33      0.9      26.0      53.9
IP-other	   193	    0.0 	1    22      0.0       3.0      78.2
Total:	       1014637	    1.2        26    99     32.8      13.8      43.9

SrcIf	      SrcIPaddress    DstIf	    DstIPaddress    Pr SrcP DstP Pkts
Gi0/1	      192.168.128.21  Local	    192.168.128.20  11 CB2B 07AF   3
Gi0/1	      192.168.150.60  Gi0/0	    10.89.17.146    06 0016 101F  55
Gi0/0	      10.89.17.146    Gi0/1	    192.168.150.60  06 101F 0016   9
Gi0/1	      192.168.150.60  Local	    192.168.206.20  01 0000 0303  11
Gi0/0	      10.89.17.146    Gi0/1	    192.168.150.60  06 07F1 0016   1

Référez-vous à Netflow Cisco IOS pour plus d'informations sur les capacités de Netflow.

Référez-vous à Introduction à Netflow Cisco IOS - Un aperçu technique pour un aperçu technique de Netflow.

ACL de classification

Les ACL de classification fournissent la visibilité dans le trafic qui traverse l´interface. Les ACL de classification ne modifient pas la stratégie de sécurité d'un réseau et sont typiquement construites pour classifier des protocoles individuels, des adresses source ou des destinations. Par exemple, un ACE qui permet tous les trafics pourrait être séparé en protocoles ou ports spécifiques. Cette classification plus granulaire du trafic dans des ACE spécifiques peut aider à comprendre le trafic du réseau parce que chaque catégorie de trafic a son propre compteur de coups. Un administrateur peut également séparer le refus implicite à la fin d'une ACL dans des ACE granulaires pour aider à identifier les types de trafic refusé.

Un administrateur peut accélérer une résolution d'incidents à l'aide des ACL de classification avec les commandes EXEC show access-list et clear ip access-list counters.

Cet exemple illustre la configuration d'une ACL de classification pour identifier le trafic SMB avant un refus par défaut :


!

ip access-list extended ACL-SMB-CLASSIFY
 remark Existing contents of ACL
 remark Classification of SMB specific TCP traffic 
 deny	tcp any any eq 139
 deny	tcp any any eq 445
 deny	ip any any 

!

Afin d'identifier le trafic qui utilise une ACL de classification, utiliser la commande EXEC show access-list acl-name. Les compteurs d'ACL peuvent être effacés à l'aide de la commande EXEC clear ip access-list counters acl-name.

router#show access-list ACL-SMB-CLASSIFY 
Extended IP access list ACL-SMB-CLASSIFY
    10 deny tcp any any eq 139 (10 matches)
    20 deny tcp any any eq 445 (9 matches)
    30 deny ip any any (184 matches) 

Référez-vous à Comprendre la journalisation de la liste de contrôle d'accès pour plus d'informations sur la façon d'activer les capacités de journalisation dans les ACL.

Contrôle d'accès avec des VLAN Maps et des listes de contrôle d'accès de port

Les listes de contrôle d'accès VLAN (VACL), ou VLAN maps et ACL de port (PACL), fournissent la capacité d´imposer le contrôle d'accès sur le trafic non routé qui est plus près des périphériques d'extrémité que des listes de contrôle d'accès qui sont appliquées aux interfaces routées.

Ces sections fournissent un aperçu des fonctionnalités, des avantages et des scénarios d'utilisation potentiels des VACL et des PACL.

Contrôle d'accès avec VLAN Maps

Les VACL, ou VLAN maps qui s'appliquent à tous les paquets qui entrent dans le VLAN, fournissent la capacité d´imposer le contrôle d'accès sur le trafic intra-VLAN. Ce n'est pas possible en utilisant les ACL sur des interfaces routées. Par exemple, un VLAN map peut être utilisé afin d'empêcher les hôtes qui sont contenus dans le même VLAN de communiquer entre eux, réduisant au minimum de ce fait les opportunités pour des attaquants locaux ou des vers d´exploiter un hôte sur le même segment de réseau. Afin d´empêcher des paquets d'utiliser un VLAN map, vous pouvez créer une liste de contrôle d'accès (ACL) qui correspond au trafic et, dans le VLAN map, définir l'action pour rejeter. Une fois qu'un VLAN map est configuré, tous les paquets qui entrent dans le LAN sont séquentiellement évalués contre le VLAN map configuré. Les VLAN access maps prennent en charge IPv4 et les listes d'accès MAC ; cependant, ils ne prennent pas en charge la journalisation ou les ACL IPv6.

Cet exemple utilise une liste d´accès nommée étendue qui illustre la configuration de cette fonctionnalité :


!

ip access-list extended <acl-name>
 permit <protocol> <source-address> <source-port> <destination-address>
     <destination-port>

!

vlan access-map <name> <number>
 match ip address <acl-name>
 action <drop|forward>

!

Cet exemple démontre l'utilisation d'un VLAN map pour refuser les ports TCP 139 et 445 ainsi que le protocole vines-IP :


!

ip access-list extended VACL-MATCH-ANY
 permit ip any any

!

ip access-list extended VACL-MATCH-PORTS
 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 445
 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 139

!

mac access-list extended VACL-MATCH-VINES
 permit any any vines-ip

!

vlan access-map VACL 10
 match ip address VACL-MATCH-VINES 
 action drop

!

vlan access-map VACL 20 
 match ip address VACL-MATCH-PORTS
 action drop

!

vlan access-map VACL 30
 match ip address VACL-MATCH-ANY
 action forward

!

vlan filter VACL vlan 100 

!

Référez-vous à Configuration de la sécurité réseau avec des ACL pour plus d'informations sur la configuration des VLAN maps.

Contrôle d'accès avec des PACL

Les PACL peuvent seulement être appliqués à la direction entrante sur des interfaces physiques de la couche 2 d'un commutateur. Semblable aux VLAN maps, les PACL fournissent le contrôle d'accès sur trafic non-routé ou de couche 2 . La syntaxe pour créer des PACL, qui ont la priorité au-dessus des VLAN maps et des ACL de routeur, est identique à celle des ACL de routeur. Si un ACL est appliqué à une interface de couche 2, il est alors désigné sous le nom de PACL. La configuration implique de créer un IPv4, IPv6 ou MAC ACL et de l'appliquer à l'interface de couche 2.

Cet exemple utilise une liste d´accès nommée étendue afin d´illustrer la configuration de cette fonctionnalité :


!

ip access-list extended <acl-name>
 permit <protocol> <source-address> <source-port> <destination-address> 
     <destination-port>

!

interface <type> <slot/port>
 switchport mode access
 switchport access vlan <vlan_number>
 ip access-group <acl-name> in 

!

Référez-vous à la section ACL de port de Configuration de la sécurité réseau avec des ACL pour plus d'informations sur la configuration des PACL.

Contrôle d'accès avec MAC

Les listes de contrôle d'accès MAC ou les listes étendues peuvent être appliquées sur un réseau IP avec l'utilisation de cette commande en mode de configuration d'interface :

Cat6K-IOS(config-if)#mac packet-classify

Remarque: C´est pour classifier les paquets de couche 3 comme paquets de couche 2. La commande est prise en charge dans le Logiciel Cisco IOS Version 12.2(18)SXD (pour Sup 720) et le Logiciel Cisco IOS Versions 12.2(33)SRA ou ultérieures.

Cette commande d´interface doit être appliquée sur l'interface d'entrée et elle demande au moteur de transfert de ne pas inspecter l'en-tête IP. Le résultat est que vous pouvez utiliser une liste d'accès de MAC sur l'environnement IP.

Utilisation des VLAN privés

Les VLAN privés (PVLAN) sont une fonction de sécurité de la couche 2 qui limite la connectivité entre les postes de travail ou les serveurs dans un VLAN. Sans PVLAN tous les périphériques sur un VLAN de couche 2 peuvent communiquer librement. Des situations de réseau existent où la sécurité peut être facilitée en limitant la communication entre les périphériques sur un seul VLAN. Par exemple, des PVLAN sont employés souvent afin d'interdire la communication entre les serveurs dans un sous-réseau publiquement accessible. Si un seul serveur devient compromis, le manque de connectivité à d'autres serveurs en raison de l'application des PVLAN peut aider à limiter la compromission au seul serveur.

Il y a trois types de VLAN privés : VLAN isolés, VLAN de communauté et VLAN principaux. La configuration des PVLAN se sert des VLAN principaux et secondaires. Le VLAN principal contient tous les ports proches, qui sont décrits plus tard, et inclut un ou plusieurs VLAN secondaires, qui peuvent être des VLAN isolés ou de communauté.

VLAN isolés

La configuration d'un VLAN secondaire en tant que VLAN isolé empêche complètement la communication entre les périphériques dans le VLAN secondaire. Il peut seulement y avoir un VLAN isolé par VLAN principal, et seulement les ports proches peuvent communiquer avec des ports dans un VLAN isolé. Les VLAN isolés devraient être utilisés sur des réseaux non sécurisés comme les réseaux qui prennent en charge des invités.

Cet exemple de configuration configure VLAN 11 en tant que VLAN isolé et l´associe au VLAN principal, VLAN 20. L´exemple ci-dessous configure également l´interface FastEthernet 1/1 en tant que port isolé dans le VLAN 11 :


!

vlan 11
 private-vlan isolated

!

vlan 20
 private-vlan primary
 private-vlan association 11

!

interface FastEthernet 1/1
 description *** Port in Isolated VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 11

!

VLAN de communauté

Un VLAN secondaire qui est configuré en tant que VLAN de communauté permet la communication entre les membres du VLAN aussi bien qu'avec tous les ports proches dans le VLAN principal. Cependant, aucune communication n'est possible entre deux VLAN de communauté quelconques ou entre un VLAN de communauté et un VLAN isolé. Les VLAN de communauté doivent être utilisés afin de grouper des serveurs qui ont besoin de connectivité entre eux, mais où la connectivité à tous les autres périphériques dans le VLAN n'est pas requise. Ce scénario est commun dans un réseau accessible publiquement ou partout où des serveurs fournissent un contenu aux clients non sécurisés.

Cet exemple configure un VLAN de communauté seul et configure le port de commutation FastEthernet 1/2 en tant que membre de ce VLAN. Le VLAN de communauté, VLAN 12, est un VLAN secondaire du VLAN principal 20.


!

vlan 12
 private-vlan community

!

vlan 20
 private-vlan primary
 private-vlan association 12

!

interface FastEthernet 1/2
 description *** Port in Community VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 12

!

Ports proches

Les ports de commutation qui sont placés dans le VLAN principal sont connus comme ports proches. Les ports proches peuvent communiquer avec tous les autres ports dans les VLAN principaux et secondaires. Les interfaces de routeurs ou de pare-feux sont les périphériques les plus communs de ces VLAN.

Cet exemple de configuration combine les exemples précédents de VLAN isolés et de communauté et ajoute la configuration de l´interface FastEthernet 1/12 comme port proche :


!

vlan 11
 private-vlan isolated

!

vlan 12
 private-vlan community

!

vlan 20
 private-vlan primary
 private-vlan association 11-12

!

interface FastEthernet 1/1
 description *** Port in Isolated VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 11

!

interface FastEthernet 1/2
 description *** Port in Community VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 12

!

interface FastEthernet 1/12
 description *** Promiscuous Port ***
 switchport mode private-vlan promiscuous
 switchport private-vlan mapping 20 add 11-12

!

En mettant en application les PVLAN, il est important de s'assurer que la configuration de couche 3 en place prenne en charge les restrictions qui sont imposées par les PVLAN et ne permette pas que la configuration du PVLAN soit corrompue. Le filtrage de la couche 3 en utilisant une ACL de routeur ou un pare-feu peut empêcher la subversion de la configuration du PVLAN.

Référez-vous à VLAN privés (PVLAN) - proches, isolés, de communauté, situé sur la page d´accueil de Sécurité LAN, pour plus d'informations sur l´utilisation-et la configuration des VLAN privés.

Conclusion

Ce document vous donne un large aperçu des méthodes qui peuvent être utilisées afin de sécuriser un périphérique du système Cisco IOS. Si vous sécurisez les périphériques, il augmente la sécurité globale des réseaux que vous gérez. Dans cet aperçu, la protection de la gestion, du contrôle et des plans de données est discutée, et des recommandations pour la configuration sont fournies. Dans la mesure du possible, suffisamment de détails sont donnés pour la configuration de chaque fonctionnalité associée. Cependant, dans tous les cas, des références complètes sont fournies pour vous fournir les informations nécessaires à une évaluation complémentaire.

Remerciements

Quelques descriptions de la fonction dans ce document ont été écrites par des équipes de développement de l'information de Cisco.

Annexe : Périphérique de Cisco IOS durcissant la liste de contrôle

Cette liste de contrôle est une collection de toutes les étapes durcissantes qui sont présentées de ce guide. Les administrateurs peuvent l'utiliser pendant qu'un rappel de tout le durcissement comporte utilisé et considéré pour un périphérique de Cisco IOS, même si une caractéristique n'a pas été mise en application parce qu'elle ne s'est pas appliquée. Des administrateurs sont informés évaluer chaque option pour son risque potentiel avant de mettre en application l'option.

Plan de gestion

  • Mots de passe

    • Activez le MD5 hachant (option secrète) pour des mots de passe d'enable et d'utilisateur local

    • Configurez le verrouillage de relance de mot de passe

    • Reprise de mot de passe de débronchement (considérez le risque)

  • Services inutilisés de débronchement

  • Configurez le Keepalives de TCP pour des sessions de Gestion

  • Placez les notifications de mémoire et de seuil CPU

  • Configurez

    • Notifications de seuil de mémoire et CPU

    • Mémoire de réserve pour l'accès de console

    • Détecteur de fuite de mémoire

    • Détection de débordement de tampon

    • Collection améliorée de crashinfo

  • IACLs d'utilisation pour limiter l'accès de Gestion

  • Filtre (considérez le risque)

    • Paquets d'ICMP

    • Fragments IP

    • Options IP

    • Valeur de TTL en paquets

  • Protection du plan de contrôle

    • Configurez le filtrage de port

    • Configurez les seuils de file d'attente

  • Accès de Gestion

    • Management Plane Protection d'utilisation pour limiter des interfaces de gestion

    • Placez le délai d'attente d'exécutif

    • Utilisez un protocole de transport chiffré (tel que le SSH) pour l'accès CLI

    • Contrôlez le transport pour des lignes vty et tty (l'option de classe d'accès)

    • Avertissez en utilisant des bannières

  • AAA

    • AAA d'utilisation pour l'authentification et le retour

    • Utilisez l'AAA (TACACS+) pour l'autorisation de commande

    • AAA d'utilisation pour la comptabilité

    • Serveurs redondants d'AAA d'utilisation

  • SNMP

    • Configurez les communautés SNMPv2 et appliquez ACLs

    • Configurez SNMPv3

  • Se connecter

    • Configure a centralisé se connecter

    • Sets logging level pour tous les composants appropriés

    • Placez le logging source-interface

    • Configurez la finesse de logging timestamp

  • Gestion de la configuration

Plan de contrôle

  • Débronchement (considérez le risque)

    • L'ICMP réoriente

    • Unreachables d'ICMP

    • ARP Proxy

  • Configurez l'authentification de NTP si le NTP est utilisé

  • Configurez la Réglementation du plan de commande/protection (filtrage de port, les seuils de file d'attente)

  • Protocoles de routage sécurisés

    • BGP (TTL, MD5, préfixes maximum, listes de préfixes, chemin ACLs de système)

    • IGP (MD5, interface passive, filtrage d'artère, consommation de ressource)

  • Configurez les bornes de débit de matériel

  • Sécurisez les premiers protocoles de Redondance de saut (GLBP, HSRP, le VRRP)

Plan de données

  • Configurez la baisse sélective d'options IP

  • Débronchement (considérez le risque)

    • Acheminement de source IP

    • Diffusions dirigées IP

    • L'ICMP réoriente

  • Diffusions dirigées IP de limite

  • Configurez les tACLs (considérez le risque)

    • ICMP de filtre

    • Fragments IP de filtre

    • Options IP de filtre

    • Valeurs de TTL de filtre

  • Configure a exigé des protections anti-spoofing

  • Control Plane Protection (cef-exception de contrôle-avion)

  • Configurez le NetFlow et la classification ACLs pour l'identification du trafic

  • Configure a exigé le contrôle d'accès ACLs (cartes VLAN, PACLs, le MAC)

  • Configurez les VLAN privés

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 13608