Sécurisation d'un switch Cisco — CLI, Telnet, SSH et cryptographie RSA

Sécurisation des accès à un switch Cisco manageable via CLI, Telnet et SSH

Qui Vitally Lubin — seule
Quoi Sécurisation des accès à un switch Cisco manageable via CLI (Command Line Interface), Telnet (TELecommunication NETwork) et SSH (Secure Shell)
GRETA-CFA Bretagne Occidentale, Quimper — Lycée Thépot (matériel partagé)
Quand En cours de formation — 12/03/2026 (rendu 31/03/2026)
Comment PuTTY connexion série, CLI Cisco IOS, bannière MOTD (Message Of The Day), mots de passe secret/MD5 (Message Digest 5), Telnet démontré non sécurisé via Wireshark, migration SSH avec cryptographie RSA (Rivest-Shamir-Adleman)
Combien 1 switch Cisco Catalyst 2960-24TT-L, 2 comptes utilisateurs configurés, 5 modes d'accès comparés
Pourquoi Sécuriser les accès au matériel réseau et comprendre les risques des protocoles non chiffrés

Contexte de réalisation

Le modèle OSI (Open Systems Interconnection) comme fil conducteur

Ce TP part d'une question théorique — à quelle couche du modèle OSI opère un switch ? — pour arriver à une conclusion pratique : pourquoi SSH (Secure Shell) est le seul choix acceptable pour administrer un équipement réseau.

Un switch de niveau 2 fait une seule chose : lire l'adresse MAC (Media Access Control) de destination dans chaque trame et décider sur quel port la renvoyer. Les couches supérieures transitent à travers lui sans qu'il les lise — comme un facteur qui achemine une lettre sans l'ouvrir.

Mais ce switch est manageable — configurable à distance. Et c'est là que d'autres couches entrent en jeu, non pas pour la commutation, mais pour l'administration : une adresse IP lui est attribuée sur le VLAN 1 (Virtual LAN) pour le joindre sur le réseau (couche 3), et les protocoles applicatifs utilisés pour lui envoyer des commandes opèrent en couche 7 — c'est précisément là que tout se joue.

L'objectif du TP est de démontrer, preuves à l'appui, que tous les protocoles d'accès ne se valent pas. La démonstration est progressive, du moins sécurisé au plus robuste :

Cinq niveaux, cinq preuves. La conclusion s'impose d'elle-même : sur un équipement réseau, Telnet est une faille. SSH est la réponse.

Compétences E5 mobilisées

1.1 ✅ Recenser et identifier les ressources numériques

Inventorier les composants du système d'information (matériels, logiciels, données, services) et les documenter pour en assurer la traçabilité et la gestion.

J'ai identifié et documenté le switch Cisco Catalyst 2960-24TT-L : modèle, adresse MAC (18:33:9D:2C:9C:00), adresse IP configurée (172.20.6.103), version IOS (12.2), numéro de série, et port COM (Communication Port) COM4 nécessaire à la connexion série via PuTTY. C'est le recensement préalable indispensable à toute intervention sur un équipement réseau.


1.2 ✅ Exploiter des référentiels, normes et standards

S'appuyer sur des documentations officielles, des normes de qualité ou des standards techniques pour guider ses choix et garantir la conformité des solutions produites.

J'ai appliqué les recommandations de l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) sur la bannière MOTD et les bonnes pratiques Cisco IOS : usage de secret (MD5) plutôt que password (type 7, déchiffrable), migration de Telnet vers SSH v2, génération d'une clé RSA de 1024 bits. J'ai également intégré le cadre légal — article 323-1 du Code pénal sur l'accès frauduleux aux STAD (Systèmes de Traitement Automatisé de Données).


1.3 ✅ Mettre en place et vérifier les niveaux d'habilitation

Définir et contrôler qui a accès à quoi : droits, rôles, comptes utilisateurs — de façon à protéger les ressources tout en permettant le travail des personnes autorisées.

J'ai créé deux comptes aux droits différenciés : stagiaire (accès limité) et admin (privilege 15 — droits d'administrateur complets, mot de passe stocké en MD5 avec secret). J'ai configuré login local sur les lignes console et VTY (Virtual TeleType) pour forcer l'authentification sur la base locale sur les deux vecteurs d'accès — physique et distant.


1.4 ✅ Vérifier les conditions de la continuité d'un service

S'assurer qu'un service peut rester disponible ou être rapidement rétabli en cas d'incident, de panne ou d'intervention technique.

J'ai utilisé write mem pour copier la running-config (configuration active en RAM) vers la NVRAM (Non-Volatile RAM), puis vérifié après reload que la configuration persistait — hostname OPALE, comptes, paramètres SSH intacts. Dans ce contexte de TP sur matériel partagé, c'est la vérification de continuité applicable à la session : le service d'administration sécurisé reste opérationnel après redémarrage.


1.5 ❌ Gérer des sauvegardes

Mettre en place une stratégie de sauvegarde des données et des configurations, avec une procédure permettant de les restaurer en cas de perte ou de corruption.

Non applicable dans ce contexte. Le TP se déroulait sur matériel partagé au Lycée Thépot : write mem était un outil de vérification pédagogique intra-session, pas un acte de sauvegarde intentionnel. En fin de session, le professeur a exécuté write erase — procédure de remise en configuration d'usine obligatoire sur matériel partagé, pour qu'aucune clé RSA ni mot de passe ne persiste après notre départ.


1.6 ✅ Vérifier le respect des règles d'utilisation

Contrôler que l'usage des outils et des systèmes est conforme aux règles définies : chartes, politiques de sécurité, obligations légales (RGPD, licences, etc.).

J'ai mis en place la bannière MOTD dont la fonction juridique est précisément de signifier que l'accès est restreint — sans elle, impossible de poursuivre un intrus qui prétendrait ne pas savoir que l'accès était interdit (référence ANSSI). Par ailleurs, le TP s'est déroulé dans un environnement appliquant une politique de sécurité réelle : remise en configuration d'usine obligatoire en fin de session sur matériel partagé, pour qu'aucune donnée sensible ne persiste après notre départ.

2.1 ❌ Collecter, suivre et orienter des demandes

Recueillir les demandes des utilisateurs, les qualifier, les prioriser et les orienter vers la bonne ressource ou procédure de traitement.

Non applicable : pas de ticket, pas de demande utilisateur formalisée. C'est un TP guidé sur cahier des charges pédagogique, pas une intervention sur incident déclaré.


2.2 ✅ Traiter des demandes concernant les services réseau et système

Diagnostiquer et résoudre des incidents ou des demandes liés à l'infrastructure : réseau, système d'exploitation, serveurs, équipements physiques.

C'est le cœur du TP : j'ai traité une demande de sécurisation d'un équipement réseau réel, de la connexion série initiale jusqu'à la migration SSH. J'ai diagnostiqué pourquoi Telnet était insuffisant — démontré par capture Wireshark montrant le mot de passe Rootopale2026 en clair dans le flux réseau — et appliqué la solution adaptée : SSH v2 avec authentification RSA.


2.3 ❌ Traiter des demandes concernant les applications

Diagnostiquer et résoudre des incidents ou des demandes liés aux applications : dysfonctionnement, anomalie, évolution fonctionnelle.

Non applicable : infrastructure réseau pure, pas d'application logicielle en jeu.

3.1 ❌ Participer à la valorisation de l'image de l'organisation sur les médias numériques

Contribuer à construire ou améliorer l'image de l'organisation sur le web, en tenant compte de son identité, de sa charte graphique et du cadre juridique applicable.

Non applicable. Ce TP ne concerne pas la présence en ligne d'une organisation.

3.2 ❌ Référencer les services en ligne de l'organisation et mesurer leur visibilité

Mettre en œuvre des techniques de référencement (SEO, sitemap, structuration des URL) pour améliorer la visibilité des services en ligne dans les moteurs de recherche.

Non applicable. Ce TP ne concerne pas la présence en ligne d'une organisation.

3.3 ❌ Participer à l'évolution d'un site Web exploitant les données de l'organisation

Concevoir, modifier ou enrichir un site web en intégrant les données propres à l'organisation, dans le respect de ses besoins et contraintes techniques.

Non applicable. Ce TP ne concerne pas la présence en ligne d'une organisation — aucune des trois sous-entrées du bloc 3 n'est mobilisée.

4.1 ✅ Analyser les objectifs et les modalités d'organisation d'un projet

Lire et comprendre un cahier des charges, identifier les contraintes, les acteurs et les ressources nécessaires avant de démarrer une réalisation.

Le TP repose sur un cahier des charges explicite : état des lieux des accès réseaux, sécurisation du matériel. J'ai formalisé les objectifs dans mon rapport avant les manipulations — comprendre le modèle OSI (Open Systems Interconnection), paramétrer un équipement selon un cahier des charges, sécuriser les communications — et j'ai fait le lien avec le cadre légal et les normes ANSSI de ma propre initiative.


4.2 ✅ Planifier les activités

Découper un projet en tâches, les séquencer dans le temps et organiser leur enchaînement pour atteindre les objectifs dans les délais impartis.

J'ai suivi et documenté une progression logique et séquentielle : connexion série → configuration de base (hostname, comptes, bannière) → démonstration de l'insécurité Telnet (capture Wireshark) → migration SSH (clé RSA, lignes VTY restreintes) → interface web HTTPS. Chaque étape conditionne la suivante.


4.3 ✅ Évaluer les indicateurs de suivi d'un projet et analyser les écarts

Mesurer l'avancement réel d'un projet par rapport à ce qui était prévu, identifier les écarts et les causes de blocage, et ajuster si nécessaire.

J'ai vérifié à chaque étape que les actions produisaient le résultat attendu : changement de prompt immédiat après hostname, mots de passe chiffrés visibles dans show run, ping réussi vers 172.20.6.103, capture Wireshark montrant les données en clair en Telnet, puis session SSH chiffrée opérationnelle, interface web en session "Sécurisé". Ce sont des indicateurs concrets, documentés et vérifiables.

5.1 ✅ Réaliser les tests d'intégration et d'acceptation d'un service

Vérifier que les composants d'un service fonctionnent correctement ensemble et que le résultat correspond aux attentes exprimées avant mise en production.

J'ai réalisé des tests concrets et documentés à chaque étape : ping pour valider la connectivité IP, connexion Telnet avec capture Wireshark prouvant l'absence de chiffrement (mot de passe visible en clair), connexion SSH réussie validant la sécurisation effective, accès à l'interface web en session HTTPS confirmant le bon fonctionnement global. Les résultats sont capturés et commentés dans le TP.


5.2 ✅ Déployer un service

Installer, configurer et mettre en production un service dans son environnement réel, de façon opérationnelle et sans interruption du service existant.

J'ai déployé et rendu opérationnel l'accès SSH sur un switch réel : génération de clé RSA 1024 bits, configuration des lignes VTY restreintes à SSH uniquement (transport input ssh), timeout et nombre de tentatives limités, configuration sauvegardée en NVRAM et vérifiée après redémarrage. Le service d'administration sécurisé était pleinement fonctionnel en fin de session.


5.3 ❌ Accompagner les utilisateurs dans la mise en place d'un service

Former, documenter ou guider les utilisateurs pour qu'ils puissent s'approprier un service et l'utiliser en autonomie.

Non applicable : réalisation individuelle en formation, pas d'accompagnement d'utilisateurs tiers.

6.1 ✅ Mettre en place son environnement d'apprentissage personnel

Structurer les outils, méthodes et ressources qui permettent d'apprendre en faisant, de progresser de façon autonome et de capitaliser ses connaissances.

J'ai constitué un environnement outillé et actif : PuTTY pour la connexion série et SSH, Wireshark pour la capture réseau, CLI Cisco IOS. Mais au-delà des outils, ma démarche est visible dans le TP lui-même — j'ai rédigé des encadrés explicatifs personnels ("À quoi sert PuTTY ?", "Pourquoi une bannière ?", "À quoi sert Wireshark ?"), ce ne sont pas des copier-coller : c'est la preuve que j'ai cherché à comprendre le pourquoi, pas juste à exécuter. J'ai aussi documenté mes échecs — la bannière MOTD qui n'a pas fonctionné figure dans le TP.


6.2 ✅ Mettre en œuvre des outils et stratégies de veille informationnelle

Identifier des sources fiables, les consulter régulièrement et exploiter les informations recueillies pour rester à jour sur les évolutions technologiques et professionnelles.

J'ai croisé plusieurs sources techniques pour prendre des décisions éclairées : recommandations ANSSI, frameip.com pour vérifier en direct la faiblesse du chiffrement type 7 Cisco (le mot de passe Rootopale2026 a été récupéré en clair), et une conversation Claude approfondie sur les raisons de l'insécurité de Telnet le jour même du rendu (31/03/2026). C'est une veille technique appliquée à des décisions concrètes.


6.3 ✅ Gérer son identité professionnelle

Construire et entretenir une présence numérique cohérente avec son parcours et ses compétences : portfolio, profil LinkedIn, livrables publics.

Cette réalisation est documentée et publiée sur mon portfolio praxis-debug.net. J'ai fait le choix actif de rendre ce TP visible professionnellement, avec captures CLI, explications techniques et mise en contexte juridique — démarche de construction d'identité professionnelle publique et traçable, qui montre concrètement ce que je sais faire en administration réseau.


6.4 ❌ Développer son projet professionnel

Analyser ses expériences pour identifier ses points forts, ses axes de progression et les compétences à acquérir en vue d'un objectif professionnel.

Non mobilisé directement sur ce TP. Cette compétence se défend mieux sur d'autres réalisations qui ont soulevé des questions d'orientation ou de spécialisation.

← Retour au portfolio