Tout ceci nous a appris pas mal de choses, mais de façon un peu décousue, il faut bien le dire. Essayons d'y mettre un peu d'ordre.

Il semble bien qu'au final, seules les versions 1, 2c (classique) et 3 soient utilisées.

La version 3 apporte des fonctions de sécurité (chiffrement et authentification) qui permettent d'utiliser SNMP dans un environnement « hostile », mais n'est pas implémenté sur tous les matériels. Cette version n'apportant rien de plus pour la compréhension du fonctionnement de SNMP, nous n'en parlerons pas d'avantage.

La version 1 est généralement implémentée sur tous les équipements proposant SNMP, de même que la version 2c, qui ne fait qu'ajouter des compteurs sur 64 bits. Ces deux versions offrent une sécurité tout à fait indigente. Il n'y a ni chiffrement des données, ni authentification (aussi bien de l'agent que du manager). Dans un environnement « hostile » il restera possible de pallier cet inconvénient par l'usage de tunnels chiffrés, de vlans etc. Voyons tout de même ce que proposent les versions 1 et 2 en termes de restrictions d'accès.

Nous illustrerons le propos en configurant l'agent snmpd proposé dans les distributions GNU/Linux.

Une communauté représente un groupe d'utilisateurs. Nous nous sommes jusqu'ici déclarés de la communauté public (option -c public dans les diverses commandes).

Par défaut, la plupart des équipements proposent les communautés public et private. Il est toutefois possible de les renommer ou d'en créer d'autres.

La communauté public n'a généralement accès qu'en lecture, et pas forcément à toute l'étendue des informations exposées.

La communauté private est généralement exploitée pour écrire (donc reconfigurer) un équipement. Il est donc nécessaire d'en réserver l'accès qu'aux administrateurs autorisés, mais ceci ne peut se faire que sur la base des adresses IP des managers, ce qui reste très rudimentaire.

Il est clair que dans un environnement hostile, il reste assez simple d'utiliser SNMP (v 1 et 2) à des fins tout à fait malveillantes.

Nous allons faire quelques manipulations sur notre Lynx Lucide pour illustrer les restrictions que l'on peut appliquer avec les communautés.

Nous avons fait, lors de l'installation de snmpd une modification de la configuration par défaut. Revoici une configuration minimale, équivalente, ne prenant en compte que les versions 1 et 2c de SNMP :

com2sec readonly  default         public
com2sec readwrite default         private
group MyROGroup v1         readonly
group MyROGroup v2c        readonly
group MyRWGroup v1         readwrite
group MyRWGroup v2c        readwrite
view all    included  .1
access MyROGroup ""      any       noauth    exact  all    none   none
access MyRWGroup ""      any       noauth    exact  all    all    none

La logique séquentielle de ce fichier n'est pas forcément la meilleure. Commençons donc par les view.

Ici nous n'avons qu'une view qui inclut la totalité de l'arbre (.1) et qui s'appèle all. Nous aurions pu tout aussi bien écrire

view bidule    included  .1

ou

view machin    included  .1

le mot-clé est view le nom de la vue sera all (ou bidule ou machin) et ce qui est inclus dans cette vue c'est .1 c'est-à-dire la totalité de ce que l'agent peut proposer.

Nous créons des noms de groupes auxquels nous associons un « nom de sécurité », en fonction de la version du protocole utilisé. Ceci n'a de réel sens qu'avec la version 3, mais en v1 et en v2c, il faut en passer par là quand même.

Nous avons écrit :

group MyROGroup v1         readonly
group MyROGroup v2c        readonly
group MyRWGroup v1         readwrite
group MyRWGroup v2c        readwrite

Nous aurions aussi bien pu faire :

group voyeurs v1     regarderMaisPasToucher
group voyeurs v2c    regarderMaisPasToucher
group violeurs v1    regardeEtPlus
group violeurs v2c   regardeEtPlus

pas forcément du meilleur gout, mais tout aussi correct syntaxiquement parlant.

Ces groupes et noms de sécurité nous serviront plus loin.

Ils sont de la forme :

access GROUP CONTEXT {any|v1|v2c|usm} LEVEL PREFX READ WRITE NOTIFY

On va faire simple :

• le CONTEXT n'a de sens que pour la version 3 ;
• le LEVEL est forcément noauth pour les versions 1 et 2c ;
• le PREFIX n'a pas de sens pour v1 et v2c, nous mettrons exact ;
• le NOTIFY « is not currently used ».

reste donc :

• le GROUP est un nom que l'on a créé de toutes pièces, juste au dessus ;
• le READ sera le nom de la vue dans laquelle le groupe aura le droit de lire ou none s'il ne peut rien lire (ce qui n'aurait aucun sens, pourquoi créer un groupe qui aurait le droit de ne rien lire) ;
• le WRITE sera le nom de la vue dans laquelle le groupe pourra écrire (ou none s'il ne peut écrire).

Ainsi, dans notre fichier :

access MyROGroup ""      any       noauth    exact  all    none   none
access MyRWGroup ""      any       noauth    exact  all    all    none

Veut dire qu'il existe deux groupes, MyROGroup et MyRWGroup :

• MyROGroup peut lire dans la vue all mais ne peut y écrire et ce, en utilisant aussi bien les protocoles v1 que v2c ;
• MyRWGroup peut aussi bien lire qu'écrire dans la vue all aussi vien en v1 qu'en v2c.

C'est ici que l'on recolle tous les morceaux, en ajoutant en prime les communautés. De la forme :

com2sec  [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
* ''CONTEXT'' n'a toujours pas de sens en v1 ni en v2c) ;
* ''SECNAME'', ça vient d'un peu plus haut dans l'explication ;
* ''SOURCE'', c'est l'adresse IP source (ou le sous-réseau IP, ou ''default'' si c'est « wide open ») ;
* ''COMMUNITY'', c'est le nom de la communauté dans laquelle l'agent s'est déclaré.

Nous avons :

com2sec readonly  default         public
com2sec readwrite default         private

Autrement dit, le groupe de sécurité readonly (qui aurait pu s'appeler regarderMaisPasToucher) est attaché à la communauté public. Comme ce groupe de sécurité est attaché au groupe MyROGroup (qui aurait pu s'appeler voyeurs) pour les protocoles v1 et v2c et que ce groupe MyROGroup peut aussi bien en v1 qu'en v2c lire et seulement lire partout, il s'ensuit que tout manager qui se connectera sur notre hôte en se déclarant de la communauté public pourra lire ce qu'il veut.

L'ennui, c'est que si le manager se déclare de la communauté private, qui est attachée au groupe de sécurité readwrite (qui aurait pu s'appeler ?…) depuis n'importe où (default) et que ce groupe de sécurité est attribué au groupe MyRWGroup (qui aurait pu s'appeler ?…), lequel peut lire dans all mais aussi y écrire, alors ce manager pourra modifier tout ce qui est modifiable sur notre hôte, preuve que notre configuration est complètement nulle. En fait, elle est là pour l'exemple, nous en ferons une moins sale par la suite.

Bien sûr ! Et ceci va nous permettre de créer une configuration un peu plus complète de la façon suivante :

• une communauté public, qui aura droit à l'accès en lecture seule, mais seulement à la branche system pour tous ceux qui peuvent joindre notre agent, quelle que soit leur adresse IP ;
• une communauté private aura droit à la lecture seule de toutes les informations possibles, mais seulement à partir d'un réseau IP particulier ;
• une communauté admin pourra lire et écrire partout où c'est possible, mais depuis une adresse IP bien particulière.