Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

SNMP

Here are a few places that students have recommended around Manchester

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of SNMP

SNMP Généralités Principe de fonctionnement La MIB La sécurité SNMP Le protocole SNMP Le protocole SNMP (Simple Network Management Protocol, ou autrement dit « protocole de gestion réseau simplifié »), que nous allons étudier plus en détails dans la presentation suivante, a pour rôle exclusif la gestion réseau, et offre en conséquence un grand nombre d’avantages que n’ont pas les autres protocoles. SNMP propose une interface de transaction commune à tous les matériels, et donc la plus homogène possible. Son utilisation reste peu importante suite à des débuts difficiles, mais SNMP tend à devenir à terme l’une des références en matière de gestion réseau. SNMP est un protocole de la famille TCP/IP (Internet protocol), et peut donc être utilisé sur tous les réseaux de type Internet. Il exploite les capacités du protocole de transport UDP : Présentation SNMP Le protocole SNMP se base sur le fait qu’il existe une station de gestion réseau, le
manageur, dont le rôle est de contrôler le réseau et de communiquer via ce protocole avec un agent. L’agent est de manière générale une interface SNMP embarquée sur le matériel destiné à être administré à distance. Base de SNMP Architecture globale Les buts du protocole SNMP sont de :
>> connaître l'état global d'un équipement (actif, inactif, partiellement opérationnel...).
>> gérer les évènements exceptionnels (perte d'un lien réseau, arrêt brutal d'un équipement...).
>> analyser différents métriques afin d'anticiper les problèmes futurs (engorgement réseau...).
>> agir sur certains éléments de la configuration des équipements. Le paquet de données SNMP est inséré dans le paquet de données UDP, qui est inséré dans le paquet de données IP. Comme on a pu le voir dans le paragraphe précédent, la MIB est organisée sous la forme d'un arbre hiérarchisé qui contient des informations et chaque portion de l'arbre est décrite par un fichier MIB particulier. Tâchons de voir maintenant ce qu'est un fichier MIB. Les fichiers MIB Quelques difficultés courantes avec les MIB Paquet de données SNMP Le protocole SNMP est un protocole réseau qui comporte différentes requêtes. Ces requêtes sont regroupées en 3 familles :
>> les messages du superviseur SNMP vers l'agent SNMP.
>> les messages de l'agent SNMP vers le superviseur SNMP.
>> les messages entre agents SNMP. Comme on a commencé à le voir dans le paragraphe précédent, SNMP définit deux choses, le protocole, c'est-à-dire la façon dont est transportée l'information et les informations dynamiques, fournies par les différents agents SNMP. Ces informations sont spécifiées dans ce que l'on appelle la MIB (Management Information Base).
La MIB est un ensemble structuré d'informations organisé sous la forme d'un arbre hiérarchisé de la même manière que l'arborescence des domaines Internet. Chaque information dans cette hiérarchie est identifiée par son OID (Object Identifier). Par exemple, l'objet ifDescr est identifié par son OID 1.3.6.1.2.1.2.2.1.2.
Comme on peut le voir dans l'exemple, un OID est une séquence de nombres séparés par le caractère "." (point). Vue générale - Chaque trame possède une adresse source et une adresse destination qui permettent aux protocoles de niveaux supérieurs comme SNMP de pouvoir adresser leurs requêtes. - Le protocole UDP peut utiliser un checksum optionnel qui couvre l'en-tête et les données de la trame. En cas d'erreur, la trame UDP reçue est ignorée : gage de fiabilité. - Le protocole UDP fonctionne en mode non connecté, c’est-à-dire qu’il n’existe pas de lien persistant entre la station d’administration et l’agent administré. Cela oblige les deux parties à s’assurer que leurs messages sont bien arrivés à destination, ce qui apporte également un important gage de fiabilité pour la gestion réseau. - Deux ports sont désignés pour l'utilisation de SNMP :
>> Port 161 pour les requêtes à un agent SNMP.
>> Port 162 pour l'écoute des alarmes destinées à la station d'administration. Les différents éléments que l'on peut identifier avec le protocole SNMP sont synthétisés par le schéma ci-dessous Les agents SNMP : ce sont les équipements (réseau ou serveur) qu'il faut superviser. Le superviseur SNMP : c'est une machine centrale à partir de laquelle un opérateur humain peut superviser en temps réel toute son infrastructure, diagnostiquer les problèmes et finalement faire intervenir un technicien pour les résoudre. Le protocole SNMP : c'est le protocole utilisé par les agents SNMP et leur superviseur pour communiquer entre eux. La MIB : ce sont les informations dynamiques instanciées par les différents agents SNMP et remontées en temps réel au superviseur. Les outils SNMP. Ce sont les différents utilitaires utilisés par le superviseur pour l'aider à diagnostiquer un problème. Ces différents outils sont aussi utilisés lors de la configuration du superviseur pour prendre en compte les spécificités de l'infrastructure. - Les messages du superviseur SNMP vers l'agent SNMP (le port UDP 161) : >> Message "Get Request" : ce message permet au superviseur d'interroger un agent sur les valeurs d'un ou de plusieurs objets de la MIB.
>> Message "Get Next Request" : ce message permet au superviseur d'interroger un agent pour obtenir la valeur de l'objet suivant dans l'arbre des objets de l'agent. Ce message permet de balayer des objets indexés de type tableau.
>> Message "Get Bulk Request" : introduite avec la version 2 du protocole SNMP, ce message permet de mixer les messages "Get Request" et "Get Next Request" pour obtenir des blocs entiers de réponses de la part de l'agent.
>> Message "Set Request" : ce message permet au superviseur de positionner ou modifier la valeur d'un objet dans l'agent. - Les messages de l'agent SNMP vers le superviseur SNMP ( le port UDP 162) :
>> Message "Get Response" : ce message est utilisé par l'agent pour répondre aux messages "Get Request", "Get Next Request" et "Get Bulk Request" envoyés par le superviseur.
>> Message "Trap" : ce message est envoyé par l'agent à son superviseur de manière asynchrone pour signaler un événement, un changement d'état ou un défaut. L'agent n'attend pas d'acquittement de la part du superviseur.
>> Message "Notification" : introduit avec la version 2 du protocole SNMP, ce message est similaire au message "Trap". Il est envoyé par l'agent à son superviseur de manière asynchrone pour signaler un événement, un changement d'état ou un défaut. L'agent n'attend pas d'acquittement de la part du manager.
>> Message "Inform" : introduit avec la version 2 du protocole SNMP, ce message est envoyé par l'agent à son superviseur de manière asynchrone pour signaler un événement, un changement d'état ou un défaut. L'agent attend un acquittement de la part du superviseur et il y aura une retransmission en cas de non réponse. Ce message peut aussi être utilisé pour un dialogue superviseur - superviseur. - Les messages entre agents SNMP : Le seul message envoyé entre les agents SNMP est :

>> Message "Report" : introduit avec la version 2 du protocole SNMP mais jamais implémenté, ce message permet aux différents agents de communiquer entre eux (principalement pour remonter des problèmes de traitement des messages SNMP). Résumé des commandes SNMP Le début de l'arborescence des OID défini dans les différentes RFC est le suivant : La MIB est un arbre hiérarchisé très dense. Il existe plusieurs milliers d'OID dans la MIB. Il est par conséquent impossible de décrire tous ces OID dans un seul fichier MIB.
De même que pour le DNS, les différentes parties de la MIB sont définies dans différents fichiers MIB. Chaque fichier MIB a la responsabilité d'une branche particulière de la MIB. Tout d'abord, un fichier MIB est un fichier texte. Il contient la spécification de différents OID. Pour chaque OID, cette spécification comprend: un OID unique, dans l'arbre des OID. Par exemple 1.3.6.1.2.1.1.3 un nom générique. Par exemple sysUpTime une description de cet OID. Par exemple, "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." son type. Par exemple TimeTicks. Il existe différents types possibles de données qui permettent de couvrir tous les besoins son statut. Par exemple mandatory. Les différents statuts possibles sont "mandatory", "optional", "obsolete" son mode d'accès. Par exemple read-only. Les différents accès sont "read-only", "read-write", "write-only", "not-accessible" Exemple de définition d'OID
sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The time (in hundredths of a second) since the
network management portion of the system was last
re-initialized."
::= { system 3 }

sysContact OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The textual identification of the contact person
for this managed node, together with information
on how to contact this person."
::= { system 4 }

sysName OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"An administratively-assigned name for this
managed node. By convention, this is the node's
fully-qualified domain name."
::= { system 5 }

sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The physical location of this node (e.g.,
`telephone closet, 3rd floor')."
::= { system 6 } Un fichier MIB est écrit en utilisant une syntaxe particulière. Cette syntaxe s'appelle SMI (pour Structure of Management Information). Comme pour le protocole SNMP lui-même, SMI est basé sur ASN.1. Disponibilité du fichier MIB. S'il n'est pas nécessaire de disposer de la MIB d'un équipement pour le superviser, il est parfois difficile voire impossible de comprendre le rôle des OID de cet agent ou de deviner à la suite de quel événement va être envoyé un message "Trap" au superviseur. La seule référence reste le fichier MIB de l'équipement et ce fichier est parfois difficile à trouver. Erreur de syntaxe. Il est très courant de trouver des fichiers MIB comportant des erreurs de syntaxe. Le dernier exemple que j'ai vécu, est la ligne suivante tirée du fichier d'un équipementier réseau qui faisait planter le compilateur de MIB. Il y avait un double commentaire (le double caractère '-'), et la norme ASN.1 est très claire à ce sujet : un commentaire commence avec le double caractère '-' et se termine à la fin de la ligne ou alors au double caractère '-' suivant présent sur la même ligne. En conclusion, il n'est pas exclu de trouver des erreurs de syntaxe dans un fichier MIB (même écrit par un équipementier réseau renommé). Sous SNMPv1 et SNMPv2c, la sécurité est assurée par deux choses :
>> Dans sa requête, il faut envoyer une chaîne de communauté, qui correspond en quelque sorte à un mot de passe, et dont les droits varient suivant cette chaîne : il est ainsi possible d’autoriser certaines personnes un accès en lecture seule, et à d’autres personnes un accès complet suivant la communauté qu’ils utilisent.
>> L’agent peut vérifier et contrôler l’origine des données, afin de vérifier que la personne en question a accès aux informations. Il s’agit généralement d’une vérification basée sur l’adresse IP source. Nous constatons toutefois que la sécurité est particulièrement lacunaire pour deux raisons : le contenu de la transaction n’est pas crypté, et il suffit que la communauté soit connue de n’importe qui pour que cette personne puisse lire les informations. Ces différents problèmes ont été résolus dans SNMPv3. En effet, celui-ci propose
plusieurs modèles de sécurités différents :
>> Le premier modèle est dépourvu de sécurités et est comparable à SNMPv1/v2c.
>>Le second modèle offre des capacités d’authentification par utilisateur, c’est-àdire que chaque utilisateur dispose d’un mot de passe d’accès, ainsi que d’une clé publique de cryptage permettant de sécuriser le contenu de la transaction.
>>Le troisième modèle ajoute au précédent un niveau de cryptage supplémentaire en utilisant le principe d’échange des clés privées : le contenu des paquets est ainsi totalement crypté mais ce modèle n’est applicable qu’en fonction des lois sur la cryptographie en vigueur. BenAbdelmalek Houssem Eddine Mustapha
MPSSI 2
2012-2013
Full transcript