Cisco – Définir et configurer une stratégie d’accès (role-based) sur un IOS : 4

Comments
FILED UNDER AAA, CISCO, IOS, ROLE BASED CLI, SÉCURITÉ BY USER
Cet article a pour objectif de présenter l’implémentation des profils d’accès basés sur des rôles. Ce modèle appelé « role-based
cli » par Cisco permet la conception de profils d’accès afin d’administrer les équipements. Ce qui se traduit dans la pratique par
la création de profils disposant de privilèges différents dans le cadre de l’exploitation des équipements composant
l’infrastructure d’un réseau.

Dans le cadre de l’application d’une politique globale de sécurité d’une entreprise, (dans notre cas d’une unité) un technicien de
niveau 1 ne doit pas disposer des mêmes privilèges qu’un architecte. En effet le périmètre d’intervention de ces deux profils n’a
pas la même étendue, il est donc nécessaire de limiter les droits aux uns et pas aux autres.

Cette fonctionnalité de l’IOS est très intéressante dans le cadre de la gestion des accès aux équipements d’un réseau en
environnements de productions. Le niveau de granularité offert par ce modèle permet de donner à chacun un niveau de privilège
adéquat en fonction de son périmètre d’intervention.

Pour conclure cette introduction, le modèle de Cisco s’imprègne du modèle très rependu plus connu sous l’acronyme RBAC
« Role-Based Access Control ».

Comment mettre en œuvre sa stratégie ?

L’accès aux équipements ( routeur, switch pare-feu etc … ) devant se faire en fonction des besoins et des personnes habilités à y
accéder, il est donc nécessaire de se poser les questions suivantes :

Qui ?

Qui sont les personnes autorisées à accéder au système.

Quoi ?

Quel est le domaine d’intervention pour la ou les personnes devant accéder au système. Ceci se traduit dans la pratique, quelle
commande l’utilisateur pourra utiliser et donc quelle information pourra être exploité.

Où ?

Identifier pour quels équipements les utilisateurs serons habilités à accéder.

Quand ?

Identifier les tranches horaires permettant l’accès au système. A quel moment l’utilisateur en question pourra accéder au
système (5 /7, 7/7 etc …).

Comment ?

Dans le cadre de l’accès administratif à un équipement, savoir par quels moyens les exploitants ou autres accéderons au système
à administrer.

Pourquoi ?

Identifier les raisons pour lesquelles elles ont à accéder au système.

Rappel sur la sécurité des mots de passe :

Le mot d’ordre en terme de sécurité est simple, il n’est pas possible d’empêcher quelqu’un d’atteindre son objectif, cependant
il est possible de le ralentir dans ses actions et très fortement (plusieurs heures, jours, mois, années). L’objectif est tout
simplement de retarder l’échéance au maximum, les évolutions technologiques permettent à une personne mal intentionnée
quoi qu’il arrive d’atteindre son objectif.

Le risque
Il est important de rappeler l’existence de moyens permettant de s’affranchir de la connaissance d’un mot de passe pour un
compte donné par le biais de l’utilisation d’un genre d’outil utilisé en cryptanalyse. L’utilisation d’outil de type « brute force »
permet de réaliser des tentatives d’accès afin de trouver un mot de passe de manière dynamique (attaque par dictionnaire,
rainbow table ..).

• D’autre méthode permettent de trouver un mot de passe :

• La simple connaissance de la personne.
• L’ingénierie sociale.
• Ecoutes (sniffing réseaux, téléphonique etc …).
• Les techniques de cryptanalyse.
• Chevaux de Troie.
• Keyloggeurs.
• Phishing.
• Etc …

Les contres mesures :

La création d’un compte de connexion doit se faire dans les règles de l’art, à savoir respecter les consignes suivantes :

Le comportement des utilisateurs :

• Un mot de passe ne doit pas être noté sur un bout de papier ou autre support visible par le plus grand nombre.
• Un utilisateur ne doit en aucun cas divulguer ses accès à qui que ce soit et ce par un quelconque moyen (téléphone, vis-à-vis,
courrier électronique etc …).
• Toujours s’assurer de l’identité et des intentions de la personne souhaitant obtenir cette information.
• Sensibiliser les utilisateurs sur les risques associés à la négligence des règles de sécurité
Qui ne défend pas ses droits mérite de les perdre “Gérard Haas”.

Le login et le mot de passe :

• On parle souvent de la complexité du mot de passe, le login ne doit pas être en reste.
• Un mot de passe doit avoir une taille maximale pour une plus grande efficacité.
• Un mot de passe doit respecter un niveau de complexité. Plus un mot de passe est long et complexe, moins il sera facile de le
trouver (le temps de calcul sera croissant).
• Un mot de passe ne doit pas avoir de logique permettant à quiconque d’en déduire la valeur.
• Il est nécessaire de limiter le nombre de tentative infructueuse est bloquer l’accès durant un certain temps avant une
prochaine tentative (Holdtime).

Appliquer une stratégie d’accès au système :

• Le moyen d’accès doit permettre de garantir la confidentialité lors de sa transmission à travers un media. Le chiffrement des
données est la représentation la plus claire de la garantie de confidentialité. Exemple un accès en SSH ou HTTPS pour
l’administration.
• Indiquer au système d’exploitation que la création d’un compte doit respecter une complexité et une taille minimale (9
caractères, majuscule, minuscule, chiffre, caractères spéciaux).
• Définir des tranches horaires pour l’accès aux différents services lorsque ceci est applicable (définir des access-class aux accès
VTY par exemple).

Les étapes de la mise d’une stratégie d’accès en mode « role-

based » :
Identifier le rôle de chacun. Exemple ci-dessus:

• Pôle exploitation niveau 1 : Accès uniquement pour la visualisation des paramètres.

• Pôle exploitation niveau 2 : Accès permettant la visualisation des paramètres et la modification des paramètres de routage,
VLAN etc …
• Pôle exploitation niveau 3: Accès à l’ensemble des fonctions du système.
Avant de parler de paramétrage, il est nécessaire d’introduire le vocabulaire utilisé par Cisco dans le contexte de la mise en
œuvre d’une stratégie de type Role based CLI. Dans le cadre de la conception de cette stratégie d’administration, Cisco a
raisonné sur la base d’une logique d’implémentation hiérarchique de la gestion des différents profils.

Qu’est ce qu’une root view ?

Une root view ou vue racine :
• Il s’agit de la vue permettant la gestion des View et Superview.
• Il est nécessaire de disposer dun niveau de privilège 15 pour accéder à la vue root.
• Il est naturellement conseillé d’appliquer un mot de passe à l’accès de la vue racine.
Qu’est ce qu’une view ?
Une View ou vue est un profil disposant des caractéristiques suivantes :
• Une vue dépend toujours de la vue root ou d’une super vue
• Une vue contient la liste des différentes commandes pouvant être exécutées par l’exploitant.
• La création d’une vue ne nécessite pas obligatoirement l’application d’un niveau de privilège.
• Le niveau de privilège est tout simplement régi par les commandes pouvant être exécutées.
• Il est fortement conseillé d’appliquer un mot de passe à l’ensemble des vue.
• Les vues sont indépendantes les unes des autres.
Qu’est-ce qu’une superview ?
Une superview ou super-vue est un profil disposant des caractéristiques suivantes :
• Une super-vue dépend toujours de la vue root
• Une super-vue contient la liste des différents profils (view) appartenant par exemple à une entité
administrative de l’organisation.
• La création d’une super-vue ne nécessite pas l’application d’un niveau de privilège.
• Il est fortement conseillé d’appliquer un mot de passe à l’ensemble des super- vue.
• Les super-vue sont indépendantes les unes des autres.
• Une vue peut appartenir à plusieurs super vues.
• Il n’est pas possible d’associer des commandes à une super vues, ceci est le rôle d’une vue
L’image pouvant être appliquée à l’utilisation des super vues, est celle de la mise en œuvre d’une stratégie
active directory. Un compte est une vue, une stratégie appliquée à une OU est une superview, le tout dépendant
de l’arbre étant la forêt.
Schéma de principe :

Procéder au paramétrage de l’équipement:

1.Activer AAA
2.Créer un utilisateur de type administrateur (nécessaire à l’accès du mode root view).
3.Créer le compte.
4.Appliquer le modèle d’authentification local à la fonction AAA
5.Appliquer le modèle d’authentification au différents moyens d’accès (console, vty …).
6.Passer en mode “enable” afin de créer une vue.
7.Créer les différentes vues sur la base de votre stratégie.
8.Vérifier l’application des différentes vues.

Configuration des rôles et vues (views) :

Premièrement activer la fonction AAA :

rolebased_test(config)#config t
rolebased_test(config)#aaa new-model
rolebased_test(config)#exit
Créer un utilisateur de type administrateur et spécifier un mot de
passe enable (mode secret de préférence) :
rolebased_test(config)#username aghiles privilege 15 secret M@qu€1tE2016
rolebased_test(config)#enable secret level 15 téS1$2015@*A
rolebased_test(config)#aaa authentication login default local

Appliquer le modèle d’authentification aux différents moyens

d’accès (console, vty …) :
rolebased_test(config-line)#line console 0 0
rolebased_test(config-line)#login authentication default
rolebased_test(config-line)#line vty 0 15
rolebased_test(config-line)#login authentication default

Le paramétrage des différentes vues:

Dans un premier temps il est nécessaire de passer dans le contexte VIEW afin de créer et administrer les vues.

Dans un premier temps il est nécessaire de passer dans le contexte VIEW afin de créer et administrer les vues.
Passer en mode view:
rolebased_test#enable view
*Mar 1 00:01:34.035: %PARSER-6-VIEW_SWITCH: successfully set to view ‘root’.

Configuration des différentes SUPERVIEW :

Bien que dans notre contexte la superview ne sera pas utile, cependant dans un but purement péadagogique, l’implémentation
est tout de même décrite.

La création d’une superview nécessite de configure les éléments suivants:

1.Créer la superview
2.Définir un mot de passe
3.Intégrer les différentes view dans la superview

Configuration:
rolebased_test(config)#parser view production superview
*Mar 1 00:33:15.967: %PARSER-6-SUPER_VIEW_CREATED: super view ‘production’ successfully created.

rolebased_test(config-view)#?
View commands:

default Set a command to its defaults

exit Exit from view configuration mode

no Negate a command or set its defaults

secret Set a secret for the current view

view View to be added to SuperView

rolebased_test(config-view)#secret production
rolebased_test(config-view)#view exploitn1
*Mar 1 00:33:54.783: %PARSER-6-SUPER_VIEW_EDIT_ADD: view exploitn1 added to superview production.

rolebased_test(config-view)#view exploitn2
*Mar 1 00:33:56.507: %PARSER-6-SUPER_VIEW_EDIT_ADD: view exploitn2 added to superview production.

rolebased_test(config-view)#
Configuration des différentes VIEW :
Affecter les droits pour chacune des vues.
Création du compte exploin1 :
rolebased_test(config)#parser view exploitn1
rolebased_test(config-view)# secret 5 $1$c2MW$M5KUmRH/VcwWt/Ut5yM1y0
rolebased_test(config-view)# commands exec include traceroute
rolebased_test(config-view)# commands exec include ping
rolebased_test(config-view)# commands exec include show ip route
rolebased_test(config-view)# commands exec include show ip
rolebased_test(config-view)# commands exec include show version
rolebased_test(config-view)# commands exec include show interfaces
rolebased_test(config-view)# commands exec include show
rolebased_test(config-view)#
rolebased_test(config-view)#exit
rolebased_test(config)#
Création du compte exploin2:
rolebased_test(config)#parser view exploitn2
rolebased_test(config-view)#
*Mar 1 00:09:52.827: %PARSER-6-VIEW_CREATED: view ‘exploitn2′ successfully created.
rolebased_test(config-view)#password 5 exploitn2
rolebased_test(config-view)#commands exec include ping
rolebased_test(config-view)#commands exec include trace
rolebased_test(config-view)#commands exec include show version
rolebased_test(config-view)#commands exec include show interfaces
rolebased_test(config-view)#commands exec include show run
rolebased_test(config-view)#commands exec include show config
rolebased_test(config-view)#commands exec include show ip hardware
rolebased_test(config-view)#commands configure include access-list
rolebased_test(config-view)#commands configure include clock
rolebased_test(config-view)#commands configure include hostname
rolebased_test(config-view)#commands configure include interface
rolebased_test(config-view)#commands configure include ip
rolebased_test(config-view)#commands configure include line
rolebased_test(config-view)#
Création du compte exploin3:
La création d’un compte pour un utilisateur de niveau 3 est beaucoup plus simple, l’application d’un compte de type level 15 est
largement suffisant.

rolebased_test(config)# username exploitn3 privilege 15 view exploitn3 secret 5

$1$gWjV$Z6qFqdejgO.it9XoZvAIr1

Comment supprimer une VIEW ?

Il faut savoir que la suppression doit se faire en mode enable view afin d’accèder au différents profils.

Exemple ci-dessus:

rolebased_test(config)#no parser view showcommand

No view Active! Switch to View Context

Les étapes:
Passer en mode enable view

rolebased_test#enable view
Passer en mode de configuration globale

rolebased_test#conf t
Exécuter la commander permettant de supprimer la vue concernée.

rolebased_test(config)#no parser view configure

Exemple de suppression ci-dessous:

rolebased_test#enable view
rolebased_test#

*Mar 1 00:42:48.359: %PARSER-6-VIEW_SWITCH: successfully set to view ‘root’.

rolebased_test#
 rolebased_test#conf t
Enter configuration commands, one per line. End with CNTL/Z.

rolebased_test(config)#no parser view configure

*Mar 1 00:42:54.991: %PARSER-6-VIEW_DELETED: view ‘configure’ successfully deleted.

rolebased_test(config)#no parser view showcommand

*Mar 1 00:42:57.755: %PARSER-6-VIEW_DELETED: view ‘showcommand’ successfully deleted.

rolebased_test(config)#

Commande permettant de visualiser les VIEW et SUPERVIEW configurées:

rolebased_test#show parser view all

Views/SuperViews Present in System:

exploitn2

exploitn1

production *

——-(*) represent superview——-

rolebased_test#