Vous êtes sur la page 1sur 146

Administration des réseaux

ObjectifsObjectifs dudu courscours

• Définir la notion de gestion de réseaux

• Supervision

• Gestion

• Administration …

• But = maintenir un service

QuellesQuelles ressourcesressources ??

– 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, …)

ClassificationClassification normaliséenormalisée

• Gestion de la configuration

• Gestion des fautes

• Gestion de la performance

• Gestion de la sécurité

• Gestion de l’audit

GestionGestion dede lala configurationconfiguration

localisation

i

iti

li

a sa

ti

ons

configurations logicielles et matérielles

états (on, off, stand-by, busy, listen…) n

Identifications

manipulations des configurations

GestionGestion desdes fautesfautes

• Détection

• Localisation

• Correction

• Restauration

• Détection + intervention rapides

GestionGestion dede lala performanceperformance

• Capacité du réseau

• Trafic temps réel

• Débit

li

ti

par app ca on

• 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

oliti ue de sécurité

p

q

• 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

network management system A.Laaroussi 10

Relation manager/agent

Relation manager/agent A.Laaroussi 11

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: Object IDentifier )

– 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

Language 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, OCTET STRING, 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 OCTET STRING:

– 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-2 1}

– sysDescr OBJECT IDENTIFIER ::= {system 1}

Types complexes ASN.1

• Deux types complexes pour définir des tableaux:

• SEQUENCE OF : liste ordonnées de valeurs de même type.

• SEQUENCE : liste ordonnées fixe de valeurs de type 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}

}

• Routeur ipRoutingTable ::= { {181.23.54.0, 181.23.55.1}, {181.23.53.0, 181.23.55.255} } A.Laaroussi 24

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 Intervale

Conventions ASN.1

• ASN.1 fait la différence entre minuscules et majuscules

Terme Types Values Macros Modules Mots réservés

Convention 1ere caractère en Majuscule 1ere caractère en Minuscule tous les caractères en Majuscule 1ere caractère en Majuscule tous les caractères en Majuscule

Macro

• Une macro permet de déclarer un type autre que ceux utilisé de base.

• Déclaration 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-onl "

y

| "read-write"

| "write-only"

| "not-accessible "

Status ::= "mandatory"

| "optional"

| "obsolete"

| "deprecated "

DescrPart ::= "DESCRIPTION" value (description DisplayString)

END

| empty

A.Laaroussi

29

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

END

Counter DisplayString

mib-2

OBJECT-TYPE

TRAP-TYPE

-- Remote Network Monitoring MIB

rmon

-- textual conventions

FROM RFC1155-SMI FROM RFC1158-MIB FROM RFC1213-MIB FROM RFC-1212 FROM RFC-1215;

OBJECT IDENTIFIER ::= { mib-2 16 }

.

.

ÉtiquettesÉtiquettes dede typetype (Tag)(Tag)

• Distinguer d’une manière unique les types.

• Permettre de localiser la provenance des objets (leurs déclaration)

• Utiliser un autre

aramètre autre

ue le

p

q

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

ClassesClasses d’étiquettesd’é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

A.Laaroussi

définie par l’utilisateur pour ses propres besoins

37

ClassesClasses d’étiquettesd’étiquettes

• La classe des étiquettes (entre crochet)

applicative : [APPLICATION n]

– contextuelle : [n]

– universelle ou non étiqueté : INTEGER

– privée : [private n]

ClassesClasses d’étiquettesd’étiquettes

• SNMP utilise les trois premières classes:

• Universal: permet d’encoder les types simples INTEGER, OCTET STRING,etc

• Application: permet d’encoder les types pré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 A.Laaroussi 42
Codage Type-Length-Value A.Laaroussi 42

Codage Type-Length-Value

Codage Type-Length-Value A.Laaroussi 43

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

A.Laaroussi 45

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 INTEGER OCTET STRING NULL OBJECT IDENTIFIER SEQUENCE SEQUENCE-OF

Tag Number 00000010 = 02H 00000100 = 04H 00000101 = 05H 00000110 = 06H 00110000 = 30H 00110000 = 30H

Tag (Application)

Type

IpAddress

Counter

Gauge

TimeTicks

Opaque

Tag Number 01000000 = 40H 01000001 = 41H 01000010 = 42H 01000011 = 43H 01000100 = 44H

Tag Context

Type

GetRequest

GetNextRequest

GetResponse

SetRequest

Trap

Tag Number 10100000 = A0H 10100001 = A1H 10100010 = A2H 10100011 = A3H 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)

TLV (Length) A.Laaroussi 51

Codage INTEGER

Codage INTEGER INTEGER type, Value = “75” A.Laaroussi 52

INTEGER type, Value = “75”

Codage OCTET STRING

Codage OCTET STRING OCTET STRING type, Value = “BBM” A.Laaroussi 53

OCTET STRING type, Value = “BBM”

Codage OBJECT IDENTIFIER

• Pour econimiser 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

Codage OBJECT IDENTIFIER OBJECT IDENTIFIER, Value = { 1 3 6 1 2 1 1 }

OBJECT IDENTIFIER, Value = { 1 3 6 1 2 1 1 }

Codage NULL

Codage NULL NULL type, Value = NULL A.Laaroussi 56

NULL type, Value = NULL

Codage SEQUENCE

VarBind ::= SEQUENCE { name ObjectName value ObjectSyntax

}

VarBindList ::= SEQUENCE OF VarBind

Codage SEQUENCE

Codage SEQUENCE A.Laaroussi 58

Codage IpAddress

Codage IpAddress IpAddress type, Value = “128.150.161.8” A.Laaroussi 59

IpAddress type, Value = “128.150.161.8”

A.Laaroussi

59

Codage TimeTicks

Codage TimeTicks TimeTicks type, Value = “263691156” A.Laaroussi 60

TimeTicks type, Value = “263691156”

Codage Context class

Codage Context class A.Laaroussi 61

Codage Context class (SNMP)

Codage Context class (SNMP) A.Laaroussi 62

A.Laaroussi

62

SIMPLE NETWORK MANAGEMENT PROTOCOL

Historique

SGMP

SNMP

RMON MIB SNMPv2
RMON MIB
SNMPv2

Working Group

Historique SGMP SNMP RMON MIB SNMPv2 Working Group Secure SNMP SNMP v2 Security Working Group SNMP
Historique SGMP SNMP RMON MIB SNMPv2 Working Group Secure SNMP SNMP v2 Security Working Group SNMP

Secure SNMP

Historique SGMP SNMP RMON MIB SNMPv2 Working Group Secure SNMP SNMP v2 Security Working Group SNMP

SNMP v2 Security Working Group

Historique SGMP SNMP RMON MIB SNMPv2 Working Group Secure SNMP SNMP v2 Security Working Group SNMP
Historique SGMP SNMP RMON MIB SNMPv2 Working Group Secure SNMP SNMP v2 Security Working Group SNMP

SNMP v2

ARCHITECTURE SNMP

Processus Processus Manager Agent 7 7 6 SNMP SNMP 6 5 5 4 UDP UDP
Processus
Processus
Manager
Agent
7
7
6
SNMP
SNMP
6
5
5
4
UDP
UDP
4
3
IP
IP
3
Protocoles liés
2
1
au réseau
Protocoles liés
au réseau
2
1
Réseau

Composantes SNMP

STATION DE GESTION DU RESEAU

 
 

MANAGER

 
   
    Tra p  

Tra p

 
SetRequest  

SetRequest

 
   
 

AGENT

 

AGENT

EQUIPEMENT B

EQUIPEMENT B

EQUIPEMENT B
EQUIPEMENT C

EQUIPEMENT C

EQUIPEMENT C

VUE B DE LA MIB

VUE C DE LA MIB

GetRequest

GetNextRequest

VUE B DE LA MIB VUE C DE LA MIB GetRequest GetNextRequest AGENT EQUIPEMENT A VUE

AGENT

AGENT EQUIPEMENT A VUE A DE LA MIB

EQUIPEMENT A

EQUIPEMENT A

VUE A DE LA MIB

LE DIALOGUE SNMP

Station de gestion SNMP

Agent SNMP

Application de gestion Application gère les objets Ressources Gérées Objets Gérés par SNMP Messages SNMP
Application de
gestion
Application
gère les objets
Ressources
Gérées
Objets Gérés par SNMP
Messages
SNMP
SNMP
SNMP
UDP
UDP
IP
IP
Protocoles liés au réseau
Protocoles liés au réseau
Réseau
Get Request
GetNe xtRequest
tReS
tseuqe
GetR esponse
Trap
GetR equest
GetNext Request
RteS
tseuqe
GetR esponse
T
rap

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 noeud géré (agent) de répondre à une requête provenant de la station de gestion

(mana er)

g

.

TRAP

• Cette opération permet à un noeud géré (agent) d'envoyer un message à une station de gestion (manager) lorsqu'un

événement s'est

p roduit sur le noeud

• L'envoi s'effectue de façon asynchrone par l’émission d'un descriptif complet de la situation d'un noeud

SNMP Protocol Data Units (PDUs)

SNMP Protocol Data Units (PDUs) A.Laaroussi 73

Structure SNMP PDU

Structure SNMP PDU A.Laaroussi 74

Structure SNMP PDU

• version number: (INTEGER) assure que le manager te 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 Type

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

GetRequest/GetResponse PDU A.Laaroussi 79

SetRequest/GetResponse PDU

SetRequest/GetResponse PDU A.Laaroussi 80

structure de la PDU Trap

structure de la PDU Trap A.Laaroussi 81

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

A.Laaroussi 85

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 noeuds qui implémentent EGP

• CMOT : relatif au protocole CMOT (Common Management Over TCP/IP).

Groupe System

Groupe System A.Laaroussi 87

Groupe Interfaces

Groupe Interfaces A.Laaroussi 88

Groupe Address Translation

Groupe Address Translation A.Laaroussi 89

Groupe IP

Groupe IP A.Laaroussi 90

Groupe ICMP

Groupe ICMP A.Laaroussi 91

Groupe TCP

Groupe TCP A.Laaroussi 92

Groupe UDP

Groupe UDP A.Laaroussi 93

Groupe EGP

Groupe EGP A.Laaroussi 94

Groupe Transmission

Groupe Transmission A.Laaroussi 95

LES AGENTS SPECIAUX

LES AGENTS SPECIAUX Station C Station D Station A Routeur Routeur Lien WAN Mise à jour

Station C

LES AGENTS SPECIAUX Station C Station D Station A Routeur Routeur Lien WAN Mise à jour

Station D

LES AGENTS SPECIAUX Station C Station D Station A Routeur Routeur Lien WAN Mise à jour

Station A

Routeur Routeur Lien WAN Mise à jour des informations
Routeur
Routeur
Lien WAN
Mise à jour
des
informations

Sonde RMON

A Routeur Routeur Lien WAN Mise à jour des informations Sonde RMON Station B Station de

Station B

A Routeur Routeur Lien WAN Mise à jour des informations Sonde RMON Station B Station de

Station de

gestion

RMON

• La RMON MIB est une MIB spéciale qui contient les objets nécessaires à la gestion distante, via SNMP, d'un

é q

ui ement de mesure

p

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 Station de gestion SNMP Agent 1 SNMP Agent 1 XYZ PROXY AGENT Agent

Station de gestion SNMP

LES AGENTS PROXY Station de gestion SNMP Agent 1 SNMP Agent 1 XYZ PROXY AGENT Agent

Agent 1 SNMP

Agent 1 XYZ

PROXY AGENT

Agent 2 XYZ

Agent 2 SNMP

Agent 3 XYZ

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

Valeurs des PDU

PDU Type Value

PDU Type

0

GetRequest

1

GetNextRequest

2

Response

3

SetRequest

4

Trap SNMPv1

5

GetBulkRequest

6

InformRequest

7

Trap SNMPv2

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.

un message. • La PDU GetBulkRequest offre la possibilité de spécifier des successeurs multiples. A.Laaroussi 109

GetBulkRequest PDU format

GetBulkRequest PDU format • PDU type — Identifie le PDU comme opération GetBulk. • Request ID

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

A.Laaroussi

110

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 ).

A.Laaroussi

111

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

Statut d'erreur

Nom

Statut d'erreur

Nom

0

noError

7

wrongType

14

commitFailed

1

tooBig

8

wrongLength

15

undoFailed

2

noSuchName

9

wrongEncoding

16

authorizationError

3

badValue

10

wrongValue

17

notWritable

4

readOnly

11

noCreation

18

inconsistentName

5

genErr

12

inconsistentValue

 

6

noAcess

13

resourceUnavailable

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 seul 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

Agent

GetResponse Trap Manager Bilingue SNMP v2 Agent
GetResponse
Trap
Manager
Bilingue
SNMP v2
Agent

GetRequest

GetNextRequest

SetRequest

GetRequest

InformRequest

GetNextRequest SetRequest GetRequest InformRequest GetNextRequest GetBulkRequest Setrequest InformRequest Trap

GetNextRequest

GetBulkRequest

Setrequest

InformRequest Trap SNMP v2 Response

SNMP v2

Manager

SNMP v3

• Cette norme reprend la versions 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

Authentification Les étapes d'authentification sont les suivantes : •Le transmetteur groupe des informations à

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

Le cryptage A.Laaroussi 122

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érieur à 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 A.Laaroussi 125

Distribution des mots de passe

SnmpEngineID

Mot de passe

Hash

Digest0

Distribution des mots de passe SnmpEngineID Mot de passe Hash Digest0 Hash Digest1 Mot de passe
Distribution des mots de passe SnmpEngineID Mot de passe Hash Digest0 Hash Digest1 Mot de passe

Hash

Digest1

Mot de passe localisé

SNMPv3 ARCHITECTURE

SNMP ENTITY

SNMP APPLICATIONS

COMMAND

COMMAND

NOTIFICATION

NOTIFICATION

PROXY

GENERATOR

RESPONDER

ORIGINATOR

RECEIVER

FORWARDER

OTHER

OTHER

SNMP ENGINE

DISPATCHER

MESSAGE PROCESSING SUBSYSTEM

SECURITY

SUBSYSTEM

ACCESS CONTROL SUBSYSTEM

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’occuppe des services d’authentification et de cryptage. Authentification est soit community-based (SNMP v1 and v2) ou user- based 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: pemet la redirection des messages SNMP.

SNMPv3 ARCHITECTURE: MANAGER

A.Laaroussi
A.Laaroussi

130

SNMPv3 ARCHITECTURE: AGENT

A.Laaroussi
A.Laaroussi

131

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

contextName=card1

contextName=card2

SNMP ENTITY

MIB

MIB
MIB
MIB
SNMP ENTITY MIB MIB COMMAND RESPONDER APPLICATION OTHER SNMP ENGINE snmpEngineID=1 The context can be reached

COMMAND RESPONDER APPLICATION

OTHER

SNMP ENGINE

snmpEngineID=1

The context can be reached from this engine, thus:

contextEngineID=1

SNMPv3 MESSAGE STRUCTURE

A.Laaroussi
A.Laaroussi

134

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 si il n’y a pas

d’authentification. Autrement, ce champ contient le digest HMAC du message.

• msgPrivacyParameters : la valeur est nulle si 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

USM message processing A.Laaroussi 138

SNMPv3 flow

SNMPv3 flow A.Laaroussi 139

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

MIB VIEWS A.Laaroussi 143

ACCESS CONTROL TABLES

MIB View

Allowed

Allowed

Required level of security

operations

Managers

Interface Table

SET

Admin1

authentication

Interface Table

GET/GETNEXT

Admin2

Authentication

Encryption

System

GET/GETNEXT

Admin3

None

logique VACM

logique VACM A.Laaroussi 145

SNMPv3 RFCs

SNMP ENTITY

RFC 2571

SNMP APPLICATIONS

RFC 2573

OTHER

SNMP ENGINE

RFC 2572

DISPATCHER

RFC 2572

MESSAGE PROCESSING SUBSYSTEM

USM: RFC 2574

SECURITY

SUBSYSTEM

VACM: RFC 2575

ACCESS CONTROL SUBSYSTEM