Administration Réseau-système
Principales nouveautés techniques propres à V3
Yüklə 181,14 Kb.
|
- Bu səhifədəki naviqasiya:
- 2.6 Structure du message
- Modèle de sécurité
- Qui êtes vous
- Yes/No decision
2.5 Principales nouveautés techniques propres à V3
2.6 Points faibles du modèle SNMPv3
2.6 Structure du messageL’action des différents sous systèmes se traduit dans la composition du message (figures 4 et 6). La structure du message se divise en 4 champs :
msgMaxsize : taille maximum du message supporté par l’expéditeur du message. msgFlags : masque indiquant le degré de sécurisation du message, ainsi que la possibilité ou non de provoquer une PDU REPORT en retour (PDU de service entre machines SNMP) msgSecurityModel : actuellement ne peut être que 3 (USM) dans un tel message.
On retrouve une partie des objets présents dans la table USM. (identifiant Engine, paramètres de temps de la cible, Principal, et selon le degré de sécurité, le résultat de l’application des clés sur le message (Salt values).
La PDU est accompagnée (dans le cas général) de son nom de contexte et de l’identifiant correspondant. Pour illustrer le cas de contextes différents, un switch ATM par exemple, pourrait affecter à chaque interface un contexte différent, les adresses IP et MAC étant différentes. A ne pas confondre avec snmpEngineID correspondant à l’adresse sous laquelle cet équipement répond. 2.7 Déroulement des opérations Le message donné en exemple est le résultat de l’opération, la réponse du Responder à l’Initiator. Pour parvenir à communiquer avec le Responder, cela suppose que l’expéditeur (l’Initiator) connaisse du destinataire (Responder), outre les clés requises, les renseignements suivants : L’identifiant snmpEngineID cible Les paramètres de temps de la cible (Responder) snmpEngineBoots et snmpEngineTime Dans le cas étudié, si le processus de découverte du gestionnaitre (Initiator) n’a pas enregisté la machine authoritative, il doit y avoir une première requête avec les champs de sécurité vides. Le responder répond par une PDU REPORT (service entre machines SNMP), qui contient les paramètres désirés. Un deuxième get-request avec un message complet permettra le succès de l’opération. Exemple de commandes SNMP mode ligne avec NET-SNMP (ancien UCD-SNMP) sur LINUX Exemple de commande SNMPv1 snmpget –v 1 localhost public .1.3.6.1.2.1.1.4.0 (communauté = « public ») 1.3.6.1.2.1.1.4.0 (sysContact) = M.Dupont
1.3.6.1.2.1.1.3.0 (SNMPv2-MIB::sysUpTime.0) Value: Timeticks: (249447) 0:41:34.47
L’utilisateur (Principal) xavier Le protocole d’authentification MD5 Le password de xavier passsnmpv3 (lequel mouliné avec EngineID => clé d’authentification) La cible (ici localhost) L’OID de la variable cible 1.3.6.1.2.1.3.0 : sysUpTime du groupe système, (.0) pour instance unique 
Figure 5
.
Simple Network Management Protocol Version: 3
Message Global Header Length: 13 Message ID: 9 Message Max Size: 1472 Flags: 0x01 .... .0.. = Reportable: Not set .... ..0. = Encrypted: Not set .... ...1 = Authenticated: Set Paramètres de sécurité SnmpEngineID = 800007E501869E619D Engine Boots et Time doivent coïncider avec ceux de la cible (Time à +/-150s près) Auth params : l’application de la clé à l’arrivée doit donner le même résultat Priv param : permet, si il y a cryptage , de retouver, avec la clé, le vecteur d’initialisation (IV) et ainsi de décrypter scoped PDU Message Security Model: USM Message Security Parameters Message Security Parameters Length: 46 Authoritative Engine ID: 800007E501869E619D Engine Boots: 5 Engine Time: 2494 User Name: xavier Authentication Parameter: DA4D094554A2946557EB7F74 Privacy Parameter: Context Engine ID: 800007E501869E619D
Qui met en œuvre le mécanisme décrit plus bas (& VACM). 4 tables contiennent l’ensemble des paramètres qui déterminent ce contrôle. Context Name: PDU type: RESPONSE Request Id: 0x8 Error Status: NO ERROR Error Index: 0 Object identifier 1: 1.3.6.1.2.1.1.3.0 (SNMPv2-MIB::sysUpTime.0) Value: Timeticks: (249447) 0:41:34.47 2.8 Avancée fondamentale : la sécurisation des échanges en deux phases La sécurisation dans SNMPv3 est réalisée à deux niveaux :
Authentification de la source, contrôle de l’intégrité du message Eventuellement cryptage des informations à protéger (on notera qu’il est possible de travailler sans authentification ni cryptage, mais pas sans contrôle de la fenêtre en temps). Contrôle du timing pour éviter les manipulations de ré-émission ou modification de séquence (maximum de +/- 150s d’écart pour l’accès à la machine « authoritative », si le nombre de redémarrage coïncide). L’accès à la machine « non authoritative » est moins sévère, le temps du message entrant ne devant pas retarder de plus de 150s.
VACM est actuellement le seul mécanisme de contrôle d’accès retenu dans SNMPv3. Rappelons que le contrôle d’accès sur la MIB d’un équipement, supportant SNMPv3, sera applicable à des commandes SNMPv1 ou v2C. C’est un des points remarquables de la nouvelle architecture. Ce deuxième niveau de sécurité est réglementé par les objets des différentes tables du sous-système VACM dont les fonctionnalités sont données ci dessous. Le diagramme d’état figure 7 explicite le rôle des objets impliqués. SecurityToGroupTable La première vérification est réalisée au niveau du couple (securityName, securityModel) , le Principal qui essaye d’accéder doit être associé à un modèle de sécurité, et appartenir à un groupe figurant dans la table « securityToGroupTable ». Il est important de voir qu’on peut trouver des groupes dont le modèle de sécurité est SNMPv1, ou v2C. Un couple (securityName, securityModel) ne peut appartenir qu’à un groupe, mais un Principal (securityName) peut appartenir à plusieurs groupes avec des modèles de sécurité différents. Le modèle de sécurité v1 ou v2C, avec securityName associé est dérivé de la communauté (voir MIB SNMP-COMMUNITY-MIB dans la RFC 2576 traitant de la coexistence entre versions de SNMP).
On peut être amené à distinguer dans un équipement des zones à traiter séparément les unes des autres (on a évoqué des interfaces de commutateurs ATM par exemple, considérés comme des contextes différents). Cette table contiendra les noms des contextes. VacmAccessTable Cette table détermine la nature de l’accès demandé (Read/Write/Notify). Quatre index (groupe, modèle de sécurité, niveau de sécurité, et nom de contexte) déterminent la nature de l’opération. VacmViewTreeFamilyTable Cette table va conditionner la granularité plus ou moins précise de l’accès . l’OID SubTree (toutes les instances filles d’un point de l’espace de nommage), pourra être inclus ou exclu de l’accès (included/excluded) avec un raffinement procuré par un masque qui précisera sur l’OID de subTree, les instances précises que l’on veut inclure/exclure du champ d’accès. Les instances qui peuplent ces tables conditionnent le résultat de la primitive isAccessAllowed, résultat qui autorise ou non finalement l’opération sur l’instance de l’objet cible. Diagramme D’état de la primitive d’accès au sous-système de Contrôle d’Accès Status= isAccessAllowed (securityModel, securityName, securityLevel, viewType, contextName, variableName) Modèle de sécurité ?Niveau de sécurité Auth ? cryptage ?        
securityModel 
securityName
contextName  
securityModel securityLevel object-type
groupName viewType (read/write/notify)        
viewName   
VariableName(OID)    Qui êtes vous ?Model de sécurité ? Quel contexte ?Pour quoi faire ?Read/write Notify ? Quel objet de la MIB ? Quelle instance?  
Quel groupe ? object-instance
Figure 7 3. Coexistence entre les versions SNMPv1, V2c et V 3: L’importance du parc installé SNMPv1 et v2c imposait que le nouveau protocole prenne en compte l’existant, d’une façon aussi transparente que possible pour l’utilisateur. S’il est assez aisé d’équiper les gestionnaires des moyens de communiquer avec les différentes versions de SNMP, le problème des agents ne supportant qu’une version de SNMP nécessitait d’être traité avec soin. Cette situation avait déjà été rencontrée avec la coexistence entre version V1 et V2c. Des modules MIB écrits selon le SMIv1 peuvent continuer à être accédés par des versions de protocole utilisant des PDU SNMPv2. Toutefois , si on veut être en conformité avec le SMIv2, un certain nombre de changements (environ 20) doivent être apportés dans la modification de la MIB écrite en SMIv1[6 ]. Deux autres types de situations de coexistence sont à considérer : 1) Les entités en présence sont les suivantes : Gestionnaires ou agents ne parlant que V1 ou V1 et V2C 2) Gestionnaires et agents supportant V3 et en pratique capables de communiquer en V1 et V2C Les mécanismes pour communiquer avec des entités de versions SNMP différentes sont de deux sortes :
La fonction multilinguale est par exemple ce qu’on doit trouver dans le sous système MP (Message Processing) dans les entités SNMP implémentant la nouvelle architecture, coté gestionnaire et coté agent (MP pour V1, V2C, V3). Le seul réel problème est l’interrogation par une entité gestionnaire SNMPv1 d’une variable 64 bit provenant d’un agent écrit selon les règles du SMIv2. La traduction de la fonction proxy en SNMPv1doit ignorer ce type de variable. Une autre situation est celle qui permet d’utiliser les fonctionnalités de VACM, (limitation de l’accès à la MIB de l’agent) dans le cas d’une requête provenant d’un gestionnaire V1 ou V2c. Une MIB (snmpCommunityMIB) décrit les objets qui sont utilisés, permettant la translation communauté (securityName, securityModel). On a ainsi défini des valeurs de securityModel pour V1(=1) et V2C(=2) ainsi que messageprocessingModel pour V1 (=0) et V2C(=1). Un mécanisme « Community-based Security Model » va être invoqué en plus des modèles de traitement V1/V2C présents dans le sous système MP de la nouvelle architecture.
Pour les gestionnaires, de petits constructeurs ont fait l’effort (SNMPC de Castlerock, MG-SOFT… et d’autres). Ajoutons aussi le remarquable travail de NET-SNMP (ancien UCD produit libre offrant agent et gestionnaire SNMPv1, v2C, v3 en mode ligne sur la plupart des plates-formes UNIX et Windows) .
HP porte une lourde responsabilité dans l’attentisme de la communauté SNMP. La plate-forme HPOV est la référence dans le monde de l’administration réseau. Le retard de HP à intégrer en natif le nouveau protocole a été interprété que comme une marque de défiance vis à vis de SNMPv3. La solution (un peu confidentielle) de HPOV pour travailler en SNMPv3 est d’acquérir le logiciel commercial de SNMP RESEARCH ce qui n’est pas ce qu’on pourrait attendre d’un grand constructeur comme HP. La conséquence est que l’ensemble des matériels HP ignore SNMPv3 et privilégie à l’évidence les techniques WEB.
Cisco a introduit SNMPv3 partiellement sur certaines lignes de matériels (36XX , et 7000). Un aperçu est donné dans l’exemple qui suit, les fonctionnalités étant assez correctement vérifiées. Les autres matériels CISCO (switch 35XX ou 29XX) acceptent les instructions de configuration V3 mais redémarrent quand on applique une commande V3. En l’absence d’informations de réelles implémentations SNMPv3 dans des équipements réseaux, on se limitera à donner en annexe un apercu de l’exploration d’un serveur PPP 3640 de Cisco, accédé par un gestionnaire SNMPv3 UCD-SNMP sur LINUX. Les résultats avec un gestionnaire MG-SOFT (graphique) donnent les mêmes résultats
Le travail de réflexion sur l’évolution de SNMP et de son environnement est mené dans deux groupes de travail, EOS (Evolution Of SNMP) et SMIng (ng pour New Generation): SNMP est reconnu comme un mécanisme élégant pour échanger des messages bien formalisés entre entités. Cependant combien d’achats de plate-formes onéreuses, censées apporter des solutions, se résument finalement à une implémentation d’un mécanisme simple qui est d’envoyer des ping 24H/24, 7 jours/7 …. On espérait quelque chose de simple à installer, à utiliser et à comprendre (une solution finale en somme) et on s’aperçoit que l’investissement en temps est lourd pour matérialiser une administration digne de ce nom. Le protocole SNMP est simple, mais la difficulté réside dans la compréhension du contenu des MIBs, spécialement des MIBs constructeurs. La voie qui pourrait apporter un plus est peut être de compléter cette structure de données difficile à appréhender par de l’intelligence préparée spécialement à son environnement. On pense à des multiples et très légers « plug-in », « add-on » , peu onéreux qui pourrait enrichir spécifiquement les plate-formes génériques. Cette approche, qui rejoint les approches alternatives à SNMP, est envisageable pour deux raisons :
4.3 SMIng (ng pour New Generation), groupe EOS (Evolution Of SNMP) Le but au départ du groupe de réflexion SMIng était de s’attaquer aux imperfections du SMIv2 et devait aboutir à une proposition pour un SMI renouvelé (SMIng). Les évaluations ont été conduites dans l’environnement d’un projet parrallèle « libsmi », en y adjoignant un pré-compilateur (parser) ainsi qu’un genérateur de code. Les résultats d’une première étape ont été rassemblés dans une présentation [14]. Le groupe de travail SMIng travaillait alors sous l’égide de l’IRTF/NMRG (Network Management Research Group, IRTF Internet Research Task Force affilié à IETF). Un certain nombre de documents ont été produits :
L’IETF s’est alors impliqué dans le processus en créant le groupe « SMIng », dont les futures spécifications doivent être regroupées dans 4 parties distinctes :
Plusieurs Drafts ont été produits SNMP Extended Protocol MIB SNMP Row Operations Extensions SNMP Object Identifier Compression Efficient Transfer of Bulk SNMP data SNMP Bulk Data Transfer Extensions
Les remarques faites pour l’évolution de SNMP (intelligence accrue dans les équipements, omniprésence du WEB) sont applicables aux approches alternatives ou complémentaires. Ces approches seront simplement citées , avec références pour étude plus complète. La présentation diapositive privilégie les schémas et fonctionnalités de ces architectures.
L’administration OSI est antérieure à SNMP et les concepts de l’administration ont été posé par OSI. CMIP/CMIS a suivi le destin des produits OSI, qui se cantonnent dans des niches confidentielles. Les déploiements de CMIP/CMIS comptent quelques secteurs très particuliers (surveillance radar européenne de l’aviation civile, certains secteurs des telecoms…). Pour des institutions qui avaient un besoin impératif de sécurité, pour lesquelles le coût de l’installation n’était pas dissuasif, CMIP/CMIS constituait une réponse. Les applications OSI satisfont au modèle OSI, et s’appuient indifféremment sur le mode non connecté de OSI ou sur le mode connecté. Cette démarche est possible si on accepte de constituer un ensemble isolé, relié par lignes spécialisées par exemple. Aujourd’hui, l’arrivée de SNMPv3, le poids de TCP/IP doivent amener les utilisateurs de CMIP/CMIS à s’interroger sur la pérennité de leur choix.
On ne peut parler de SNMP et du WEB sans se référer à une des premières tentatives de marier SNMP et le WEB. Ecrit en langage PERL, MRTG tourne sur de nombreuses plates-formes UNIX (LINUX essentiellement). Le mécanisme est simple : lecture d’une variable à intervalles périodiques (5mn par défaut), génération de pages WEB contenant des images GIF, visualisation par un navigateur WEB de l’historique des valeurs prises par la variable mesurée. Cette approche est à classer dans la rubrique des techniques de « Monitoring », SNMP effectuant des GET-REQUEST , c’est à dire des lectures de compteurs essentiellement. La surveillance par graphiques retraçant une historique s’applique à tout équipement (routeurs, stations, switches…)
Dans cette approche, un serveur WEB est implanté dans l’équipement qui possède une adresse HTTP. On parle alors d’un agent WEB lequel communique par HTTP avec une application d’administration. Un agent WEB peut être sophistiqué comparé à l’agent SNMP. Un autre avantage EWBM est qu’il peut tirer avantage des outils portables pour écrire l’agent WEB (par exemple WEB agent et WEB serveur peuvent être écrits en JAVA. On peut trouver des exemples d’implémentations commerciales d’agents WEB, mais elles sont basées sur des protocoles propriétaires. La plupart des constructeurs d’équipements réseaux ont une offre d’agent WEB dans leur Hubs et Switches. Ces agents WEB coexistent et communiquent le plus souvent avec l’agent SNMP. La communication avec l’application de gestion couplée au navigateur (Advance Stack Assistant chez Hewlett Packard) se fait par HTTP. Pour les switches, cette méthode est moins coûteuse que la sonde RMON attachée à chaque port.
DMI se situe entre les composants des architectures machine et les logiciels qui les gèrent. Des entités « component Agents », qui peuvent être du logiciel (scruteur de virus), ou matériel (carte réseau) dialoguent avec une application résidente « Desktop management » à travers DMI. DMI consulte une base de données au format « MIF » (Management Information Format comparable à la MIB de SNMP, utilisant aussi ASN.1) et communique avec les deux entités par le jeu d’API. Le but est d’arriver à gérer toutes les plate-formes sur un réseau de façon centralisée, indépendamment du constructeur et du système d’exploitation (DMI 2.0). DMI est assez différent de SNMP ; toutefois une tentative pour intégrer DMI dans SNMP a été tentée mais sans succès. Entre 1996-98, la mission de DMTF a été élargie pour intégrer les standard de gestion existants (SNMP, CMIP, DMI et HTTP) et promouvoir le projet WBEM (Web Based Entreprise Management). L’implication de Microsoft dans ce projet pourrait lui assurer une place significative dans la gestion des réseaux de PC.
Cela implique les points suivants :
WBEM n’a pas l’objectif de remplacer les protocoles établis (SNMP, et aussi CMIP) mais est censé intégrer ces techniques. Le navigateur WEB constitue l’interface utilisateur. L’architecture détaillée de WBEM peut être trouvée dans les documents cités en référence [11] et [15] Avantages de cette approche : Réduit la complexité des solutions d’administration, puisqu’elle offre, par un navigateur WEB, une visualisation complète des données d’administration. Yüklə 181,14 Kb. Dostları ilə paylaş:
|