13 Administration et sécurité

Prérequis et objectifs

1. Prérequis

Maîtriser l’usage ordinaire du PC dans un environnement Windows.

2. Objectifs

À la fin de ce chapitre, vous serez en mesure de :

Mettre en place une authentification locale sur un routeur, fondée sur l’utilisation de couples nom d’utilisateur/mot de passe.

Mettre en place une authentification centralisée à l’aide d’un serveur RADIUS.

Mettre en place un serveur SYSLOG.

Établir une connexion sécurisée via SSH.

Objectifs extraits du cours Accès au réseau étendu (Atteinte partielle)

Décrire les menaces de sécurité courantes pour le réseau et expliquer comment mettre en place une stratégie de sécurité complète permettant de faire face aux menaces les plus courantes sur les périphériques, les hôtes et les applications du réseau.

Décrire les fonctions des appareils et des applications de sécurité les plus courants.

Décrire les pratiques de sécurité recommandées pour la sécurisation des périphériques réseau.

- 1 -© ENI Editions - All rigths reserved - FORMATIONS AFIP

enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA/NDAwODk1IC0gRk9STUFUSU9OUyBBRklQIC0gYTVkMjI0NzgtZTdhYi00MmJkLTk1MTUtNTk5OWE1ZDMyYzczy5wCEx9AzYgLAA==-enidentnumber

Identification des utilisateurs

Le lecteur désireux de s’en tenir strictement aux attendus de la certification CCNA peut ignorer ce chapitre.

1. Les niveaux de privilège

La notion de modes du routeur exposée précédemment dans cet ouvrage est en réalité à associer avec cette nouvelle notion de niveaux de privilège. L’IOS supporte seize niveaux de privilège, numérotés de 0 à 15. À chaque commande de l’IOS est associé un niveau de privilège. Par défaut, l’IOS répartit l’ensemble de ses commandes sur les trois niveaux [0, 1, 15] :

Le niveau 0 ne comporte que cinq commandes : disable, enable, exit, help et logout.

Le niveau 1 correspond à ce que nous avons appelé mode utilisateur et comporte un large ensemble de commandes qui ont en commun de ne pouvoir affecter que la configuration du routeur.

Le niveau 15 correspond à ce que nous avons appelé mode privilégié ou enable et donne accès à l’ensemble des commandes de l’IOS.

La commande show privilege que l’on peut abréger par sh priv confirme le niveau de privilège de la session en cours :

Ainsi, la connexion via les ports console, auxiliaire ou vty, après éventuelle entrée d’un mot de passe, place la session au niveau de privilège 1 par défaut. Les commandes enable et disable peuvent être associées à un argument spécifiant le niveau de privilège cible, supérieur au niveau en cours dans le cas de la commande enable, inférieur au niveau en cours dans le cas de la commande disable :

Dans les versions actuelles de l’IOS, seuls les trois niveaux 0, 1 et 15 sont utilisés. Il est parfaitement possible de créer des niveaux de privilège intermédiaires entre le niveau 1 et le niveau 15 :


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA/NDAwODk1IC0gRk9STUFUSU9OUyBBRklQIC0gYTVkMjI0NzgtZTdhYi00MmJkLTk1MTUtNTk5OWE1ZDMyYzczYeYZGR9AzYgLAA==-enidentnumber

La séquence de commandes de cette capture provoque la création des deux niveaux de privilège supplémentaires 5 et 10. Le niveau 5 est associé au mot de passe ccent, le niveau 10 est associé au mot de passe ccie. Observez qu’une élévation du niveau de privilège en cours réclame le mot de passe correspondant. Une diminution du niveau de privilège en cours s’effectue sans délai. Observez également que l’invite de commandes reste la même quel que soit le niveau de privilège dès qu’il est supérieur à 1 :

Mode utilisateur → Niveau de privilège 1 → Invite de commandes : Nantes> ;

Modes privilégiés → Niveaux de privilège 2 à 15 → Invite de commandes : Nantes#.

On peut sans doute regretter que l’IOS ne rappelle pas le niveau de privilège en cours dans l’invite de commandes, un affichage du type Nantes#5# par exemple aurait été bien commode.

Venonsen à la véritable utilité de ces différents niveaux de privilège. Ils vont permettre de réaliser une délégation des privilèges de l’administrateur à granularité fine. L’administrateur peut donner à un administrateur délégué l’accès à tous les outils dont ce délégué a besoin mais pas plus. L’administrateur parvient à ce résultat en associant l’un des niveaux de privilège inférieur à 15 avec le sousensemble de commandes adéquat. Imaginons par exemple appartenir à un fournisseur d’accès Internet. Une équipe de techniciens a pour activité principale le déploiement de routeurs d’accès chez les clients. Ces techniciens ont besoin de configurer des interfaces serial (c’estàdire leur affecter une adresse IP). Ils doivent donc disposer des commandes configure terminal, interface et ip address. De plus, ils doivent pouvoir tester la connectivité du routeur et ont besoin pour ce faire des commandes ping et trace. L’administrateur décide d’affecter ces commandes au niveau de privilège 5 :

Mais comment s’assurer que les techniciens disposeront bien de ces commandes mais pas plus ? Fort à propos, l’aide contextuelle vient au secours de l’administrateur :

- 2 - © ENI Editions - All rigths reserved - FORMATIONS AFIP


L’administrateur, rassuré sur la portée de sa délégation, provoque une commande show run afin de visualiser le résultat des commandes passées dans le but de déléguer. Une petite surprise l’attend :

En effet, il ne s’attendait pas à trouver les lignes « privilege interface level 5 ip » et « privilege exec level 5 configure ». Ce n’est étrange qu’en première approche. Pour que la commande ip address puisse être au niveau de privilège 5, il faut que la commande ip le soit également. De façon globale, que la commande « aaa bbb ccc » soit au niveau de privilège x suppose que la commande « aaa bbb » le soit également.

2. Qu’estce que l’authentification ?

Pour mémoire, l’identification répond à la question « qui estil ? ». Pour éviter que la question ne se transforme en « Qui prétendil être ? », il faut accompagner l’identification d’une authentification qui répond à la question « Estce bien lui ? ». Le nom d’utilisateur est nécessairement accompagné d’un mot de passe, qui joue le rôle de preuve visàvis de l’identité numérique.

Malgré nos efforts, la sécurité mise en place jusqu’à présent est somme toute assez limitée. Il y manque précisément un aspect essentiel : l’authentification. Les mots de passe affectés aux lignes ainsi qu’au passage vers le mode privilégié doivent être confiés à toute personne appelée à intervenir sur l’équipement. Si l’administrateur décide de mettre en place un serveur SYSLOG en vue de collecter les évènements qui affectent le routeur, chaque évènement provoqué par un intervenant reste anonyme dans le journal d’évènements. Les messages se bornent à restituer quelle est la ligne qui a servi à l’intervenant. C’est ainsi que jusqu’à présent, nous avons dû nous contenter des messages console de ce type :

*Nov 6 19:13:43.115: %SYS-5-CONFIG_I: Configured from console by vty0(172.31.1.104) *Nov 6 20:04:19.271: %SYS-5-CONFIG_I: Configured from console by console

Les hommes n’étant que des hommes, l’anonymat déresponsabilise, une réelle politique de sécurité doit à minima attribuer à chaque utilisateur un ensemble [identifiant / mot de passe]. Bien sûr, l’IOS offre cette possibilité et propose à l’administrateur deux alternatives :

1. Gérer les identifiants localement. Ces identifiants sont stockés dans les fichiers de configuration du routeur. L’inconvénient est que la procédure doit être répétée autant de fois que le réseau comporte de routeurs. Imaginez la



somme de travail que peut représenter le simple ajout d’un utilisateur ou le changement de mot de passe pour un utilisateur existant.

2. Gérer les identifiants de façon centralisée sur un ou plusieurs serveurs. L’IOS supporte deux technologies, l’une normalisée par l’IETF est RADIUS (Remote Authentication DialIn User Service), l’autre propriétaire est TACACS+ (Terminal Access Controller AccessControl System Plus).

a. Le modèle AAA

Authentifier un utilisateur sur le réseau n’est pas suffisant. La question globale ne peut se résumer à « Qui ? » mais doit être « Qui peut faire quoi, quand l’atil fait et pendant combien de temps ? ». CISCO prend en compte ces trois questions, qui, quoi, quand en proposant un modèle de sécurité baptisé AAA (Authentication, Authorization, Accounting/Auditing) :

Authentication : c’est le préalable incontournable car autoriser un utilisateur à entreprendre une action ou profiter d’un service suppose d’être certain de son identité. De la même façon, il ne servirait à rien d’enregistrer les faits et gestes d’un utilisateur dans un journal si un doute pesait sur son identité. Le modèle AAA identifie un certain nombre de méthodes d’authentification. L’administrateur crée des listes nommées dans lesquelles il place la ou les différentes méthodes qu’il souhaite utiliser. Il reste ensuite à appliquer la liste convenable à une ou plusieurs interfaces du routeur. L’IOS appliquera la première méthode à l’interface puis la seconde si la première échoue et ainsi de suite.

Authorization : autoriser devrait être traduit par contrôler l’accès, c’estàdire autoriser un utilisateur à accéder à une entité ou un service, de façon plus ou moins partielle ou complète, le niveau d’accès étant modulé selon le niveau de privilège du demandeur. Exemples d’autorisations : affectation d’une adresse IP, restriction d’accès selon l’heure du jour, temps de connexion maximal, qualité de service, bande passante...

Accounting : il s’agit ici de rendre traçable les faits et gestes de l’utilisateur, les objectifs sont multiples, ce peut être d’atteindre la nonrépudiation, c’estàdire l’incapacité pour un utilisateur de nier une action qu’il a effectuée, ce peut être également le souhait de comptabiliser des temps d’accès ou des volumes échangés dans un but de facturation (billing).

3. Méthode d’authentification locale

Nantes(config)#username ycousin password sangria Nantes(config)#username avaucamps password fantasia Nantes(config)#aaa new-model Nantes(config)#aaa authentication login auth_locale local Nantes(config)#^Z Nantes#

En mode de configuration globale, la commande aaa newmodel établit l’authentification selon le modèle AAA sur le routeur Nantes. La commande aaa authentication login crée la liste nommée auth_locale. Cette liste ne comporte qu’une seule méthode d’authentification appelée local. La méthode d’authentification locale s’appuie sur la base de comptes locale pour assurer sa fonction.

Attention ici au risque d’étreinte fatale. De façon générale, être victime d’une étreinte fatale, c’est avoir verrouillé un mécanisme sans possibilité de le déverrouiller. Exemple d’étreinte fatale : j’oublie les clés de ma voiture dans le coffre puis machinalement, je referme le coffre alors que ma voiture est déjà verrouillée. Dans le cas présent, l’étreinte fatale consisterait à entrer la commande de configuration globale aaa newmodel sans avoir au préalable créé de compte utilisateur à l’aide de la commande username. Puis par maladresse ou par accident, à mettre fin à la session en cours. Peutêtre estil prudent lors de ce délicat passage au modèle aaa, d’ouvrir deux sessions d’interface ILC. Ainsi, si par



erreur l’administrateur provoque un verrouillage lors de ses essais sur la session 1, il peut rétablir la situation à l’aide de la session 2. En dernier recours, il reste la possibilité d’entamer une procédure de recouvrement de mot de passe.

Observez l’effet de la commande aaa authentication login qui contraint l’IOS à effectuer une double demande nom d’utilisateur puis mot de passe lors de l’ouverture de session via une ligne vty. La commande show user permet d’afficher les sessions actives sur le routeur Nantes. La session accompagnée d’une étoile est celle depuis laquelle on a entré cette commande.

Nous nous étions plaints de l’anonymat qui régnait dans les évènements rapportés par les messages console. Désormais, cet anonymat n’existe plus, ce que confirme l’observation des quelques messages console cidessous :

Depuis la version 12.0(18)S de l’IOS, il existe une version encryptée de la commande username :

Une commande show run confirme le cryptage obtenu :

! username ycousin secret 5 $1$TKN1$7EpYz5pTBLW.0B9nKo71/0 username avaucamps secret 5 $1$WGjm$XRCQXBc0GYi1gbxPJmhqr1 !

Tout comme pour la commande enable secret, c’est l’algorithme MD5 qui est utilisé. À nouveau, les recommandations de longueur et de complexité s’appliquent. Dans l’exemple qui précède et dans celui qui suit, un administrateur habilité à modifier la configuration du routeur doit saisir un mot de passe deux fois consécutivement : le premier mot de passe est associé à son nom d’ouverture de session, c’est celui de l’authentification, le second mot de passe est nécessaire pour passer au mode privilégié. Avec la mise en place de l’authentification à l’aide du modèle AAA, le mot de passe du passage au mode privilégié ne se justifie plus (ou se justifie moins). Une solution consiste à associer le niveau de privilège 15 à la configuration des lignes vty :



Vérifions le résultat en ouvrant à nouveau une session via Telnet :

Immédiatement après s’être identifié et avoir été authentifié, la session s’ouvre dans le mode privilégié ainsi que le rappelle l’invite de commandes. Une commande sh priv confirme le niveau de privilège en cours.

4. Méthode d’autorisation locale

Très modestement, il s’agit ici de montrer au lecteur ce que peut être l’intérêt du second « A » dans le modèle AAA. Cet exemple crée un utilisateur à seule fin d’exécuter une et une seule commande :

Nantes#conf t Enter configuration commands, one per line. End with CNTL/Z. Nantes(config)#username run nopasswordnoescape Nantes(config)#username run autocommand show ip interface brief Nantes(config)#aaa authorization exec default local Nantes(config)#^Z Nantes#

Pour ce faire, on adjoint à la commande username, le paramètre autocommand qui provoque l’exécution de la commande spécifiée après ce motclé, ce dès la connexion de l’utilisateur désigné, dans le cas présent « run ». Puisqu’une commande est de longueur quelconque et peut comprendre des espaces, la commande spécifiée à l’aide du motclé autocommand doit être la dernière option de la commande username. Le motclé nopassword entraîne que lorsque le nom d’utilisateur est « run », l’IOS ne demande pas de mot de passe. Le motclé noescape évite que l’utilisateur « run » ne puisse revenir au mode utilisateur en tapant la touche [Echap], ce qui lui permettrait ensuite de taper d’autres commandes. Observez également que l’administrateur a utilisé plusieurs instances de la commande username pour spécifier plusieurs options qui concernent le même compte utilisateur « run ».

Une fois la commande spécifiée à l’aide du motclé autocommand exécutée, show ip interface brief dans le cas présent, le routeur met fin à la session. Il faut configurer Putty afin d’éviter qu’il ne ferme la fenêtre dès l’exécution terminée empêchant ainsi la lecture du résultat :



La capture suivante montre le résultat de la connexion avec le nom d’utilisateur « run » :

Opportunément, observez le résultat de la commande show ip interface brief, qu’il est possible d’agréger en sh ip int br : cette commande fournit un résumé qui renseigne sur l’état des interfaces du routeur. Chaque interface est concernée par la couche d’accès du modèle TCP/IP, c’estàdire les couches 1 et 2 du modèle OSIRM. La colonne Status du résumé renseigne sur l’état de la couche physique : dans le cas présent, seule l’interface fa1/0 a été activée par l’administrateur à l’aide de la commande no shutdown, ce qui explique l’état administratively down sur l’interface fa0/0. La colonne Protocol renseigne sur l’état de la couche Liaison. Quand la couche 1 est à l’état down, la couche 2 ne peut que l’être également. Quand la couche 1 est up, la couche 2 est up si le protocole associé a pu établir le lien avec la couche 2 de l’interface en visàvis.

5. Méthode d’authentification RADIUS

Puisque nous sommes déjà largement hors cadre du CCNA, nous nous en tiendrons à ces quelques éléments sur RADIUS, normalisé par l’IETF, et négligerons TACACS+, technologie propriétaire de CISCO. Comme le rappelle son nom (Remote Authentication DialIn User Service), RADIUS a été conçu pour résoudre un problème qui se posait aux fournisseurs d’accès Internet. En effet, les FAI devaient authentifier des utilisateurs distants qui se connectaient par modems via le réseau téléphonique commuté. Les serveurs étaient multiples mais il fallait que la base de comptes d’utilisateurs soit unique. Cette base de comptes doit permettre l’authentification, c’estàdire la vérification des couples nom d’utilisateur/mot de passe mais doit également pouvoir fournir des informations de configuration qui préciseront le type de service dont doit bénéficier l’utilisateur. RADIUS est décrit dans deux RFC :

RFC 2865 RADIUS Juin 2000 → traite de l’authentification ;



RFC 2866 RADIUS Accouting Juin 2000 → traite de la comptabilité et de la journalisation des connexions.

La figure suivante détaille les dispositifs clés d’une architecture RADIUS :

L’usager fait une demande d’ouverture de session sur un serveur d’accès réseau, retenons l’acronyme anglais NAS. Le NAS ne traite pas directement la demande mais la soustraite auprès du serveur RADIUS. Le serveur d’accès réseau est donc client de RADIUS, ce client est chargé de transmettre les informations d’utilisateur à un serveur ou à un groupe de serveurs RADIUS désignés, puis d’agir en fonction de la réponse retournée. Un serveur RADIUS, quand il reçoit une demande de connexion d’usager, demande transmise par un NAS, authentifie l’usager (ou rejette la demande) puis retourne les informations de configuration nécessaires afin que le client livre le service convenable à l’usager.

À aucun moment l’usager ne dialogue directement avec le serveur RADIUS et il peut parfaitement ignorer que son authentification a été prise en charge par ce dernier. Tout équipement réseau susceptible d’ouvrir des sessions peut confier l’authentification mais aussi les autorisations et la comptabilité de connexion à un serveur RADIUS. Il devient alors serveur d’accès NAS et client RADIUS. L’administrateur d’un interréseau composé de plusieurs routeurs peut ainsi centraliser la gestion des identifiants. Si les routeurs de son interréseau proviennent exclusivement de CISCO, alors il peut mettre en place un serveur TACACS+. Dans le cas contraire, un ou plusieurs serveurs RADIUS sont une solution.

RADIUS s’appuie sur le protocole de transport UDP, il y a d’excellentes raisons pour avoir fait ce choix, raisons bien expliquées dans le RFC. La figure suivante détaille le format du paquet RADIUS encapsulé dans le champ de données du datagramme UDP. Les premiers développements de RADIUS utilisaient le numéro de port UDP 1645 mais actuellement, le port officiellement alloué est 1812 :



Le champ Code sur un octet identifie le type de paquet RADIUS.

Le champ Identifiant sur un octet permet de faire correspondre demandes et réponses.La valeur du champ n’est pas modifiée dans le cas d’une retransmission, le serveur RADIUS peut ainsi détecter une demande dupliquée.

Le champ Longueur, sur deux octets, indique la longueur du paquet RADIUS en incluant les champs Code, Identifiant, Longueur, Authentifiant et Attribut. Les octets qui seraient reçus audelà de la longueur indiquée doivent être ignorés à la réception. À l’inverse, si le paquet est plus court qu’indiqué dans le champ Longueur, alors le paquet est éliminé en silence.

L’authentifiant est un élément clé de la sécurité fournie par RADIUS. Le NAS et le serveur RADIUS partagent un secret. Lorsque le client génère une demande d’accès, il génère un nombre aléatoire sur 16 octets (aussi long qu’une adresse IPv6 !) appelé authentifiant de demande et dont la valeur devrait être imprévisible et unique, pendant la durée de vie du secret partagé. En effet, une répétition d’un même authentifiant de demande conjugué à un même secret permettrait à un attaquant de jouer une fausse réponse avec un authentifiant de réponse précédemment intercepté. Le serveur RADIUS qui reçoit une demande génère une réponse (accès accepté, accès rejeté, épreuve d’accès) dans laquelle l’authentifiant de réponse contient un hachage MD5 calculé sur l’ensemble code, identifiant, longueur, authentifiant de demande, attributs, secret partagé.

Le secret partagé doit être aussi long et imprévisible qu’un mot de passe convenablement choisi. Il est conseillé d’adopter une longueur égale au moins à 16 octets.

a. Type de paquet Demande d’accès

La demande d’accès envoyée à un serveur RADIUS porte les informations nécessaires à l’authentification mais aussi les services particuliers demandés pour cet usager. Si le client est valide, le serveur doit répondre. La demande d’accès devrait contenir l’attribut nom d’utilisateur (Type 1) et doit contenir l’attribut Adresse IP de NAS (Attribut type 4) ou l’attribut Identifiant de NAS (Attribut type 32) ou les deux. La demande d’accès doit également contenir un mot de passe utilisateur (Attribut type 2) ou un mot de passe CHAP (ChallengeHandshake Authentification Protocol) (Attribut type 3). Quand le NAS distingue ses différents accès, la demande d’accès devrait contenir l’attribut Ligne d’accès de NAS (type 5) ou l’attribut Type d’accès de NAS (type 61) ou les deux. Lorsque le mot de passe est présent, il est crypté selon une méthode fondée sur MD5.

b. Type de paquet Accès accepté

L’accès accepté envoyé par le serveur RADIUS fournit les informations spécifiques de configuration dont le NAS a besoin pour débuter la livraison du service à l’usager. Quand toutes les valeurs d’attributs reçues dans une demande d’accès sont acceptables, le serveur RADIUS doit transmettre ce paquet dont la valeur Code est



positionnée à 2 (Accès accepté).

6. Atelier RADIUS

Notre objectif n’est évidemment pas de construire un serveur RADIUS d’envergure mais d’observer comment configurer le routeur pour que, dans le cadre du modèle AAA, il fasse appel à un serveur RADIUS quand il doit authentifier un administrateur qui souhaite ouvrir une session. S’il fallait progresser dans le domaine des serveurs RADIUS, le lecteur pourrait se reporter sur le site :

http://freeradius.org

Mais pour cet atelier, l’auteur propose une alternative bien plus abordable nommée RADL :

http://www.loriotpro.com/Products/RadiusServer/FreeRadiusServer_EN.php

Toujours en s’aidant de VMware et de GNS3, l’auteur vous propose de reproduire l’atelier suivant :

Effectuez un « snapshot » (une photographie instantanée) de vos machines virtuelles avant toute installation. Ainsi, il est facile de restaurer l’état antérieur.

Téléchargez le logiciel RADL (radlv150ab.exe, 218 Ko au moment où ces lignes sont écrites) et installezle sur la machine virtuelle VMWKS01 qui fera office de serveur RADIUS.

Une fois RADL lancé, configurez le serveur conformément à la capture cidessous :



S’il fallait revenir aux numéros de ports officiels qui sont 1812 et 1813, il serait facile de le faire ici. Patientons jusqu’à avoir configuré le routeur.

Toujours dans RADL, configurez le client conformément à la capture cidessous :

Le serveur RADIUS connaît désormais l’adresse IP du NAS 172.31.1.1 et le secret à partager avec lui : « macleradius ».

Pour en finir avec la configuration de RADIUS, ajoutez à la base de comptes, l’usager « ycousin », mot de passe « sangria » conformément à la capture cidessous :

Évidemment, cette configuration est très sommaire, RADL est capable de faire plus mais ce n’est pas l’objet de cet atelier.

Ouvrez une session console sur le routeur Nantes puis entrez la séquence de commandes suivante :



La commande aaa newmodel n’est peutêtre pas utile si le modèle AAA a déjà été activé au cours d’un atelier précédent mais entrer à nouveau une commande déjà présente dans le fichier de configuration est sans conséquence.

La commande aaa authentication login crée une liste de méthodes d’authentification nommée liste_eni et place dans cette liste les deux méthodes radius et local. Ainsi lors d’une ouverture de session, si le ou les serveurs radius sont injoignables, l’IOS tente une authentification avec la seconde méthode de la liste. La méthode locale est celle qui fait appel à la base de comptes locale, c’estàdire la base de comptes alimentée à l’aide des commandes username. La liste de méthode peut comprendre jusqu’à quatre méthodes d’authentification, on pourrait ajouter la méthode enable qui utilise le mot de passe associé au passage en mode privilégié s’il existe et/ou la méthode none qui autorisera l’accès sans authentification.

La commande radiusserver host informe l’IOS de l’existence d’un serveur radius à l’adresse 172.31.1.101.

La commande radiusserver key configure le secret partagé. Dans cet exemple, il n’est ni suffisamment long, ni suffisamment complexe.

Il reste à affecter la liste de méthodes d’authentification à une ou plusieurs lignes, c’est l’objet de la commande login authentication en sousmode de configuration de lignes vty.

Une commande show runningconfig (extrait) confirme le résultat obtenu :

! aaa authentication login liste_eni group radius local ! usernameycousin secret 5 $1$TKN1$7EpYz5pTBLW.0B9nKo71/0 usernameavaucamps secret 5 $1$vy6K$arNsNrc9CZ.LtEvf0jzSJ. ! radius-server host 172.31.1.101 auth-port 1645 acct-port 1646 radius-server key macleradius ! Linevty 0 4 privilege level 15 login authentication liste_eni ! end

Observez que l’IOS a complété la ligne de commande radiusserver host en ajoutant les numéros de ports UDP qu’il utilisera pour joindre le service authentification du serveur RADIUS (port 1645) et pour joindre le service de comptage (Accounting, port 1646). Nous aurions donc pu compléter la commande et entrer ces paramètres s’il avait fallu imposer les ports UDP 1812 et 1813. Mais dans le cas présent, nous pouvons en rester là car cette configuration est également celle de notre serveur RADL.

Observez que l’IOS a ajouté le motclé group devant la méthode radius. Cela signifie que la méthode utilisera l’ensemble des serveurs RADIUS déclarés dans le fichier de configuration pour authentifier. Une autre façon de procéder aurait été de créer un groupe de serveurs RADIUS, groupe nommé :



L’exemple cidessus crée le groupe de serveurs RADIUS nommé grp_radius puis utilise ce groupe dans la liste de méthodes d’authentification nommée liste_eni. Il est temps de vérifier que l’authentification selon la méthode RADIUS fonctionne :

Si Wireshark est installé sur l’une des machines virtuelles, lancezle puis démarrez une capture.

Revenez à la machine hôte puis démarrez une session Telnet 172.31.1.1 à l’aide de PuTTY :

Stoppez puis analysez la capture Wireshark (cette capture cap_2L_01.pcap est disponible en téléchargement sur le site des Editions ENI) :



À l’aide du format de paquet RADIUS fourni précédemment, portez notamment votre attention sur le paquet de demande d’accès en trame n°94.

Cet atelier est maintenant terminé.



Journalisation, le protocole SYSLOG

RFC utiles :

RFC 5424 The Syslog Protocol mars 2009 ;

RFC 5425 Transport Layer Security (TLS) Transport Mapping for Syslog mars 2009 ;

RFC 5426 Transmission of Syslog Messages over UDP mars 2009.

Parmi les multiples tâches accomplies par l’IOS, l’une d’elles intéresse particulièrement l’administrateur parce qu’elle lui permet de découvrir ou mieux comprendre les évènements qui affectent le fonctionnement du routeur et donc du réseau. Il s’agit de l’activité de journalisation des évènements. En la matière, CISCO comme une majorité de constructeurs se conforme au protocole SYSLOG normalisé dans le RFC 5424. Par défaut, la manifestation de SYSLOG sur un routeur se limite à l’émission des messages d’évènements vers le port console. Quel administrateur au cours de son travail depuis la console n’a pas été agacé par l’arrivée impromptue de ces messages qui viennent perturber la saisie en cours ? Problème facile à résoudre d’ailleurs car il existe une commande de configuration de ligne logging synchronous qui peut être appliquée à la console ainsi qu’aux lignes vty et qui modifie le comportement de l’IOS quand il envoie un message : si une commande est en cours de saisie, alors l’IOS réaffiche le contenu de la ligne saisie dans l’état où elle se trouvait immédiatement avant l’envoi du message.

L’IOS génère des messages SYSLOG liés à son activité de façon naturelle mais l’administrateur peut susciter une production beaucoup plus intense de ces messages lorsqu’il provoque une commande debug. Cette commande constitue l’un des outils majeurs dans la résolution de problèmes sur un routeur et dispose d’options pléthoriques qui permettent d’ajuster le résultat selon le type d’activité à surveiller. À ce sujet, rappelons qu’il faut être prudent car certaines options peuvent entraîner une production de messages telle qu’elle consomme la majeure partie des ressources processeur de la machine empêchant le routeur d’accomplir sa tâche normale.

La commande undebug all ou no debug all désactive toutes les commandes debug qui seraient en cours de traitement. Une mesure sage consiste à entrer cette commande de façon systématique avant d’entrer une quelconque commande debug. La

commande undebug all se trouve alors dans l’historique de commandes et il suffit d’une action sur la touche [Flèche en haut] puis de valider par la touche [Entrée] pour la provoquer. L’administrateur peut ainsi espérer arrêter une commande debug malheureuse même avec un processeur « noyé ».

La figure ciaprès résume les cinq flux possibles de messages SYSLOG :

Par défaut, l’IOS envoie l’ensemble des messages sur le port console, ce qui correspond à la commande console logging.

Depuis le mode privilégié, la commande Terminal monitor provoque l’affichage des messages SYSLOG, messages debug compris, sur la session en cours. Cette commande est utile pour obtenir les messages depuis une session ouverte via une ligne vty. Puisqu’il ne s’agit pas d’une commande de configuration, cette commande n’est pas mémorisée et son effet cesse lorsque la session prend fin (ceci est vrai pour toutes les commandes Terminal).

Plus intéressante encore est cette faculté qui consiste à mémoriser les messages dans un tampon, ce qui permet à l’administrateur de les consulter quand bon lui semble à l’aide d’une commande show logging. Le tampon, créé par la commande de configuration globale logging buffered, est circulaire, les évènements les plus récents remplacent les plus anciens. La commande admet deux paramètres importants :

Il est possible de préciser la taille du tampon de 4096 à 2 147 483 647 octets, la taille par défaut dépend de la plate


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA/NDAwODk1IC0gRk9STUFUSU9OUyBBRklQIC0gYTVkMjI0NzgtZTdhYi00MmJkLTk1MTUtNTk5OWE1ZDMyYzczpiwbJR9AzYgLAA==-enidentnumber

forme. Entrer la commande default logging buffered pour revenir à la taille par défaut. 4000 octets permettent de mémoriser environ 50 messages. Un dimensionnement à 16000 octets et donc la possibilité de mémoriser 200 messages semble un bon compromis, attention à ne pas approcher les limites de la plateforme ce que l’administrateur pourra vérifier à l’aide d’une commande show memory.

Il est possible de filtrer les évènements mémorisés dans le tampon selon un critère de sévérité. En la matière, les messages d’avertissement CISCO IOS se conforment au RFC 5424 qui établit huit niveaux de sévérité de 0 à 7, la gravité croît quand le niveau de sévérité diminue, il est quasi impossible d’obtenir un message de sévérité 0 puisque ce niveau correspond à un système inexploitable. Le tableau cidessous répertorie les niveaux de sévérité :

Exemple : la commande logging buffered 16384 critical entraîne que seuls les évènements de sévérité 0, 1 et 2 sont mémorisés dans le tampon fixé ici à 16 Ko.

De la même manière que nous avions souhaité centraliser la gestion des comptes utilisateur avec la méthode RADIUS, il peut être intéressant de centraliser la gestion des messages SYSLOG. Un serveur SYSLOG mémorise sur des supports disques, d’importantes quantités d’évènements en provenance d’équipements très différents pourvu qu’ils se conforment au RFC 5424(*). Les avantages sont nombreux : les historiques peuvent remonter sur de longues périodes ; en évitant d’emprunter de la mémoire vive pour stocker les messages, on ne pénalise pas le fonctionnement des équipements ; il devient possible de filtrer les évènements de façon fine selon différents critères de date, de sévérité, de type… Le protocole SYSLOG s’appuie sur le protocole de transport UDP, le serveur SYSLOG est à l’écoute sur le port UDP 514, il n’existe pas d’acquittements de messages SYSLOG. Une commande de configuration globale logging host @IP_serveur_syslog provoque l’envoi des messages vers le serveur dont l’adresse IP est @IP_serveur_syslog. L’atelier SYSLOG proposé dans ce chapitre fournira l’occasion de tester une mise en œuvre mais la commande logging host admet de nombreux paramètres et il est préférable de se reporter à l’outil « Command Lookup Tool » de CISCO pour des mises en œuvre plus complexes de cette commande.

Pour être complet, citons la possibilité d’émettre les messages SYSLOG sous forme d’interceptions SNMP (SNMP traps) à une station d’administration SNMP. La commande snmpserver enable traps indique à l’IOS de transmettre les interceptions SNMP, notifications SYSLOG incluses, à condition bien sûr que SNMP ait été configuré au préalable.

(*) À ce sujet, il faut se rappeler que la loi sur la sécurité quotidienne, dite LSQ et promulguée le 26 mars 2006, comporte entre autres obligations, celle faite aux opérateurs de communications électroniques (dont les FAI) de conserver pendant un an les activités de leurs clients. Ceci comprend l’identification de l’utilisateur du service et du terminal utilisé, les destinataires de la communication, la date, l’heure ainsi que les services complémentaires utilisés et leurs fournisseurs.

1. Atelier SYSLOG

Pour cet atelier, l’auteur propose de mettre à profit la plateforme créée pour tester les listes étendues du chapitre précédent :

Niveau Motclé Objet

0 emergencies System isunusable Système inexploitable.

1 alerts Action must be taken immediately Il faut agir sans tarder.

2 critical Critical conditions Contexte critique.

3 errors Error conditions Erreurs.

4 warnings Warning conditions Avertissements.

5 notifications Normal but significant condition Événement normal mais important.

6 informational Informational messages Information.

7 debugging Debuglevel messages Messages résultant d’une commande debug.



Objectifs

Installer le serveur SYSLOG sur la machine VMSRV01 ;

Configurer les routeurs R100m et R120m afin de centraliser les messages SYSLOG des deux routeurs sur le serveur SYSLOG :

Le routeur R100m enverra les messages SYSLOG à l’aide du protocole de transport par défaut, soit UDP, port 514.

Le routeur R120m enverra les messages SYSLOG comme le ferait un boîtier PIX de Cisco (Private Internet eXchange, le boîtier parefeu de CISCO), c’estàdire à l’aide du protocole de transport TCP sur le port 1468.

Les messages DEBUG devraient être exclus des messages SYSLOG enregistrés sur le serveur.

Étape 1 : installation du serveur SYSLOG

Téléchargez la version gratuite ou mieux la version d’évaluation de Kiwi SYSLOG qui pendant 30 jours offre les fonctionnalités de la version payante puis bascule sur les fonctionnalités de la version gratuite. Au moment où ces lignes sont écrites, la version 9 est disponible, le fichier à télécharger occupe 28784 Ko. Rendezvous sur le site de l’éditeur : http://www.kiwisyslog.com/

Par tout moyen à votre convenance, transférez le fichier d’installation sur la machine virtuelle VMSRV01. Exemple : par les fonctionnalités « Shared Folders » de Vmware.

Installez Kiwi SYSLOG. Le programme d’installation propose d’installer le logiciel en tant que service ou en tant que programme. Pour une installation qui viserait à créer un serveur de production, l’administrateur devrait préférer l’installation en tant que service. Mais pour notre éphémère atelier, une installation en tant que programme convient parfaitement.

Lancez Kiwi SYSLOG puis configurezle de façon à ce qu’il soit à l’écoute des messages sur :

l’adresse 10.0.8.1 et le port UDP 514 ;

l’adresse 10.0.8.1 et le port TCP 1468.



Étape 2 : configuration de R100m

Vérifiez qu’aucune liste de contrôle d’accès n’est appliquée sur l’interface f0/1 du routeur R100m :

R100m#sh run Building configuration... ......... ! interface FastEthernet0/1 ip address 10.0.8.254 255.255.255.0 duplex auto speed auto ......... R100m#

Provoquez l’émission des messages SYSLOG vers le serveur :

R100m#conf t Enter configuration commands, one per line. End with CNTL/Z. R100m(config)#logging ? Hostname or A.B.C.D IP address of the logging host ......... R100m(config)#logging host ? Hostname or A.B.C.D IP address of the syslog server R100m(config)#logging host 10.0.8.1 ? filtered Enable filtered logging transport Specify the transport protocol (default=UDP) vrf Set VRF option xml Enable logging in XML <cr> R100m(config)#logging host 10.0.8.1 transport ? tcp Transport Control Portocol udp User Datagram Protocol R100m(config)#logging host 10.0.8.1 transport udp ? filtered Enable filtered logging port Specify the UDP port number (default=514) xml Enable logging in XML



<cr> R100m(config)#logging host 10.0.8.1 transport udp port ? <1-65535> Port number R100m(config)#logging host 10.0.8.1 transport udp port 514 ? filtered Enable filtered logging xml Enable logging in XML <cr> R100m(config)#logging host 10.0.8.1 transport udp port 514

Réglez le niveau de sévérité pour que seuls les messages de 0 à 6 soient envoyés au serveur :

R100m(config)#logging trap ? <0-7> Logging severity level alerts Immediate action needed (severity=1) criticalCritical conditions (severity=2) debuggingDebugging messages (severity=7) emergencies System is unusable (severity=0) errors Error conditions (severity=3) informational Informational messages (severity=6) notifications Normal but significant conditions (severity=5) warnings Warning conditions (severity=4) <cr> R100m(config)#logging trap 6

R100m(config)#^Z R100m#

Étape 3 : configuration de R120m

Cette fois, imposez le transport via TCP :

R120m(config)#logging host 10.0.8.1 transport ? tcp Transport Control Portocol udp User Datagram Protocol R120m(config)#logging host 10.0.8.1 transport tcp port ? <1-65535> Port number R120m(config)#logging host 10.0.8.1 transport tcp port 1468

R120m(config)#logging trap 6 R120m(config)#^Z R120m#

Étape 4 : test

Provoquez sur chacun des routeurs quelques évènements générant des messages SYSLOG. Exemples :

Entrez en mode de configuration puis revenez au mode privilégié.

Effacez les compteurs (commande clear counters).

Ajoutez l’option log à quelques éléments de listes d’accès puis provoquez du trafic afin de solliciter les listes d’accès.

Vous devriez observer ces différents évènements collectés par Kiwi. L’écran pourrait alors ressembler à la capture suivante :



L’outil serveur Kiwi recèle sans doute des trésors d’ingéniosité pour extraire l’information utile des messages bruts SYSLOG. Mais leur découverte sort du cadre de l’ouvrage et de plus, nul doute que l’outil qui semble d’utilisation très intuitive se laissera prendre en main sans autre assistance que l’aide intégrée.




Adoptez SSH

1. Contexte

Quelques RFC utiles autour de SSH :

RFC 4250 The Secure Shell (SSH) Protocol Assigned Numbers Janvier 2006 ;

RFC 4251 The Secure Shell (SSH) Protocol Architecture Janvier 2006 ;

RFC 4252 The Secure Shell (SSH) Authentication Protocol Janvier 2006 ;

RFC 4253 The Secure Shell (SSH) Transport Layer Protocol Janvier 2006 ;

RFC 4254 The Secure Shell (SSH) Connection Protocol Janvier 2006 ;

RFC 4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints Janvier 2006 ;

RFC 4256 Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) Janvier 2006 ;

RFC 4335 The Secure Shell (SSH) Session Channel Break Extension Janvier 2006 ;

RFC 4344 Secure Shell (SSH) Transport Layer Encryption Modes Janvier 2006 ;

RFC 4345 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol Janvier 2006 ;

RFC 4419 DiffieHellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol Mars 2006 ;

RFC 4432 RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol Mars 2006 ;

RFC 4716 The Secure Shell (SSH) Public Key File Format Novembre 2006 ;

Le RFC 4253 est disponible en français sur le site http://abcdrfc.free.fr/.

SSH et TLS (Transport Layer Security) sont deux protocoles qui proposent une réponse au manque de sécurité des protocoles de communication de l’Internet. Ils intercalent une couche de sécurité entre TCP et les protocoles applicatifs. SSH permet, entre autres, l’administration de machines à distance tandis que TLS est plus généralement chargé de sécuriser les échanges dans un contexte Web ou mail.

Telnet (Teletype Network) est l’application historique de la pile TCP/IP qui permet la prise de main à distance. Hélas, les échanges de Telnet se font en clair et l’absence totale de sécurité d’une telle prise de main est devenue quasirédhibitoire. Secure Shell (SSH) offre une solution alternative dont l’usage est appelé à s’étendre depuis son adoption par l’IETF.

La première version de SSH (désormais appelée SSH1) date de 1995 et on la doit à M. Tatu Ylönen, chercheur de l’université d’Helsinki. Pour l’anecdote, M. Ylönen avait dû faire face à une attaque type découverte de mot de passe par sniffer. M. Ylönen a ensuite fondé sa société SSH communications Security dans le but de développer et commercialiser SSH.

En janvier 2006, le groupe de travail « secsh » de l’IETF a publié le standard SSH2 Cette version est compatible avec les premières implémentations fondées sur le brouillon (draft) de SSH2. M. Ylönen fait partie des auteurs des RFC 4251 à 4254.

Attention, cet ouvrage n’est ni dédié à la sécurité, ni dédié à l’étude du protocole SSH. Un ouvrage entier ne suffirait pas à couvrir ces deux sujets. Soyons pragmatiques et limitons notre ambition à la mise en œuvre de SSH sur nos platesformes CISCO afin qu’il puisse se substituer à Telnet.

2. Les bases du chiffrement

Un texte lisible et compréhensible sans intervention particulière est un texte en clair. Le chiffrement est la méthode


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA/NDAwODk1IC0gRk9STUFUSU9OUyBBRklQIC0gYTVkMjI0NzgtZTdhYi00MmJkLTk1MTUtNTk5OWE1ZDMyYzczU/qbLR9AzYgLAA==-enidentnumber

permettant de transformer ce texte en clair en charabia inintelligible que l’on appelle texte chiffré. Seules les personnes auxquelles le message est destiné doivent pouvoir réaliser l’opération inverse, le retour au texte d’origine, c’estàdire le déchiffrement. L’auteur confesse une approximation commise dans l’ouvrage précédent Cisco Notions de base sur les réseaux dans la collection Certifications aux Editions ENI qui consiste à confondre décryptage et déchiffrement. Les définitions suivantes ont été extraites du site http://www.larousse.fr/dictionnaires/francais/ :

Chiffrer : transformer un message par un procédé de chiffrement.

Chiffrement : opération qui consiste à transformer un message à transmettre, dit « message clair », en un autre message, inintelligible pour un tiers, dit « message chiffré », en vue d’assurer le secret de sa transmission.

Déchiffrer : rétablir dans sa forme primitive un texte chiffré en utilisant en sens inverse le procédé de transformation adopté par le chiffreur et connu du déchiffreur.

Décrypter : retrouver le sens clair d’un message chiffré en écriture secrète, sans connaître la clef ayant servi à le transcrire.

a. Les objectifs du chiffrement

Par essence, les informations mises à disposition sur Internet sont publiques (si elles ne le sont pas, leur publication est illégale). La communication entre un navigateur et l’un des sites qui met ces informations à disposition n’a pas besoin d’être sécurisée. Posezvous la question : quelles informations ou quels échanges méritent d’être sécurisés ?

La première réponse qui vient spontanément est la sécurisation des transactions commerciales. Valider un achat sur un site de ecommerce suppose que l’acheteur envoie en ligne des informations bancaires (numéro de carte de crédit, date de fin de validité...). Imaginez le désastre si un pirate parvient à récupérer ces informations en « écoutant » le réseau. Pour ce qui nous concerne, les échanges avec nos matériels réseaux en vue de les administrer méritent autant de vigilance. Imaginez à nouveau la catastrophe si un pirate parvenait à prendre la main sur un ou plusieurs de nos routeurs pour ensuite refaire une configuration sur mesures.

Notre belle époque voit une bonne partie d’experts informaticiens ou mathématiciens qui s’ingénient à proposer des solutions de chiffrement de plus en plus élaborées pendant qu’une autre partie s’ingénie à trouver des failles dans les dispositifs mis en place, motivés par l’argent, le goût de détruire ou la vanité, chaque pirate se prenant pour un petit génie injustement méconnu.

Le chiffrement poursuit quatre objectifs essentiels :

L’usurpation d’identité est une technique très accessible et donc très appréciée des pirates. Les outils sont légion qui permettent d’écouter le réseau puis d’usurper l’identité d’une machine, d’un service réseau, le plus grave étant naturellement d’usurper l’identité d’une personne. L’authentification, c’est être sûr de l’identité de celui avec qui on s’apprête à communiquer et d’avoir pu le rassurer sur notre propre identité. Une authentification réussie repose sur le chiffrement des informations sensibles nécessaires à sa réalisation, par exemple les mots de passe.

Attention au risque de confusion. L’intégrité dont nous avons parlé jusqu’à présent garantissait qu’un flux de données reçu était identique au flux de données émis. Cette garantie est obtenue en ajoutant de la redondance à l’information transportée. Pour mémoire :

L’émetteur (la source) segmente le flux de bits en séquences de bits.

À chaque séquence, l’émetteur ajoute de la redondance, c’estàdire un certain nombre de bits calculés à partir de la séquence de bits d’information.

L’émetteur expédie le nouveau tronçon ainsi constitué (bits d’information + bits de redondance).

Le récepteur (le puits) reçoit le tronçon et à partir des bits d’information tels qu’il les perçoit calcule les bits de redondance tels qu’ils devraient être.

Le récepteur (le puits) compare les bits de redondance tels qu’il les a calculés avec les bits de redondance qu’il a reçus. Si les deux séquences de redondance sont identiques, le message est intègre.

Cette intégrité est suffisante pour protéger des altérations que peut engendrer le transport de l’information mais ne l’est plus face au piratage. Dans la séquence décrite cidessus, rien n’interdit à un pirate de modifier le contenu de

L’authentification

L’intégrité



l’information puis de calculer la séquence de redondance adéquate. L’intégrité assurée par le chiffrement va bien audelà en garantissant que le fichier reçu est bien tel qu’il était lorsque son auteur l’a engendré et qu’aucune modification n’a été effectuée par une tierce personne. On peut raisonner par couches : l’intégrité assurée par TCP est une intégrité de couche 4. L’intégrité assurée par le chiffrement est une intégrité de couche 6 (couche Présentation).

L’intégrité assurée par le chiffrement pourrait être particulièrement utile dans la lutte contre les virus. S’il est possible de garantir l’origine et l’intégrité d’un fichier, l’utilisation d’un logiciel antivirus est sans objet. Un fichier ayant fait l’objet d’un chiffrement est un fichier signé, l’utilisation de fichiers signés est certainement appelée à s’étendre.

On le sait, impossible de faire confiance à notre infrastructure réseau en imaginant ne pouvoir être écouté. Puisqu’on ne peut empêcher l’écoute frauduleuse, rendonsla sans intérêt en chiffrant les informations transportées.

Si l’authentification avait répondu à la question : « mon destinataire estil bien celui qu’il prétend être ? », la signature répond à la question « l’auteur ou l’expéditeur de ce message ou de ce document estil bien celui annoncé ? Le chiffrement est mis à profit par la signature électronique de documents afin de garantir formellement l’identité de l’expéditeur ou de l’auteur.

Il arrive que la sensibilité du message luimême ne justifie pas vraiment un chiffrement. Mais le destinataire peut vouloir la garantie que les données sont distribuées dans leur forme originale et qu’elles n’ont pas été envoyées par un imposteur. Et si ces deux garanties sont obtenues, on obtient naturellement une caractéristique importante dite de « nonrépudiation ». Puisqu’on est certain de l’identité de l’expéditeur et du contenu de son message, impossible pour lui de nier en être l’auteur. La nonrépudiation, c’est redonner du sens au mot engagement, le contraire de l’anonymat.

Exemple de secteur où l’usage de la signature électronique apporterait un bénéfice indéniable : celui du courrier électronique à l’heure où nos boîtes à courrier sont inondées de courriers non sollicités (Spam). Un premier pas vers le règlement de ce problème serait de généraliser la signature électronique puis de refuser les courriers anonymes.

b. Les algorithmes de chiffrement

Également appelé chiffrement à clé secrète, le chiffrement symétrique utilise une seule clé pour chiffrer et déchiffrer les données. Les deux parties doivent donc partager la clé et c’est bien là le point faible du dispositif car à un moment donné, les deux correspondants vont devoir s’échanger la clé, par un moyen sûr de préférence.

L’intérêt du chiffrement symétrique réside dans le fait qu’il est peu consommateur de ressources et qu’il s’exécute rapidement. Son inconvénient est que chaque nouvelle paire de correspondants nécessite une nouvelle clé et que rapidement un matériel réseau peut avoir à gérer un grand nombre de clés. Sa robustesse est évidemment liée à sa longueur, un second point faible du dispositif. Claude Shannon a démontré dans les années 1980 que pour que cette méthode de chiffrement soit totalement sûre, il faudrait que la longueur de clé utilisée soit au moins égale à la longueur du message à encoder. Sans aller jusquelà, une méthode mise à profit par la version 2 de SSH consiste à changer de clé symétrique (la clé de session, patientez) de façon régulière par exemple après une heure d’utilisation ou 1 Mo de données échangées. Nous sommes sur un milieu mouvant et une longueur donnée est liée à un stade de technologie donné. Si l’évolution des processeurs et mémoires est modélisable à l’aide de la fameuse loi de Moore, il est probable que l’évolution de la longueur des clés de chiffrement suit une progression semblable.

Quelques exemples d’algorithmes de chiffrement symétrique d’usage courant à l’heure où ces lignes sont écrites :

DES (Data Encryption Standard) → issu d’un logiciel d’IBM nommé Lucifer et modifié par la NSA (National Security Agency), organisme gouvernemental américain, DES fut publié en 1977. Il manipule des clés de 56 bits.

La confidentialité

Signature électronique

Chiffrement symétrique



3DES (ou Triple DES) enchaîne trois applications successives de DES avec deux ou trois clés différentes. Quel que soit le nombre de clés différentes utilisées, la longueur effective de clé et donc la robustesse du chiffrement est de 112 bits.

RC2 (RivestCipher) → conçu par Ronald Rivest en 1987. Développement financé par l’éditeur Lotus qui avait besoin d’un chiffrement personnalisé pour son produit de messagerie Lotus Notes. Longueur de clé 64 bits.

RC4 → clé de taille variable de 40 à 256 bits.

RC5 → clé de taille variable jusqu’à 2048 bits.

IDEA (International Data Encryption Algorithm) → clé de 128 bits.

Blowfish → conçu par Bruce Schneier en 1993. Clé de taille variable de 32 à 448 bits. Cinq fois plus rapide que Triple DES, demeure très solide, la version complète n’ayant à ce jour pas montré de faille. Utilisé dans de nombreux logiciels dont des logiciels du monde libre (notamment OpenSSH).

AES (Advanced Encryption Standard) → choisi en novembre 2000 par le NIST (National Institute of Standards and Technology) pour devenir le standard de chiffrement du gouvernement des EtatsUnis et donc remplacer DES. AES est issu d’un appel à candidatures lancé en 1977. Le NIST a reçu quinze propositions, RC6 faisait partie des candidats. Le candidat retenu a été conçu par deux cryptologues belges Joan Daemen et Vincent Rijmen. La longueur de clé peut être choisie parmi 128, 192 ou 256 bits.

Également appelé chiffrement à clé publique, un utilisateur qui désire mettre à profit ce chiffrement doit disposer d’un couple de clés composé d’une clé publique et d’une clé privée. Comme son nom l’indique, la clé publique est destinée à être diffusée le plus largement possible tandis que la clé privée doit rester connue de son seul propriétaire. On peut chiffrer les données soit avec la clé publique, soit avec la clé privée :

Les données chiffrées avec la clé publique ne peuvent être déchiffrées qu’avec la clé privée correspondante. Exemple : Brett envoie un message confidentiel à Danny. Brett chiffre le message avec la clé publique de Danny. Danny déchiffre le message avec sa clé privée.

Réciproquement, les données chiffrées avec la clé privée ne peuvent être déchiffrées qu’avec la clé publique. Exemple : Brett souhaite envoyer un message à Danny en lui donnant la certitude qu’il en est bien l’auteur, c’estàdire en signant le message. Brett chiffre le message avec sa clé privée. Si Danny parvient à déchiffrer le message avec la clé publique de Brett, alors Brett est bien l’auteur du message.

Brett souhaite envoyer un message à Danny en signant le document et en garantissant la confidentialité. Brett procède à un double chiffrement : les données sont d’abord chiffrées avec sa clé privée (signature) puis une seconde fois avec la clé publique de Danny (confidentialité).

En théorie, il n’est pas possible de deviner la clé privée à partir de la clé publique. Quelques exemples d’algorithmes de chiffrement à clé asymétrique :

DSA (Digital Signature Algorithm) → standard du NIST quand l’algorithme RSA était encore breveté. DSA peut être utilisé gratuitement.

RSA (du nom de ses auteurs « Rivest, Shamir, Adleman ») → décrit en 1977, protégé par un brevet déposé par le MIT en 1983, brevet qui a expiré le 21 septembre 2000. Certainement le système à clé publique le plus

Chiffrement asymétrique



utilisé, exemples : ecommerce, cartes bancaires, SSH...

C’est entendu, il ne s’agit que de satisfaire, humblement, un peu de curiosité intellectuelle :

Choisir deux nombres premiers très grands p et q (plus de 100 chiffres) ;

Calculer n = p x q, n est le modulo du chiffrement ;

Choisir un nombre e plus petit que n et premier avec (p 1)(q 1). Pour mémoire, un nombre a est premier avec le nombre b si a et b ne partagent aucun facteur premier autre que 1 ;

Calculer d tel que d x e = 1 mod [(p 1) x (q 1)]. d est calculé à l’aide de l’algorithme dit d’Euclide étendu. Cet algorithme permet d’exprimer l’inverse d’un nombre modulo n.

d est donc l’inverse de e dans l’arithmétique modulo [(p 1)(q 1)].

La clé publique est donnée par le couple (n, e) et la clé privée est d ;

Découper le message en blocs de longueur identique (200 octets ou plus) ;

Chiffrer en appliquant la formule c = (m)emod n ;

Déchiffrer en appliquant la formule m’ = (c)dmod n = (m)d×emod n = m.

On comprend pourquoi la méthode est coûteuse en ressources machine. Il est difficile de trouver de grands nombres premiers et les opérations dans l’arithmétique modulo n sont difficiles à réaliser. La sécurité de l’algorithme reste assurée tant que :

Les nombres p et q qui ont servi à la génération d’une paire ne sont pas divulgués ;

Factoriser de grands nombres restera une opération difficile ;

Calculer la clé privée d à partir de la clé publique (n, e) restera sans méthode de résolution.

Les tentatives, nombreuses, pour « casser » l’algorithme de chiffrement asymétrique sont pour le moment mises en échec si les clés sont de longueur suffisante. On frémit à l’idée que l’ensemble de la sécurité réseau de la planète repose sur le pari que les choses resteront ainsi.

En termes de consommation de ressources machine, les algorithmes à clé asymétrique sont beaucoup moins performants que leurs homologues à clé symétrique. Les protocoles réseau dont l’objet est la sécurité les utilisent par conséquent dans les phases de négociation et d’authentification préalables à l’établissement d’une connexion sécurisée.

Une fois en accord pour ouvrir un circuit sécurisé, les deux parties mettent à profit la phase chiffrée à l’aide du chiffrement asymétrique pour s’échanger une clé de session qui servira de clé de chiffrement symétrique pour la totalité des échanges dans la suite de la connexion. On peut même imaginer changer de clé de session de façon régulière, les clés périssables expirant après un certain temps d’activité ou un certain volume d’informations transporté.

Les algorithmes de chiffrement décrits empêchent l’écoute frauduleuse mais restent susceptibles aux attaques dites du milieu ou attaques par interception.

Génération des clés RSA

Combinaison asymétriquesymétrique

Attaque « Man in the middle »



Le pirate a intercepté la clé publique du serveur. Il envoie au client sa propre clé publique. Le client utilise ses informations de connexion pour établir une session avec ce qu’il croît être le serveur. Le pirate récupère ces informations qu’il peut déchiffrer avec sa clé privée. Il lui reste à encoder ces informations avec la clé publique du serveur. Le pirate est à la fois client (illégitime) du serveur et serveur (illégitime) du client. Client et serveur croient être directement connectés.

Où est la faille qui a rendu cette attaque possible ?

Le problème naît du fait que le client a accepté la clé publique du pirate comme étant celle du serveur. En fait, la question est « Comment établir la confiance avec un inconnu ? » Une fois de plus, le comportement que nous faisons adopter à nos machines se calque sur nos propres comportements. On aborde que difficilement un inconnu dans la rue. Mais si un tiers de confiance vous présente un inconnu, alors la confiance peut s’établir sans délai et selon la formule « les amis de mes amis sont mes amis ».

L’équivalent du tiers de confiance en matière de réseaux est l’autorité de certification. Cette autorité rend le service attendu en délivrant des certificats. Un certificat de clé publique, généralement appelé simplement un certificat, est un document électronique signé numériquement qui lie la valeur d’une clé publique à l’identité de la personne, de la machine ou du service qui contient la clé privée correspondante.

La plupart des certificats communément utilisés sont basés sur la norme de certificat X.509 v3 :

Un certificat contient les informations suivantes :

La clé publique du sujet.

Des informations identifiant le sujet, par exemple son nom et son adresse de messagerie.

La période de validité (durée pendant laquelle le certificat est valide).

Des informations identifiant l’autorité de certification.

La signature numérique de l’autorité de certification qui atteste de la validité de la liaison entre la clé publique du sujet et les informations d’identification de ce dernier.

Le demandeur d’un certificat envoie les informations demandées dont la clé publique qu’il utilise à un organisme de certification (VeriSign par exemple). L’organisme vérifie ces informations puis y ajoute ses propres informations. Il signe ensuite le certificat c’estàdire qu’il ajoute un résumé des informations contenues encodé avec sa clé privée.

Il reste au client qui récupère le certificat à décoder la signature à l’aide de la clé publique de l’organisme de

Les certificats



certification (une clé bien connue en quelque sorte).

Un certificat n’est valide que pour la durée spécifiée à l’intérieur ; chaque certificat contient les dates Valide à partir du et Valide jusqu’au qui définissent les limites de la période de validité. Une fois que la période de validité d’un certificat est dépassée, un nouveau certificat doit être demandé par le sujet du certificat expiré.

3. Le protocole SSH

Le modèle proposé par SSH est comme Telnet un modèle clientserveur, le port affecté au serveur SSH est le port TCP 22 :

Le protocole SSH couvre l’authentification, la confidentialité et l’intégrité des données.

a. SSH version 1

L’établissement d’une connexion sécurisée en SSH version 1 comporte les phases suivantes :

Le client initie une session TCP avec le serveur, port serveur 22, port client xxx.

Le serveur annonce la version du protocole qu’il reconnaît par exemple « SSH1.99Cisco1.25 ».

Le client fait de même et annonce par exemple « SSH1.5PuTTY_Release_0.60 ».

Ces annonces se font en clair. « SSH1.99Cisco1.25 » signifie protocole SSH version 1.99 implémenté par Cisco version 1.25. La version de l’implémentation est un commentaire facultatif parfois mis à profit par certaines implémentations afin de contourner des bogues connus. Si les versions client et serveur sont compatibles, alors l’établissement de la connexion se poursuit. Dans le cas présent, le serveur annonce qu’il supporte à la fois les versions 1 et 2, le client annonce 1, la connexion s’établira en version SSH1.

À ce stade, si l’établissement se poursuit, les deux extrémités basculent véritablement sur le protocole SSH



encapsulé dans IP. Le format des paquets SSH est le suivant :

La longueur du bourrage est aléatoire de 1 à 8 octets. Le CRC32 porte sur les champs bourrage, type de paquet et données. Le polynôme générateur est 0xEDB88320.

Le serveur s’identifie auprès du client et fournit un certain nombre de paramètres de session :

Sa clé d’hôte (Host Key), c’est une clé publique RSA qui authentifie le serveur.

Sa clé de serveur (Server Key), c’est à nouveau une clé publique RSA mais régénérée toutes les deux heures.

Une séquence aléatoire de 8 octets appelée (Check bytes). Le client doit inclure ces octets dans sa prochaine réponse. L’objet de ce « cookie » aléatoire est de rendre plus difficiles les attaques en usurpation d’identité.

Des informations complémentaires comme la liste des chiffrements symétriques supportés ainsi que la liste des authentifications supportées.

Parvenu à ce stade, chacun des deux correspondants génère un identifiant de session exprimé sur 128 bits et qui permettra de distinguer dans les paquets qui suivent ceux appartenant à la session SSH en cours. L’identifiant de session est obtenu par un hachage MD5 de l’ensemble clé d’hôte + clé de serveur + les 8 octets « check bytes ».

Un point intéressant est le comportement du client quand il reçoit la clé d’hôte. Le client s’interroge : cette clé m’estelle connue ? Le client consulte une base de données des hôtes connus. S’il peut répondre oui, tout va bien. Dans le cas contraire, on peut imaginer deux possibilités. Le serveur peut être inconnu, ou être connu mais avec une clé d’hôte différente. Dans les deux cas, il est probable que le client sollicite l’intervention de l’administrateur pour décider s’il faut faire confiance ou pas à la nouvelle clé. Exemple avec PuTTY en tant que client :

La séquence d’établissement de la connexion sécurisée se poursuit :

Le client génère une clé de session (256 bits) et la chiffre deux fois en utilisant la paire de clés RSA issues du serveur (clé d’hôte + clé de serveur) puis envoie cette clé chiffrée au serveur accompagnée de l’algorithme



de chiffrement symétrique retenu ainsi que du cookie de 64 bits.

Les deux extrémités basculent en mode chiffré symétrique en utilisant l’algorithme choisi.

À partir de ce moment, le canal est chiffré ce qui en fait un tunnel et il pourrait servir à bien autre chose que le simple transport d’un « shell » c’estàdire d’une session de terminal virtuel, ce que nous apprêtons à en faire. La phase d’établissement du tunnel SSH est terminée, la phase d’authentification du client peut commencer.

Plusieurs méthodes d’authentification sont possibles mais le temps et l’espace manquent, nous n’évoquerons que la méthode désignée SSH_AUTH_PASSWD. Il s’agit d’une identification classique « à la Telnet » avec utilisation du couple nom/mot de passe. Le client envoie le mot de passe sous forme texte (mais il est chiffré par le tunnel), mot de passe lu directement depuis l’entrée au clavier de l’utilisateur.

Un tel établissement a été capturé à l’aide de Wireshark, le contexte était le suivant : La station 10.0.8.10 établit une connexion SSH sur le serveur SSH 10.0.8.254 (un routeur). La capture est disponible sur le site ENI (cap_2L_02.pcap).

La version 1 de SSH n’est pas un standard de l’IETF et présente certaines failles de sécurité. Il est recommandé d’utiliser si possible la version 2.

b. SSH version 2

La couche de sécurité de SSH2 comporte trois souscouches :

Un premier niveau Transport établit la communication sécurisée entre client et serveur. Ce niveau est chargé de la manipulation des paquets SSH, du chiffrement et de l’intégrité des données.

Un second niveau authentifie les utilisateurs (le premier niveau a authentifié les machines).

Un troisième niveau offre un service de gestion des connexions, ces connexions peuvent comprendre le transfert de ports.

Le standard recommande d’encapsuler SSH2 dans un protocole de transport fiable. En effet, toute erreur de transmission est détectée par SSH et provoque la coupure immédiate de la connexion. C’est donc TCP qui est utilisé, l’IANA a affecté le port TCP 22 au serveur SSH.

Une fois la session TCP établie (SYN, SYNACK, ACK), les deux parties échangent une chaîne d’identification dont le format est :

SSH-protoversion-softwareversion SP comments CR LF

protoversion → annonce la version du protocole. Dans le cas de SSH2, la chaîne est 2.0.

softwareversion → annonce la version de l’implémentation logicielle.

comments → optionnel, séparé par le caractère Espace (ASCII 32).

La taille maximale de cette chaîne est 255 caractères en incluant les caractères CR LF (Retour chariot et saut de ligne).

Un serveur peut supporter les deux versions du protocole mais dans ce cas, il annonce 1.99. Un serveur strictement compatible avec la version 2 annonce 2.0. Un client SSH2 qui se connecte à un serveur SSH1.99 interprète cette version comme étant la 2.0. Qu’elles soient attribuées au client ou au serveur, la version 1 est incompatible avec la version 2.

Le format du paquet SSH2 est le suivant :

Souscouche Transport

Structure du paquet SSH



La longueur du paquet n’inclut pas le code d’authentification des messages. Les données peuvent être compressées mais elles ne le sont pas initialement. La longueur du bourrage ne peut excéder 255 octets. La taille d’un paquet ne peut excéder 35000 octets, valeur choisie arbitrairement par SSH2 pour être supérieure à la charge utile non compressée prévue inférieure ou égale à 32768 octets.

Quand client et serveur ont négocié un algorithme de compression, cette compression s’exerce exclusivement sur les données. Chaque sens de flux peut utiliser une méthode de compression différente mais le standard recommande d’utiliser la même méthode pour les deux sens de flux. Les méthodes de compression suivantes sont actuellement définies :

Aucune → exigée ;

zlib → facultative, compression décrite dans les RFC 1950 et 1951.

Le chiffrement s’opère à l’aide d’un algorithme négocié lors de l’échange des clés. Quand il devient effectif, tout le contenu du paquet à l’exception du code d’authentification de message est chiffré. Le chiffrement intervient toujours après la compression. Les champs concernés sont longueur de paquet, longueur de bourrage, charge utile et bourrage. À nouveau, chaque sens de flux peut utiliser un algorithme différent mais à nouveau le standard recommande d’utiliser le même algorithme pour les deux sens de flux. Le standard énumère les algorithmes suivants :

Compression

Chiffrement

Désignation Requis/non requis Description

3descbc EXIGÉ 3DES à trois clés en mode CBC.

blowfishcbc FACULTATIF Blowfish en mode CBC.

twofish256cbc FACULTATIF Twofish en mode CBC, avec une clé de 256 bits.

twofishcbc FACULTATIF alias pour "twofish256cbc" (ne figure que pour des raisons historiques).

twofish192cbc FACULTATIF Twofish avec clé de 192 bits.

twofish128cbc FACULTATIF Twofish avec clé de 128 bits.

aes256cbc FACULTATIF AES en mode CBC, avec clé de 256 bits.

aes192cbc FACULTATIF AES avec clé de 192 bits.

aes128cbc RECOMMANDÉ AES avec clé de 128 bits.

serpent256cbc FACULTATIF Serpent en mode CBC, avec clé de 256 bits.

serpent192cbc FACULTATIF Serpent avec clé de 192 bits.

serpent128cbc FACULTATIF Serpent avec clé de 128 bits.

arcfour FACULTATIF chiffrement de flux ARCFOUR avec clé de 128 bits.

ideacbc FACULTATIF IDEA en mode CBC mode.



Le standard recommande un chiffrement dont la longueur de clé soit supérieure ou égale à 128 bits.

CBC signifie « Cipher Block Chaining ». Il s’agit du mode opératoire utilisé par l’algorithme de chiffrement pour traiter les blocs d’octets en clair et les blocs chiffrés. Le terme « chaining » rappelle que le mode CBC fait intervenir dans le chiffrement du bloc en cours le résultat du chiffrement du bloc précédent :

Le chiffrement "3descbc" est le tripleDES à trois clés (chiffrementdéchiffrementchiffrement), où les huit premiers octets de la clé sont utilisés pour le premier chiffrement, les huit octets suivants pour le déchiffrement, et les huit octets suivants pour le chiffrement final. Cela exige 24 octets de données de clé (dont 168 bits sont en fait utilisés. Dans la mesure où cet algorithme a seulement une longueur effective de clé de 112 bits, il ne satisfait pas à l’exigence de longueur de clé du standard. Cependant, cet algorithme est toujours exigé pour des raisons historiques. En effet, l’essentiel des mises en œuvre connues au moment de la rédaction du RFC 4253 prenait en charge cet algorithme, et il est couramment utilisé parce qu’il est l’algorithme interopérable fondamental. Le standard prévoit pourtant de le déconseiller dès qu’un algorithme plus fort (AES) pourra prétendre à la même universalité.

Chacun des deux participants à la session SSH effectue un comptage des paquets et donc entretient de manière secrète un numéro de séquence de paquet. Ce numéro de séquence est associé au contenu du paquet ainsi qu’à un secret partagé pour calculer le MAC ou code d’authentification du paquet (MAC : Message Authentication Code) dont l’objet est de vérifier l’intégrité des données.

Le MAC est à la couche SSH ce que la somme de contrôle est à la couche TCP.

L’algorithme d’authentification de message et la clé sont négociés durant l’échange de clés. Au départ, aucun MAC n’est activé (longueur zéro). Une fois activé, le MAC du paquet est calculé avant chiffrement de la façon suivante :

mac = MAC(clé, numéro_de_séquence || paquet_non_chiffré)

paquet_non_chiffré est le paquet entier sans séquence mac ;

numéro_de_séquence est le numéro du paquet connu grâce au comptage des paquets. Ce numéro est initialisé à 0 pour le premier paquet puis incrémenté systématiquement à chaque paquet et jamais remis à 0. Puisque le comptage s’effectue sur 32 bits, le numéro revient naturellement à 0 après 232 paquets.

La valeur mac issue de l’algorithme MAC est transmise sans chiffrement à la queue du paquet SSH. Sa longueur dépend de l’algorithme choisi. Le standard énumère les algorithmes suivants :

cast128cbc FACULTATIF CAST128 en mode CBC.

aucun FACULTATIF NON RECOMMANDÉ.

Intégrité des données

Désignation Requis/Non requis Description

hmacsha1 EXIGÉ HMACSHA1 (longueur du résumé = longueur de clé = 20).

hmacsha196 RECOMMANDÉ 96 premiers bits de HMACSHA1 (longueur de résumé = 12, longueur de clé = 20).



La méthode d’échange de clé spécifie comment les clés de session à utilisation unique sont générées pour le chiffrement et pour l’authentification, et comment l’authentification du serveur est faite.

Le standard définit deux méthodes d’échanges de clés :

diffiehellmangroup1sha1 → EXIGÉ ;

diffiehellmangroup14sha1 → EXIGÉ.

Le standard prévoit de fonctionner avec la plupart des formats, nombreux, de clés publiques. Plusieurs aspects définissent un type de clé publique :

Le format de clé : comment la clé est codée et comment sont représentés les certificats (en effet, les formats de clés du protocole SSH peuvent contenir des certificats en plus des clés).

Les algorithmes de signature et/ou chiffrement : certains types de clés peuvent ne pas prendre en charge à la fois la signature et le chiffrement.

Le codage des signatures et/ou données chiffrées. Cela inclut, sans s’y limiter, le bourrage, l’ordre des octets, et les formats de données.

Les formats de clé publique et/ou de certificat suivants sont définis actuellement :

Les deux correspondants annoncent les formats supportés puis choisissent un format communément supporté.

Le protocole d’authentification SSH offre son service en s’appuyant sur le service offert par le protocole de transport SSH.

Échange initial

L’authentification est provoquée par le client à l’aide d’un paquet SSH_MSG_USERAUTH_REQUEST. Le mot de passe n’est pas inclus dans ce premier message. À la réception de ce message, le serveur doit répondre par l’un des messages suivants :

SSH_MSG_USERAUTH_SUCCESS → accepte l’authentification ;

SSH_MSG_USERAUTH_FAILURE → refuse l’authentification ;

hmacmd5 FACULTATIF HMACMD5 (longueur de résumé = longueur de clé = 16).

hmacmd596 FACULTATIF 96 premiers bits de HMACMD5 (longueur de résumé = 12, longueur de clé = 16).

aucune FACULTATIF pas de MAC ; NON RECOMMANDÉ.

Méthodes d’échange de clés

Algorithmes de clés publiques

Désignation Requis/Non requis Signature ? Description

sshdss EXIGÉ signature clé DSS brute.

sshrsa RECOMMANDÉ signature clé RSA brute.

pgpsignrsa FACULTATIF signature certificats OpenPGP (clé RSA).

pgpsigndss FACULTATIF signature certificats OpenPGP (clés DSS).

Souscouche Authentification de l’utilisateur



SSH_MSG_USERAUTH_INFO_REQUEST → demande d’information supplémentaire afin de poursuivre l’authentification.

Le standard conseille de ne pas répondre le message SSH_MSG_USERAUTH_FAILURE au premier message d’authentification par nom d’utilisateur. Le comportement à préférer est de répondre par un message SSH_MSG_USERAUTH_INFO_REQUEST puis de faire suivre ce message par un message SSH_MSG_USERAUTH_FAILURE différé de quelques secondes. On évite ainsi de faciliter la tâche des algorithmes dits « attaque en force brute » qui parviendraient autrement à valider un nom d’utilisateur par un message unique envoyé au serveur.

Demandes d’informations

Le serveur peut demander des informations d’authentification au client à l’aide du message SSH_MSG_USERAUTH_INFO_REQUEST. Un serveur qui génère ainsi une requête en attend la réponse avant de générer éventuellement une nouvelle requête. Le client doit accepter un nombre de requêtes indéfini. Le message d’interrogation définit un tableau de valeurs à récupérer. À chaque valeur sont associés une invite de commandes à afficher à l’utilisateur ainsi qu’un booléen qui précise si oui ou non la réponse entrée par l’utilisateur doit s’afficher (pas d’écho distant, le booléen dit « écho local ou pas d’écho local »).

Une fois collectées les réponses de l’utilisateur, le client génère un message de réponse SSH_MSG_USERAUTH_INFO_RESPONSE. Le message doit contenir autant de réponses que demandées dans le message de requête et de plus, les réponses doivent être disposées dans un ordre identique à celui des questions respectives posées dans le message de requête.

Le serveur qui reçoit le message de réponse doit répondre à l’aide de l’une des trois réponses possibles : succès, échec ou demande d’informations supplémentaires. En cas d’échec, le standard recommande de n’envoyer le message d’échec qu’après quelques secondes d’attente (généralement 2 secondes) ce, toujours dans le but de compliquer la tâche des algorithmes d’attaque.

La version 2 de SSH définit un troisième protocole qui s’appuie sur le protocole d’authentification précédent. Son objet est de permettre l’exécution de commandes à distance, le transfert de connexions TCP et de connexions X11 (prise de main à distance dans un environnement graphique). Chaque fonctionnalité offerte provoque l’établissement de canaux SSH, chaque canal peut être initié à l’aide de messages par l’un ou par l’autre correspondant.

Un établissement SSH2 a été capturé à l’aide de Wireshark, le contexte était le suivant : La station 10.0.8.10 établit une connexion SSH sur le serveur SSH 10.0.8.254 (un routeur). La capture est disponible sur le site ENI (cap_2L_03.pcap).

4. Mise en œuvre

Objectifs

La mise en situation réutilise le contexte proposé pour l’atelier SYSLOG, contexte qui avait été préparé pour l’étude des listes de contrôle d’accès.

On se propose de prendre la main via SSH sur R100m depuis une station connectée à LAN8. Pour mémoire, dans le tout premier chapitre de l’ouvrage, nous avions ajouté sur la machine hôte un adaptateur réseau virtuel connecté à VMnet8 et donc à LAN8. PuTTY exécuté sur la machine hôte permettra cette connexion SSH.

Depuis la session SSH ouverte sur R100m, on se propose de prendre la main via SSH sur le routeur R120m.

Étape 1 : adopter la bonne version d’IOS

Assurezvous que l’IOS utilisé supporte SSH. S’il s’agit de prendre la main sur un routeur depuis une station, le routeur doit disposer de SSH server, et par suite requiert le support de IPsec et de ses algorithmes de chiffrement (DES ou 3DES). C’est le cas quand le nom de l’image comporte la lettre « K » (Support de IPsec et de SSH), le mieux étant encore d’adopter une version qui porte le symbole « K9 » (Support de la cryptographie forte à savoir 3DES et AES). Relire si nécessaire le chapitre Gestion de la plateforme logicielle CISCO IOS.

S’il s’agit de prendre la main sur un routeur R2 depuis un autre routeur R1, alors l’IOS de R1 doit avoir la fonctionnalité SSH client, c’est le cas depuis la version 12.1(3)T.

Pour notre part, la plateforme utilisée reste le 2621 doté de l’image c2600advipservicesk9mz.12418a.bin.

Souscouche Connexion



Étape 2 : créer la base de comptes

À moins que ce n’ait déjà été fait dans un atelier précédent, créez les deux comptes utilisateur :

R100m(config)#username brett password tamajeste R100m(config)#username danny password fulton R100m(config)#^Z R100m#

Étape 3 : activer la méthode d’authentification locale

Si nécessaire, relisez la section correspondante dans ce chapitre.

Activez le modèle AAA :

R100m(config)#aaa new-model R100m(config)#aaa authentication login auth_locale local

Étape 4 : doter le routeur d’un nom pleinement qualifié (FQDN)

La mise en œuvre de SSH requiert de créer sur le routeur une paire de clés (publique/privée) RSA. La clé privée est conservée par le routeur et inscrite dans la partition NVRAM. La clé publique sera fournie au client afin de chiffrer la phase de négociation et d’authentification préalable à l’échange proprement dit. La paire est identifiée par un nom. L’administrateur peut au choix générer une paire nommée et dans ce cas lui attribuer un nom ou générer une paire sans la nommer et dans ce cas l’IOS nomme la paire « hostname.domain_name ».

Nommez le routeur puis renseignez le nom de domaine auquel il appartient (relire si nécessaire la section Résolution de noms du chapitre Tâches de configuration des routeurs) :

Router(config)#hostname R100m R100m(config)#ip domain-name ccna.fr R100m(config)#^Z R100m#

Étape 5 : doter le routeur d’une paire de clés RSA

La commande à mettre en œuvre est crypto key generate rsa dont la syntaxe est la suivante :

crypto key generate rsa [general-keys | usage-keys | signature | encryption] [label

key-label] [exportable] [modulus modulus-size] [storage devicename:][redundancy][on

devicename:]

Les arguments majeurs de la commande sont :

generalkeys

Optionnel, crée une paire de clés à usage général, c’est le choix par défaut.

usagekeys

Optionnel, crée deux paires de clés dont une dédiée au chiffrement, l’autre à la signature.

signature

Optionnel, crée une paire de clés dédiée à la signature.

encryption

Optionnel, crée une paire de clés dédiée au chiffrement.

label keylabel



Optionnel, nomme la clé ce qui est nécessaire si l’administrateur souhaite l’exporter. Quand aucun nom n’est spécifié, l’IOS utilise le nom pleinement qualifié du routeur.

exportable

Optionnel, rend la paire exportable vers un autre équipement CISCO.

modulus modulussize

Optionnel, spécifie la taille de la clé.

Par défaut, la taille d’une clé issue d’une autorité de certification (CA) est 1024 bits. La taille recommandée est 2048 bits. La commande accepte toute taille de clé comprise entre 350 et 4096 bits.

Attention : générer une clé de 512 bits sur une plateforme 4700 prend une seconde mais générer une clé de 2048 bits sur une plateforme 2500 prend une heure !

storage devicename:

Optionnel, spécifie la partition sur laquelle sera enregistrée la paire de clés.

Si le routeur dispose déjà d’une paire (ou deux) de clés RSA, l’exécution de la commande provoque un avertissement avant de remplacer la (ou les) paire existante par la paire en cours de création. Outre la paire d’usage général ou les deux paires dédiées au chiffrement et à la signature, l’exécution de la commande provoque la création d’une paire de clés dédiée à SSH. Cette paire est exclusivement utilisée par SSH et l’IOS la nomme « hostname.domain_name.server »

La commande n’est pas réellement une commande de configuration même s’il faut la provoquer en mode de configuration globale. C’est pourquoi elle n’est pas sauvegardée dans le fichier de configuration runningconfig. Cependant, les clés générées par la commande sont sauvegardées en NVRAM (dans un fichier caché et non transférable vers un autre dispositif) en même temps que l’administrateur provoque une sauvegarde de la configuration courante. Hélas, ce fonctionnement n’est pas reproduit par la plateforme émulée à l’aide de Dynamips. La manipulation reste possible mais en cas de redémarrage de la topologie, il faudra générer à nouveau les clés.

Les clés ne font pas partie de la configuration mais c’est pourtant la commande de sauvegarde de la configuration qui provoque également la sauvegarde des clés.

Si la configuration n’est pas sauvegardée, les clés générées seront perdues au prochain rechargement du routeur !

Appliquée au cas présent :

R100m(config)#crypto key generate ? rsa Generate RSA keys <cr> R100m(config)#crypto key generate rsa ? general-keys Generate a general purpose RSA key pair for signing and encryption usage-keys Generate separate RSA key pairs for signing and encryption <cr> R100m(config)#crypto key generate rsa general-keys ? exportable Allow the key to be exported label Provide a label modulus Provide number of modulus bits on the command line <cr> R100m(config)#crypto key generate rsa general-keys modulus ? <360-2048> size of the key modulus [360-2048] R100m(config)#crypto key generate rsa general-keys modulus 1024 ? exportable Allow the key to be exported <cr> R100m(config)#crypto key generate rsa general-keys modulus 1024 The name for the keys will be: R100m.ccna.fr



% The key modulus size is 1024 bits % Generating 1024 bit RSA keys, keys will be non-exportable...[OK] R100m(config)# *Mar 1 01:59:15.531: %SSH-5-ENABLED: SSH 1.99 has been enabled R100m(config)#^Z R100m# *Mar 1 02:00:23.391: %SYS-5-CONFIG_I: Configured from console by brett on console R100m#copy run start Destination filename [startup-config]? Building configuration... [OK] R100m#

Observez dans la capture cidessus, la création de la paire de clés s’accompagne de l’activation de SSH sur le routeur. On apprend également que la version supportée de SSH est la version 1.99, ce qui signifie que le serveur SSH en place accepte les connexions qu’elles soient issues de clients SSH1 ou SSH2.

Vérifiez que les clés sont effectivement créées :

R100m#sh crypto key ? mypubkey Show public keys associated with this router pubkey-chain Show peer public keys R100m#sh crypto key mypubkey ? rsa Show RSA public keys R100m#sh crypto key mypubkeyrsa % Key pair was generated at: 01:59:15 UTC Mar 1 2002 Key name: R100m.ccna.fr

Usage: General Purpose Key Key is not exportable. Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00D1D6C4 DC64DBC9 11C786FF 9794310C 587121DE 623804E2 053FCC82 09200431 041C47A9 68F7ED05 BEF2332E 1E55A63F 48159085 52E87745 B6BAB5B4 61696FAC 14374CEB 0BE0FEBC 8C9BCD46 C9BD943A 49959014 F0173B81 E3533B22 5167388A 61B7781C AC45EE7F 57103E87 C63638DE 7282E702 D4378418 6390055D 908976D2 01020301 0001 % Key pair was generated at: 01:59:15 UTC Mar 1 2002 Key name: R100m.ccna.fr.server

Usage: Encryption Key Key is not exportable. Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B042AA FDE95871 EE6DDB3F DE2DFF1C 3518882D 14E41865 6625997D 6F264B1E B9809261 C0D7B152 89CDFA98 BA8F9B0D 3997C9A7 BA700F5D 990402BB 6DA1974A DFFC7F08 1D9F7473 A0A15799 8E86EE47 BFA3387F 4E8868EC FF5CD9A8 ACEBC1E2 A3020301 0001 R100m#

Ainsi, la commande crypto key generate rsa a engendré deux clés, l’une prévue pour un usage général, l’autre dédiée à SSH.

Étape 6 : régler les paramètres de l’authentification ssh

En mettant à profit la commande ip ssh en mode de configuration globale :

ipssh [timeout seconds | authentication-retries integer]

... dont les arguments sont les suivants :

timeout

Optionnel, règle le temps d’attente de la réponse du client par SSH Server. Ce temps ne concerne que la phase de négociation de SSH. Une fois la session ouverte, c’est le temporisateur timeout appliqué aux lignes vty qui s’applique également à la session SSH. Ce temporisateur expire par défaut 10 minutes après le démarrage de session.

seconds



Optionnel, exprimé en seconds. Temps max = Temps par défaut = 120 s.

authenticationretries

Optionnel, nombre de tentatives d’ouvertures de session admises.

integer

Optionnel, nombre de tentatives, 5 maxi, 3 par défaut.

Réglez les paramètres de l’authentification ssh comme suit :

R100m(config)#ip ssh time-out 120 R100m(config)#ip ssh authentication-retries 4 R100m(config)#^Z R100m#

Vérifiez la configuration obtenue :

R100m#sh ip ssh SSH Enabled - version 1.99 Authentication timeout: 120 secs; Authentication retries: 4 R100m#

Comment vérifier les sessions en cours ? :

R100m#sh ssh %No SSHv2 server connections running. %No SSHv1 server connections running. R100m#

La réponse à cette commande show est riche d’enseignements puisqu’on y découvre comment l’implémentation de CISCO supporte à la fois les versions 1 et 2 du protocole SSH. Cisco a simplement prévu deux serveurs et un système d’aiguillage vers le serveur adéquat. L’administrateur peut imposer la version de SSH à utiliser. Démonstration :

R100m(config)#ip ssh version ? <1-2> Protocol version R100m(config)#ip ssh version 2 R100m(config)#^Z R100m#sh ip ssh SSH Enabled - version 2.0

Authentication timeout: 120 secs; Authentication retries: 4 R100m#sh ssh %No SSHv2 server connections running. %No SSHv1 server connections running.

Passage par la version 1, puis retour au comportement par défaut :

R100m(config)#ip ssh version 1 R100m# R100m#sh ip ssh SSH Enabled - version 1.5

Authentication timeout: 120 secs; Authentication retries: 4 R100m#conf t Enter configuration commands, one per line. End with CNTL/Z. R100m(config)#no ip ssh version R100m(config)#^Z R100m#sh ipssh SSH Enabled - version 1.99

Authentication timeout: 120 secs; Authentication retries: 4

C’est une confirmation, il faut conclure que l’affichage « version 1.99 » doit être interprété comme la possibilité pour le routeur d’ouvrir indifféremment une session SSH1 qu’une session SSH2.



Étape 7 : imposer le transport de la session de terminal vty par ssh

Si nous laissions la configuration dans cet état, l’ouverture de session par Telnet resterait possible :

R100m(config)#line vty 0 4 R100m(config-line)#tra R100m(config-line)#transport ? input Define which protocols to use when connecting to the terminal server output Define which protocols to use for outgoing connections preferred Specify the preferred protocol to use R100m(config-line)#transport input ? all All protocols mop DEC MOP Remote Console Protocol none No protocols pad X.3 PAD rlogin Unix rlogin protocol ssh TCP/IP SSH protocol telnet TCP/IP Telnet protocol udptn UDPTN async via UDP protocol v120 Async over ISDN R100m(config-line)#transport input ssh ? mop DEC MOP Remote Console Protocol pad X.3 PAD rlogin Unix rlogin protocol telnet TCP/IP Telnet protocol udptn UDPTN async via UDP protocol v120 Async over ISDN <cr> R100m(config-line)#transport input ssh

R100m(config-line)#^Z R100m#

Observez qu’en fait, la commande transport admet une liste de protocoles potentiels. Ainsi, entrer la commande transport input ssh telnet permettrait autant une ouverture de session par SSH que par Telnet.

Étape 8 : test de l’ouverture de session sur R100m via SSH

Il est temps d’explorer les possibilités de PuTTY en ce domaine :



Étiquettes 1, 2 et 3 → L’administrateur indique l’adresse IP du routeur objet de la prise de main puis coche le protocole de transport SSH. Observez le port TCP correspondant soit 22.

Étiquettes 4, 5 et 6 → L’administrateur peut souhaiter ou imposer une version du protocole SSH. Naturellement, en production, la version 2 est à préférer quand elle est supportée. Adoptons un comportement exploratoire en préférant dans un premier temps la version 1 du protocole.

Étiquettes 7, 8 → L’administrateur règle le comportement du client SSH PuTTY dans le renouvellement des clés de session. Ceci ne concerne que les sessions ouvertes avec SSH version 2.

Ouvrez la session (étiquette 9).

Vérifiez à l’aide d’une commande show ssh la version de protocole SSH utilisée et par suite quel a été l’algorithme de chiffrement choisi pour créer le tunnel sécurisé SSH. L’algorithme AES ne peut être utilisé que par SSH2, PuTTY a tenté de négocier « Blowfish » sans succès, le troisième algorithme de la liste était 3DES, cet algorithme convenait aux deux parties :

login as: danny Sent username "danny" [email protected]’s password: R100m>en Password: R100m#sh ssh Connection Version Encryption State Username 66 1.5 3DES Session started danny

%No SSHv2 server connections running. R100m#



Fermez cette session puis configurez PuTTY afin de préférer SSH2 à la prochaine ouverture.

Ouvrez à nouveau la session et observez que cette fois, l’algorithme de chiffrement est AES :

login as: danny Using keyboard-interactive authentication. Password: R100m>sh ip ssh SSH Enabled - version 1.99 Authentication timeout: 120 secs; Authentication retries: 4 R100m>en Password: R100m#sh ssh Connection Version Mode Encryption Hmac State Username 66 2.0 IN aes256-cbc hmac-sha1 Session started danny

66 2.0 OUT aes256-cbc hmac-sha1 Session started danny

%No SSHv1 server connections running. R100m#

Observez également l’apparition d’une colonne supplémentaire qui renseigne sur le contrôle d’intégrité choisi, hmacsha1 dans le cas présent. Autre différence notable avec la version 1 : Il faut deux lignes pour décrire la session en cours. En effet, puisqu’il est possible d’imposer un algorithme de chiffrement et un algorithme d’intégrité différents pour chaque sens de flux, la commande affiche une ligne par sens de flux (« IN », « OUT »).

Étape 9 : activer SSH sur R120m

Une autre faculté de l’IOS est de pouvoir créer des clés RSA nommées. Dans ce cas, l’étape préalable qui consistait à doter le routeur d’un nom pleinement qualifié n’est pas indispensable :

R120m(config)#ip domain-name ccna.fr R120m(config)#^Z R120m#

Sur R120m, générez une paire de clés nommée cle_RSA_pour_SSH :

R120m(config)#crypto key generate rsa general-keys label cle_RSA_pour_SSH ? exportable Allow the key to be exported modulus Provide number of modulus bits on the command line <cr> R120m(config)#$generate rsa general-keys label cle_RSA_pour_SSH modulus 1024 The name for the keys will be: cle_RSA_pour_SSH % The key modulus size is 1024 bits % Generating 1024 bit RSA keys, keys will be non-exportable...[OK] R120m(config)# Mar 1 00:05:25.139: %SSH-5-ENABLED: SSH 1.99 has been enabled

R120m(config)#^Z R120m#

Observez le message SYSLOG qui avertit de l’activation de SSH1.99.

Vérifiez que les clés sont effectivement créées :

R120m#sh crypto key mypubkey rsa % Key pair was generated at: 00:05:25 UTC Mar 1 2002 Key name: cle_RSA_pour_SSH Usage: General Purpose Key Key is not exportable. Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00E2BBDB



B50E39F6 309CFBF0 03C03121 C59C60D5 C593E2A7 F3FBE2D8 ADECA102 47228EE1 F32D717A A49EA7B9 2B0E7CCC 3DE7CB6A 8BBDCB93 58F82743 5A006F6C 94CE6B3C 09E46CF4 4FA7B9BE 49851696 6179DF1F D6B28C8E CE3271F8 1D4E33E1 42F81B7D 63E18693 79C15F42 4E17D5A5 1904D948 97AA3EB9 F94E8748 04D85DB5 2D020301 0001 % Key pair was generated at: 00:05:25 UTC Mar 1 2002 Key name: cle_RSA_pour_SSH.server

Usage: Encryption Key Key is not exportable. Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00DF4136 259E7A4E D72C474A 7FDEB6A0 4909511B 92E53AC1 C9A83CA8 CE195ACF 08505544 E1AAC8B6 002AA4F5 671E3FE0 6AD7B8E3 60903D5D BC0B3D86 FDF7F74D C02BCFF8 FC90542F D053E6AA 3072DB55 E7B3D1A1 39535D0C BF49890C 4E7C96DB 21020301 0001

Étape 10 : régler les paramètres de l’authentification ssh

Ajustez ces paramètres à l’identique avec R100m :

R120m(config)#ip ssh time-out 120 R120m(config)#ip ssh authentication-retries 4 R120m(config)#^Z R120m#

Étape 11 : imposer le transport de la session de terminal vty par ssh

Si nous laissions la configuration dans cet état, l’ouverture de session par Telnet reste possible :

R120m(config)#line vty 0 4 R120m(config-line)#transport input ssh

R120m(config-line)#^Z R120m#

Observez qu’en fait, la commande transport admet une liste de protocoles potentiels. Ainsi, entrer la commande transport input ssh telnet permettrait autant une ouverture de session par SSH que par Telnet.

Étape 12 : attribuer la clé nommée à ssh

Commençons par une erreur volontaire afin d’observer le comportement de l’IOS :

R120m(config)#ip ssh rsa keypair-name cle_RSA_pour_SSH.server Please create RSA keys to enable SSH.

R120m(config)# Mar 1 00:08:56.655: %SSH-5-DISABLED: SSH 1.99 has been disabled

Le nom de clé n’a pas été reconnu par l’IOS qui en conclut que l’administrateur doit encore créer cette paire (« Please create RSA keys to enable SSH »). En attendant, SSH est désactivé.

Attribuez la paire en la nommant telle qu’attendue par l’IOS :

R120m(config)#ip ssh rsa keypair-name cle_RSA_pour_SSH

R120m(config)# Mar 1 00:09:41.759: %SSH-5-ENABLED: SSH 1.99 has been enabled R120m(config)#^Z Mar 1 00:10:16.207: %SYS-5-CONFIG_I: Configured from console by danny on console R120m#copy run start Destination filename [startup-config]? Building configuration... [OK] R120m#

Étape 13 : ouvrir une session SSH depuis R100m sur R120m

La commande ssh permet d’ouvrir une session vers un serveur SSH (cette commande active donc un client SSH).



Observez qu’elle admet de nombreux arguments qui permettent d’établir une session « sur mesures » :

R100m#ssh ? -c Select encryption algorithm -l Log in using this user name -m Select HMAC algorithm -o Specify options -p Connect to this port -v Specify SSH Protocol Version WORD IP address or hostname of a remote system R100m#ssh -c ? 3des triple des SSHv2 only cipher list: aes128-cbc AES 128 bits aes192-cbc AES 192 bits aes256-cbc AES 256 bits R100m#ssh -l ? WORD Login name R100m#ssh -m ? SSHv2 Hmac list: hmac-md5-128 hmac-md5 MD5 based HMAC(128 bits) hmac-md5-96 MD5 based HMAC(96 bits) hmac-sha1-160 hmac-sha1 SHA1 based HMAC(160 bits) hmac-sha1-96 SHA1 based HMAC(96 bits) R100m#ssh -o ? numberofpasswordprompts Specify number of password prompts R100m#ssh -p? -p WORD R100m#ssh -v? -v WORD R100m#ssh -v ? 1 Protocol Version 1 2 Protocol Version 2

Utilisez cette déclinaison de la commande :

R100m#ssh -l danny 10.0.8.253

Password: R120m>sh ip ssh SSH Enabled - version 1.99 Authentication timeout: 120 secs; Authentication retries: 3 R120m>sh ssh Connection Version Mode Encryption Hmac State Username 66 1.99 IN aes128-cbc hmac-sha1 Session started danny 66 1.99 OUT aes128-cbc hmac-sha1 Session started danny %No SSHv1 server connections running. R120m>exit [Connection to 10.0.8.253 closed by foreign host] R100m#




Validation des acquis : questions/réponses

1. Questions

La plupart des thèmes exposés dans ce chapitre ne sont pas réellement des attendus de la certification CCNA et ont pour but d’aider le lecteur à devenir un administrateur surentraîné. Les quelques questions qui suivent ont donc surtout pour objet de donner l’envie de lire le chapitre :

Quel est l’objet du modèle AAA de CISCO ?

Un administrateur vient de créer une paire de clés RSA sur un routeur. Il reçoit un message d’avertissement « %SSH5ENABLED: SSH 1.99 has been enabled ». Que peutil conclure ?

Quelle commande de l’interface ILC fautil utiliser pour provoquer l’affichage des messages SYSLOG sur la session de terminal virtuel en cours ?

Une fois le modèle AAA mis en place sur un routeur, les identifiants des comptes utilisateurs sontils stockés sur le routeur ou sur un serveur centralisé type RADIUS ou TACACS ?

Pourquoi estil indispensable de définir à quel domaine appartient un routeur avant de générer une paire de clés RSA ?

Les paires de clés RSA générées sur un routeur ne font pas partie du fichier de configuration. Comment l’administrateur s’assuretil de leur sauvegarde ?

Un administrateur de vos amis souhaite substituer SSH à Telnet qu’il utilisait jusqu’ici pour administrer ses routeurs. Une commande show version sur au moins l’un des équipements dont il a la charge lui confirme que la version d’IOS en cours d’usage est c2600imz.12326.bin. Que lui ditesvous ?

2. Résultats

Référezvous aux pages suivantes pour contrôler vos réponses. Pour chacune de vos bonnes réponses, comptez un point.

Nombre de points /7

Pour ce chapitre, votre score minimum doit être de 6 sur 7.

3. Réponses

Quel est l’objet du modèle AAA de CISCO ?

Proposer un modèle de sécurité qui prenne en compte trois éléments fondamentaux : l’authentification, les autorisations et la traçabilité (Accounting) (relire si nécessaire la section Le modèle AAA).

Un administrateur vient de créer une paire de clés RSA sur un routeur. Il reçoit un message d’avertissement « %SSH5ENABLED: SSH 1.99 has been enabled». Que peutil conclure ?

Le serveur de l’équipement supporte autant SSH version 1 que SSH version 2 (relire si nécessaire la section Le protocole SSH).

Quelle commande de l’interface ILC fautil utiliser pour provoquer l’affichage des messages SYSLOG sur la session de terminal virtuel en cours ?

Router#terminal monitor

(Relire si nécessaire la section Journalisation, le protocole SYSLOG).

Une fois le modèle AAA mis en place sur un routeur, les identifiants des comptes utilisateurs sontils stockés sur le routeur ou sur un serveur centralisé type RADIUS ou TACACS ?

Le modèle AAA de Cisco permet indifféremment d’entretenir les comptes localement ou sur un serveur centralisé. La seconde solution est à préférer puisqu’ainsi, chaque compte n’est à créer qu’une seule fois (relire si nécessaire la section Qu’estce que l’authentification).

Pourquoi estil indispensable de définir à quel domaine appartient un routeur avant de générer une paire de clés RSA ?

L’administrateur peut au choix générer une paire nommée et dans ce cas lui attribuer un nom ou générer une paire sans la nommer et dans ce cas l’IOS nomme la paire « hostname.domain_name ». Mais cette seconde faculté a un prérequis : le routeur doit être doté d’un nom de domaine (relire si nécessaire la section Adoptez SSH Mise en œuvre).

1

2

3

4

5

6

7

1

2

3

4

5


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA/NDAwODk1IC0gRk9STUFUSU9OUyBBRklQIC0gYTVkMjI0NzgtZTdhYi00MmJkLTk1MTUtNTk5OWE1ZDMyYzczaYkLPB9AzYgLAA==-enidentnumber

Les paires de clés RSA générées sur un routeur ne font pas partie du fichier de configuration. Comment l’administrateur s’assuretil de leur sauvegarde ?

Quand le routeur est doté de paires de clés RSA, la commande copy runningconfig startupconfig est une commande à double effet : le premier effet est connu, il consiste à sauvegarder le fichier de configuration courante, le second effet ne se manifeste qu’en cas de présence de paires de clés RSA qui sont alors sauvegardées et cachées en NVRAM (relire si nécessaire la section Adoptez SSH Mise en œuvre).

Un administrateur de vos amis souhaite substituer SSH à Telnet qu’il utilisait jusqu’ici pour administrer ses routeurs. Une commande show version sur au moins l’un des équipements dont il a la charge lui confirme que la version d’IOS en cours d’usage est c2600imz.12326.bin. Que lui ditesvous ?

Vous lui dites que SSH n’est supporté qu’à la condition de disposer d’un IOS doté des fonctionnalités cryptographie forte, ce qu’il est facile d’identifier par la présence du symbole « k9 » dans le nom de l’image IOS (relire si nécessaire la section Adoptez SSH Mise en œuvre ainsi que le chapitre Gestion de la plateforme logicielle CISCO IOS).

6

7


enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA/NDAwODk1IC0gRk9STUFUSU9OUyBBRklQIC0gYTVkMjI0NzgtZTdhYi00MmJkLTk1MTUtNTk5OWE1ZDMyYzczaYkLPB9AzYgLAA==-enidentnumber

13 Administration et sécurité

Documents

Transcript of 13 Administration et sécurité