Comme pour tout dispositif informatique, les switchs Cisco requièrent un logiciel système pour fonctionner. Ce logiciel, désigné par Cisco sous le nom d’Internetwork Operating System (IOS). Cisco IOS ne se limite pas à superviser les performances et le comportement du switch. Il offre également une interface utilisateur, connue sous le nom de CLI (Command Line Interface). Cette interface permet à l’utilisateur d’interagir avec le switch via un programme d’émulation de terminal qui reçoit et traite les entrées textuelles. Une fois la touche Entrée pressée, le CLI transmet ces instructions au switch qui exécute la commande correspondante et affiche les résultats sur le CLI. Trois méthodes principales permettent d’accéder au CLI du switch : se connecter via la console, utiliser Telnet, et employer Secure Shell (SSH).
Tandis que Telnet et SSH communiquent via le réseau IP pour établir la connexion, l’accès par console nécessite une liaison physique directe entre le PC de l’utilisateur et le port console du switch, ainsi que l’installation de logiciels appropriés sur le PC. À la différence de l’accès par console, Telnet et SSH exploitent le réseau TCP/IP existant pour le transfert de données, nécessitant uniquement le logiciel adéquat sur l’appareil de l’utilisateur pour établir la connexion.
Connexion au CLI
L’accès au CLI d’un switch ou à un routeur utilise trois composants, le port de la console physique sur le commutateur, un port série physique sur le PC et un câble.
Le commutateur Cisco offre deux types de ports pour accéder au CLI d’administration de l’équipement : le port console, un port RJ45 femelle spécifiquement dédié à cette tâche et reconnaissable par son nom « console » et un liseré bleu pour son identification.
Sur le PC, nous avons la possibilité de nous y connecter via le port série si ce dernier est présent sur l’ordinateur. Dans le cas contraire, il existe des adaptateurs USB-Serie.
Pour les commutateurs plus récents, nous pourront aussi utiliser le port USB.
Configuration mot de passe sur le port console
Lorsque vous avez un nouveau switch, sorti de son emballage, nous ne pouvons accéder au CLI, uniquement par le biais du port console. On appelle le terminal CTY.. Il n’y aura pas de mot de passe de configurer. Chaque méthode de connexion proposera à un lien vers un terminal spécifique. A l’aide de la commande « show line » exécuter dans le mode enable, nous pouvoir les liens proposés par l’équipement.
Nous voyons sur la capture d’écran le résultat de la commande « show line ». Dans la colonne « Typ », nous avons 3 types de terminal :
- CTY : Terminal pour la connexion via le port console
- AUX : Terminal pour la connexion via le port auxiliaire (Modem)
- VTY : Terminal pour la connexion via l’adresse IP (Telnet ou SSH)
Les modes du terminal
Lors de la connexion via l’un de ces terminaux, on accède au mode Exec, caractérisé par un niveau de privilèges minimal. Afin de restreindre l’accès aux terminaux, il est possible d’y définir un mot de passe. Nous devons réaliser cette opération dans la configuration globale du switch. Pour entrer dans ce mode, il est nécessaire de lancer la commande « Configure Terminal » une fois dans le mode « Enable ».
Après avoir exécuté cette commande, nous observons que l’invite de commande a changé. Le terme (config) s’est ajouté entre le nom du switch et le signe « # », confirmant ainsi notre accès au mode « configuration ». Nous allons à présent définir un mot de passe pour l’accès CTY. Pour ce faire, nous devons d’abord accéder au mode de configuration spécifique à notre console. Pour entrer dans le mode de configuration de l’interface console, la commande à utiliser est « line console 0 ». Nous procéderons ensuite à l’activation de l’authentification par mot de passe. Nous utiliserons la commande « login », puis nous définirons le mot de passe en le précédant de la commande « password ». Ces étapes se résument en trois commandes successives.
Switch(config)#line console 0
Switch(config-line)#password mot2passe
Switch(config-line)#login
Le switch stocke la configuration actuelle dans sa mémoire RAM, sous un fichier nommé running-config. Pour consulter le contenu de ce fichier, il faut saisir la commande « show running-config » une fois en mode Enable. Pour rester en mode configuration sans quitter ce dernier, il est possible d’exécuter cette commande directement depuis le mode « Configuration » en préfixant la commande par « do ».
Switch(config-line)#do show running-configUne fois cette commande exécutée, examinons à nouveau le mot de passe dans notre fichier de configuration.
Faiblesse du chiffrement
Cisco sécurise le mot de passe avec l’algorithme de Vigenère. Bien que cet algorithme puisse sembler complexe pour certains, il ne représente pas un grand défi pour un attaquant expérimenté. Pour s’en convaincre, il suffit d’effectuer une recherche sur internet en utilisant les mots-clés « Decrypt password type7 ». Vous découvrirez alors de nombreux outils capables de décrypter un mot de passe à partir de sa version chiffrée. Cela illustre le caractère réversible de l’algorithme.
Ces quelques lignes permettent de conclure aisément que cette méthode, prise isolément, ne saurait constituer une mesure de sécurité fiable. Désactiver ce port est une fausse bonne idée. En effet, ‘il représente l’unique moyen d’accéder au switch en cas de souci de configuration. Il devient donc essentiel de sécuriser l’accès physique à ce port (et par extension au switch) et de le surveiller.
Switch(config-line)#logging synchronousNous devrons également ajouter un time-out qui provoquera une déconnection après un temps défini d’inactivité. Dans l’exemple ci-dessous, nous activerons la déconnexion après 15 minutes d’inactivité.
Switch(config-line)#exec-timeout 15Pour rendre cette configuration soit persistante, c’est-à-dire présente lors d’un redémarrage de l’équipement, il faudra copier le fichier présent dans la RAM qui se nomme « running-config » vers le fichier « startup-config » qui lui est présent dans la NVRAM, c’est-à-dire une RAM Non volatile, ce type de RAM à la particularité de ne pas s’effacer à chaque fois que l’équipement s’éteint ou redémarre.
Switch(config)#copy running-config startup-configPour lire le contenu du fichier startup-config, nous utiliserons également la commande « show startup-config ».
Sécuriser l’accès au VTY
Le VTY, ou terminal virtuel, est accessible par le biais d’une adresse IP et permet l’accès à distance via les protocoles TELNET ou SSH. Ces protocoles ont été développés pour se connecter à des équipements informatiques identifiables par une adresse IP. Dans la série Cisco Catalyst, il est possible de configurer une interface virtuelle, désignée sous l’appellation SVI (Switch Virtual Interface).
Configurer une IP sur une SVI
Pour commencer, nous assignerons une adresse IP à l’interface Vlan1. Le processus débute par l’entrée dans le mode de configuration de l’interface.
Switch>enable
Switch#configure terminal
Switch(config)#interface vlan 1
Il est important de noter que nous utilisons le VLAN 1 à des fins pédagogiques. Le VLAN 1, par mesure de sécurité , ne devra jamais être utilisé en production. Si vous souhaitez en savoir plus sur les VLAN, c’est par ici >>
Une fois dans le mode de configuration de l’interface, nous procéderons à la saisie de l’adresse IP. L’interface Vlan1 présente des spécificités que nous examinerons en détail ultérieurement. Pour notre objectif immédiat, qui est d’attribuer une adresse IP à cette interface, il est nécessaire d’effectuer une étape supplémentaire pour rendre l’interface opérationnelle. Cette étape consiste à activer l’interface.
Switch(config-if)#ip address 192.168.0.1 255.255.255.0
Switch(config-if)#no shutdownLa première commande attribuera l’adresse et la deuxième commande permet d’activer l’interface. Nous vérifierons que l’interface a bien été configurée, en exécutant la commande :
Switch(config-if)#do show ip interface brief | include Vlan 1Vérification de la configuration de l’interface SVI
Nous exécuterons la commande par « do », c cette commande permet d’exécuter des commandes du mode enable dans le mode de configuration. Nous avons également un « pipe » suivi de l’option « include », qui nous permet d’inclure seulement la ligne de l’interface Vlan1.
Dans la réponse de notre commande, nous observons que la fin de la ligne indique deux mentions « UP » ; la première se rapporte à l’état physique de la connexion (couche 1 du modèle OSI) et la seconde à son état logique (couche 2 du modèle OSI). Ainsi, nous avons établi une IP sur notre switch, qui servira d’adresse de configuration, communément désignée comme l’adresse IP de management. Comme écris précédemment, nous pouvons nous connecter aux terminaux via deux protocoles : Telnet et SSH.
Configuration TELNET
Nous commencerons par configurer Telnet, en particulier parce que les équipements Cisco de la série Catalyst activent par défaut le serveur Telnet. Au départ, nous devons spécifier le nombre maximal de connexions simultanées permises, ce qui revient à définir un nombre de terminaux virtuels (VTY).
Configuration des terminaux virtuels
L’IOS CISCO limite à 16, numérotés de 0 à 15. À titre d’exemple, nous choisirons d’autoriser 5 connexions VTY simultanées, ce qui se concrétise par la commande suivante :
Switch(config)#line vty 0 4Configuration du mot de passe pour l’accès TELNET
Nous allons maintenant activer l’authentification par mot de passe.
Switch(config-line)#loginEnsuite nous allons définir un mot de passe.
Switch(config-line)#password mot2passeTest de la configuration du mot de passe TELNET
Nous pouvons faire un test depuis une machine connecté sur le même réseau que le switch via un client telnet. Pour mon test, j’activerais la fonctionnalité « client telnet » présent sur Windows.
Lorsque la connexion est établie, nous sommes invités à renseigner un mot de passe que nous avons configuré précédemment.
Une fois le mot de passe renseigné, nous aurons accès au mode Exec.
Configuration de l’accés au mode Enable
Si par curiosité nous essayons d’accéder au mode « Enable », un message d’erreur « No password Set » apparaîtra. En réalité, l’authentification que nous avons mise en place nous autorise uniquement à entrer en mode exec.
Pour activer le mot de passe, il nous suffira d’exécuter la commande suivante sur l’équipement réseau :
Switch(config)#enable password mot2passeNous pouvons maintenant accéder à l’interface d’administration.
Chiffrer le mot de passe
Nous faisons face à une situation similaire à celle rencontrée lors de la configuration du mot de passe du port console. Sans activer la fonction « password-encryption », nos mots de passe seront visibles en clair dans le fichier de configuration.
Nous activerons ce service.
Switch(config)#service password-encryptionEnsuite, nous vérifierons que le mot de passe n’est pas en clair.
Nous vérifierons que le mot de passe permettant d’accéder au « mode Enable » ne soit pas lisible.
Augmenter le niveau de chiffrement du mot de passe
Comme nous l’avions évoqué précédemment, le niveau de sécurité offert est insuffisant en raison de la réversibilité de l’algorithme utilisé. Nous chercherons donc à rendre le mot de passe d’accès au « mode Enable » plus difficile à déchiffrer. À cet effet, au lieu d’utiliser la commande « password », nous devrons opter pour la commande « secret ». De cette manière, si nous décidons de supprimer le mot de passe précédemment configuré pour l’accès au mode exec de notre switch via le protocole Telnet.
Switch(config)#no enable passwordPuis, nous configurons le mot de passe en utilisant la commande « secret ».
Switch(config)# enable password mot2passe4enableLorsqu’on affiche notre fichier running-config, nous pouvons voir que le mot de passe a été complexifier en ajoutant des caractères spéciaux.
Dans la capture d’écran ci-dessus, l’expression « secret 5 » signifie que nous employons l’algorithme MD5 assorti de salage, une technique destinée à améliorer la sécurité du mot de passe. Bien que le MD5 soit considéré comme réversible, l’ajout de salage augmente sa complexité. Cependant, cela ne le rend pas indéchiffrable : un attaquant déterminé, disposant de temps et de moyens financiers, pourrait le décrypter. Pour rehausser notre niveau de sécurité, nous envisageons de complexifier davantage le processus de chiffrement. Ainsi, une attaque par force brute ou par dictionnaire nécessiterait une quantité significative de ressources, rallongeant le temps nécessaire pour « casser le mot de passe » et augmentant les coûts pour l’attaquant.
Modification de l’algorithme de chiffrement
Sur l’IOS, nous avons la possibilité de modifier l’algorithme de chiffrement associer à la commande « secret », nous avions bien évidemment le MD5 qui est l’algorithme par défaut. Ensuite nous avons deux autres algorithmes plus complexes, le sha256 et le « scrypt ». Cisco recommande que nous utilisions l’algorithme scrypt pour sa robustesse face aux tentatives de déchiffrage, cette algorithme de chiffrement est disponible à partir de l’IOS 15.3. Pour les équipements qui ne prendrais pas en charge le « scrypt », il recommandé d’utiliser le sha256.Pour exemple, nous activerons l’algorithme « scrypt ».
Switch(config)# enable algorithm-type scrypt secret mot2passe4enableNous pouvons voir dans notre fichier « running-config » que le mot de passe pour accéder au « mode enable » est plus complexe.
Les faiblesses de sécurité du TELNET
Nous avons partiellement résolu le problème de sécurité, mais un autre défi persiste, lié intrinsèquement au protocole Telnet. Rappelons que Telnet est un protocole ancien, ce qui en soi n’est pas un souci, mais cela remet les choses dans leurs contexte. La première RFC définissant les spécifications de Telnet remonte à juin 1980 (RFC 764). À cette époque, les préoccupations de sécurité n’étaient pas les mêmes qu’aujourd’hui, et en conséquence, Telnet ne possède pas de mécanisme de chiffrement. Par conséquent, si une personne malintentionnée effectue un balayage de votre réseau, elle pourrait intercepter le mot de passe, car il circulerait en clair sur le réseau, du fait de l’absence de mécanisme de chiffrement dans le protocole. La capture d’écran ci-dessous a été réalisée sur ma maquette de test à l’aide de l’outil Wireshark.
Le mot de passe Telnet apparaît effectivement en clair, et cette problématique concerne également le mot de passe permettant l’accès au mode « Enable ». En effet, la mesure de chiffrement que nous avons mise en œuvre précédemment ne concerne que le fichier de configuration et n’assure pas le chiffrement des données transmises sur le réseau.
Le protocole Telnet est donc à proscrire (dans la mesure du possible) si nous voulons pleinement sécuriser l’accès à notre switch. Il faudra lui préférer le protocole SSH qui sera traité la prochaine partie.
Configuration du protocole SSH
Le protocole SSH (Secure Shell) facilite l’ouverture d’une session sécurisée entre un client SSH, qui dans notre cas est un PC sous Windows 10, et un serveur SSH exécuté sur le switch. Pour établir cette session, un échange de clés est nécessaire. Cette clé servira à chiffrer les communications entre le client et le serveur. Ils échangeront des informations qui permettront de générer cette clé, ce qui caractérise un chiffrement symétrique. Ainsi, une unique clé est employée à la fois pour le chiffrement et le déchiffrement des messages.
Le SSH peut être également utilisé avec du chiffrement asymétrique, c’est-à-dire une clé privée qui est hébergé sur le serveur SSH et les clients ont une clé différente appelée clé publique. Une clé publique ne pourra pas être identique sur 2 clients SSH. Le rôle de la clé publique sera alors de chiffrer et la clé privée sera la seul qui pourra la déchiffrée
Configurer l’accés au SWITCH en SSH
Pour configurer l’accès SSH à notre switch, nous devons d’abord définir le nom de l’équipement et le domaine auquel il appartient, car nous intégrerons ces informations dans le certificat.. Ainsi, la première étape consistera à nommer le switch « SW1 » et à définir le nom de domaine comme « cisco.lab ».
Switch(config)#hostname SW1
SW1(config)#ip domain-name cisco.labLe protocole SSH fonctionne sur un modèle AAA, Authentication, Autorization, Accounting ou Auditing soit en français l’authentification, l’autorisation, et la traçabilité. Il nous faut donc activer ce modèle
SW1(config)#aaa new-modelNous allons ensuite générer notre clé en définissant la taille de votre clé. Sa taille peut être configuré entre 360 et 2048. La taille 1024 est un bon compromis. Plus la taille sera grande, plus cela demandera de la ressources processeurs pour déchiffrer qui, pour certain, équipement se traduira par des latences réseaux.
SW1(config)#crypto key generate rsa general-keys modulus 1024
Les faiblesses de la configuration SSH par défaut
La capture d’écran ci-dessus montre clairement que la clé a été générée avec succès, mais il y a une autre information qui mérite notre attention. La version actuelle du SSH est la 1.X, une version qui comporte de nombreuses vulnérabilités, lesquelles ont été corrigées dans la version 2. Nous pouvons confirmer cela en demandant les détails de la configuration du protocole SSH avec la commande suivante :
SW1(config)#do show ip ssh
Il nous faudra donc activer la version 2. Pour ce faire nous exécuterons la commande suivante
SW1(config)#ip ssh version 2Nous réexécuterons la commande de vérification « show ip ssh », nous pouvons vérifier que la version a bien été modifiée.
Pour que le client puisse se connecter aux serveurs, il lui faudra indiquer un couple identifiant/mot de passe. Nous créerons donc un compte local admin et nous associerons un mot de passe.
SW1(config)#username admin secret mot2passeNous en avons fini avec la configuration, nous pouvons vérifier que notre configuration fonctionne.
Si un attaquant utilise un scanner de réseau, contrairement à ce qui se passerait avec le protocole Telnet, les données capturées ne seront pas déchiffrables grâce au chiffrement offert par SSH, comme le démontre la capture d’écran suivante :
Nous avions écrit plus tôt qu’il fallait proscrire le telnet au profit du SSH, c’est ce que nous allons faire. Pour cela, il nous faudra autoriser que le mode de transport en SSH sur les VTY
SW1(config)#line vty 0 4
SW1(config-line)#transport input sshEn tentant de nous connecter en Telnet, nous aurons un message d’erreur.
