11. Considérations de sécurité

11.1. Pratiques recommandées

Cette section décrit les pratiques qui contribuent au fonctionnement sûr et efficace des mécanismes définis dans ce mémo.

• Un moteur SNMP doit rejeter les messages de réponse SNMP qui ne correspondent à aucun message de requête actuellement en attente. Il incombe au module de traitement des messages de s'en occuper. Par exemple, il peut utiliser un msgID à cette fin.

  Une application SNMP Command Generator doit rejeter toute PDU de classe Response pour laquelle il n'existe aucune PDU de classe Confirmed actuellement en attente ; par exemple pour les PDU SNMPv2 [RFC3416], le composant request-id dans la PDU peut être utilisé pour corréler les réponses aux requêtes en attente.

  Bien qu'il soit typique pour un moteur SNMP et une application SNMP Command Generator de le faire naturellement, lors de l'utilisation de ces protocoles de sécurité, cela est significatif en raison de la possibilité de duplication de messages (malveillante ou autre).

• Si un moteur SNMP utilise un msgID pour corréler les messages de réponse aux messages de requête en attente, il DOIT utiliser des msgID différents dans tous ces messages de requête qu'il envoie pendant une période de fenêtre temporelle (150 secondes).

  Une application Command Generator ou Notification Originator DOIT utiliser des request-ids différents dans toutes les PDU de requête qu'elle envoie pendant une période de fenêtre temporelle (150 secondes).

  Cela doit être fait pour se protéger contre la possibilité de duplication de messages (malveillante ou autre).

  Par exemple, commencer les opérations avec une valeur msgID et/ou request-id de zéro n'est pas une bonne idée. Les initialiser avec un nombre imprévisible (pour qu'ils ne commencent pas de la même manière après chaque redémarrage) puis les incrémenter de un serait acceptable.

• Un moteur SNMP devrait effectuer la synchronisation temporelle en utilisant des messages authentifiés afin de se protéger contre la possibilité de duplication de messages (malveillante ou autre).

• Lors de l'envoi de messages modifiant l'état à un moteur SNMP autoritatif géré, une application Command Generator devrait retarder l'envoi de messages successifs à ce moteur SNMP géré jusqu'à ce qu'un accusé de réception positif soit reçu pour le message précédent ou jusqu'à ce que le message précédent expire.

  Aucun ordre de message n'est imposé par SNMP. Les messages peuvent être reçus dans n'importe quel ordre par rapport à leur heure de génération et chacun sera traité dans l'ordre reçu. Notez que lorsqu'un message authentifié est envoyé à un moteur SNMP géré, il sera valide pendant une période d'environ 150 secondes dans des circonstances normales, et est sujet à rejeu pendant cette période. En effet, un moteur SNMP et les applications SNMP Command Generator doivent naturellement faire face à la perte et au réordonnancement des messages résultant d'anomalies dans le réseau.

  Cependant, un objet géré, snmpSetSerialNo [RFC3418], est spécifiquement défini pour être utilisé avec les opérations SNMP Set afin de fournir un mécanisme garantissant que le traitement des messages SNMP se produit dans un ordre spécifique.

• La fréquence à laquelle les secrets d'un utilisateur du modèle de sécurité basé sur l'utilisateur doivent être modifiés est indirectement liée à la fréquence de leur utilisation.

  La protection des secrets contre la divulgation est essentielle pour la sécurité globale des protocoles. L'utilisation fréquente d'un secret fournit une source continue de données qui peut être utile à un cryptanalyste pour exploiter des faiblesses connues ou perçues dans un algorithme. Les changements fréquents du secret évitent cette vulnérabilité.

  Changer un secret après chaque utilisation est généralement considéré comme la pratique la plus sûre, mais une quantité importante de surcharge peut être associée à cette approche.

  Notez également que dans un environnement local, la menace de divulgation peut être moins importante, et en tant que telle, le changement des secrets peut être moins fréquent. Cependant, lorsque des réseaux de données publics sont utilisés comme chemins de communication, plus de prudence est recommandée.

11.2 Définition des utilisateurs

Les mécanismes définis dans ce document emploient la notion d'utilisateurs au nom desquels les messages sont envoyés. La façon dont les "utilisateurs" sont définis est soumise à la politique de sécurité de l'administration réseau. Par exemple, les utilisateurs peuvent être des individus (par exemple, "joe" ou "jane"), ou un rôle particulier (par exemple, "operateur" ou "administrateur"), ou une combinaison (par exemple, "joe-operateur", "jane-operateur" ou "joe-admin"). De plus, un utilisateur peut être une entité logique, telle qu'une application SNMP ou un ensemble d'applications SNMP, agissant au nom d'un individu ou d'un rôle, ou d'un ensemble d'individus, ou d'un ensemble de rôles, y compris les combinaisons.

L'annexe A décrit un algorithme pour mapper un "mot de passe" utilisateur vers une valeur de 16/20 octets à utiliser comme clé d'authentification ou clé de confidentialité de l'utilisateur (ou les deux). Notez cependant que l'utilisation du même mot de passe (et donc de la même clé) pour l'authentification et la confidentialité est une très mauvaise pratique de sécurité et devrait être fortement découragée. Les mots de passe sont souvent générés, mémorisés et saisis par un humain. Les mots de passe générés par l'homme peuvent être inférieurs aux 16/20 octets requis par les protocoles d'authentification et de confidentialité, et les attaques par force brute peuvent être assez faciles sur un ensemble de caractères ASCII relativement court. Par conséquent, l'algorithme de l'annexe A effectue une transformation du mot de passe. Si l'algorithme de l'annexe A est utilisé, les implémentations SNMP (et les applications de configuration SNMP) doivent s'assurer que les mots de passe ont au moins 8 caractères. Veuillez noter que des mots de passe plus longs avec des chaînes répétitives peuvent aboutir exactement à la même clé. Par exemple, un mot de passe 'bertbert' donnera exactement la même clé qu'un mot de passe 'bertbertbert'.

Étant donné que l'algorithme de l'annexe A utilise ces mots de passe (presque) directement, il est très important qu'ils ne soient pas facilement devinables. Il est suggéré qu'ils soient composés de caractères alphanumériques et de ponctuation à casse mixte qui ne forment pas de mots ou de phrases qui pourraient être trouvés dans un dictionnaire. Des mots de passe plus longs améliorent la sécurité du système. Les utilisateurs peuvent souhaiter saisir des phrases de plusieurs mots pour allonger leur chaîne de mot de passe tout en s'assurant qu'elle est mémorisable.

Étant donné qu'il est impossible pour les utilisateurs humains de maintenir des mots de passe différents pour chaque moteur SNMP, mais que les exigences de sécurité découragent fortement d'avoir la même clé pour plus d'un moteur SNMP, le modèle de sécurité basé sur l'utilisateur utilise un compromis proposé dans [Localized-key]. Il dérive les clés utilisateur pour les moteurs SNMP à partir du mot de passe de l'utilisateur de telle manière qu'il est pratiquement impossible de déterminer soit le mot de passe de l'utilisateur, soit la clé de l'utilisateur pour un autre moteur SNMP à partir de n'importe quelle combinaison de clés utilisateur sur les moteurs SNMP.

Notez cependant que si le mot de passe de l'utilisateur est divulgué, la localisation de clé ne sera d'aucune aide et la sécurité du réseau peut être compromise dans ce cas. Par conséquent, le mot de passe d'un utilisateur ou une clé non localisée NE DOIT PAS être stocké sur un appareil/nœud géré. Au lieu de cela, la clé localisée DOIT être stockée (le cas échéant), de sorte que, au cas où un appareil serait compromis, aucun autre appareil géré ou de gestion ne soit compromis.

11.3. Conformité

Pour être qualifiée d'"implémentation SNMP sécurisée" basée sur le modèle de sécurité basé sur l'utilisateur, une implémentation SNMP DOIT :

• implémenter un ou plusieurs protocoles d'authentification. Les protocoles d'authentification HMAC-MD5-96 et HMAC-SHA-96 définis dans ce mémo sont des exemples de tels protocoles.

• dans la mesure du possible, interdire l'accès aux secrets de chaque utilisateur sur lequel elle maintient des informations dans un Local Configuration Datastore (LCD) en toutes circonstances sauf si nécessaire pour générer et/ou valider les messages SNMP concernant cet utilisateur.

• implémenter le mécanisme de localisation de clé.

• implémenter le SNMP-USER-BASED-SM-MIB.

De plus, un moteur SNMP autoritatif DEVRAIT fournir une configuration initiale conformément à l'annexe A.1.

L'implémentation d'un protocole de confidentialité (le protocole de chiffrement symétrique DES défini dans ce mémo en est un) est optionnelle.

11.4. Utilisation des rapports

L'utilisation de rapports non sécurisés (c'est-à-dire leur envoi avec un securityLevel de noAuthNoPriv) expose potentiellement un moteur SNMP non autoritatif à certaines formes d'attaques. Certaines personnes considèrent qu'il s'agit d'attaques par déni de service, d'autres non. Une installation devrait évaluer le risque encouru avant de déployer des PDU de rapport non sécurisées.

11.5 Accès au SNMP-USER-BASED-SM-MIB

Les objets de cette MIB peuvent être considérés comme sensibles dans de nombreux environnements. Plus précisément, les objets dans la usmUserTable contiennent des informations sur les utilisateurs et leurs protocoles d'authentification et de confidentialité. Il est important de contrôler étroitement (à la fois en lecture et en écriture) l'accès à ces objets MIB en utilisant des modèles de contrôle d'accès configurés de manière appropriée (par exemple le modèle de contrôle d'accès basé sur les vues tel que spécifié dans [RFC3415]).