Objectifs de certification

CCNA 200-301

  • 4.4 Expliquer la fonction de SNMP dans les opérations réseau


Supervision du réseau SNMP

1. Protocole SNMP

Simple Network Management Protocol (abrégé SNMP), en français “protocole simple de gestion de réseau”, est un protocole de communication qui permet aux administrateurs réseau de gérer les équipements du réseau, de superviser et de diagnostiquer des problèmes réseaux et matériels à distance.

SNMP utilise les ports UDP 161 et UDP 162.

1.1. Version de SNMP

Il existe actuellement 3 versions différentes du protocole SNMP :

La coexistence des trois versions est détaillée dans le RFC 3584.

Il est recommandé d’utiliser SNMPv3 de manière sécurisée avec des méthodes d’authentification et de chiffrement fortes.

1.2. Éléments d’architetcure SNMP

Les systèmes de gestion du réseau par SNMP sont basés sur trois éléments principaux :

  • un superviseur,
  • des noeuds (ou nodes)
  • et des agents.

1.3. Superviseur

Dans la terminologie SNMP, le synonyme “manager” est plus souvent employé que superviseur.

Le superviseur est la console qui permet à l’administrateur réseau d’exécuter des requêtes de gestion SNMP.

Il est client SNMP qui obtient des informations d’un serveur (soit l’équipement à gérer).

1.4. Agents et noeuds

Les agents sont des entités qui se trouvent au niveau de chaque interface, connectant au réseau l’équipement géré (noeud) et permettant de récupérer des informations sur différents objets.

Les équipements gérés tels que des routeurs ou des commutateurs, mais aussi des serveurs et des matériels spécifiques des centres de données remplissent le rôle de serveur SNMP (UDP161/UDP162).

1.5. Objets OID

Les commutateurs, routeurs, postes de travail et serveurs (physiques ou virtuels) sont donc des exemples d’équipements contenant des objets gérables.

Ces objets gérables peuvent être des informations matérielles, des paramètres de configuration, des statistiques de performance et autres objets qui sont directement liés au comportement en cours de l’équipement en question.

Ces objets sont classés dans une sorte de base de données arborescente définie par l’ISO appelée MIB (“Management Information Base”).1 SNMP permet le dialogue entre le superviseur et les agents afin de recueillir les objets souhaités dans la MIB. Disposer du MIB d’un constructeur ou d’un type de matériel a donc tout son intérêt et peut faire l’objet de services payants.

1.6. SNMP en bref

Les équipements gérés (“managed devices”) sont des éléments du réseau (ponts, commutateurs, concentrateurs, routeurs ou serveurs), contenant des “objets de gestion” (“managed objects”) pouvant être des informations sur le matériel, des éléments de configuration ou des informations statistiques.

Les agents, c’est-à-dire les applications de gestion de réseau résidant sur un périphérique, sont chargés de transmettre les données locales de gestion du périphérique dans le format SNMP.

Les systèmes de gestion de réseau (“network management systems” notés “NMS”) sont les consoles à travers lesquelles les administrateurs peuvent réaliser des tâches d’administration.

1.7. SNMP en pratique

Concrètement, dans le cadre d’un réseau, SNMP est utilisé :

  • pour administrer les équipements
  • pour surveiller le comportement des équipements

Il suscite des menaces de sécurité selon la version déployée. Il est déconseillé de l’utiliser dans un réseau non contrôlé.

Il s’implémente d’une part sur le matériel à gérer et, d’autre part, avec une solution de gestion tel qu’un NMS.

1.8. Mise en oeuvre de SNMP

SNMP peut être utilisé de deux manières distinctes : le polling et les traps.

Polling

Le polling consiste simplement à envoyer une requête à intervalles réguliers pour obtenir une valeur particulière. Cette technique est appelée “vérification active”.

On peut vérifier avec un programme ou un script si des valeurs sont correctes. Si la requête échoue, il est possible qu’il y ait un problème avec le périphérique. Cependant, vu que SNMP s’appuie sur UDP, il est conseillé de réitérer la requête pour confirmer le problème.

Traps

Les traps consistent à faire de la vérification passive ; en gros, on configure l’agent SNMP pour qu’il contacte un autre agent SNMP en cas de problème. C’est-à-dire que l’on peut configurer un périphérique réseau (comme un routeur) pour qu’il envoie un trap SNMP lors de certains événements.

Par exemple, le routeur peut envoyer un trap lorsqu’il détecte que la ligne est coupée (down). Quand un événement trap apparaît, l’agent sur le périphérique va envoyer le trap vers une destination pré-configurée communément appelé trap host.

Le trap host possède son propre agent SNMP qui va accepter et traiter les traps lorsqu’ils arrivent. Le traitement des traps est effectué par des trap “handlers”. Le “handler” peut faire ce qui est approprié pour répondre au trap, comme envoyer un courriel d’alerte ou n’importe quel autre acte.

2. SNMPv2c sous Cisco IOS

Les schémas de sécurité dépendent des versions de SNMP (v1, v2c ou v3).2

Dans les versions 1 et 2c, une requête SNMP contient un nom appelé communauté, utilisé comme un “mot de passe”. Sur de nombreux équipements, la valeur par défaut de communauté est “public” ou “private”. Pour des raisons de sécurité, il convient de modifier cette valeur. Un nom de communauté différent peut être envisagé pour les droits en lecture (RO, pour “Read-Only”, lecture seule) et ceux en écriture (RW, pour Read-and-Write, lecture et écriture).

Aussi, on prendra garde de contrôler le trafic entrant avec des ACLs (trafic entrant) sur base des adresses IP d’origine.

Les versions 1 et 2 du protocole SNMP comportent de nombreuses lacunes de sécurité. C’est pourquoi les bonnes pratiques recommandent aujourd’hui de n’utiliser que la version 3.

2.1. Configuration SNMPv2c sous Cisco IOS

En configuration globale, en précisant un nom de communauté et en choisisant les droits RW ou RO (recommandé) :

(config)#snmp-server community <nom> RO

2.2. Sécurisation de SNMPv2c

SNMPv2c se sécurise :

  1. En choisissant judicieusement un nom de Communauté
  2. En configurant des SNMP View
  3. En activant des ACLs sur les Communautés et sur les interfaces
  4. En isolant ce trafic dans un VLAN contrôlé par des ACLs
  5. En activant SNMPv3

Configuration d’ACLs SNMPv2c

Par exemple :

access-list 10 deny any log
snmp-server community public RO 10

2.3. Test SNMP

Point de départ d’un lab SNMPv2c et SNMPv3 en viosl2, en vios, en IOS 12.4 (c3725-adventerprisek9-mz.124-15.T14)

Installation des outils Net-SNMP3 sous Rehat Enterprise Linux ou Centos (RHEL7) :

# yum install net-snmp-utils

Usage :

snmpwalk -v2c -c <nom de la communauté> <périphérique à gérer>

SnmpB est un outil graphique semblable à snmpwalk :http://sourceforge.net/p/snmpb/wiki/Home/

2.4. OIDs

L’arborescence minimale correspond à l’objet .1.3.6.1, iso.org.dod.internet. :

NumberLabel
1iso
.3org
.6dod
.1internet

La commande suivante nous offre la liste de tous les types d’objets disponibles sur le périphérique :

$ snmpwalk -v 2c -c public 192.168.1.254  .1.3.6.1

Dans cette liste, on peut remarquer le type d’objet IF-MIB::ifDescr :

$ snmptranslate -On IF-MIB::ifDescr
.1.3.6.1.2.1.2.2.1.2

2.5. Exemples de requêtes SNMP

Voici quelques exemples de requêtes SNMP récoltant la valeur d’un type d’objet sur un routeur Cisco.

IF-MIB::ifDescr :

snmpwalk -v 2c -c public 192.168.1.254 IF-MIB::ifDescr

IF-MIB::ifType :

snmpwalk -v 2c -c public 192.168.1.254 IF-MIB::ifType

IF-MIB::ifName :

snmpwalk -v 2c -c public 192.168.1.254 IF-MIB::ifName

Voici des exemples avec des filtres d’expressions rationnelles (RegExp) sur l’objet IF-MIB::ifName :

$ snmpwalk -v 2c -c public 192.168.1.254 IF-MIB::ifName | egrep 'Gi0'
IF-MIB::ifName.1 = STRING: Gi0/0
IF-MIB::ifName.2 = STRING: Gi0/1
IF-MIB::ifName.3 = STRING: Gi0/2
IF-MIB::ifName.4 = STRING: Gi0/3
$ snmpwalk -v 2c -c public 192.168.1.254 IF-MIB::ifName | egrep 'Gi0/[0-1]'
IF-MIB::ifName.1 = STRING: Gi0/0
IF-MIB::ifName.2 = STRING: Gi0/1
$ snmpwalk -v 2c -c public 192.168.1.254 IF-MIB::ifName | egrep '(Gi0/[0-1]|Gi1/[2-3])'
IF-MIB::ifName.1 = STRING: Gi0/0
IF-MIB::ifName.2 = STRING: Gi0/1
IF-MIB::ifName.7 = STRING: Gi1/2
IF-MIB::ifName.8 = STRING: Gi1/3
$ snmpwalk -v 2c -c public 192.168.1.254 IF-MIB::ifName | egrep 'Gi[0-1]/[0-1]'
IF-MIB::ifName.1 = STRING: Gi0/0
IF-MIB::ifName.2 = STRING: Gi0/1
IF-MIB::ifName.5 = STRING: Gi1/0
IF-MIB::ifName.6 = STRING: Gi1/1

2.6. Entrées SNMP communes

DescriptionMIBOID
HostnamesysName.1.3.6.1.2.1.1.5.0
UptimesysUpTime.1.3.6.1.2.1.1.3.0
System DescriptionsysDescr.1.3.6.1.2.1.1.1.0
System ContactsysContact.1.3.6.1.2.1.1.4.0
System LocationsysLocation.1.3.6.1.2.1.1.6.0
IOS Version ciscoImageString.5.1.3.6.1.4.1.9.9.25.1.1.1.2.5
1 Minute CPU Util.avgBusy1.1.3.6.1.4.1.9.2.1.57.0
5 Minute CPU Util.avgBusy5.1.3.6.1.4.1.9.2.1.58.0
Free MemoryfreeMem.1.3.6.1.4.1.9.2.1.8.0
IOS Feature SetciscoImageString.4.1.3.6.1.4.1.9.9.25.1.1.1.2.4
Reload ReasonwhyReload.1.3.6.1.4.1.9.2.1.2.0

On trouvera d’autres sources d’inspiration sur ces pages : How To Calculate Bandwidth Utilization Using SNMP et oid 1.3.6.1.2.1.31.1.1.1

2.7. Exemple RW

Exemple de rapatriement via SNMP de la configuration d’un routeur Cisco (IOSv 15.7(3)M3) à condition de disposer d’un serveur TFTP fonctionnel et d’avoir activé les droits RW sur le périphérique à gérer.

Avec le logiciel net-snmp-utils on peut tenter ce script bash4 :

#!/bin/bash
com=cisco
ip=192.168.1.254
tftp=192.168.1.100
file=config.text

snmpset -c $com -v 2c $ip 1.3.6.1.4.1.9.9.96.1.1.1.1.2.111 i 1
snmpset -c $com -v 2c $ip 1.3.6.1.4.1.9.9.96.1.1.1.1.3.111 i 4
snmpset -c $com -v 2c $ip 1.3.6.1.4.1.9.9.96.1.1.1.1.4.111 i 1
snmpset -c $com -v 2c $ip 1.3.6.1.4.1.9.9.96.1.1.1.1.5.111 a $tftp
snmpset -c $com -v 2c $ip 1.3.6.1.4.1.9.9.96.1.1.1.1.6.111 s $file
snmpset -c $com -v 2c $ip 1.3.6.1.4.1.9.9.96.1.1.1.1.14.111 i 1

2.8. Vérification de la configuration SNMP

#show snmp ?
  chassis      show snmp chassis
  community    show snmp communities
  contact      show snmp contacts
  context      show snmp contexts
  engineID     show local and remote SNMP engine IDs
  group        show SNMPv3 groups
  host         show snmp hosts
  location     show snmp location
  mib          show mib objects
  pending      snmp manager pending requests
  sessions     snmp manager sessions
  stats        show snmp statistics
  sysobjectid  show snmp sysObjectId
  user         show SNMPv3 users
  view         show snmp views
  <cr>

3. SNMPv3 sous Cisco IOS

On a vu comme la sécurité des échanges SNMP peut être compromises à travers deux options de droits (RO et RW) et un nom de communauté visible comme seule authentification et sans chiffrement. Il va de soi que le filtrage implémenté sur les périphériques et dans les politiques de transfert (pare-feu, VACLs, IDS/IPS) restent des bonnes pratiques.

Le principal intérêt d’utiliser SNMPv3 sont les suivantes :

  • L’authentification.
  • Le chiffrement du trafic.

3.1. Choix de configuration

Trois configurations sont possibles : noAuthNoPriv, authNoPriv et authPriv qui correspondent à trois niveaux d’authentification (nulle, MD5 ou SHA) et de chiffrement (DES, 3DES, AES-128, AES-192 ou AES-256).

NiveauAuthentificationChiffrement
noAuthNoPrivNom d’utilisateurNon
authNoPrivMessage Digest Algorithm 5 (MD5) ou Secure Hash Algorithm (SHA)Non
authPrivMD5 ou SHADES, 3DES, AES-128, AES-192, AES-256

3.2. Configuration SNMPv3 sécurisée sous Cisco IOS

Dans cet exemple5, on trouvera la configuration d’un périphérique Cisco avec les fonctionnalité suivantes :

  • un filtrage IP (ACL)
  • un filtrage de Vue sur les OIDs SNMP
  • SNMPv3 avec authentification et chiffrement

La procédure de configuration se résume en quatre étapes :

  1. Créer une liste d’accès qui autorise les ordinateurs à interroger le serveur SNMP.
  2. Configurer une vue (“view”) SNMP. Une “view” permet de limiter l’accès à la MIB.
  3. Configurer le groupe SNMP : nom, version, authentification/chiffrement, droits d’accès, vue associée et ACL.
  4. Configurer un utilisateur comme membre du groupe SNMPv3 : nom, groupe, version (v3), authentification (MD5/SHA), mot de passe, chiffrement (AES 128/AES 192/AES 256), mot de passe.

Dans la console du routeur en présumant certains paramètres :

(config)#ip access-list extended LAN
(config-ext-nacl)#permit ip 192.168.1.0 0.0.0.255 any
(config-ext-nacl)#exit
(config)#snmp-server view SNMP-RO iso included
(config)#snmp-server group ADMIN v3 priv read SNMP-RO access LAN
(config)#snmp-server user bob ADMIN v3 auth sha testtest priv aes 128 testest
(config)#snmp-server user alice ADMIN v3 auth md5 testtest priv des testest
(config)#snmp-server host 192.168.1.1 version 3 priv bob

3.3. Test SNMPv3

Sur la station de contrôle, on tenter un connexion avec l’utilisateur bob avec une authentification SHA et un chriffrement AES.

USER=bob
PASSWORD=testtest
SECRET=$PASSWORD
HOST=192.168.1.254

snmpwalk -v3  -l authPriv -u $USER -a SHA -A $PASSWORD -x AES -X $SECRET $HOST

4. Diagnostic SNMP sous Cisco IOS

4.1. show snmp group

La commande “show snmp group” affiche le nom des groupes sur le périphérique, le modèle sécurité, le statut des différentes vues et le type stockage pour chaque groupe.

4.2. show snmp pending

La commande “show snmp pending” affiche la version des requêtes en attente.

Router# show snmp pending
req id: 47, dest: 171.69.58.33.161, V2C community: public, Expires in 5 secs
req id: 49, dest: 171.69.58.33.161, V2C community: public, Expires in 6 secs
req id: 51, dest: 171.69.58.33.161, V2C community: public, Expires in 6 secs
req id: 53, dest: 171.69.58.33.161, V2C community: public, Expires in 8 secs

4.3. show snmp engineID

La commande show snmp engineID” affiche l’identifiant de l’agent SNMP local et de tous les agents distants qui ont été configurés sur le périphérique. Dans la sortie suivante, on observe qu’un routeur a été configuré avec local engineID 00000009020000000C025808 et qu’un agent SNMP distant adressé en 171.69.37.61 s’est connecté en SNMP.

Router# show snmp engineID
Local SNMP engineID: 00000009020000000C025808
Remote Engine ID           IP-addr          Port
123456789ABCDEF000000000   171.69.37.61     162

5. Autres considérations sur SNMP

Les procédures de gestion qui précèdent sont démonstratives sur le plan fondamental mais ne sont pas praticables en environnement de production. On trouvera dans cette dernière section quelques considération d’exploitation.

5.1. Graphes MRTG/RRD

RRDtool6 est un outil de gestion de base de données RRD (Round-Robin database) créé par Tobias Oetiker. Il est utilisé par de nombreux outils open source, tels que Cacti, collectd, Lighttpd, et Nagios, pour la sauvegarde de données cycliques et le tracé de graphiques, de données chronologiques. Cet outil a été créé pour superviser des données serveur, telles la bande passante et la température d’un processeur. Le principal avantage d’une base RRD est sa taille fixe.

RRDTool inclut également un outil permettant de représenter graphiquement les données contenues dans la base.

RRDTool est un logiciel libre distribué selon les termes de la GNU GPL.

5.2. Supervision Open Source

Sous Windows :

  • TFTPD32 / TFTPD64 : Serveur DHCP, TFTP, DNS, SNTP, Syslog,TFTP client, prêt en IPv6.

En “Appliance” ou logiciel Linux :

5.3. Cacti

Cacti est un outil de graphes basé SNMP, assez léger à déployer.

Sous Debian/Ubuntu, voici sa procédure d’installation :

apt-get install cacti

Choix du serveur Web :

Apache [enter]

Définition des mots de passe.

Configuration en interface Web sur l’URL http://<your_instances_ip>/cacti/.

  1. Il s’agit d’une nomenclature qui identifie des objets et non d’une base de donnée relationnelle comme un SGBD. 

  2. Source : https://fr.wikipedia.org/wiki/Simple_Network_Management_Protocol 

  3. Source: Net-SNMP 

  4. gist 

  5. Cisco Troubleshooting TechNotes : Securing Simple Network Management Protocol 

  6. Source : RRDTool