Transcript dess-chap7.p

Chapitre 7
Administration SNMP avancée
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)
SNMPv1
RMON MIB
Secure SNMP
SNMPv2
Working Group
SNMPv2 Security
Working Group
SNMPv2 (original version)
SNMPv2C
SNMPv2*
SNMPv2u
SNMPv3
Le modèle de sécurité USM de SNMPv3
(User-Based Security Model)
RFC
2574
• 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
Machine (ou moteur) SNMPv3
Command
initiator
Entité
SNMP
Command
responder
Notification
initiator
Notification
receiver
Machine SNMP
(identifiée par snmpEngineID)
Dispatcher
Message
Processing
subsystem
Security
subsystem
Access control
subsystem
• 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
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
Cadre d’administration SNMPv3
1.3.6.1
10 -> 18 RFC2571 à RFC 2576
2
MIB-2
4
6
Private
1
SNMPv2
snmpProxys
2
snmpModules
3
14
snmpMIB
Admin
1
10
11
Frame
Work
Engine
1
12
MPD Applications
2
1
2
3
MD5
SHA
1
Conformance
EngineID
2
Engine
Boots
3
14
15
Notifications Proxys
2
Priv
protocol
1
3
13
USM
MIB
Objects
1
Context
UsmUser
2
Security
4
Engine Max
Time
Message
Size
1
16
18
VACM
1
2
1
MIB
Objects
1
2
Access
3
snmp
Community
Table
4 TreeFamily
Format du message SNMPv3
• Format général du message SNMPv3 :
Message SNMPv3
msgVersion(3) msgGlobalData msgSecurityParameters
msgData
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)
}
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 SNMPv3
msgAuthoritativeEngineID
msgAuthoritativeEngineBoots
msgAuthoritativeEngineTime
msgUserName
msgAuthenticationParameters
msgPrivacyParameters
• 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
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 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
(Tronqués à 96 bits)
authKey
(128 bits)
MD5
algorithm
Output
(128 bits)
msgAuthenticationParameters
(Tronqués à 96 bits)
SNMP
message
• Génération de msgAuthenticationParameters avec HMAC-SHA-96
authKey
(128 bits)
MD5
algorithm
SNMP
message
Output
(128 bits)
msgAuthenticationParameters
(Tronqués à 96 bits)
Paramè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 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 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
• 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)
RFC
2575
• 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
Fonctionnalité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 à 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 RMON
RFC
2819
STD
0059
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)
NMS
RMON
agent
RMON
manager
RMON
RMON
agent
• Valable pour tout type de réseau physique
— Bien adapté pour les LAN
RMON
agent
PC
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)
• 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 alarme
Sampled-object
value
*
*
Rising
threshold
Falling
threshold
*
Entry first
set to valid
*Alarm-event generated
*
*
Time
Evè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-1
internet
1
1
directory
1
2
mgmt
mib-II
16
1
2
3
statistics
alarm
history
experimental
3
4
host
4
private
1
rmon
5
hostTopN
6
7
8
9
filter
event
matrix
packet capture
RMON-2
• RMON2 est une extension de RMON-1
RFC
2021
• 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
Groupes 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)
• 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)
• 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
• 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