Administration de réseaux

Présentation au sujet: "Administration de réseaux"— Transcription de la présentation:

1 Administration de réseaux

2 Sommaire INTRODUCTION SNMP MIB SYNTAX CONCLUSION Concept, Architecture
Modes de communication Caractéristiques générales Structure des messages SNMP v1, SNMP v2 MIB Espace de nommage MIB SNMP Equipements physiques gérés:Hubs, Ponts, Routeurs , RMON SYNTAX ASN1, SMI, Codage TLV, CONCLUSION

3 Administration réseaux
Exploiter, Opérer, Gérer les ressources du réseau pour délivrer un service aux utilisateurs du système d'information Garantir une QoS à ces utilisateurs La QoS se mesurera au travers de divers métriques caractérisant le fonctionnement, souvent un contrat de service (SLA).

4 Administration réseaux …
Installer, Configurer Surveiller, Détecter Evaluer les performances, la Qos Disponibilité ( Par exemple 95% 5 jours sur 7) De délai (Temps de réponse à une connexion) De capacité (Exemple : débit d'une ligne) Mais aussi Prévenir, Faire évoluer.

5 Modèle - Architecture

6 Que doit on administrer ? Architecture?
Tous les élements constituants le réseau, toutes les machines connectées au système Bâtir une solution consiste à élaborer un solution sur le mode client – serveur, ou plutôt agent manager, en utilisant principalement le protocole SNMP. Sur chaque élément managé un agent collecteur d’information (notion de répondeur à des messages, mais aussi envoi de messages non sollicités)

7 Protocole d’administration deux aspects
Les échanges d’information Protocole et définition de la structure des messages échangés entre les acteurs (agent, manager) Les données échangées Nature et structure

8 Equipements administrés ?
Equipements en réseaux : Stations, concentrateurs, ponts, switchs, routeurs Administrables et disposant d’un agent SNMP Attention!!! Il n’y a pas toujours d’agents disponible : ex. carte de management intégrer dans le châssis de l’équipement.

9 Protocoles ? SNMP: Issue des travaux de l’IETF
Simple Network Management Protocol) CMIS/CMIP: Issue des travaux de ISO Common Management Information Service/Protocol Plus spécifiques SNMP prédominant dans l’exploitation des équipements de réseaux. SNMP (Simple Network Management Protocol): rfc 1157 (1990) - utilise UDP : transmission simple ! Norme OSI d'administration de réseau (ISO 7498) : - CMIS/CMIP (ISO 9595 et 9596) : Common Management Information Service/Protocol ☞ CMOP (CMIP over TCP) : rfc1189. MIB (Management Information Base) : rfc 1156 ☞ Base de données répartie . indépendance vis-à-vis des protocoles (uniforme) . uniformité ≠ adaptabilité aux différents besoins (Ethernet : rfc 1398, FDDI : rfc 1512, pont : rfc 1493, DEC : rfc 1289) ☞ MIB-II : rfc 1213 (1993)

10 Gestionnaire de réseau
En un schéma ! Base d ’administration (compilation des Bases agents) Gestionnaire de réseau Protocole de gestion réseau. SNMP Agent Agent Agent Agent Bases d ’informations locales

11 Détails WAN Station de Gestion Réseau (NMS) Agent Agent Agent Agent
SERVEUR Agent STATION Agent ROUTEUR Agent Agent PONT Station de Gestion Réseau (NMS)

12 La notion de proxy Le modèle organisationnel, de ISO ou de l ’IETF, est basé sur une relation: Manager - Agent :via des échanges de messages réalisés par le protocole SNMP pour l’IETF et CMIP pour l’ISO Si l ’agent, ou le Manager, n ’utilise pas le même protocole, une tierce- party est nécessaire entre l ’agent et le Manager : PROXY AGENT (ou PROXY) Le rôle du Proxy-Agent est alors d ’adapter les données du message et le protocole pour qu’ils soient traités par le manager. MANAGER SNMP Objets non SNMP Agent SNMP Autre Agent Relation spécifique Protocole SNMP

13 SNMP

14 SNMP en 3 points Protocole d ’administration réseau Pour l’échange de MESSAGES d ’administration entre le gestionnaire de réseau et un agent dans l ’architecture TCP/IP Plusieurs versions SNMP V1, désigné aussi SNMP : Le plus utilisé (dans les petits sites) SNMP V2 : Pour des sites importants réparties géographiquement ; Cette version permet surtout une augmentation de la sécurité dans les échanges SNMP et l ’échange de certains types de messages d ’administration entre gestionnaires de réseau. SNMP V3 encore plus de sécurité Largement utilisé sur diffèrents systèmes par exemple: Unix, windows.

15 SNMP et TCP/IP SNMP s’appuie sur la couche transport UDP:
L'agent écoute sur le port n° 161 Le client (ou manager) écoute les alarmes (trap) sur le port n° 162 Le standard est défini dans la RFC1157 (SNMP V1). Le protocole respecte les principes suivants : chaque noeud géré est vu comme un ensemble de variables. La lecture de ces variables permet de superviser le réseau (au sens de voir son état) ; leur écriture permet d'agir sur le réseau pour le contrôler (d’où un problème fondamental sur la sécurité du réseau qui se trouve éventuellement à la merci d’une prise de pouvoir par un pirate). En plus des opérations de lecture-écriture, deux mécanismes sont introduits : l'opération de traversée et l'opération de trap.

16 Mode POLLING dirigé par TRAP
Mode communication GESTIONNAIRE DE RESEAU AGENT Mode SCRUTATION : C ’est le gestionnaire qui interroge régulièrement l ’agent. Mode INTERRUPTION : L ’agent envoie des messages sur des occurrences de conditions préprogrammées. Mode POLLING dirigé par TRAP Le gestionnaire polle l ’agent suite à un trap. MODES DE COMMUNICATION Mode SCRUTATION Mode INTERUPTION Mode POLLING dirigé par TRAP TRAP = Occurrence d ’un événement au niveau de l ’équipement agent

17 Mode de communication (2)
MESSAGES D ’ADMINISTRATION GESTIONNAIRE DE RESEAU AGENT Via le PROTOCOLE SNMP Le Gestionnaire peut demander : - des statistiques concernant : - le nombre de paquets traités - des status de fonctionnement (Ex : Interfaces) Le Gestionnaire peut envoyer : - des instructions pour modifier des entrées de la MIB - des seuils de conditions L ’agent peut envoyer : - des réponses aux requêtes du gestionnnaire - des traps (Exemple : lorsque la charge du trafic dépasse une limite matérielle) - des réponses, sur conditions atteintes

18 Mode de communication (3)
Dans le système d ’accueil (du gestionnaire ou de l ’agent) SNMP est indépendant du type de transport. Port 162 Requête/ Réponse Trap UDP Port 161 IP Autre Sous-réseau Ethernet

19 La communauté SNMP introduit une notion dite ‘communauté SNMP’. Une communauté SNMP désigne un groupement d ’agents et d ’applications gestionnaires appartenant à un même domaine d ’administration. Elle est identifiée dans le protocole SNMP V1 par le champ « community ». La valeur du champ « community » est une chaine de caractères qui désigne le « nom de la communauté ». La connaisssance de la valeur du champ ‘Community’ permet aux applications manager de modifier une variable de la MIB d’un agent (la communauté est spécifiée dans l ’agent). L’inconvénient majeur de SNMP V1 est que cette authentification est triviale (codage du champ en clair dans les échanges…. elle peut être connue aisément par un espion de ligne). Un agent, qui ne reconnaît pas le nom par lequel un manager tente de lui accéder enverra un trap « Echec d ’authentification ». Dans le protocole SNMP V2 d ’autres mécanismes, plus élaborés, sont définis pour la sécurisation (authentification et cryptage) des échanges. Le nom de communauté « public » ne permet que des accès de type lecture seule aux ressources administrées.

20 Résumé SNMP Caractérisé par l ’échange de MESSAGES entre manager et agent . Permet au manager de LIRE, de MODIFIER les variables de la MIB d ’un agent. Permet à l ’agent de signaler des évènements désignés TRAP. SNMP V2 permet des échanges de messages entre managers. Le codage (syntaxe) des différents paramètres du message SNMP utilise la notation ASN.1 Attention: SNMP V1 et SNMP V2 ne sont pas interopérables: Un manager SNMP V1 gère seulement des agents SNMP V1 Un manager SNMP V2 gère seulement des agents SNMP V2

21 Les messages échangés get-request : Recherche d ’une information d’administration spécifique get-next-request : Recherche de l ’information suivante (très utile pour parcourir des tableaux de la MIB) get-response : Réponse fournie par l’agent pour les requêtes précédentes set-request : Permet de modifier la valeur d’un objet administré trap : Reporting, par l ’agent, d’évènements Manager Manager Agent SNMP Agent SNMP Get-Request GetNext-Request Set-Request Trap Get-Response

22 Synoptique des échanges
Base d’informations d’administration du réseau Ressources administrées APPLICATION D ’ADMINISTRATION MIB Gestion d’OBJETS Objets gérés par SNMP MIB MANAGER AGENT SNMP GET ; SET Request GET Response TRAP Protocole SNMP GET Response TRAP GET ; SET Request Réseau de communication

23 Structure messages SNMP V1
Version Community PDU Version Community PDU Authentification (Chaîne ASCII) GetRequest-PDU GetNextRequest-PDU GetResponse-PDU SetRequest-PDU Trap-PDU (0) pour la version 1 Remarque : Le nom de commmunité « public » ne permet qu’un accès en lecture.

24 PDU get/set (0) GetRequest (1) GetNextRequest (2) GetResponse
Type PDU Identificateur Etat d ’erreur Index erreur Objet 1, Valeur 1 Objet 2 , Valeur Définition des variables objets et valeurs associées (0) GetRequest (1) GetNextRequest (2) GetResponse (3) SetRequest Index pointant sur la variable origine de l ’erreur (le champ état d ’erreur n ’est positionné que sur Get-Response-PDU ) (0) noerreur Opération réalisée correcte (1) TooBig La réponse ne peut pas tenir dans le PDU get-Response (2) noSuchName L ’objet demandé n ’existe pas. (3) badValue La valeur fournie, par la requête set, n ’est pas correcte (4) readOnly Lecture autorisée seulement sur l ’objet (5) genErr Autre type d ’erreur Valeur permettant de corréler la réponse à la requête

25 PDU Les traps Adresse IP de l ’agent émettant le trap
Type PDU entreprise Adresse agent Type de trap générique Type de trap spécifique Horodatage Objet1, Valeur1 Objet2, valeur2 .. Adresse IP de l ’agent émettant le trap Définition des variables objets et valeurs associées (4) trap Temps entre dernière (ré) initialisation de l ’agent et la génération du trap (0) coldStart (1) warmStart (2) linkDown (3) linkUp (4) authentificationFailure (5) egpNeighborLoss (6) entrepriseSpecific Si trap « entrepriseSpecific » Identifie l’objet pour lequel le trap a été défini. Si trap « entrepriseSpecific » contient un numéro de trap spécifique à l ’application 0 : Réinitialisation de l ’équipement (la configuration a pu être modifiée) 1: Réinitialisation de l ’équipement (la configuration n’est pas modifiée) 2: Anomalie détectée sur un des liens de communication (l’interface concernée est indiquée en variable) 3: Un lien de communication est activé (l’interface concernée est indiquée en variable) 4: :Message reçu mal authentifié 5: Perte de contact avec le voisin (Routeur EGP) 6 : Trap non générique (spécifique à un fabricant)

26 SNMP V2 Le RFC 1446 définit les règles de sécurité SNMP V2;
Le RFC 1450 définit les MIB SNMP V2; Le RFC 1448 définit les opérations de protocole. SNMP V2 a pour vocation première d’intégrer des fonctions de sécurité plus élaborées que SNMP V1: Par l’authentification des entités communicantes d ’administration afin de garantir la confidentialité des lectures et l’intégrité des données modifiables Basée sur le calcul d ’une valeur secrète en utilisant l’algorithme MD5 La clé est une valeur connue du manager et de l ’agent Par la confidentialité des données échangéesr Cryptage des données échangées: Chiffrement, à base de clé, au niveau applicatif Les contenus des messages sont protégés: seules les adresses (émetteur et recepteur) transitent en clair, recours à l’algorithme DES Une des plus grandes faiblesses du protocole SNMPv1 est l'absence d'un mécanisme adéquat pour assurer la confidentialité et la sécurité des fonctions de gestion. Les faiblesses comprennent aussi l'authentification et le cryptage, en plus de l'absence d'un cadre administratif pour l'autorisation et le contrôle d'accès. Ce problème rend la sécurité sur SNMPv1 du type : "SHOW-AND-TELNET", c'est à dire qu'on utilise SNMP pour l'acquisition des données de gestion, mais pas pour effectuer le contrôle on utilise le protocole Telnet. Le groupe de travail de l'IETF qui a œuvré sur SNMPv2 a voulu inclure la sécurité dans la nouvelle version. Malheureusement, ce groupe n'a pas pu atteindre un consensus sur le fonctionnement du mécanisme de sécurité. Partant de là, deux propositions ont été développées (SNMPv2u et SNMPv2*). La plupart des experts s'entendent pour dire que deux standards SNMP ne peuvent pas coexister, et que ceci n'est pas une solution à long terme. Tous les consensus du groupe de travail ont été rassemblés (uniquement les améliorations qui ne portaient pas sur la sécurité), et le groupe de travail SNMPv2 de l'IETF a terminé ses travaux en publiant une version de SNMPv2 (on l'appelle SNMPv2c, RFC 1901, RFC 1905 et RFC 1906) sans sécurité.

27 SNMP v2 – Modifications sur les messages
GetBulkRequest : pour transférer de grands blocs d’informations (Ex : tables) InformRequest : échange d’informations entre Managers SNMPV2-trap : remplace le trap de SNMP V1 Les améliorations de SNMPv2c SNMPv2c a introduit quelques nouveaux types, mais sa nouveauté majeure est l'opération GETBULK, qui permet à une plate forme de gestion, de demander en bloc de plusieurs variables consécutives dans la MIB de l'agent. Généralement, on demande autant de variables que l'on peut mettre dans un paquet SNMP. Ceci règle un problème majeur de performance dans SNMPv1. Avec la version 1, la plate forme est obligée de faire un GETNEXT et d'attendre la réponse pour chaque variable de gestion.

28 Structure des messages SNMP V2
Entête SNMP V PDU SNMP V2 Informations pour l ’Authentification et la confidentialité Type de PDU IDentificateur Etat d ’erreur Index erreur Variables (Objets, valeurs) Idem SNMP V1 (pour les PDU 0 à 4) Types de PDU (0) GetRequest (1) GetNextRequest (2) GetResponse (3) SetRequest (4) Obsolète (5) GetBulkRequest (6) InformRequest (7) SNMPV2-trap

29 Sécurité - SNMP V3 User Security Module (USM)
View- based Access Control Model) (VACM) Cette nouvelle version du protocole SNMP vise essentiellement à inclure la sécurité des transactions. La sécurité comprend l'identification des parties qui communiquent et l'assurance que la conversation soit privée, même si elle passe par un réseau public. Cette sécurité est basée sur 2 concepts : USM (User-based Security Model) VACM (View- based Access Control Model)

30 Sécurité - SNMP V3 User Security Module (USM)
Trois mécanismes pour contrer des attaques type : Authentification Empêcher la modification des paquets SNMPv3 en cours de route S’assurer de la validité du mot de passe de l’émetteur à l’origine de la requête. Le cryptage Empêcher la lecture des informations de gestions contenues dans un paquet SNMPv3. L'estampillage du temps Empêcher la réutilisation d’un paquet SNMPv3 User Security Module (USM) Trois mécanismes sont utilisés. Chacun de ces mécanismes a pour but d'empêcher un type d'attaque. L'authentification : Empêche quelqu'un de changer le paquet SNMPv3 en cours de route et de valider le mot de passe de la personne qui transmet la requête. Le cryptage : Empêche quiconque de lire les informations de gestions contenues dans un paquet SNMPv3. L'estampillage du temps : Empêche la réutilisation d'un paquet SNMPv3 valide a déjà transmis par quelqu'un.  L'authentification L'authentification permet d’assurer que le paquet reste inchangé pendant la transmission, et que le mot de passe est valide pour l'usager qui fait la requête. La construction de ce mécanisme repose sur fonctions de hachage (Exemples de fonctions: MD5 et SHA-1). Ces fonctions prennent en entrée une chaîne de caractères de longueur indéfinie, et génèrent en sortie une chaîne d'octets de longueur finie (16 octets pour MD5, 20 octets pour SHA-1). Pour authentifier l'information qui va être transmise, on doit aussi avoir un mot de passe qui est « partagé ». Le mot de passe ne doit donc être connu que par les deux entités qui échangent les messages.

31 Sécurité - SNMP V3 Authentification
S’assuer de l’invariance du paquet transmis Validité du mot de passe (partagé par l'émetteur et récepteur ). → Recours aux fonctions de hachage ( MD5 et SHA-1). Message Digest 5 : md5 User Security Module (USM) Trois mécanismes sont utilisés. Chacun de ces mécanismes a pour but d'empêcher un type d'attaque. L'authentification : Empêche quelqu'un de changer le paquet SNMPv3 en cours de route et de valider le mot de passe de la personne qui transmet la requête. Le cryptage : Empêche quiconque de lire les informations de gestions contenues dans un paquet SNMPv3. L'estampillage du temps : Empêche la réutilisation d'un paquet SNMPv3 valide a déjà transmis par quelqu'un.  L'authentification L'authentification permet d’assurer que le paquet reste inchangé pendant la transmission, et que le mot de passe est valide pour l'usager qui fait la requête. La construction de ce mécanisme repose sur les fonctions de hachage (Exemples de fonctions: MD5 et SHA-1). Ces fonctions prennent en entrée une chaîne de caractères de longueur indéfinie, et génèrent en sortie une chaîne d'octets de longueur finie (16 octets pour MD5, 20 octets pour SHA-1). Pour authentifier l'information qui va être transmise, on doit aussi avoir un mot de passe qui est « partagé ». Le mot de passe ne doit donc être connu que par les deux entités qui échangent les messages. Figure authentification Les étapes d'authentification sont les suivantes : L’émetteur regroupe les données à transmettre avec le mot de passe. Une fonction de hachage à une direction est appliquée sur ces données. Emission des données et du code de hachage sur le réseau. Le récepteur prend le bloc des données, et y ajoute le mot de passe. La fonction de hachage à une direction est réappliquée sur ces données. Si le code de hachage calculé est identique au code reçu, l’metteur est authentifié. Avec cette technique, le mot de passe est validé sans qu'il ait été transmis sur le réseau. Quelqu'un qui saisit les paquets SNMPv3 passants sur le réseau ne peut pas facilement trouver le mot de passe.

32 Sécurité - SNMP V3 Cryptage
Protéger les informations de gestion (requêtes et les réponses ) des écoutes sur le réseau. Validité du mot de passe (partagé par l'émetteur et récepteur ). Recours aux fonctions de hachage ( MD5 et SHA-1).  Le cryptage Le cryptage a pour but d'empêcher que quelqu'un n'obtienne les informations de gestion en écoutant sur le réseau les requêtes et les réponses de quelqu'un d'autre. Avec SNMPv3, le cryptage de base se fait sur un mot de passe « partagé » entre le manager et l'agent. Ce mot de passe ne doit être connu par personne d'autre. Pour des raisons de sécurité, SNMPv3 utilise deux mots de passe : un pour l'authentification et un pour le cryptage. Ceci permet au système d'authentification et au système de cryptage d'être indépendants. Un de ces systèmes ne peut pas compromettre l'autre. SNMPv3 se base sur DES (Data Encryption Standard) pour effectuer le cryptage. On utilise une clé de 64 bits (dont 8 réservés à la parité, la clé réelle est sur 56 bits) . DES encrypte 64 bits à la fois. Comme les informations que l'on doit encrypter sont plus longues que 8 octets, on utilise du chaînage de blocs DES de 64 bits. Une combinaison du mot de passe, d'une chaîne aléatoire et d'autres informations forme le « Vecteur d'initialisation ». Chacun des blocs de 64 bits est passé par DES et est chaîné avec le bloc précédent avec un XOR. Le premier bloc est chaîné par un XOR au vecteur d'initialisation. Le vecteur d'initialisation est transmis avec chaque paquet dans les « Paramètres de sécurité », un champs qui fait partie du paquet SNMPv3. Contrairement à l'authentification qui est appliquée à tout le paquet, le cryptage est seulement appliqué sur le PDU. La RFC 3826 "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model" relate l'intégration d'AES dans SNMP. Celui renforce le chiffrement en remplacement du DES.

33 LES ENTETES (SECURITE)
Partie authentification privDest digest dstTimestamp srcTimeStamp dstParty srcParty context PDU privDst répète le champ dstParty. Cette répétition est faite pour avoir le destinataire en clair, quand tout le reste du message est encrypté. srcParty : Identifie le gestionnaire, ou l’agent, qui émet le message dstParty : Identifie le gestionnaire, ou l ’agent, destinataire du message context : Pour identifier le contexte d ’éxécution (au sein duquel les opérations sont restreintes) L ’authentification : Basée sur un mécanisme de signature : Utilisation du protocole MD5 (Message Digest 5) + clé d ’authentification La signature est le champ « digest ». La clé n ’est jamais transmise. Elle permet de confirmer que le message reçu est bien celui qui a été émis. Emetteur et récepteur font le même calcul avec même protocole et même clé L ’Encryptage : Utilisation de l ’algorithme DES (Data Encryption Standard)

34 Les objets MANAGES

35 MIB Base de données d’ informations (OBJETS associés à des valeurs ) maintenue par l'agent, et exploité par le manager Structure arborescente ou chaque nœud est défini par un nombre ou OID (Object Identifier). Nomenclature hiérarchisée. – Exemple : iso.org.dod suite de n° correspondants aux n° de feuilles Géré par l ’ISO –UIT 2 MIB publics normalisées MIB I et II (les MIB propriétaires intégrées à cet espace de nommage). Management Information base – MIB La MIB (Management Information base) est la base de données des informations de gestion maintenue par l'agent, auprès de laquelle le manager va venir pour s'informer. Deux MIB publics ont été normalisées: MIB I et MIB II (dite 1 et 2) Un fichier MIB est un document texte écrit en langage ASN.1 (Abstract Syntax Notation 1) qui décrit les variables, les tables et les alarmes gérées au sein d'une MIB. La MIB est une structure arborescente dont chaque nœud est défini par un nombre ou OID (Object Identifier). Elle contient une partie commune à tous les agents SNMP en général, une partie commune à tous les agents SNMP d'un même type de matériel et une partie spécifique à chaque constructeur. Chaque équipement à superviser possède sa propre MIB. Non seulement la structure est normalisée, mais également les appellations des diverses rubriques. Ces appellations ne sont présentes que dans un souci de lisibilité. En réalité, chaque niveau de la hiérarchie est repéré par un index numérique et SNMP n'utilise que celui-ci pour y accéder.

36 Les types de MIBs Standard, ( organismes de normalisation, Ex :IETF )
Propriétaires Standard, ( organismes de normalisation, Ex :IETF ) - MIB 1; MIB 2; MIB Rmon (Ethernet; TR; FDDI) ; MIB ponts ; MIB routeurs Propriétaires, spécifiques aux constructeurs, - Manager leurs équipements propres .

37 Espace de nomage Racine (sans nom, ni numéro) 1 iso uit 2
1 iso uit 2 iso/uit (Groupe ISO/UIT) 1 2 3 iso.org (organisation identifiée) iso.org.dod 1 2 3 4 5 6 Administré par l ’IAB Internet -Les MIB II SNMP dans l ’espace de nommage : -Les MIB propriètaires dans l ’espace de nommage: 1 directory mgmt experimental private security snmp v2 1 2 3 4 5 6 experimental : Les nouveaux objets sont expérimentés dans Internet Si succès, migration vers Management directory : Reservé pour intégration des annuaires ISO (ex : X500) Non utilisé par SNMP private :Permet aux constructeurs d ’apporter des MIB ’s spécifiques, dont les objets sont absents dans MIB II SNMP 1 1 entreprises mib (MIB II SNMP) 2 9 36 ...... IBM Cisco DEC

38 Espace de nommage Nouveaux objets expérimentés sur Internet
Racine (sans nom, ni numéro) uit iso iso/uit (Groupe ISO/UIT) 1 2 iso.org (organisation identifiée) 1 2 3 iso.org.dod 1 2 3 4 5 6 experimental : Nouveaux objets expérimentés sur Internet Si succès, migration vers Management directory : Reservé pour intégration des annuaires ISO (ex : X500) Non utilisé par SNMP private : Apports spécifiques par les constructeurs si objets absents des MIB II SNMP Espace de nommage : 1.3.6

39 Espace de nommage iso.org.dod Administré par l’IAB Internet directory
3 iso.org.dod 6 Administré par l’IAB Internet directory 1 experimental security private snmp v2 1 mgmt 2 3 4 5 6 1 mib MIB II SNMP 1 entreprises 2 9 36 ... IBM Cisco DEC Internet Architecture Board  = IAB Espace de nommage : MIB II SNMP : MIB propriètaires :

40 La mib II 1 Définition des objets approuvés par l ’IAB 1 3 5 7 10 14 17 at transmission bridge system icmp udp ospf 2 4 6 8 11 15 16 23 interfaces ip tcp egp snmp bgp rmon rip 9 26 cmot MIB 1 (RFC 1156) hub Autres MIB standard MIB 2 (RFC 1213) MIB 1 et 2 structurées en GROUPES d ’administration mib I : 8 groupes (system; interfaces; ...) mib II : 10 groupes (system; interfaces; ...)

41 Annexe - Détails sur mib I et mib II
Les groupes d’objets de MIB 1 et MIB 2 sont définis essentiellement pour gérer une architecture TCP/IP Nombre de VARIABLES MIB 1 MIB2 Groupe d ’objets Définition system Informations générales sur l ’équipement 3 7 interfaces Informations sur les interfaces réseaux at Informations sur la résolution d ’adresses IP 3 3 ip Informations sur les paquets IP et tables routage 33 38 icmp Compteurs sur les messages ICMP tcp Informations sur les datagrammes TCP udp Informations sur les datagrammmes UDP 4 7 egp Informations sur le routage EGP transmission Informations détaillées sur un type d ’interface 0 snmp Informations sur les messages SNMP - 30

42 Variables du groupe system
d ’Objets Variables Nommage Description Accès system( .1) sysDescr .1 Description générale de l ’équipement RO sysObjectID .2 Identité de l ’objet RO sysUpTime .3 Temps écoulé depuis réinitialisation RO sysContact .4 Responsable à contacter RW sysName .5 Nom de l ’équipement RW sysLocation .6 Localisation e  ’équipement RW sysServices .7 N° du service offert par l ’équipement RO 1 physique (ex : répéteur) 2 liaison de donnée (ex: pont) 4 Internet (ex : routeur) 7 Application (ex : passerelle) RO = Read Only RW = Read and Write Accès aux variables

43 Exemple groupe system 0x48 (transport, application) Services offerts
sysServices ‘Bâtiment II pièce H33’ localisation sysLocation ‘g-Routeurxxx.fr’ Nom de l’équipement sysName Nom de la personne à contacter sysContact Durée depuis le démarrage de l’agent sysUpTime Identité de l’objet sysObjectID « Routeur Velizy--n°2 » Description de l’équipement sysDescr

44 Groupe interface GROUPE d ’Objets Désignation VARIABLE Nommage Description Accès interfaces ( .2) ifNumber Nombre d ’interfaces (actives ou non) RO ifTable. ifEntry able des entrées des interfaces NA ifIndex N° de l ’interface dans la table RO ifDescr Description de l ’interface RO ifType Type d ’interface (ex:Eth; TR; ..) RO ifMtu Valeur du MTU RO ifSpeed Débit de l ’interface en bits/s RO ifPhysAddress Adresse physique RO ifAdminStatus Etat normal de l ’interface RW ifOperStatus Etat actuel de l ’interface RW ifLastChange Quand l ’interface est passé opérationnel RO ifInOctets Nbre d ’octets reçus RO ifUnUcastPkts Nbre de paquets, en unicast, fournis RO ifUnNUcastPkts Nbre de paquets ,en diffusion, fournis RO ifInDiscards Nre de paquets rejetés par défaut place RO ifInErrors Nbre de paquets erronés RO ifInUnknownProtos Nbre de paquets rejetés,protocole erroné RO ifOutOctets Nbre d ’octets transmis RO ifOutUcastPkts Nbre de paquets, en unicast, soumis RO ifOutNUcastPkts Nbre de paquets , en diffusion, soumis RO ifOutDiscards Nbre de paquets rejetés par l ’interface RO ifOutErrors Nbre de paquets non transmis RO ifOutQLen Capacité, en nbre de paquets ,de la file RO ifSpecific Référence OID vers infos constructeur RO

45 Extension du groupe transmission
1 Mib SNMP ( ) 10 transmission 5 7 9 15 16 32 33 x25 dot3 dot5 fddi lapb frame relay rs-232 Objets X25 (RFC 1382) Objets TR (RFC 1231) Objets LAP-B (RFC 1381) Objets RS232 Objets Ethernet (RFC 1398) Objets FDDI (RFC 1512) Objets FR (RFC 1382)

46 Qu’administre t-on? Composants physiques :
Accès médias ; transceivers ; cartes d ’interface réseau; répéteurs ... Groupes d’objets pour ces équipements : MIB 1 ou MIB 2 system (mib.1) Identification de l ’équipement physique interface (mib.2) Description de l ’interface et statistique de trafic transmission (mib.10) Informations propres à l ’interface

47 HUB La MIB HUB IEEE (mib. 26 définie par le RFC 1516) est dédiée à la gestion de répéteur Hub IEEE 802.3 2 groupes d ’objets : Groupe de base intégrant des objets valables pour tous les répéteurs ( Ex : état ; configuration ....) Groupe de statistique et contrôle pour le trafic et informations sur les ports Si la MIB est inadéquate pour la gestion de l’équipement, recourir à la MIB propriétaire.

48 ROUTEURS Groupes d ’objets : Aspects généraux
system (mib.1) Identification de l ’équipement routeur interface (mib.2) Description des interfaces et statistique des trafics transmisssion (mib.10) Informations spécifiques aux interfaces Groupes d ’objets : Routeurs IP at (mib.3) Traduction des adresses IP- adresses sous-réseaux ip (mib.4) Informations sur les paquets IP icmp (mib.5) Informations sur les messages ICMP egp (mib.8) Informations sur le protocole de routage EGP (si nécessaire) snmp (mib.11) Informations sur les messages SNMP Extensions supplémentaires : ospf (mib.14) Informations sur le protocole de routage OSPF rip (mib.23) Informations sur le protocole de routage RIP version 2 bgp (mib.15) Informations sur le protocole de routage BGP version 4 Remarque : Pour des fonctionnalités spécifiques recourir aux extensions MIB propriétaires.

49 SONDES Développement de MIB RMON : Permettre à des Agents SNMP spécifiques de : Capturer le trafic sur un segment de réseau (ex : Ethernet ou Token-Ring) Traiter ce trafic, en fonction des directives de l ’administrateur, pour en élaborer principalement des résultats de statistiques, des alarmes De restituer les résultats et/ou alarmes vers le MANAGER Cette Fonction est désignée par « SONDE Rmon ». Après paramétrage, la sonde autonome pendant l’exploitation , élabore les résultats. Elle décharge le manager de ces types d ’activités et permet d ’éviter des trafics de flux importants vers le manager. Elle est surtout utilisée dans le cadre d ’audits réseaux ou pour analyse de problèmes de trafics à différentes époques . Une sonde est livrée avec son logiciel spécifique d ’exploitation à intégrer au manager.

50 Les sondes Manager (+ logiciel d ’exploitation sonde) WAN Agent Rmon
Chaque agent gère la MIB rmon Agent Rmon Agent Rmon Agent Rmon

51 Sonde RMON Dispose d’une ou plusieurs interfaces pour la capture simultanée de trafics. Requiert une capacité de calcul Peut être intégrée dans : Une carte réseau + firmware ou logiciel (ex : PC) Un module spécifique dans un équipement d ’interconnexion; Un équipement dédié (boitier).

52 MIB RMON La MIB RMON (Niveau couche MAC) comprend :
9 Groupes standard de MIB RMON (RFC 1271), utilisés pour Ethernet. 6 Groupes de MIB RMON (RFC 1513) pour la gestion de Token-Ring. Il existe d’autres groupes 1 Mib ( ) 16 4 3 2 8 6 5 7 rmon 9 statistics alarm hostTopN filter event history host matrix packet capture 10 tr ring station control table order configuration source routing

53 Annexe - Groupes rmon statistics (rmon.1) : Statistique du trafic sur un segment Charge du réseau (nb de trames; d’octets; de collisions), Distribution des trames par taille, Trames en erreurs (de CRC; trop courtes; trop longues), Trafic opératoire (trames broadcast; multicast) history (rmon.2) : Statistiques périodiques sur des variables. alarm (rmon.3) : Fixer des seuils d’alarme. host (rmon.4) : Statistique du trafic sur un host (trafic émis, reçu; broadcast; multicast ...) hostTopN (rmon.5) : Etend le groupe « host », fournit des statistiques triées. matrix (rmon.6) : Matrice de trafic niveau MAC, construite par paire de hôtes (paire = hôte émetteur-hôte recepteur) . filter (rmon.7) : Etablir des filtres pour générer des évènements ou capturer du trafic relatif au filtre. packet capture (rmon.8) : Trafic mémorisé en fonction du critère filtre. Event (rmon.10) : Evènements générés et transmis par l ’agent. L ’administrateur peut donc contrôler les variables qui lui semblent opportunes, et faire générer des évènements en cas de mauvais fonctionnement. statistics (rmon.1) : Statistique du trafic sur un segment Charge du réseau (nb de trames; d’octets; de collisions), Distribution des trames par taille, Trames en erreurs (de CRC; trop courtes; trop longues), Trafic opératoire (trames broadcast; multicast) history (rmon.2) Pour enregistrement périodique de statistique sur différentes variables. Il permet donc d’établir un historique sur le comportement des différentes variables. alarm (rmon.3) Pour permettre de détecter des seuils d’alarme. host (rmon.4) Statistique du trafic concernant un host sur le segment (trafic émis, reçu; broadcast; multicast ...) hostTopN (rmon.5) Etend le groupe « host » en fournissant des statistiques triées. matrix (rmon.6) Pour matrice de trafic au niveau MAC, construite par paire de hôtes (paire = hôte émetteur-hôte recepteur) . filter (rmon.7) Permet d ’établir des filtres, dans le but de générer des évènements ou de capturer du trafic relatif au filtre. packet capture (rmon.8) Trafic mémorisé en fonction du critère filtre. Event (rmon.10) Evènements générés et transmis par l ’agent. L ’administrateur peut donc contrôler les variables qui lui semblent opportunes, et faire générer des évènements en cas de mauvais fonctionnement.

54 Annexe : MIB II de rmon protocol directory : Définit les protocoles que la sonde peut analyser protocol distribution Maintenir des statistiques fonction des protocoles. permet de connaître l ’allocation de bande passante utilisée par les différents protocoles adress mapping Etablir la correspondance et l ’interface correspondante network layer host Comptabilse les trames envoyées ou reçues par .Ces Statistiques ne sont plus limitées au segment network layer matrix Réaliser des statistiques entre paires application layer host Comptabilse le volume de trafic par protocole, émis ou reçu par statistiques au niveau application. application layer matrix Réaliser des statistiques de trafic entre 2 machines, selon le protocole applicatif. La matrice de trafic est établie , protocole par protocole, entre toutes . user history Définir un historique. L ’utilisateur spécifie les parties de la MIB à collecter par la sonde. probe configuration Permet la configuration à distance de la sonde. L ’objectif étant de normaliser la méthode de configuration pour assurer une intéropérabilité d’équipements venant de différents utilisateur.

55 Le codage des données

56 La syntaxe des données transmises
Contraintes : On parle bien de la même chose ? Sous quelle forme l'information est elle transportée ? Solutions : Décrire sous forme mutuellement compréhensible les objets concernés par l’échange. - SYNTAXE ABSTRAITE normalisée par l’OSI: l’ASN.1 Déterminer une forme commune de représentation de ces objets qui sera utilisée au cours de la communication: - SYNTAXES DE TRANSFERT (TLV)

57 ASN.1 Langage ASN.1, non spécifique à l'administration de réseaux, créé pour servir de support aux services de la couche Présentation. Il permet entre autre la transparence des implémentations pour la transmission des informations échangées par la couche Application. ASN.1 permet de générer, pour le langage visé (on peut parler de compilateur ASN.1 vers un langage donné, comme C, ADA, C++; ...), les structures de données des objets décrits dans ce langage. Il produit également les procédures d'encodage de ces données pour le transport par les protocoles utilisés, ce que l'on appelle la syntaxe de transfert : codage de type TLV ou Type Longueur Valeur. En conclusion: deux applications pourront, par le biais de l'encodage ASN.1, échanger des informations sur les objets, quels que soient les langages ou les systèmes support utilisés (qui seront d'ailleurs inconnus des entités qui dialoguent).

58 SMI SMI = Structure of Management Information (RFC 1155; extension = RFC 1212). SMI définit le nommage et la structure des données de management en MIB en utilisant ASN 1. Le nom d ’objet est représenté, de manière unique, par l ’Identificateur d ’objet (OID). Il est aussi désigné « OBJET IDENTIFIER », et est attribué d’une façon administrative. OID = Séquence de nombres entiers définissant un parcours dans l’arbre global. Exemples : L ’objet « internet », dans l’arbre ISO/UIT, est désigné par : internet OBJET IDENTIFIER ::= { iso org(3) dod(6) 1 } l ’OID est représenté par le préfixe :

59 OID L’OBJECT IDENTIFIER est l’identificateur qui permet de nommer de manière unique l'objet que l'on désire atteindre. Exemples DESCRIPTION Notation relative Absolue mgmt OBJECT IDENTIFIER :: = { internet 2 } mib OBJECT IDENTIFIER ::= { mgmt 1 } interfaces OBJECT IDENTIFIER ::= { mib 2 }

60 Arbre de nommage des objets ASN.1

61

62

63 Les types d’objets Types primitifs: INTEGER; OCTET STRING; OBJET IDENTIFIER; NULL Types construits : SEQUENCE ; SEQUENCE OF SEQUENCE Constructeur de listes SEQUENCE OF Constructeur de tables Types supplémentaires : NetworkAddress ; pAddress; Counter; Gauge; TimeTicks; Opaque NetworkAdress : Représenter des adresses de protocoles. IpAddress : Représenter des adresses Internet sur 32 bits. Counter : Définir des compteurs sur l ’intervalle [0; 2 puissance 32-1]. Gauge : Caractériser un entier positif borné. TimeTicks : Compteur de temps, en 1/100 ème depuis une date. Opaque : Représenter une syntaxe qcq, encodée sous forme d ’OCTET STRING.

64 Le formulaire des types d’objets
OBJECT-TYPE Nom textuel de l ’objet, avec un Identificateur d’objet correspondant SYNTAX Syntaxe pour le type d ’objet DEFINITION Description textuelle du type d ’objet ACCESS read-only ; read-write ; write-only ; not-accessible STATUS mandatory ; optional ; obsolete

65

66 MIB II

67

68 Suite colonne 2 Suite colonne 1

69 Encodage TLV Type Longueur Valeur

70 Encodage du Type dans TLV
LONGUEUR VALEUR 1 OCTET Si valeur>31; alors on met ces 5 bits à ‘ 1 ’ puis codage sur octet(s) suivant(s) TYPE 2 bits 1 bit 5 bits Type primitif = 0 Type construit =1 Valeur de l ’étiquette (Tag) Ex : Etiquettes de classe UNIVERSAL 2 = INTEGER ; 4 = OCTET STRING 5 = NULL ; 6 = OBJET IDENTIFIER 16 =SEQUENCE ou SEQUENCE OF Valeur de la classe 00 UNIVERSAL 01 APPLICATION 10 CONTEXT-SPECIFIC( CHOICE)* 11 PRIVATE * Exemple pour un PDU SNMP choice entre un get getnext set etc.. Dans ce cas tag représente la valeur du choice

71 Encodage Longueur dans TLV
2. Encodage du champ LONGUEUR TYPE LONGUEUR VALEUR 1 octet/ n octets Lg champ « valeur », en octets Lg<127 oct 1 Nbre d ’octets suivants Lg >127 oct Lg champ valeur Lg du champ valeur

72 INTEGER : Nbre minimum d ’octets pour représenter l ’entier
3. Encodage du champ VALEUR TYPE LONGUEUR VALEUR 1 octet/ n octets Exemple: INTEGER : Nbre minimum d ’octets pour représenter l ’entier OCTET STRING : Valeurs de la chaîne d’octets NULL : Pas de valeur OBJET IDENTIFIER : Il s ’agit de coder la valeur de l ’OID On code selon la formule : 1er composant x 40 décimal + 2ème composant les autres valeurs de composants sont codés indépendamment

73 3. Encodage du champ VALEUR
TYPE LONGUEUR VALEUR 1 octet/ n octets Exemple : Le codage de l’OID sera : 40x1 + 3 = 43 ; puis 6; puis 1 etc .... 200 = C8 sera codé, en hexa, sur 2 octets : 81 48 Chaque élément sera codé sur 7 bits On aura donc, le codage de VALEUR avec les octets suivants 2B Classe universal (0), tag=6 object identifier Codage TLV de l’OID B

74 SEQUENCE : Concaténation du codage de ses composants Exemple :
SEQUENCE (INTEGER, INTEGER) : SEQUENCE (7,11) Le chiffre 7 est codé Le chiffre 11 est codé B 30 (Type construit + 16 SEQUENCE) Donc le codage est : B TLV de l ’entier 7 TLV de l ’entier 11 Type Long de SEQUENCE

75 Annexe : message PDU get response

76 Annexe : Extrait rfc 1157

77 Annexe : Extrait rfc 1157

78 Annexe : Extrait rfc 1157

79 Le codage 30 2a c 69 63 a2 1d 30 12 30 10 b e 69 78

80 Applications web services
ASSURANCE Service management MISE EN PLACE USAGE Gestion des fautes Gestion des performances Services réseaux Systèmes serveurs Applications web services Data Storage

81 Maîtriser son SI Gérer les incidents

82 Gestion des incidents Une gestion proactive –Des alarmes et évènements
Une vue intégrée et corrèlee de tout le système d’information Une reconnaissance automatiser des fautes et évenement Activation d’actions spécifiques ou de règle de corrélation Une vue “intelligente des problèmes”Intelligent problem determination, -uniquement les bonnes alarmes au bon opérateur- Améliore la pertinance et réduire la charge des operations

83 Gestion des incidents Un workflow automisé
Distribué les fonctions entre plusieurs consoles d’administration Notion de profil d’administrateur avec droits d’accès Des fonctions de configuration efficaces pour faciliter les changement dans “staff duty” L’inititalisation automatique de tickets d’incident avec une database d’expérience Jose Réduire les coûts d’opération

84 Pertinance des incidents remontés
Pas d’alarme dupliquées Une analyse temporelle et un filtrage sophistiqué des incidents qui remontes Une language pour définier les règes Des règles qui permettent de faire de la corrélation Possibilité de groupés les règles par scenarii Donner seulement l’information pertinance aux opérateurs

85 Maîtriser son SI Mesurer la Qos

86 La gestion des performances
Une gestion en temps réel et “capacity planning” des performance du système Une vue dynamique de toute l’infrastructure du système d’information Des indicateurs temps réel de performance Une gestion automatisée de la collecte et du traitement pour générer des rapports de performance pertinent Assurer et donner un vue d’ensemble du niveau de service

87 Gérer la qualité de service
Exemple de Reporting Distribution des alarmes en fonction du temps, des éléments managés. Une mesure du temps entre le temps d’apparition et de résolution des incidents, avec rapports journalier, mensuel, annuel Des publication synthétique et historique des élément clés administrés. Un suivi des indicateurs QoS indicators Gérer la QoS au travers de rapport

88 SNMP Un Manager(s) des agents Un protocole Une structure de donnée
Des objets (MIB I, etc.....) Un codage TLV Des applications