Configuration de l’agent SNMP V3 Unix NET-SNMP (formely UCD-SNMP)

Introduction
Les directives du fichier de configuration SNMPD.CONF
Directive rocommunity et rwcommunity
Directive rouser et rwuser
Directive COM2SEC
Directive GROUP

Directive VIEW

Directive ACCESS

Création d'utilisateurs pour SNMP v3

Exemples de configurations

Configuration avec restriction limitée aux communautés SNMP

Configuration avec restriction sur l'adresse IP du Manager SNMP

Configuration avec restriction sur le réseau source

Configuration avec restriction sur une branche de l’arbre des MIB

Configuration avec restrictions multiples

Configuration avec restriction sur utilisateur (SNMP V3)

Configurer les HOST sous LORIOTPRO pour SNMP v3.

Introduction

Ce HOW TO explique par l’exemple les configurations de l’agent NET-SNMP (UCD-SNMP) disponible pour de nombreuse plate forme Unix. Les exemples de configuration présents dans ce document ont été réalisés sur une REDHAT 7.3  avec UCD-SNMP 4.2.4 Release 3.

Ce document est la propriété de la société LUTEUS et ne peut être reproduit et/ou diffusé sans son accord.

UCD-SNMP peut être utilisé dans les trois versions de SNMP d’ou son intérêt dans notre démonstration. L’objectif étant à la finale de disposer avec LORIOTPRO d’un mode de supervision et d’administration sécurisé des systèmes UNIX grâce à SNMP v3.

Le dernier chapitre traite de la configuration de LORIOTPRO avec l’agent UCD-SNMP préalablement configuré.

Les directives du fichier de configuration SNMPD.CONF

Pour comprendre ces directives il est important de lire en premier le How to sur SNMP V3 et les concepts VACM et USM.

UCD-SNMP dispose de deux modes de configuration. Pour simplifier la configuration, des directives simples et minimales permettent rapidement de configurer le contrôle d’accès en SNMP v1, SNMP v2c et SNMP v3 ainsi que les utilisateurs en SNMP v3

Les directives simples sont ROCOMMUNITY, RWCOMMUNITY, ROUSER et RWUSER.

Pour les administrateurs qui souhaitent avoir la maîtrise précise de qui fait quoi en terme d’accès devront utiliser les directives avancées COM2SEC, GROUP, VIEW et ACCESS.

En premier il faut définir "à qui les accès sont donnés". Pour cela les directives à utiliser, sont COM2SEC et GROUP.

Après avoir défini le "à qui les accès sont donnés" il faut définir le « à quoi les utilisateurs pourront accéder » dans l'arbre des MIB. Les directives ACCESS et VIEW

Ces directives vont permettre de créer les table du modèle VACM (View Access Control Model) définie par le RFC 2575) pour rappel ci-dessous.

Nous commençons par étudier les directives simples puis ensuite nous détaillerons les directives avancées utilisées pour compléter les tables

Les quatre tables sont dans le  modèle VACM visibles dans la branche des MIB SNMPv2


Il est donc possible de vérifier et de modifier à partir du manager SNMP le contenu des tables de configuration des agents

Directive rocommunity et rwcommunity

Ces deux commandes  permettent de configurer rapidement et simplement l'accès à l'agent pour des utilisateurs en mode SNMP v1 et v2c.

Syntaxe :

rocommunity COMMUNITY [SOURCE] [OID]
rwcommunity COMMUNITY [SOURCE] [OID]


L'option obligatoire COMMUNITY est la communauté de l'agent (sorte de mot de passe utilisé par le manager pour accéder à l'agent)
L'option non obligatoire SOURCE permet comme dans les options de com2sec de spécifier un nom de host ou une adresse IP et son masque
L'option non obligatoire OID permet de spécifier l'OID d'un objet ou d'une branche et sont contenu dans l'arbre des MIB.

Ces commandes créent dans les tables VACM les entrées nécessaires.

Directive rouser et rwuser

Ces deux commandes  permettent de configurer rapidement et simplement l'accès à l'agent pour des utilisateurs et en mode SNMPv3.

rouser USER [noauth|auth|priv] [OID]
rwuser USER [noauth|auth|priv] [OID]



L'option [noauth|auth|priv] permet de spécifier le mode de sécurité, sans authentification, avec authentification, avec chiffrement.
L'option OID permet de spécifier l'OID d'un objet ou d'une branche et sont contenu dans l'arbre des MIB.
rouser donne l'accès en lecture seulement (read only)
rwuser donne l'accès en lecture et écriture (read write)

La création du premier utilisateur dans la table des utilisateurs doit être réaliser en mode v1 ou v2c. Il est impossible de créer un utilisateur en mode v 3 tant qu'il n'y a pas au moins un utilisateur sur avec lequel on puisse modifier la table.

Pour cela on utilise la commande snmpusm suivante
snmpusm -v 2c localhost create user1

ensuite ils est possible de créer des utilisateurs sécurisés par la commande :

Directive COM2SEC

La directive com2sec permet de définir un nom symbolique appelé SECURITY NAME et d'établir une correspondance avec une paire constituée du nom du host ou de son adresse IP, la SOURCE et de sa communauté COMMUNITY. La communauté étant ici celle utilisée classiquement en SNMP.
Si la source prend la valeur réservé "default" cela permet de ne pas restreindre ce SECURITY NAME à un host particulier.

Syntaxe :

com2sec SECURITY.NAME SOURCE COMMUNITY

Exemple : com2sec intranet 12.1.1.0/24 public
crée le nom intranet contenant tous les host appartenant au réseau 12.1.1.0 utilisant la communauté public.

SI le host est configuré pour utiliser la même communauté en lecture seule et lecture écriture une seule ligne suffit. Sinon il faut créer deux correspondance :

Exemple :

comm2sec rocom default public
com2sec rwcom default private

Directive GROUP

La directive group permet de définir un nom symbolique pour établir une correspondance avec une paire constitué du securityName et d'un securityModel.

Syntaxe

group NAME SECURITY.MODEL SECURITY.NAME

Le SECURITY.NAME est créé par la directive com2sec.

Le SECURITY.MODEL est soit «v1 pour SNMP version 1, soit v2c pour SNMP version 2 soit usm (User-based Security Model) pour SNMP version3. RFC3414.

Si usm est spécifié seul les utilisateurs définis par createUser (voir création d'utilisateurs en SNMPv3) seront concernés.

Exemple :

group administrateurs v2c intranet

crée le group administrateurs sur la version SNMP v2c pour le securityName intranet

Exemple de table vacmsecuritytogroupentry dans le mode VACM View-Based Access Control Model définie dans le RFC2275.

avec comme objets

Directive VIEW

Le mot réservé view est utilisé pour créer un nom symbolique représentant une sélection un ou des objets particulier de l'arbre des MIB. Ce peut être une branche entière de l'arbre, un seul objet voire une instance d'un d'objet table (une interface réseau par exemple).

La syntaxe est la suivante:

view NAME  included/excluded OID MASK

le paramètre NAME permet d'identifier cette view pour y faire référence dans la commande access. Le nom donné peut être quelconque.

le paramètre suivant est un mot clé dont la valeur est soit included soit excluded. Il permet d'inclure ou d'exclure une branche, un objet, une instance particulière.

le paramètre OID précise sur quelle branche ou objet de la MIB s'applique la view. Le nom peut être long ".iso.org.dod.internet.mgmt.mib-2.system") ou court "system".La valeur peut être précisé sous sa forme d'OID numérique. (exemple : .1.3 pour iso.org)

Le paramètre mask est utilisé pour contrôler quels éléments d'une branche  ou d'une table doit être pris en compte. Il vous permet par exemple de contrôler l'accès à une ligne dans une table. Un ISP  peut avec ce principe donner l'accès à ses clients à leur interface réseau d'un serveur mutualisé.

Par défaut (ff) si il n'est pas spécifié, il permet d'accéder à tous les éléments de la branche. Le masque est constitué d'une liste d'octets en hexadécimal

exemple de configuration

view      client1  included           interface.ifTable.ifentry.ifindex.1 ff.          a0
view      client2   included           interface.ifTable.ifentry.ifindex.2 ff.         a0

La première ligne permettra au client 1 de voir l'interface d'index 1 dans la table tandis que la seconde permettra au client 2 de voir l'interface d'index 2 dans la table.

L'OID de interfaces iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifIndex.1 est .1.3.6.1.2.1.2.2.1.1.1
Cette OID compte 11 éléments ce qui nécessite un masque de 11 bits minimum. Travaillant sur des masques en octet deux octets sont donc nécessaires. Le masque est lu de gauche à droite (octet de poid fort en premier)
ff.a0 == 11111111.10100000.

ce masque cache tout de la branche interface jusqu'au numéro d'index de la liste des interface à l'exception de ifIndex qui est à 0 (dixième bits)ce qui permet l'accès au contenu de cette ligne

Superposons l'OID et le masque pour une meilleur compréhension
.1.3.6.1.2.1.2.2.1.1.1
.1.1.1.1.1.1.1.1.1.0.1

Autre exemple de masque
Pour prendre l'ensemble de l'arbre des MIB préciser l'objet iso sous sa forme numérique .1 avec le masque 80 (10000000)
Pour ne prendre que la mib-2 (les RFC) sélectionner l'objet iso.org.dod.internet.mgmt.mib-2 ou sous sa forme numérique .1.3.6.1.2.1 soit un masque (11111100) "fc" en Hexa

Les masques les plus courant sont donc:

10000000

80

11000000

c0

11100000

e0

11110000

f0

11111000

f8

11111100

fc

11111110

fe

11111111

ff

Dans le cas où l’on souhaite sélectionner une seule ligne dans une table, le masque est alors plus difficile à établir. Dans l’exemple suivant nous utilisons la table des interfaces d’un host.

Exemple de table « view »


Avec comme objets :

Directive ACCESS

Le mot réservé access permet de définir une correspondance entre des groupes/security.model/security.level et des view. En d'autre terme cela permet de contrôler qui a accès et à quel l'objet de l'arbre des MIB. Celui-ci a 8 paramètres non optionnels. Si vous omettez un de ces paramètres, vous constaterez une erreur lors du chargement du daemon snmpd.

access {group} {context} {model} {level} exact/prefix {arbre-lecture} {arbre-ecriture} {arbre-notification}

Le paramètre {group} est à remplacer par un nom symbolique précédemment défini par une directive group.

Le paramètre {model} permet de restreindre la restriction de l'accès définie dans cette ligne de commande à une version particulière de SNMP, soit v1, v2c, usm).Pour les accès en v1 or v2c le level sera noauth, et le contexte sera vide.

le paramètre {level} (security level) permet de spécifier si l'accès doit être authentifié ou non. Il peut prendre les valeurs auth pour authentifié, noauth pour non authentifié et priv pour privacy. Auth permet d'authentifier les deux entités à l'origine de la communication.Privacy apporte le chiffrement des données lors des communications. Auth et Privacy ne sont disponible que pour le protocole SNMP V 3.

Les paramètres {arbre-lecture} {arbre-ecriture} {arbre-notification} sont des noms de view définis par le mot clé view.
{arbre-lecture} sera l'autorisation en lecture sur la view correspondante
{arbre-ecriture} sera l'autorisation en lecture écriture sur la view correspondante
{arbre-notification} sera l'autorisation de recevoir les notification (trap) de la view correspondante

Remarque : Le context est toujours vide en SNMP v2c et v1, l’authentification est toujours noauth.

Exemple de table « access »

Avec comme objets


Création d'utilisateurs pour SNMP v3

Le restriction d’accès par utilisateurs est disponible depuis la version 3 de SNMP.

Une fois l’utilisateur créé (le sujet de ce chapitre) il est associé à un groupe dans la directive group.

Il existe trois modes de sécurité d’accès

1.       Le mode simple ou l’utilisateur est utilisé pour identifier les requêtes SNMP.

2.       Le mode avec authentification garantit lui que l’utilisateur est bien celui qu’il prétend être

3.       Le mode avec chiffrement (Privacy) garantit la confidentialité des données SNMP.

A l’installation du package UCD-SNMP deux utilisateurs sont créés par défaut dans le fichier /var/ucd-snmp/snmpd.conf.

Les utilisateurs templateMD5 et templateSHA sont utilisés pour créer les utilisateurs définitifs puis seront supprimés par la suite.

Le fichier snmpd doit ressembler à ceci :

#
# net-snmp (or ucd-snmp) persistent data file.

#
# DO NOT STORE CONFIGURATION ENTRIES HERE.
# Please save normal configuration tokens for snmpd in SNMPCONFPATH/snmpd.conf.
# Only "createUser" tokens should be placed here by snmpd administrators.
#

usmUser 1 3 0x800007e580b3239e65aa8fef3e 0x696e697469616c00 0x696e697469616c00 NULL .1.3.6.1.6.3.10.1.1.2 0x6c8a1af4688224a2bdc24a7d4e4c0295 .1.3.6.1.6.3.10.1.2.2 0x6c8a1af4688224a2bdc24a7d4e4c0295 ""

engineBoots 25

oldEngineID 0x800007e580b3239e65aa8fef3e

ATTENTION  Ce fichier bien que portant le même nom que le fichier de configuration snmpd.conf n'est pas situé au même endroit et contiendra uniquement des directives lié à l'authentification. Il est modifié automatiquement au lancement du daemon snmpd. Ce fichier contient  les clés en mode chiffré, il est dynamiquement mise à jour par le system et ne doit pas contenir de directives telles que celles présentent dans le fichier usr/share/snmp/snmpd.conf.

Si vous n’avez pas d’utilisateur dans ce fichier, il faut en créer un.

Pour cela ajouter dans usr/share/snmp/snmpd.conf. les directives suivantes :

Soit

rocummunity public
rwcommunity private
rwuser initial

ou

Group v3group v1 initial
Group v3group v2c initial
Group v3group usm initial
View all included .1 80
Access v3groupe « «  any auth all all all

Le principe étant ici de donner le pouvoir à l’agent UCD-SNMP d’accéder aux tables des MIB pour leur mise à jour. Les paramètres v3 étant mémorisé dans les tables VACM et USM. Dans l’exemple si dessous les tables VCAM seront complétées des droits d’accès pour l’utilisateur initial

Ensuite

Pour créer un nouvel utilisateur en SNMP v3 avec UCD-SNMP il faut ajouter cette directive dans le fichier /var/ucd-snmp/snmpd.conf.

createUser username (MD5|SHA) authpassphrase [DES] [privpassphrase]

exemple de fichier

#
# net-snmp (or ucd-snmp) persistent data file.
#
# DO NOT STORE CONFIGURATION ENTRIES HERE.
# Please save normal configuration tokens for snmpd in SNMPCONFPATH/snmpd.conf.
# Only "createUser" tokens should be placed here by snmpd administrators.
#

createUser initial MD5 setup_password DES

engineBoots 25

oldEngineID 0x800007e580b3239e65aa8fef3e

Puis relancer le processus snmpd

la phrase createUser est enlevé automatiquement et remplacé par une phrase avec les clés hash protégeant la lecture des mots de passe

Pour créer un second utilisateur (user1 par exemple) ajouter la ligne suivante à usr/share/snmp/snmpd.conf

Rwuser user1

Et la ligne suivante dans /var/ucd-snmp/snmpd.conf. (en gras)

#
# net-snmp (or ucd-snmp) persistent data file.
#

# DO NOT STORE CONFIGURATION ENTRIES HERE.
# Please save normal configuration tokens for snmpd in SNMPCONFPATH/snmpd.conf.

# Only "createUser" tokens should be placed here by snmpd administrators.
#
usmUser 1 3 0x800007e580b3239e65aa8fef3e 0x757365723100 0x757365723100 NULL .1.3.6.1.6.3.10.1.1.2 0x6c8a1af4688224a2bdc24a7d4e4c0295 .1.3.6.1.6.3.10.1.2.2 0x6c8a1af4688224a2bdc24a7d4e4c0295 ""
createUser user1 MD5 phrase-de-passe DES
engineBoots 26
oldEngineID 0x800007e580b3239e65aa8fef3e

Relancer le processus snmpd.

Que contient la ligne utilisateur créé par snmpd.

usmUser 1 3 0x800007e580b3239e65aa8fef3e 0x757365723100 0x757365723100 NULL .1.3.6.1.6.3.10.1.1.2 0x6c8a1af4688224a2bdc24a7d4e4c0295 .1.3.6.1.6.3.10.1.2.2 0x6c8a1af4688224a2bdc24a7d4e4c0295 ""

Paramètre

description

usmUser

 

1

 

3

 

0x800007e580b3239e65aa8fef3e

Un numéro unique identifiant le moteur snmp. Attention sauvegardé en mode décimal et non hexa dans les table de MIB

0x757365723100

 

NULL

 

.1.3.6.1.6.3.10.1.1.2

Définie le type de paramètre d’authentification contenu dans le champ suivant.
OID possible :
usmnoauthprotocol
usmhmacmd5authprotocol
usmmacshaauthprotocol

0x6c8a1af4688224a2bdc24a7d4e4c0295

Le hash utilisé pour l’authentification

1.3.6.1.6.3.10.1.2.2

Définie le type de paramètre de chiffrement contenu dans le champ suivant.
OID possible :
Usmnprpivprotocol
usmhmacmd5authprotocol

0x6c8a1af4688224a2bdc24a7d4e4c0295

Le hash utilisé pour le chiffrement

""

 

Le fichier contient un nouvel utilisateur

#
# net-snmp (or ucd-snmp) persistent data file.
#
# DO NOT STORE CONFIGURATION ENTRIES HERE.
# Please save normal configuration tokens for snmpd in SNMPCONFPATH/snmpd.conf.
# Only "createUser" tokens should be placed here by snmpd administrators.
#
usmUser 1 3 0x800007e580b3239e65aa8fef3e 0x757365723100 0x757365723100 NULL .1.3.6.1.6.3.10.1.1.2 0x6c8a1af4688224a2bdc24a7d4e4c0295 .1.3.6.1.6.3.10.1.2.2 0x6c8a1af4688224a2bdc24a7d4e4c0295 ""
usmUser 1 3 0x800007e580b3239e65aa8fef3e 0x696e697469616c00 0x696e697469616c00 NULL .1.3.6.1.6.3.10.1.1.2 0x6c8a1af4688224a2bdc24a7d4e4c0295 .1.3.6.1.6.3.10.1.2.2 0x6c8a1af4688224a2bdc24a7d4e4c0295 ""
engineBoots 26
oldEngineID 0x800007e580b3239e65aa8fef3e

Une alternative consiste à utiliser le programme snmpusm pour la création des utilisateurs. Avec snmpusm, il faut impérativement avoir un utilisateur initial (le template par exemple) pour pourvoir créer un autre utilisateur par clonage

La commande suivante crée un nouvel utilisateur appelé user2 par clonage de l’utilisateur initial. La création est réalisée par des accès aux tables des MIB vacm et usm. Cet accès est réalisé en mode de sécurité v3 avec l’utilisateur initial.

Snmpusm –v 3 –u initial –n « «  -l authNoPriv –a MD5 –A setup_password localhost create user2 initial

Les options :

-v 3

précise le mode de sécurité utilisé

-u initial

initial est l’utilisateur nécessaire à l’accès SNMP v3

-n « « 

contexte vide

-l authNoPriv

en mode authentifié mais sans chiffrement

-a MD5

le protocole de hash utilisé pour l’authentification

-A setup_password

la phrase de passe pour l’authentification

create

Le mot clé pour la création

user2

le nouvel utilisateur à créer

initial

l’utilisateur servant au clonage

user2 étant cloné à partir de l’utilisateur initial , il hérite de la même phrase de passe que celui-ci.

Pour modifier celle-ci, une nouvelle commande snmpusm est nécessaire.

snmpusm localhost create user2 –n « «  -l authNoPriv –a MD5 –A setup_password localhost passwd –Ca setup_password moveau_password

Remarque : la creation d’utilisateur ne sert à rien si ceux-ci ne sont pas aussi créer dans le modèle VACM. Il faut donc créer une configuration adapté à ces nouveaux utilisateurs. C’est dans la table VACM que les droit d’accès sont donnés aux utilisateurs

Remarque : Avec LoriotPro il faut utiliser MD5 comme protocole de hashing pour l’authentification. Le chiffrement par DES (privacy) n’est pas disponible pour des raisons de protection à l’export.

Exemples de configurations

Configuration avec restriction limitée aux communautés SNMP

Le mode le plus simple de configuration et qui offre le plus bas niveau de sécurité. Utilisation de la notion de communauté existant depuis la version 1 de SNMP.

Mode d’accès SNMP v1 et V2c

Le fichier snmpd.conf contient les directives suivantes :

rocommunity public
rwcommunity private

Tous les hosts sans restriction sont capables de faire des requêtes SNMP v1 ou SNMP v2c en utilisant la communauté public pour les accès en lecture simple (Read Only Community) et  la communauté private pour les accès en lecture ecriture (Read Write Community). 

Tout l'arbre des MIB peut être accédé.

Configuration avec restriction sur l'adresse IP du Manager SNMP


Cette configuration permet au seul manager SNMP possédant l’adresse indiqué de  faire des requêtes sur l’agent. Evidement ce mode de sécurité est facilement contourné par un pirate connaissant l’adresse IP du manager ou ayant accès avec un sonde de capture de paquet sur le réseau.

Le fichier snmpd.conf contient les directives suivantes :

rocommunity public 12.1.1.1
rwcommunity private 12.1.1.1

Le host ayant l’adresse IP 12.1.1.1 dans notre exemple est seul capable de faire des requêtes SNMP v1 ou SNMP v2c en utilisant la communauté public pour les accès en lecture simple (Read Only Community) et  la communauté private pour les accès en lecture ecriture (Read Write Community). 

L’alternative à ces deux commandes consisterais à utiliser les directives ACCESS,VIEW,GROUP,COM2SEC. L’intérêt de cette configuration plus complexe à réaliser est son évolutivité vers des configurations avec plusieurs communautés, pour plusieurs hosts ayant des restrictions d’accès aux objets de la MIB varié.

Le fichier snmpd.conf contient dans ce cas les directives suivantes :

com2sec     rocom      12.1.1.1    public
com2sec     rwcom       12.1.1.1    private
group       rogroup     v1    rocom
group       rwgroup     v1    rwcom
group       rogroup     v2c   rocom
group       rwgroup     v2c   rwcom
view       all         included    .1    80
access      rogroup  « « any noauth exact all none none
access      rwgroup  « « any noauth exact all all none

La ligne 1 définie un nom (securityName) rocom et l’associe au host 12.1.1.1 et à la communauté public.

La ligne 2 définie un nom (securityName) rwcom et l’associe au host 12.1.1.1 et à la communauté private.

Les quatres lignes suivantes créent deux groupes et leur associent des securityModel et des securityName.

La ligne view crée un view appelée all contenant la racine de l’arbre des MIB .1 avec un masque à 80.

Les lignes access donne respectivement accès en lecture et en écriture pour les groupes correspondant à la view all.

Pour vérifier que cette configuration est opérationnelle, une requête SET peut être réalisée avec l’outil advanced SNMP query de LORIOTPRO, ici dans l’exemple en SNMP v2c.

Configuration avec restriction sur le réseau source

Ce mode de restriction est pratique quand il existe un réseau d’administration distinct (plan d’adressage IP séparé) du réseau des utilisateurs.

Le fichier snmpd.conf contient les directives suivantes (exemple) :

rocommunity public 12.1.1.0/24
rwcommunity private 12.1.1.0/24

Les hosts appartenant au réseau 12.1.1.0 masque 255.255.255.0 dans notre exemple sont capables de faire des requêtes SNMP v1 ou SNMP v2c en utilisant la communauté public pour les accès en lecture simple (Read Only Community) et  la communauté private pour les accès en lecture écriture (Read Write Community). 

Configuration avec restriction sur une branche de l’arbre des MIB

Le fichier snmpd.conf contient les directives suivantes :

rocommunity public default system
rwcommunity private default system

Tous les hosts (mot réservé default) sans restriction sont capables de faire des requêtes SNMP v1 ou SNMP v2c en utilisant la communauté public pour les accès en lecture simple (Read Only Community) et  la communauté private pour les accès en lecture ecriture (Read Write Community).  Mais seul les objets situés dans la branche system de l’arbre des MIB pourront être accédés, ici en vert dans le schéma ci-dessous

Réalisé avec MIB Tree view de LORIOTPRO

Une alternative consisterais à spécifier l’OID complet sous sa forme texte ou numérique.

rocommunity public default .1.3.6.1.2.1.1

ou

rocommunity public default iso.org.dod.internet.mgmt.mib-2.system

La même configuration en utilisant les directives avancées contiendrait :

Connaissant l’OID de « system » 1.3.6.1.2.1.1. de 7 éléments,  il est facile de déduire le masque 11111110 soit fe pour la directive view.

# SNMPD.CONF - Configuration avec restriction sur addresse IP
# HOW-TO LoriotPro - LUTEUS - snmpconf-103


com2sec rocom  default  public
com2sec rwcom  default  private
group   rogroup v1      rocom
group   rogroup v2c     rocom
group   rwgroup v1      rwcom
group   rwgroup v2c     rwcom
view    restrict-to-system     included     system fe
access  rogroup ""      any       noauth    exact  restrict-to-system none none
access  rwgroup ""      any       noauth    exact  restrict-to-system restrict-to-system  none

La ligne 1 définie un nom (securityName)rocom et l’associe au host 12.1.1.1 et à la communauté public

La ligne 2 définie un nom (securityName)rwcom et l’associe au host 12.1.1.1 et à la communauté private

Les quatres lignes suivantes créent deux groupes et leur associent des securityModel et des securityName

La ligne view crée un view appelée restrict-to-system contenant la branche system de l’arbre des MIB .1 avec un masque à 80.

Les lignes access donne respectivement accès en lecture seule et en lecture écriture pour les groupes correspondant à la view restrict-to-system.

Pour vérifier, faites un accès en SET ou GET sur un objet situé dans l’arbre system et dans un autre arbre.

Configuration avec restrictions multiples

L’objectif de cette exemple est de créer une configuration complexe incluant l’ensemble des fonctionnalités de restriction ou de contrôle d’accès hormis le contrôle par utilisateur.

L’exemple est construit pour offrir à deux manager SNMP (dont les adresses et noms  respectifs sont  129.1.1.3 manager1, 192.124.45.2 manager2).

Manager 1 doit pourvoir contrôler l’ensemble de la MIB, manager2 ne doit pouvoir lire que l’objet interface de la MIB.

Le manager 2 ne fonctionne qu’en SNMP v1.

com2sec ro-com-manager1  manager1  com-ro-manager1
com2sec rw-com-manager1  manager1  com-rw-manager1
com2sec ro-com-manager2  manager2  com-ro-manager1
group   rogroupm1 v1      ro-com-manager1
group   rogroupm1 v2c     ro-com-manager1
group   rwgroupm1 v1      rw-com-manager1

group   rwgroupm1 v2c     rw-com-manager1
group   rogroupm2 v1      ro-com-manager2

view    not-restricted     included     .iso 80
view    restrict-to-interface     included     interface fe

access  rogroupm1 ""      any       noauth    exact  not-restricted     none none
access  rwgroupm1 ""      any       noauth    exact  not-restricted     not-restricted     none
access  rwgroupm2 ""      any       noauth    exact  restrict-to-interface     none  none

Configuration avec restriction sur utilisateur (SNMP V3)

L’exemple suivant suppose l’existence d’un utilisateur user1 créé par les procédures expliquées au paragraphe « Création d’utilisateurs pour SNMP V3 ».

La configuration la plus simple pour donner un accès sans condition à un utilisateur sur l’ensemble des objets de la mib est la suivante :

Extrait du fichier /usr/share/snmp/snmpd.conf:

rwuser user1

Configuration équivalente avec les directives avancés

group groupv3             usm      user1
view    all included   .iso      80
access groupv3         ""        any       auth      exact    all         all        all

En premier, création d’un group appelé groupv3 et association de l’utilisateur user1 à ce groupe. Le mode de sécurité est usm (SNMP v3). Puis création classique d’une view sur l’arbre de MIB. Ajout d’un règle d’accès pour le groupe.

Si aucune commande rwcommunity ou rocommunity n’est ajouté au fichier snmpd.conf, l’agent ne pourra servir les requêtes SNMP que pour l’utilisateur user1 et en mode v3 uniquement.

Pour vérifier que les accès sont bien autorisé, utiliser le Common Query de LoriotPro après avoir configuré le host pour SNMP V3.


La bar de statuts supérieur indique bien les requêtes reçus en SNMP V3. Il est possible de changer de mode de requête en reconfigurant le host. Sélectionnez le host dans l’annuaire, puis propriétés. Modifier le mode par défaut appliqué pour les requêtes SNMP sur ce host.

Il est aussi possible d’utiliser les utilitaires disponibles dans le package UCD-SNMP-Util directement sur le host UNIX/LINUX

Pour un accès en SNMP v3 sans authentification

snmpget -v 3 -l noAuthNoPriv localhost sysName.0

Pour un accès en SNMP v3 avec authentification

snmpget -v 3 -l AuthNoPriv -u user1 -A password localhost sysName.0

si l'utilisateur n'existe pas le message « Unknow user name » est retourné
si le phrase de passe est mauvaise (ici "password") le message « authentication failure » est retourné

Pour éviter d'avoir à saisir systématiquement l'ensemble des paramètres il suffit de compléter le fichier /usr/share/snmp/snmp.conf avec les lignes suivantes :

defversion  3
defSecurityName user1
defPassphrase password
defAuthType MD5
defPrivType DES
defSecurityLevel AuthNoPriv

la commande peut alors se résumer à :

snmpget localhost sysName.0

Configurer le HOST sous LORIOTPRO pour SNMP v3

La configuration d’un host sous LoriotPro pour définir sont mode de fonctionnement en SNMP v3 par défaut est réalisé à partir de l’écran propriété.

Dans cet écran vous trouverez la zone suivante définissant la version de SNMP à utiliser

Cliquer sur v 3 puis sur Set V3. Un nouvel écran s’ouvre alors :

Saisir dans le champ UserName le nom de l’utilisateur en respectant la case.

Saisir le password ou phrase de passe défini pour cette utilisateur

Sélectionner le mode d’authentification

Puis presser Init Key

Si la clé s’initialise bien vous avez en retour le sysname du host. Le champ AuthoritativeEngineID et Kull sont maintenant présents.

Sinon une erreur apparaît, ici le mot de passe saisie est faux

L’impossibilité d’initialiser un utilisateur peut dépendre de nombreux facteurs. Il faut en premier vérifier que cet utilisateur existe bien sur le host distant.

Les types d’erreurs sont disponibles dans la MIB, sous la branche usmstats

La table des erreurs contient les compteurs d’échec pour chaque type d’erreur.

Usmstatsnotintimewindows

Hors de la fenêtre de temps de 150 s

Usmstatsunknownusernames

Nom d’utilisateur inconnu

Usmstatsunkownengineids

SNMP Engine ID inconnu

Usmstatswrongdigests

Pass Phrase incorrecte entraînant un digest(hash) incorrect

Usmstatsdecryptionerrors

Erreur lors du déchiffrement

Remarque : LoriotPro ne supporte pas le chiffrement dans sa version actuelle utilisé pour la réalisation de ce How To.