Ph1l's (sys|net)admin [lfo] blog

Ce n'est pas un scoop ! Cette session de formation a été une occasion supplémentaire de constater que l'outil Security Device Manager (SDM) est beaucoup trop instable pour que l'on puisse construire des travaux pratiques ou des évaluations en s'appuyant exclusivement dessus.

J'avais déjà publié un billet consacré à l'installation de SDM dans lequel je relatais toutes les difficultés rencontrées.

Toute accusation de parti pris «pro» logiciel libre tient encore moins la route que dans le précédent billet. Dans les universités britanniques que j'ai fréquentées, on connaît tout juste le mot «Linux». Le découpage métier entre gestion du parc des postes informatiques et enseignements sur les réseaux est tout à fait frappant. Le formateur ne se soucie absolument pas du système installé sur les PCs.

Dans les salles de travaux pratiques réseau du tic Learning Centre de l'université de Birmingham, chaque poste de travail dispose de deux unités centrales raccordées au même jeu écran/clavier via un micro KVM. Une UC est utilisable pour accéder au Web ; principalement au site netacad pour les tests en ligne. L'autre UC est réservée aux travaux pratiques. Un compte utilisateur générique permet de reconfigurer les interfaces réseau à volonté et d'installer les logiciels requis par les supports de travaux pratiques. Parmi ces logiciels, on retrouve le fameux Security Device Manager.

Le choix effectué ici est donc d'utiliser SDM sur le système Windoze XP du poste dédié. Ce choix est motivé par un souci d'économie dans l'utilisation de la mémoire flash des routeurs. Dans le cadre du cours CCNA Security, plusieurs travaux pratiques entraînent une consommation accrue de l'espace disponible sur les cartes CompactFlash.

	Avertissement
	Lors du transfert du paquet des signatures IPS, il faut impérativement arrêter SDM. Sinon, le système du routeur se fige et la seule solution est le redémarrage. Lors d'un test pratique (skill test), il n'est pas rare que l'on oublie de sauvegarder la configuration. Ce genre de plantage peut donc être catastrophique lors d'une évaluation.

En plus du plantage système complet rencontré avec l'utilisation conjointe des signatures IPS et de SDM, la partie 5 du support de travaux pratiques du chapitre 9 : Use SDM to configure Easy VPN Server n'a donné aucun résultat dans la mesure le menu de configuration n'est jamais apparu !

Voilà ce qui justifie le titre de cette section : l'utilisation du Security Device Manager a été un fiasco.

Côté université Paul Sabatier, j'avais choisi d'installer SDM sur les cartes CompactFlash des routeurs 1841 du bundle CCNA et de charger le système d'exploitation via TFTP lors de l'initialisation. Les travaux pratiques du module Accessing the Wan de l'été dernier ont pu fonctionner normalement sur cette base. J'espère donc pouvoir continuer sur cette base lors de la prochaine session compte tenu de l'échec de l'utilisation de SDM à partir d'une installation sur Windoze. Il va cependant falloir passer par un remplacement des cartes CompactFlash.

Le coût des cartes CompactFlash vendues chez Cisco™ étant exorbitant, il faut utiliser des cartes de fournisseurs tiers offrant des capacités beaucoup plus importantes pour assurer correctement les travaux pratiques de ce cours.

Heureusement, on trouve des références telles que celle proposée par l'excellent PacketLife.net.

Après avoir dit tout le mal possible sur SDM, que peut-on proposer comme alternative constructive ? Eh bien, pas grand chose.

La difficulté pédagogique est de taille. Comment construire une progression qui puisse permettre de se lancer dans l'utilisation des technologies de filtrage réseau ? Bien sûr, le plan du cours est tout tracé : filtrage de paquets, suivi de communication (stateful), inspection applicative et enfin filtrage par politique de sécurité. C'est la partie la plus facile et l'enseignant, aussi brillant soit-il, a tout loisir de disserter sur ces questions jusqu'au moment fatidique où les travaux pratiques arrivent. Lorsque l'on interroge les étudiants novices à l'oral ou que l'on demande de mettre en place une démarche de validation des règles de filtrage étudiées, on prend la mesure du décalage entre le discours et le niveau de compréhension de l'auditoire.

Chaque année, le support que je propose sur l'Introduction au filtrage réseau sur les systèmes GNU/Linux est celui qui pose le plus de problèmes aux étudiants. Tous les autres supports de la série «passent» beaucoup plus facilement. En évaluation, la partie sur le filtrage réseau est rarement traitée.

Pourtant, la conception du couple netfilter/iptables est très bien faite, très claire et plus simple à aborder que les fonctions de filtrage de l'IOS dans lesquelles on retrouve beaucoup plus de jargon et plus d'étapes historiques.

Dans les premières versions du curriculum CCNA, le filtrage de paquets était vu de façon complète et l'accent était mis sur la distinction entre masque réseau et wildcard dans les règles de filtrage. L'exercice emblématique consistant à autoriser l'accès Internet à une moitié seulement des adresses du réseau routé. On retrouvait ainsi une mécanique de décodage d'adresses.

Quand il a fallu intégrer le suivi de communication (ou stateful inspection), la question a été repoussée au cours CCNA Security Course. La commande auto secure sert d'échappatoire pour mettre en place un suivi de communication entre deux interfaces ; l'une exposée au réseau public l'autre au réseau interne d'une entreprise. Le support demande ensuite de modifier le jeu de protocoles soumis au suivi de communication et d'examiner les entrées de la table de suivi. Cette démarche convient très bien en phase de découverte de ces fonctions. La question qui vient ensuite est de savoir jusqu'où aller dans la prise en main de l'outil à un niveau donné. Pour qui a déjà une expérience d'exploitation sur une infrastructure réelle, s'arrêter là peut s'avérer très frustrant et la tentation de vouloir montrer des choses plus intéressantes est très grande. Le choix qui a été fait au niveau du CCNA Security Course est cohérent si l'on s'en tient à la «prise de contact» avec cette technique de filtrage et que l'on craint de perdre trop rapidement l'attention de l'auditoire.

C'est avec le filtrage par politique de sécurité (ou Zone Based Firewall) que les choses se corsent vraiment. Comment faire pour introduire un «mélange» de classification venant des fonctions de qualité de service (QoS) et de règles de filtrage ? Le choix qui a été fait dans le CCNA Security Course s'appuie sur quelques clicks dans SDM. Cette manipulation pourrait s'apparenter au recours à la commande auto secure si l'on demandait d'intervenir sur la configuration ensuite. Le problème ici, c'est que le jeu de commandes généré par les quelques clicks est tellement complexe qu'il n'est plus question d'intervenir sur la configuration autrement qu'à travers l'interface graphique. La syntaxe des commandes de validation du fonctionnement du filtrage impose que l'on comprenne l'enchaînement entre la classification et le filtrage réseau proprement dit. Là, je crois pouvoir dire que l'on «perd le contact» avec les étudiants encore plus rapidement.

Ceci-dit, je n'ai pas de méthode alternative de présentation simple introduisant ces fonctions. Le chantier est ouvert !

Le traitement de la sécurité au niveau d'un réseau local est très bon dans ce cours. On y retrouve toutes les fonctions caractéristiques d'un commutateur. Les travaux pratiques reprennent la démarche proposée dans le guide de la NSA : Cisco IOS Switch Security Configuration Guide.

Cette fois-ci, aucun «clickodrome» ne vient perturber l'attention et les démarches de validation sont bien décrites.

J'ai particulièrement apprécié l'utilisation de la fonction Switched Port Analyzer (SPAN) combinée avec WireShark pour analyser de façon déportée le trafic entre deux hôtes. C'est une technique très pédagogique !

Le chapitre sur les techniques de cryptographie est très équilibré et convient parfaitement pour une première approche sur la question. Les algorithmes y sont présentés sous forme synthétique et contextuelle. L'exercice d'équilibre entre niveau scientifique et exploitation est une fois de plus délicat à négocier. Dans le cas présent c'est réussi. On dépasse le simple catalogue d'algorithme et on dispose d'un premier niveau de choix suivant les contextes d'exploitation. Ici, l'objectif principal est d'aboutir à une synthèse comparative entre IPsec et SSL dans le but d'implémenter des solutions VPNs de différentes catégories.

Voilà pour l'analyse succincte du cours CCNA Security. Comme c'est une formation que je dois assurer au début du mois de Juillet prochain, j'ai encore du pain sur la planche. Je dois notamment préparer des images de machines virtuelles assurant les services Tacacs+ et Radius. J'aurai donc l'occasion de revenir sur ce sujet dans d'autres billets.

Ce billet est disponible en version imprimable au format PDF : ccnasecinst.pdf.

$Id: ccnasecinst.xml 1470 2010-02-16 20:23:44Z latu $