Administration des réseaux
Objectifs du cours
Définir la notion de gestion de réseaux • Supervision • Gestion • Administration …
But = maintenir un service
Quelles ressources ? – Des équipements (commutateur, routeur, …) – Des réseaux (Ethernet, ATM,…) – Des services (Web, messagerie,…) – Des applications (SGBD, Système d’information,…) – Des utilisateurs (identification, privilèges, …)
Classification normalisée
Gestion de la configuration
Gestion des fautes
Gestion de la performance
Gestion de la sécurité
Gestion de l’audit
Gestion de la configuration – localisation – configurations logicielles et matérielles – États (on, off, stand-by, busy, listen…) – initialisations – Identifications – manipulations des configurations
Gestion des fautes
Détection
Localisation
Correction
Restauration
Détection + intervention rapides
Gestion de la performance
Capacité du réseau
Trafic temps réel
Débit par application
Goulots d’étranglement
Mesure des temps de réponse = latence
Mesure des variations de temps de réponse = gigue
Gestion de la sécurité
Instaurer des règles de sécurité
Visualiser, modifier et supprimer une politique de sécurité
Authentification des utilisateurs
Audit de sécurité
Gestion de l’audit
Générer des rapports
Tarification
Ressources consommées
Pourcentage d’utilisation des ressources
Statistique des applications
Charge des serveurs
network management system
Relation manager/agent
Structure of Management Information (SMI)
Ensemble de règles pour identifier d’une manière unique les objets gérés.
Définir la structure logique de la base informationnelle MIB (Management Information Base)
Deux versions: SMI 1 et SMI 2
Structure of Management Information (SMI)
Objets du réseau gérés sont accessibles de deux manières: – Physiquement: Accès direct à l’information (@IP, nombre de paquets, état de l’interface, etc). – Logiquement: Les informations sont dans la MIB pour être consultés et modifiés
SMI est responsable de l’organisation logique de ses informations
Structure of Management Information (SMI)
Avec SMI chaque objet géré doit posséder: – Un nom: un identifiant unique (OID: ObjectIDentifier ) – Une syntaxe: type de données (integer, string, etc) Langage ASN.1 – Un codage: représentation binaire pour la transmission sur le réseau Codage BER
Langage ASN.1
ASN.1 = Abstract Syntax Notation One
Fonction de la couche présentation
Langage normalisé
Les structures de données sont indépendantes de l’architecture interne physique de la machine.
Langage interprété par l’être Humain
SMI utilise un sous-ensemble de ASN.1 pour la description des objets.
Types de données ASN.1
Chaque object possède un type et une valeur.
Règle de déclaration de type – [nom du type] ::= [définition du type]
Règle de déclaration de variable – [nom de la valeur] [nom du type] ::= [définition de la valeur]
Types de données ASN.1
ASN.1 utilise deux types de données: – Primitive: type simple (INTEGER, OCTETSTRING, etc) – Constructeur: combinaison de types simple (Listes ou des tableaux).
Types Simples ASN.1
SMI utilise un sous-ensemble des types simples de ASN.1
– INTEGER – OCTET STRING – OBJECT IDENTIFIER – NULL
Exemple de type simple
– Montant ::= INTEGER • Credit Montant ::= 2000
– Age ::=INTEGER (0..130)
• ageRetraite Age ::= 45
– phrase OCTET STRING ::= "une phrase"
OCTET STRING
Une séquence de zero, un, ou plusieurs octets
SNMP trois cas spéciaux de type OCTETSTRING:
– DisplayString: tous les caractères sont imprimables ASCII – OctetBitstring: suite de bits qui dépasse 32 bits
– PhysAddress: représente une adresse physique
OBJECT IDENTIFIER
Il permet d’organiser l’arbre SMI
Exemples: – internet OBJECT IDENTIFIER ::= {iso org(3) dod(6) 1} – mgmt OBJECT IDENTIFIER ::= {internet 2} – mib OBJECT IDENTIFIER ::= {mgmt 1} – system OBJECT IDENTIFIER ::= {mib 1} – sysDescr OBJECT IDENTIFIER ::= {system 1}
Types complexes ASN.1
Deux types cmplexes pour définir des tableaux:
SEQUENCE OF : liste ordonnées de valeurs de même type.
SEQUENCE : liste ordonnées fixe de valeurs de types différents.
Exemple de SEQUENCE
IpRoutingTableEntry ::= SEQUENCE {
ipRouteDest IpAddress, ipRouteNextHop IpAddress
}
gateway IpRoutingTableEntry ::= {194.57.88.0, 194.57.89.1}
Exemple de SEQUENCE OF
IpRoutingTable ::= SEQUENCE OF IpRoutingTableEntry
Routeur ipRoutingTable ::= { {181.23.54.0, 181.23.55.1}, {181.23.53.0, 181.23.55.255} }
Defined Types
SMI utilise un troisième type prédéfinis ‘Defined’
Defined donne une meilleure interprétation des types simples et complexe.
NetworkAddress: adresse désignant n’importe quelle famille de protocole
IpAddress: @IP sur 32 bits
Counter: entier positif qui incéremente jusqu’à revenir à la case de départ
Gauge: entier positif qui peut incrémenter ou décrémenter
TimeTicks: entier positif qui représente le temps en centième de seconde.
Convention lexicales ASN.1 Terme Description - nombre signé -- Commentaire ::= Affectation | Alternative { } Début et fin de listes [ ] Début et fin de a tag ( ) Début et fin de sous-type .. Intervalle
Conventions ASN.1
ASN.1 fait la différence entre minuscules et majuscules Terme Convention Types 1ere caractère en Majuscule Values 1ere caractère en Minuscule Macros tous les caractères en Majuscule Modules 1ere caractère en Majuscule Mots réservés tous les caractères en Majuscule Macro
Une macro permet de déclarer un objet autre que ceux utilisé de base.
Declaration d’une macro ASN.1 <macro name> MACRO ::= BEGIN
TYPE NOTATION ::= <user-defined type notation> VALUE NOTATION ::= <user-defined value notation>
<supporting syntax> END
Macro OBJECT-TYPE OBJECT-TYPE MACRO ::=
BEGIN TYPE NOTATION ::=
"SYNTAX" type(ObjectSyntax) "ACCESS" Access "STATUS" Status DescrPart
VALUE NOTATION ::= value (VALUE Object IDENTIFIER) Access ::= "read-only"
| "read-write" | "write-only" | "not-accessible "
Status ::= "mandatory" | "optional" | "obsolete" | "deprecated "
DescrPart ::= "DESCRIPTION" value (description DisplayString) | empty
END
Macro OBJECT-TYPE
OBJECT-TYPE permet une extension du SMI. sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION “ texte “ ::= { system 1 }
Macro OBJECT-TYPE
SYNTAX: Type de données
ACCESS: droits d’accès read-only, read-write, not-accessible not-accessible est utilisé pour les tables et les lignes de tables
STATUS: mandatory, optional, deprecated, ou obsolete. Obsolete est utilisé pour les objets qui ne sont plus supportés Deprecated est utilisé pour les objets qui sont remplacés par d’autres objets compatibles
Macro OBJECT-TYPE
DESCRIPTION: définition textuelle de l’objet
REFERENCE: définition textuelle d’un autre objet de référence défini dans une autre MIB
INDEX: décrit l’ordre de parution des champs d’un tableau (colonnes).
DEFVAL: Valeur par défaut des champs d’une ligne (Tableau)
Déclaration d’un objet dans la MIB tcpInSegs OBJECT-TYPE
SYNTAX Counter ACCESS read-only STATUS mandatory ::= { tcp 10 }
La déclaration précédente signifie que: – tcpInSegs est un objet qui contient des informations de type Counter. – tcpInSegs est en lecture seule – tcpInSegs doit être présent dans les systèmes gérés qui supporte son parent mib2.tcp – tcpInSegs est placé dans la position 10 dans le group tcp.
Modules
ASN.1 regroupe les déclarations d’objet dans des listes appelées: module
La déclaration d’un module commence par le nom du module suivit de DEFINITIONS
BEGIN et END englobent le corps du module
IMPORTS peut être utilisé pour faire référence à des types et valeurs déclarés dans d’autres modules
Exemple de module RMON-MIB DEFINITIONS ::= BEGIN
IMPORTS Counter FROM RFC1155-SMI DisplayString FROM RFC1158-MIB mib-2 FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212 TRAP-TYPE FROM RFC-1215; -- Remote Network Monitoring MIB rmon OBJECT IDENTIFIER ::= { mib-2 16 } -- textual conventions . .
END
Étiquettes de type (Tag)
Distinguer d’une manière unique les types.
Permettre de localiser la provenance des objets (leurs déclarations)
Utiliser un autre paramètre autre que le nom du type.
Combiner les types de base avec un autre argument.
Le nombre entre [ ] définit le tag
On distingue Quatre classes d’étiquettes
Classes d’étiquettes
universelle – types de base définis dans ASN.1 – ex : INTEGER, OCTET STRING
application – associée à une autre application : définie dans d’autres normes – Utilisé par les standards Internet
contexte – permet de distinguer les éléments d’un ensemble – Utilisé par SNMP (requête, réponse, notification)
privée – définie par l’utilisateur pour ses propres besoins
Classes d’étiquettes
La classe des étiquettes (entre crochet) – applicative : [APPLICATION n] – contextuelle : [n] – universelle ou non étiqueté : INTEGER – privée : [private n]
Classes d’étiquettes
SNMP utilise les trois premières classes:
Universal: permet d’encoder les types simples INTEGER, OCTET STRING, etc
Application: permet d’encoder les typesprédéfinis
Contexte: permet d’encoder les PDUs SNMP (GetRequest, SetRequest, etc)
Exemple de tag
TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295)
TimeTicks est un type tagé Appartenant à la classe APPLICATION Portant l’étiquette 3
IMPLICIT indique le Tag associé à INTEGER ne sera pas transmis.
Règles de codage
Basic Encoding Rules (BER) définit la syntaxe de transfert des données sur le réseau
BER décrit la représentation binaire des données
BER décrit l’acheminement des bits sur un canal de communication
BER utilise la syntaxe Type-Length-Value (TLV)
Codage Type-Length-Value
Codage Type-Length-Value
Codage TLV (Type)
Type définit la nature des données contenues dans le champ value
Il est composé de trois champs – Class: classe de données – P/C: primitive ou Constructeur
– Tag: la valeur de l’étiquette
Le Champ Class
Ce champ permet de coder les classes d’étiquette. Class Bit 8 Bit 7 Universal 0 0 Application 0 1 Context 1 0 Private 1 1
Tag (Universal) Type Tag Number INTEGER 00000010 = 02H OCTET STRING 00000100 = 04H NULL 00000101 = 05H OBJECT IDENTIFIER 00000110 = 06H SEQUENCE 00110000 = 30H SEQUENCE-OF 00110000 = 30H
Tag (Application) Type Tag Number IpAddress 01000000 = 40H Counter 01000001 = 41H Gauge 01000010 = 42H TimeTicks 01000011 = 43H Opaque 01000100 = 44H
Tag Context
Type Tag Number GetRequest 10100000 = A0H GetNextRequest 10100001 = A1H GetResponse 10100010 = A2H SetRequest 10100011 = A3H Trap 10100100 = A4H
TLV (Length)
Ce champ précise la taille du champ suivant (Valeur).
Si la taille de la valeur dépasse les 127 octets. – Le bit le plus significatif porte la valeur 1 – Le bit le plus significatif du dernier octet(Length) porte la valeur 0
TLV (Length)
Codage INTEGER
INTEGER type, Value = “75”
Codage OCTET STRING
OCTET STRING type, Value = “BBM”
Codage OBJECT IDENTIFIER
Pour économiser la taille des données envoyées, on combine le premier et le deuxième OID
Le premier sous identifiant est toujours un petit nombre (0, 1 ou 2)
Si X est la valeur du premier OID, et Y le deuxième:
Premier identifiant calculé = (X * 40) + Y
Codage OBJECT IDENTIFIER
OBJECT IDENTIFIER, Value = {1 3 6 1 2 1 1 }
Codage NULL
NULL type, Value = NULL
Codage SEQUENCE
VarBind ::= SEQUENCE {
name ObjectName value ObjectSyntax
} VarBindList ::= SEQUENCE OF VarBind
Codage SEQUENCE
Codage IpAddress
IpAddress type, Value = “128.150.161.8”
Codage TimeTicks
TimeTicks type, Value = “263691156”
Codage Context class
Codage Context class (SNMP)
SIMPLE NETWORK MANAGEMENT PROTOCOL Historique
ARCHITECTURE SNMP
Composantes SNMP
LE DIALOGUE SNMP
GET-REQUEST
Opération qui permet de lire le contenu d'un objet
Il faut lui passer en argument le libellé de l'objet
La valeur est retournée sous la forme correspondant au type de l'objet
Exemple : snmpget -v 1 –c public agent SysDesc.0
GET-NEXT-REQUEST
Opération qui retourne le prochain libellé de variable se trouvant dans la base de gestion en fonction du libellé de variable transmis
Le premier usage de cette opération est de retrouver la liste des variables gérées,
qui peut dépendre de la machine qui supporte ce noeud Exemple :
snmpgetnext -v 1 –c public agent SysDesc.0
SET-REQUEST
Cette opération permet d'affecter une valeur à une variable sur un noeud donné
Cette opération est émise par une station de gestion (manager) vers un noeud géré (agent)
Exemple : snmpset -v 1 –c public agent SysName.0 s Agent
GET-RESPONSE
Cette opération permet à un nœud géré (agent) de répondre à une requête provenant de la station de gestion (manager).
TRAP
Cette opération permet à un nœud géré (agent) d'envoyer un message à une station de gestion (manager) lorsqu'un événement s'est produit sur le nœud
L'envoi s'effectue de façon asynchrone par l’émission d'un descriptif complet de la situation d'un nœud
SNMP Protocol Data Units (PDUs)
Structure SNMP PDU
Structure SNMP PDU
version number: (INTEGER) assure que le manager et l’agent utilisent la même version.
community name (OCTET STRING): chaîne d’authentification entre le manager et l’agent.
PDU Type: précise le type d’opération (GetRequest, GetNextRequest, etc)
Structure SNMP PDU
PDU PDU Tag GetRequest 0 GetNextRequest 1 GetResponse 2 SetRequest 3 Trap 4
Structure SNMP PDU
Request ID: (INTEGER) corrélation entre la requête du manager et la réponse de l’agent.
Error Status: (INTEGER) code erreur. Error Value noError 0 TooBig 1 noSuchName 2 badValue 3 readOnly 4 genErr 5 (autre erreur)
Structure SNMP PDU
Error Index: (INTEGER) indique l’emplacement de l’erreur dans VarBindList
VarBindList: (SEQUENCE OF) liste de paires (OID,valeur)
Pour GetRequest et GetNextRequest Valeur de VarBindList est de type NULL.
GetRequest/GetResponse PDU
SetRequest/GetResponse PDU
structure de la PDU Trap
structure de la PDU Trap
Generic Trap: fournit des informations sur l’événement qui déclenché la Trap. Geniric Trap Value coldStart 0 warmStart 1 linkDown 2 linkUp 3 authenticationFailure 4 egpNeighborLoss 5 enterpriseSpecific 6
structure de la PDU Trap
Timestamp contient la valeur de l’object sysUpTime (temps entre la dernière réinitialisation de l’agent et cette PDU)
Management Information
Base
PRINCIPAUX GROUPES MIB
SYSTEME : liste des informations de configuration générique.
INTERFACE : liste des informations génériques sur les interfaces.
AT : liste de traduction d'adresses. Ces informations servent à réaliser la translation entre les adresses IP et les adresses physiques.
IP : liste des variables liées au protocole de routage IP
ICMP : représente la liste des variables liées au protocole ICMP
TCP : représente la liste des variables liées au protocole TCP.
UDP : représente la liste des variables liées au protocole UDP.
EGP : liste obligatoire dans les nœuds qui implémentent EGP
CMOT : relatif au protocole CMOT (Common Management Over TCP/IP).
Groupe System
Groupe Interfaces
Groupe Address Translation
Groupe IP
Groupe ICMP
Groupe TCP
Groupe UDP
Groupe EGP
Groupe Transmission
LES AGENTS SPECIAUX
RMON
La RMON MIB est une MIB spéciale qui contient les objets nécessaires à la gestion distante, via SNMP, d'un équipement de mesure
La RMON MIB
STATISTICS : statistiques de trafics (octets, paquets, erreurs...).
HISTORY : accumulation des statistiques en fonction du temps.
HOST : statistiques par station découverte par l'agent.
HOSTTOPN : permet le filtrage des ordinateurs qui contiennent ou sont source de statistiques.
MATRIX : matrice de statistique sur le trafic entre couple de stations.
ALARM : positionnement d'alarmes selon les seuils.
EVENT : génération d’événements selon les alarmes reçues.
FILTER : positionnement des filtres de données.
CAPTURE : capture de paquets des filtres de données.
LES AGENTS PROXY
LES AGENTS PROXY
Certaines machines peuvent avoir des protocoles propriétaires non basés sur le protocole UDP la conversion de protocole qui permet de gérer des équipements pré-SNMP ou télécom
rôle de gestion locale de base sur un réseau local distant.
Il interroge les stations, collecte périodiquement des statistiques et remonte les alarmes vers le gestionnaire principal
La sécurité sous SNMP v1
La conjugaison d'un agent SNMP avec un ensemble arbitraire d’entités d'application s'appelle une communauté SNMP
Chaque communauté SNMP est identifiée par une chaîne d'octets, le nom de la communauté
une chaîne « communauté », qui est contenue dans chaque paquet SNMP, est comparée avec la chaîne Communauté configurée de l'agent
SNMP V2
Principales améliorations SNMP v2
Communication entre des stations managers
Transfert de données avec le mode Bulk
Extension des codes d’erreurs
Utilisation de services de transport variés
Compatibilité descendante
sécurité
Variantes snmp v2
Quatre variantes sont définies: – party-based SNMPv2 (SNMPv2p); – community-based SNMPv2 (SNMPv2c), – user-based SNMPv2 (SNMPv2u) – “SNMPv2 star” (SNMPv2*).
SNMPv2p, SNMPv2c and SNMPv2u sont les seuls définis par les standard RFC – SNMP v2C : nouvelles fonctionnalités – SNMP v2U : inclut l’authentification – SNMP v2 = v2U + cryptage + configuration à distance.
Seule la version snmp2c a été implémentée et utilisée
LES OPERATIONS SNMP2 En plus des opérations SNMPv1, SNMPv2 ajoute les opérations suivantes:
– GetBulkRequest : permet de demander une réponse aussi complète (une arborescence complète) – InformRequest : permet à un manager SNMP v2 d’échanger des informations avec un autre manager. – Trap SNMP v2 : joue le même rôle que le Trap SNMP v1 mais l’agent doit réémettre le Trap s’il ne constate aucune intervention du manager
LES MIBs SNMP v2
Deux principales MIBs sont décrites dans la spécification SNMP v2 : – La SNMP v2 MIB : elle est équivalente à la MIB II de SNMP qui fournit des informations relatives à l’utilisation du protocole SNMP v2 lui-même – La MIB Manager-To-Manager (M2M) qui fait référence aux alarmes et évènements résultant d’échanges entre managers
SMI SNMP v2
Extension du SMI v1 vers SMI v2.
Ajout d’autres types – ex: counter64
Ajout d’autres macro – OBJECT-IDENTITY – Module-IDENTITY
Ajout d’autres attributs – Access: read-create
PDU Type Value PDU Type
PDU GetBulkRequest
Le but de cette PDU est de minimiser le nombre d'échanges à travers le réseau.
Cette opération permet de récupérer le maximum d'informations pouvant être contenues dans un message.
La PDU GetBulkRequest offre la possibilité de spécifier des successeurs multiples.
GetBulkRequest PDU format
PDU type— Identifie le PDU comme opération GetBulk.
Request ID—Associer une requête SNMP avec la réponse.
Non repeaters— Nombre de variables (N) dans la première partie variable dont on souhaite un simple successeur (GeTNext).
Max repetitions— Nombre de successeurs devant être retournées pour chacune des dernières R variables.
Variable bindings— association objets et valeurs (N+R)
L'agent SNMP recevant une requête de type GetBulkRequest répond avec une PDU GetResponse
PDU InformRequest
Cette opération permet une communication manager vers manager
Cette opération permet à un manager d'envoyer des informations vers un autre manager qui centralise des informations contenues dans la MIB "manager-to-manager".
Un manager se comporte à la fois comme agent et manager
Le PDU InformRequest utilise la même structure qu’une PDU Trapv2.
Une réponse au manager émetteur sous la forme d'une PDU GetReponse ( mêmes valeurs que ceux de InformRequest ).
PDU Trap v2
La PDU Trap de SNMPv2 remplit les mêmes fonctions que le PDU Trap version 1 mais avec un format différent.
La PDU Trap-SNMPv2 ne se distingue plus des autres PDU et prend la même forme.
Trap v2 n’a pas d’accusé de réception comme c’est le cas de InformRequest
Le champ variable bindings du Trap-SNMPv2 comporte les noms d'objets et leurs valeurs suivants : – sysUpTime.0 – snmpTrapOID.0 : partie du groupe Trap de la MIB SNMPv2. – variables complémentaires pouvant être rajoutées par l'agent.
GetResponse PDU
Ce PDU est identique à celui de la version 1.
Cependant son champ error-status comporte une gamme de messages d'erreurs plus vastes
Statut d'erreur Nom
La sécurité sous SNMP v2
La sécurité est décomposée en plusieurs niveaux : – Le chiffrement : c’est la protection des données contre les écoutes indiscrètees et les recopies
– L’authentification : elle protège le message contre la falsification par la vérification du délai de transfert – Contrôle d’accès : Permet de vérifier que seuls les utilisateurs autorisés ont accès à une MIB particulière
La sécurité sous SNMP v2c
SNMP v2c utilise toujours la chaine communauté comme mot de passe d’authentification.
Compatibilité snmp v1 et snmp v2
SNMP v3
Cette norme reprend la version SNMPv2 (GetBulk, InformRequest ..)
SNMP v3 ajoute les nouvelles fonctionnalités: – un nouveau format de message SNMP, – un système de sécurisation des messages, – un contrôle d'accès, – une configuration à distance des paramètres SNMP.
Cette sécurité est basée sur 2 concepts : – USM (User-based Security Model) – VACM (View- based Access Control Model)
User Security Module (USM)
Trois mécanismes sont utilisés pour 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.
Authentification
S’assurer que le message que reçoit l'entité provient bien de la machine qu'elle prétend être et qu'il n'a pas été modifié
Un mécanisme d'authentification utilisant un algorithme de hachage, et par le partage des mots de passe.
L'algorithme de hachage MD5 ou SHA
Authentification
Les étapes d'authentification sont les suivantes :
Le transmetteur groupe des informations à transmettre avec le mot de passe.
On passe ensuite ce groupe dans la fonction de hachage à une direction.
Les données et le code de hachage sont ensuite transmis sur le réseau.
Le receveur prend le bloc des données, et y ajoute le mot de passe.
On passe ce groupe dans la fonction de hachage à une direction.
Si le code de hachage est identique à celui transmis, le transmetteur est authentifié.
Le cryptage
Assurer la confidentialité des messages SNMP.
Utiliser un système de cryptage symétrique
SNMPv3 utilise l'algorithme DES (Data Encryption Standard).
Pour des raisons de sécurité, SNMPv3 utilise deux mots de passe : un pour l'authentification et un pour le cryptage.
Le cryptage
L'estampillage du temps
L'estampillage du temps doit empêcher la réutilisation d'un paquet SNMPv3 valide que quelqu'un a déjà transmis.
En effet, si une requête est transmise, les mécanismes d'authentification, de localisation et d'encryption n'empêchent pas quelqu'un de saisir un paquet SNMPv3 valide du réseau et de tenter de le réutiliser ultérieurement, sans modification.
On appelle cette attaque la« replay attack ».
Pour éviter ceci, le temps est estampillé sur chaque paquet.
Quand on reçoit un paquet SNMPv3, on compare le temps actuel avec le temps dans le paquet.
Si la différence est supérieure à 150 secondes, le paquet est ignoré.
Distribution des mots de passe La connaissance du mot de passe compromettrait la sécurité entière du domaine
d'administration.
La solution adoptée par SNMPv3 est d'utiliser un mot de passe, mais de passer par une étape de « localisation ».
«SnmpEngineID» est une chaîne unique générée par un ensemble de données comme l'adresse MAC, l'adresse IP, des nombres aléatoires ou une chaîne spécifiée par l'administrateur.
On groupe le SnmpEngineID et le mot de passe (hashé) ensemble et on passe le groupe dans une fonction de hachage.
Le mot de passe localisé est utilisé dans l'authentification et le cryptage des messages SNMPv3.
Si le mot de passe est compromis sur un agent, cela ne remet pas en cause les autres agents.
Distribution des mots de passe
Distribution des mots de passe
SNMPv3 ARCHITECTURE
SNMPv3 ARCHITECTURE
SNMP entity: implémente une fonction SNMP, peut être un agent, un manager ou une combinaison des deux.
SNMP engine: implémente les fonctions d’envoi et de réception, authentification et de cryptage des messages ainsi que le contrôle d’accès aux objets.
– Dispatcher: son rôle est la gestion du trafic SNMP. Il dispache les messages selon les versions SNMP (v1, v2, ou v3) – Message Processing Subsystem: mise en forme des PDU selon les formats des messages des différentes versions SNMP. – Security Subsystem: s’occupe des services d’authentification et de cryptage. Authentification est soit community-based (SNMP v1 and v2) ou userbased authentication (SNMPv3 ). – Access Control Subsystem: responsable du contrôle d’accès à la MIB. Quelle opération permise pour quel utilisateur sur quel Objet ?
SNMPv3 Applications
Command generator: Génère les requêtes get, getnext, getbulk, et set et traite les réponses. Cette application est implementée par le manager.
Command responder: Répond aux requêtes get, getnext, getbulk, et set. Pour les versions 1 et 2, command responder est implémenté par l’agent SNMP.
Notification originator: Génère les traps SNMP. Pour les versions 1 et 2, Notification oroginator est implementé par l’agent SNMP.
Notification receiver: Reçoit les messages traps et inform. Cette application est implémentée par le manager.
Proxy forwarder: permet la translation des requêtes SNMPV3 pour les agents SNMPv1/v2c.
SNMPv3 ARCHITECTURE: MANAGER
SNMPv3 ARCHITECTURE: AGENT
Terminologie SNMPv3
snmpEngineID: identificateur administratif unique du SNMP Engine. Combinaison entre enterprise ID, adresse IP ou adresse MAC.
snmpSecurityModel: SNMPv1, SNMPv2 ou USM
snmpEngineBoots: nombre de fois que le SNMP Engine à redémarré.
snmpEngineTime: nombre de secondes depuis la dernière incrémentation de snmpEngineBoots.
snmpSecurityLevel: Trois niveaux de sécurité. – noAuthNoPriv: pas d’authentification , pas de cryptage. securityName est toujours demandé. – AuthNoPriv: Authentification , pas de cryptage. – AuthPriv: . Authentification et cryptage.
Authoritative SNMP engine: si le message SNMP demande une réponse (get, getnext, getbulk, set, ou inform), le récepteur est authoritative. Si le message ne demande pas de réponse (trap ou report), l’émetteur du message est authoritative. Généralement, un agent SNMP est authoritative et le manager est nonauthoritative.
Context
PDU SNMP v3
PDU SNMP v3
msgVersion : Pour SNMPv3, la valeur est 3
msgID : identificateur de message. Il correspond au numéro de séquence utilisé pour différencier les messages (associer les requêtes et les réponses).
msgMaxSize. : taille maximale d'une réponse à une requête selon les capacités en mémoire tampon et les limites à décoder de longs paquets..
msgFlags: Actuellement, seulement trois bits sont utilisés sur les huit. Il s'agit des trois derniers bits, à savoir :
– Si un message SNMP Report est attendue à la réception de ce paquet (Reportable Flag) – Si un modèle de cryptage a été utilisé (Privacy Flag) – Si un modèle d'authentification a été utilisé (Authentification Flag)
msgSecurityModel : Ce module identifie le modèle de sécurité qui a émis le message. Valeurs respectives 1, 2, et 3 pour SNMPv1, SNMPv2c, et SNMPv3
PDU SNMP v3
msgAuthoritativeEngineID : snmpEngineID qui fait autorité pour l'échange.
msgAuthoritativeEngineBoots : snmpEngineBoots de l’Engine qui fait autorité pour l'échange
msgAuthoritativeEngineTime : snmpEngineTime de de l’Engine qui fait autorité pour l'échange.
msgUserName : nom de l'utilisateur qui a émis la requête
msgAuthenticationParameters : la valeur est nulle s’il n’y a pas d’authentification. Autrement, ce champ contient le digest HMAC du message.
msgPrivacyParameters : la valeur est nulle s’il n’y a pas de cryptage. Autrement, ce champ contient les paramètres du Cipher Block DES.
PDU SNMP v3 ContextEngineID : identifie d’une manière unique SNMP Entity.
Context Name : Identifie un contexte (MIB) dans snmp Engine.
Data : contient les variables de la requête ou les valeurs de la réponse.
USM message processing
SNMPv3 flow
Discovery
USM demande que msgSecurityParameters contienne snmpEngineID, snmpEngineBoots, et snmpEngineTime de l’Engine qui fait autorité d’échange.
Avant toute utilisation des opérations get, getnext ou set, l’Engine non autorité d’échange doit obtenir ces valeurs de la part de l’Engine autorité d’échange.
Discovery process est utilisé pour obtenir ces informations.
USM User Table Username: nom d’utilisateur, parfois nommé Security Name.
Authentication protocol: protocole d’authentification à utiliser: – usmNoAuthProtocol, – usmHMACMD5AuthProtocol, – usmHMACSHAAuthProtocol.
Authentication key: passphrase utilisé pour authentification. 8 caractères minimum.
Privacy protocol: protocole de cryptage à utiliser: – usmNoPrivProtocol – usmDESPrivProtocol.
Privacy key: passphrase utilisé pour authentification. 8 caractères minimum.
usmUserSpinLock: verrou qui empêche multiple modification de la table l’utilisateur.
View-based Access Control Model VACM
Modèle de contrôle d'accès basé sur une vue
Ce modèle gère les droits d'accès en lecture et écriture des MIB.
Ce contrôle permet de gérer très finement l'accès au MIB, par exemple autoriser un utilisateur à lire uniquement, et un autre à écrire uniquement.
La nouveauté de SNMPv3 est l'existence d'une MIB SNMP-VIEW-BASED-ACM-MIB, qui permet de modifier ces droits par SNMP.
On peut donc de manière centralisée gérer tous les accès à toutes les entités administrables du réseau.
MIB VIEWS
ACCESS CONTROL TABLES
MIB View Allowed
Managers Required level of logique VACM
SNMPv3 RFCs