Administration SNMP avancéeAdministration SNMP avancée

Chapitre 7Chapitre 7

Pourquoi authentification et confidentialité ?Pourquoi authentification et confidentialité ?

• Authentification :— Empêche les accès non-autorisés à une administration d’agent— Empêche les modifications non-autorisées de la configuration de

l'équipement administré– L’authentification triviale SNMPv1 limite la sécurité de l'opération set

• Confidentialité :— Protège les informations d’administration contre l’interception et les écoutes

• De quoi avons-nous besoin pour une application ?— Authentification et/ou confidentialité ?

– L'authentification limite l'accès aux entités autorisées — pénalité minime sur la performance

– La confidentialité utilise des techniques de cryptage — cela peut consommer un temps CPU très important

Etapes dans le développement de la sécurité dans SNMP (suite)Etapes dans le développement de la sécurité dans SNMP (suite)

SNMPv1

RMON MIB

SNMPv2Working Group

Secure SNMP

SNMPv2 SecurityWorking Group

SNMPv2 (original version)

SNMPv3

SNMPv2u SNMPv2*SNMPv2C

Le modèle de sécurité USM de SNMPv3 (User-Based Security Model)Le modèle de sécurité USM de SNMPv3 (User-Based Security Model)

• SNMPv3 supporte plusieurs modèles de sécurité, qui sont respectivement — SNMPv1— SNMPv2C— USM

• Le modèle USM comporte les mécanismes— D’authentification

– Intégrité des données et authentification de la source— De notion de temps

– Protection contre les tentatives de retarder ou rejouer les messages— De confidentialité

– Protection contre l’espionnage du contenu du message— De découverte

– Capacité pour une machine SNMP de prendre connaissance d’informations sur d’autres machines SNMP

— De gestion de clés pour la sécurité– Génération, changement et utilisation de clés

RFC2574

Machine (ou moteur) SNMPv3Machine (ou moteur) SNMPv3

• Dispatcher — permet le support pour différentes versions concurrentes de SNMP — Reçoit les PDUs des Applications SNMP à transmettre sur le réseau— Transmet/reçoit les PDU vers le sous-système de traitement du

message (MP)— Transmet/reçoit les messages SNMP à destination du réseau

       

 

EntitéSNMP

Machine SNMP(identifiée par snmpEngineID)

Access control subsystem

DispatcherMessage

Processingsubsystem

Securitysubsystem

Command initiator

Command responder

Notification initiator

Notification receiver

Machine (ou moteur) SNMPv3 (suite)

Machine (ou moteur) SNMPv3 (suite)

• Sous-système de traitement du message (Message processing subsystem)— Prépare les messages pour envoi — Extrait les données des messages reçus

• Sous-système de sécurité (Security subsystem)— Procure les services de sécurité, tels que l’authentification et le cryptage

• Sous-système de contrôle d’accès VACM (View based Access Control Module)— Gère les autorisations d’accès

– Peut être utilisé par une application pour vérifier les droits d’accès

2 4 6

1 2

18

3

1

1 11

2

1615141312

21

1

12

2 3 2

10

3

4

321

MD5 SHA

EngineID EngineBoots

Engine Time

Max Message Size

Priv protocol

AdminEngine

Conformance

snmpMIB

Applications Notifications Proxys USM

1

MIB Objects

UsmUser

VACM

4

3

2

1

1

1

Access

Security

Context

TreeFamily

MIB Objects

snmp Community Table

MIB-2Private

SNMPv2

1.3.6.1

snmpProxys snmpModules

MPDFrame Work

10 -> 18 RFC2571 à RFC 2576

141414

Cadre d’administration SNMPv3Cadre d’administration SNMPv3

Format du message SNMPv3 Format du message SNMPv3

• Format général du message SNMPv3 :

msgGlobalData ::= SEQUENCE { msgID INTEGER (0..2147483647), msgMaxSize INTEGER (484..2147483647),

msgFlags OCTET STRING (SIZE(1)), -- .... ...1 authFlag -- .... ..1. privFlag -- .... .1.. reportableFlag -- Please observe: -- .... ..00 is OK, means noAuthNoPriv -- .... ..01 is OK, means authNoPriv -- .... ..10 reserved, must NOT be used. -- .... ..11 is OK, means authPriv msgSecurityModel INTEGER (0..2147483647) }

msgVersion(3) msgDatamsgGlobalData msgSecurityParameters

Message SNMPv3

Format du message SNMPv3 (suite)Format du message SNMPv3 (suite)

• msgID— Utilisé entre entités SNMP pour coordonner requêtes et réponses

• msgMaxSize— Contient la taille maximum de message supportée par l’expéditeur— La taille maximum que supporte l’expéditeur

• msgSecurityModel— SNMPv3 supporte concurramment plusieurs modèles de sécurité

– Le modèle de sécurité utilisé est indiqué dans ce champ

• msgSecurityParameters— Les paramètres de sécurité transmis à l’implémentation locale du modèle de

sécurité

Paramètres de sécurité de SNMPv3Paramètres de sécurité de SNMPv3

• Chaque machine SNMP a un identificateur (ID) unique— On peut le configurer à la console ou le générer à l’aide d’un algorithme

• Tout échange SNMP implique une machine authoritative et une machine non-authoritative — La machine SNMP authoritative joue en gros le rôle de “l’agent” en v1

msgAuthoritativeEngineID

msgAuthoritativeEngineBoots

msgAuthoritativeEngineTime

msgUserName

msgAuthenticationParameters

msgPrivacyParameters

Paramètres de sécurité de SNMPv3 (suite)Paramètres de sécurité de SNMPv3 (suite)

• msgAuthoritativeEngineID— L’identificateur snmpEngineID de la machine SNMP authoritative impliquée

dans l’échange de ce message– La machine SNMP authoritative représente ce qui est habituellement

appelé “l’agent” en v1/v2C

• msgAuthoritativeEngineBoots— Nombre de fois que cette machine SNMP a été initialisée ou réinitialisée

depuis sa configuration d’origine

• msgAuthoritativeEngineTime— Temps en secondes depuis la dernière incrémentation du paramètre

snmpEngineBoots

• msgUserName— L’entité (en anglais «principal») au bénéfice de laquelle est échangé ce

message

Paramètres d’authentification de SNMPv3Paramètres d’authentification de SNMPv3

• USM autorise deux protocoles d’authentification — HMAC-MD5-96 (Message Digest 5)— HMAC-SHA-96 (Secure Hash Algorithm)

• Génération de msgAuthenticationParameters avec HMAC-MD5-96

• Génération de msgAuthenticationParameters avec HMAC-SHA-96

MD5algorithm

authKey(128 bits)

SNMPmessage

Output(128 bits)

msgAuthenticationParameters

MD5algorithm

authKey(128 bits)

SNMPmessage

Output(128 bits)

msgAuthenticationParameters

(Tronqués à 96 bits)

(Tronqués à 96 bits)(Tronqués à 96 bits)(Tronqués à 96 bits)

(Tronqués à 96 bits)

Paramètres de confidentialité de SNMPv3Paramètres de confidentialité de SNMPv3

• USM utilise DES-CBC (Data Encryption Standard avec cypher block chaining mode) pour l’encryptage— Connu sous l’appellation DES-CBC

• Une valeur de 16 octets (privKey) est entrée pour l’encryptage — Les 64 premiers bits sont utilisés comme clé d’encryptage

– Le bit le moins significatif de chaque octet est ignoré, donnant une clé de 56 bits

• DES-CBC requiert un vecteur d’initialisation de 64-bit pour chaque opération d’encryptage— Généré en prenant les 64 derniers bits de privKey et une valeur aléatoire

résiduelle (”salt”)

• Le champ msgPrivacyParameters est utilisé pour envoyer cette valeur aléatoire (”salt value”) qui permettra à la machine destinataire le déchiffrage du message

Contrôle de la notion de tempsContrôle de la notion de temps

• Chaque machine authoritative doit maintenir deux objets qui font référence à sa notion locale du temps— snmpEngineBoots (valeur maxima 231-1)

– Fixé à zéro à l’installation de la machine SNMP— snmpEngineTime (valeur maxima 231-1)

– Fixé à zéro à l’installation de la machine SNMP ou à sa réinitialisation– snmpEngineBoots est incrémenté quand on atteint la valeur maxima

• Un message est considéré en dehors de la fenêtre en temps si les paramètres de temps contenus dans le message entrant diffèrent de plus de 150 secondes de la copie locale du temps— Ou si snmpEngineBoots a atteint sa valeur maxima

Synchronisation en tempsSynchronisation en temps

• Toute machine SNMP non authoritative doit rester synchronisée de façon approximative avec la machine authoritative avec laquelle elle échange— Elle utilise à cette fin une copie locale des trois variables suivantes :

– snmpEngineBoots– snmpEngineTime– latestReceivedEngineTime

• La synchronisation est maintenue par la machine authoritative qui envoie dans chaque message ses valeurs courantes de snmpEngineBoots et snmpEngineTime— Utilisée par la machine non authoritative pour mettre à jour ses valeurs

locales

MIB du groupe usmUser MIB du groupe usmUser

• L’ensemble des MIB SNMPv3 est défini sous le branchement snmpModules 1.3.6.1.6.3 (réservé pour SNMPv2/v3)

• Chaque entité SNMP maintient un MIB group contenant des informations sur les “principals” locaux et distants— Le groupe usmUser comprend :

– usmUserSpinLock– usmUserTable

• La variable usmUserSpinLock coordonne plusieurs applications pour l’utilisation des facilités de renouvellement de clés

• La table usmUserTable comprend une rangée pour chaque “principal” susceptible de communiquer avec cette machine SNMP, contenant— Les protocoles d’authentification et de confidentialité à mettre en œuvre

dans un échange avec ce principal— Les objets à utiliser pour valider le renouvellement des clés

Le modèle de contrôle d’accès VACM (View-Based Access Control Model)Le modèle de contrôle d’accès VACM (View-Based Access Control Model)

• Le modèle VACM présente deux caractéristiques de base— Détermine si l’accès à un objet administré doit être autorisé — Utilise une MIB qui définit la politique de contrôle d’accès pour cet agent

– La MIB VACM

• Cette MIB comprend des tables pour — Les contextes locaux

– Un sous-ensemble d’instances des objets de la MIB locale— Les Groupes

– Une énumération de principals au bénéfice desquels les objets sont accédés

— Droits d’accès– Définit les accès autorisés à un contexte pour un groupe particulier

— MIB Views– Définit un ensemble d’une sous-arborescence d’objets

RFC2575

Fonctionnalités du VACMFonctionnalités du VACM

• Le modèle VACM permet de restreindre l’accès concernant : — Le Principal formulant la requête d’accès — L’objet de la MIB sur lequel l’accès est demandé— Sur le type d’accès (par ex., get ou set) requis

• En plus, le modèle VACM permet de renforcer des restrictions ultérieures telles que — La mise en œuvre de l’authentification pour les opérations set— L’utilisation de l’authentification et de la confidentialité pour l’accès à des

informations privées dans les MIB

Motivation pour le contrôle à distanceMotivation pour le contrôle à distance

• Classiquement, le contrôle de réseau requiert une visite sur site avec un analyseur de protocole— Ou une dépendance de produits propriétaires

• Les agents n'ont pas la possibilité d'envoyer des statistiques en bloc— Faute de quoi les données de la MIB sont filtrées de manière à ce que

seules les informations importantes soient communiquées au gestionnaire

• La solution SNMP est la MIB RMONRFC2819

STD0059

Services RMON Services RMON

• RMON est un enrichissement important de SNMP initial— Fournit un mécanisme pour contrôler le trafic d'un sous-réseau

– Différent des équipements connectés à un sous-réseau

• Basé sur l'idée d'un contrôle à distance— Regroupe les informations, transmises ensuite au gestionnaire

– De concept similaire à certains produits "analyseur de réseau local"

• Le contrôle à distance peut être un équipement dédié— Un routeur ou une station à usage général

• Les fonctions dispensées sont similaires aux équipements d'analyse de réseau local— Le contrôle de l'activité globale ou entre équipements particuliers— La collecte de statistiques et la capture de trafic

Services RMON (suite)Services RMON (suite)

• Valable pour tout type de réseau physique— Bien adapté pour les LAN

NMS

RMONagent

RMONmanager

RMONagent

RMON

RMONagent

PC

Fonctionnalités RMON (suite)Fonctionnalités RMON (suite)

• Contrôler un agent à partir de plusieurs gestionnaires, de manière sécurisée— Le propriétaire d'une rangée est spécifié par une colonne dans une table de

contrôle— Par convention, les non-propriétaires considèrent que la rangée est de type

lecture seule ("ro")— Aucun protocole pour passer outre cette convention

• Modifier de manière sécurisée les tables de données dans l'agent— SNMPv1 n’offre rien pour l'ajout et l'effacement des rangées de tables— RMON fournit un guide avec des règles de conventions et de procédures— Chaque table a une colonne EntryStatus permettant de contrôler les mises à

jour des “entrées”– EntryStatus ::= INTEGER {valid (1),createRequest (2),underCreation (3),invalid (4)

Fonctionnalités RMON (suite)Fonctionnalités RMON (suite)

• Dispensent de plus deux services clé :— Alarmes

– Définit une période d'évaluation et un seuil de déclenchement pour l'alarme

– Pour tout objet MIB de type compteur, jauge, TimeTicks ou INTEGER– Définit un mécanisme d'hystérésis pour prévenir les fausses alarmes

— Evénements– Une table d'événements à signaler, tels que les alarmes– Peuvent être déclenchés par une condition à un autre endroit de la MIB– Peuvent déclencher une action définie à un autre endroit de la MIB– Peuvent faire en sorte que des informations soient enregistrées– Peuvent occasionner l'émission d'une alerte SNMP

Exemple d’événement de type alarmeExemple d’événement de type alarme

Sampled-objectvalue

Risingthreshold

Fallingthreshold

Entry firstset to valid

*Alarm-event generated

Time

*

*

*

*

*

EvènementsEvènements

• L'entrée de table d'événement contient— eventIndex : un identificateur unique pour cette rangée dans eventTable— eventDescription : une description textuelle de cet événement— eventType : none (1), log (2), trap (3) ou log et trap (4)— eventCommunity : la communauté SNMPv1 pour trap, éventuellement— eventLastTimeSent : sysUpTime lorsque l'événement est déclenché

• L'entrée de table d'enregistrement contient— logEventIndex : identité de l'événement générant cette entrée— logIndex : identificateur unique de cette entrée dans l'enregistrement— logTime : sysUpTime lorsque cette entrée d'enregistrement a été créée— logDescription : description dépendante de l'implémentation de

l'événement occasionnant cette entrée d'enregistrement

MIB RMON-1MIB RMON-1

internet1

1 2 3directory

1

16 rmon

mib-II

mgmt experimental

2 4 67

filter8

1 3 5 9statistics

historyalarm

hosthostTopN

matrix packet captureevent

4

1

private

RMON-2RMON-2

• RMON2 est une extension de RMON-1

• La principale fonctionnalité ajoutée est de permettre à RMON une analyse jusqu’à la couche Application— Cet enrichissement est obtenu en ajoutant 9 nouveaux groupes

• La RFC 2021 décrit également des ajouts à la MIB RMON— On a rajouté DroppedFrames et LastCreateTime à chaque table définie

dans la MIB RMON— La table RMON filter est “augmentée” (instruction AUGMENT) par un

mécanisme qui autorise le filtrage à partir d’un offset d’un certain protocole, même si les en-têtes de ces protocoles sont de longueur variable

— Les états des bits filtre et capture de RMON sont augmentés par des bits additionnels pour des médias étendus ou génériques– Ces ajouts sont réservés uniquement pour les équipements qui

supportent déjà Rmon-1

RFC2021

Groupes fonctionnels de la MIB RMON-2Groupes fonctionnels de la MIB RMON-2

• Protocol Directory { rmon 11 }— Inventorie les protocoles que la sonde peut analyser, en autorisant la

configuration, l’addition et la suppression d’entrées dans cette liste– Les identifiants de protocoles sont définis dans la RFC 2074

• Protocol Distribution { rmon 12 }— Collecte les octets et les paquets relatifs aux différents protocoles détectés

sur le réseau

• Address Map { rmon 13 }— Liste les correspondances adresses MAC et adresses réseau découvertes

par la sonde et sur quelle interface elles ont été vues en dernier

Groupes fonctionnels de la MIB RMON-2 (suite)Groupes fonctionnels de la MIB RMON-2 (suite)

• Network Layer Host { rmon 14 }— Comptabilise la quantité de trafic à partir et à destination de chaque adresse

réseau découverte par la sonde

• Network Layer Matrix { rmon 15 }— Comptabilise la quantité de trafic échangée entre chaque paire d’adresses

réseau repérée par la sonde

• Application Layer Host { rmon 16 }— Comptabilise la quantité de trafic, par protocole, à partir et à destination de

chaque adresse réseau découverte par la sonde

Groupes fonctionnels de la MIB RMON-2 (suite)Groupes fonctionnels de la MIB RMON-2 (suite)

• Application Layer Matrix { rmon 17 }— Comptabilise la quantité de trafic, par protocole, échangée entre chaque

paire d’adresses réseau repérée par la sonde

• User History { rmon 18 }— Combine les mécanismes des groupes History et Alarm (de Rmon) pour

permettre une acquisition History sur mesure

• Probe Configuration { rmon 19 }— Contrôle de la configuration des divers paramètres opérationnels de la

sonde

Coexistence entre SNMPv1, v2 et v3 Coexistence entre SNMPv1, v2 et v3

• La stratégie de coexistence entre SNMPv1/v2/v3 est explicitée dans la RFC 2576

• Les techniques décrites font appel aux options présentées dans les pages précédentes— Utilisation d’agents ou de gestionnaires en mode dual— Utilisation d’agents proxy

• De plus, pour une coexistence complète, la RFC 2576 recommande la conversion des MIB définies pour SMIv1 en SMIv2