Accès extérieur sécurisé

[DJ TonTon]

Bonjour,

Tout d'abord désolé si je ne poste pas dans la bonne rubrique.

J'aurais voulu savoir quelle est la méthode la plus sécurisée pour envoyer des requêtes SNMP distantes sur un serveur hébergeant Nagios-Oreon ?

En clair je voudrais disposer d'un serveur avec Oreon sur un site, et pouvoir surveiller toutes mes machines qui sont sur des sites distants. Faut-il utiliser un VPN ? Dois-je utiliser SNMP V3? Je ne sais d'ailleurs pas comment utiliser ce dernier, j'ai essayé de le paramétrer mais ca ne change rien, toutes les requêtes passent en clair dans la trame et c'est toujours marqué Version 1. Merci.

[surcouf]

Accès via SNMP sécurisé : HOWTO ?

Bonjour,

Tout d'abord désolé si je ne poste pas dans la bonne rubrique.

J'aurais voulu savoir quelle est la méthode la plus sécurisée pour envoyer des requêtes SNMP distantes sur un serveur hébergeant Nagios-Oreon ?

En clair je voudrais disposer d'un serveur avec Oreon sur un site, et pouvoir surveiller toutes mes machines qui sont sur des sites distants. Faut-il utiliser un VPN ? Dois-je utiliser SNMP V3? Je ne sais d'ailleurs pas comment utiliser ce dernier, j'ai essayé de le paramétrer mais ca ne change rien, toutes les requêtes passent en clair dans la trame et c'est toujours marqué Version 1.

Si on écoute Microsoft, il faudrait encaspuler les requêtes SNMP dans IPSEC. En effet, l'agent SNMP de Windows ne supporte pas SNMPv3. Par contre, Net-SNMP et nombreux autres agents le supporte pleinement. Étant donné que cette version du protocole demeure basée sur UDP, il vaut mieux utiliser SNMPv3 (d'autant que, sous Windows et d'autres systèmes, il est toujours possible d'avoir recours à un agent SNMP alternatif : Net-SNMP) que rajouter des couches réseaux avec IPSEC. En outre, SNMPv3 est largement plus facile à mettre en oeuvre qu'IPSEC.
Revenons à SNMPv3 : cette version apporte donc un échange de clés (« à la SSH ») utilisant les algorithmes MD5 (inutile de dire qu'il est déconseillé) ou SHA1 pour identifier l'utilisateur SNMPv3. On verra par la suite que l'utilisateur SNMPv3 s'identifie aussi avec d'autres critères. À cela, se distingue la partie « cryptage » (que les puristes me pardonnent) de la requête proprement dite. Cette partie est optionnelle, en fonction du niveau de sécurité (secLevel) requis. Il existe d'ailleurs un niveau qui ne requiert ni échange, ni cryptage. Les autres niveaux sont une combinaison de présence des deux :
- noAuthNoPriv : ni identification, ni cryptage ;
- authNoPriv : identification sans cryptage ;
- authPriv : identification ET cryptage.
Les algorithmes disponibles pour Net-SNMP en matière de cryptage sont DES et AES. Les deux nécessitent une liaison avec la bibliothèque OpenSSL.
Pour ceux qui « bénéficient » en outre d'un service AD, il y a même une voie intéressante. Le modèle de sécurité par défaut est le modèle « user » ou « userSecurityModel » (usm).
Les dernières versions de Net-SNMP apportent le support du modèle kerberos (ksm), dont la technologie SSO homonyme est au coeur du système AD. Il y aurait donc un moyen simple et fort d'intégrer les utilisateurs des services SNMP dans la gestion globale du SI, si nécessaire.

Si tu as des questions concernant la configuration d'un utilisateur SNMPv3 (en fait, on configure surtout le « secName » qui est un élément de l'utilisateur : son nom), je te laisse consulter le README.snmpv3 fourni avec Net-SNMP et je serais à ta disposition pour des questions ultérieures.

[DonKiShoot]

Les dernières versions de Net-SNMP apportent le support du modèle kerberos (ksm), dont la technologie SSO homonyme est au coeur du système AD. Il y aurait donc un moyen simple et fort d'intégrer les utilisateurs des services SNMP dans la gestion globale du SI, si nécessaire.

En gros, il suffirait d'utiliser un compte user de l'AD pour interroger le snmpv3 d'un windows utilisant net-snmp ?
Ca semble pratique mais pas top secure ?

[surcouf]

En gros, il suffirait d'utiliser un compte user de l'AD pour interroger le snmpv3 d'un windows utilisant net-snmp ?
Ca semble pratique mais pas top secure ?

Si car cela resterait du Kerberos, qui se base également sur un échange par clé mais avec un serveur de confiance et qu'il serait en principe toujours possible de crypter la requête. Évidemment, si tu n'as pas confiance en Kerberos...

[DonKiShoot]

Je n'ai pas confiance en mes utilisateurs c différent )

[surcouf]

Je n'ai pas confiance en mes utilisateurs c différent )

À toi de bien gérer les accès, c'était juste histoire d'avoir une gestion centralisée. Il est évident que l'accès aux agents SNMP devra être très limité.
L'autre modèle (usm) permet également de gérer les utilisateurs de chaque agent à distance (via SNMPv3) mais de manière décentralisé (à moins de disposer d'une interface capable de faire toutes les mises à jour nécessaires en même temps).

[DJ TonTon]

Merci pour ces informations, c'est plus clair à présent! La mise en place n'a pas l'air si facile que ça. Je pense que pour l'instant je vais donc rester en SNMP v2 et accéder à mon serveur via un tunnel VPN. De toute façon se seront principalement des serveurs sous Linux qu'il y aura a superviser donc sans AD.

Le gros souci est que SNMP v2 (enfin je crois qu'il y a eu beaucoup de versions!) ne me parait pas sécurisé du tout.

[surcouf]

Merci pour ces informations, c'est plus clair à présent! La mise en place n'a pas l'air si facile que ça. Je pense que pour l'instant je vais donc rester en SNMP v2 et accéder à mon serveur via un tunnel VPN. De toute façon se seront principalement des serveurs sous Linux qu'il y aura a superviser donc sans AD.

J'ai évoquer AD et Kerberos uniquement à titre d'informations. Je ne voulais pas te faire peur. Le modèle par défau, usm, suffit amplement et demeure très simple à mettre en oeuvre : il suffit de créer le premier utilisateur en configurant l'agent SNMP et c'est tout. Tout le reste fonctionne normalement.

Le gros souci est que SNMP v2 (enfin je crois qu'il y a eu beaucoup de versions!) ne me parait pas sécurisé du tout.

La version communément appellé "v2" et largement utilisée est en fait aussi appelée "v2c". Le "c" pour "community". En effet, le protocole SNMPv2 a apporté de nombreuses améliorations de performances par rapport à SNMPv1 (notamment les nouveaux PDUs GetBulk et INFORM) mais faute d'un consensus après le rejet du protocole SNMPv2p (difficile à mettre en oeuvre) et entre les divergents protocoles SNMPv2u et SNMPv2*, le volet sécurité a été remis à plus tard. C'est pourquoi le modèle du protocole SNMPv1 a été conservé bien que moins sûr. Depuis SNMPv3, ce problème est révolu.
Je conseille à tout curieux d'en savoir davantage sur l'histoire du protocole SNMP la lecture de ce document pdf.