Aller au contenu principal

Applications du protocole simple de gestion de réseau (SNMP)

  • Statut: Internet Standard
  • Publié: December 2002
  • Stream: IETF
  • Remplace: RFC2573
  • Errata: Pas d'errata

Statut de ce mémoire​

Ce document spécifie un protocole de voie de normalisation Internet pour la communauté Internet, et demande des discussions et des suggestions d'améliorations. Veuillez vous référer à l'édition actuelle des "Normes Officielles de Protocole Internet" (STD 1) pour l'état de normalisation et le statut de ce protocole. La distribution de ce mémoire n'est soumise à aucune restriction.

Résumé​

Ce document décrit cinq types d'applications du protocole simple de gestion de réseau (SNMP) qui utilisent un moteur SNMP tel que décrit dans STD 62, RFC 3411. Les types d'applications décrits sont les générateurs de commandes, les répondeurs de commandes, les initiateurs de notification, les récepteurs de notification et les relais proxy.

Ce document définit également des modules MIB (Management Information Base) pour spécifier les cibles des opérations de gestion, pour le filtrage des notifications et pour le relais proxy. Ce document rend obsolète la RFC 2573.

7. Traduction des cibles de gestion dans les applications de relais proxy​

Les applications proxy forwarder effectuent la traduction des cibles de gestion lors du transfert des messages SNMP. Cette traduction implique le mappage des paramètres de message entrants (contextEngineID, contextName, securityModel, securityName, securityLevel) vers des paramètres de message sortants adaptés au moteur SNMP cible.

La table snmpProxyTable définit les règles de traduction utilisées par les proxy forwarders.

7.1. Request Forwarding​

Le transfert de requête implique la réception d'une requête de commande d'un générateur de commande, la traduction des paramètres de requête et le transfert de la requête vers un répondeur de commande.

7.1.1. Traitement d'une requête entrante​

Lorsqu'un proxy forwarder reçoit une requête :

  1. Extrait les paramètres entrants du message reçu :

    • contextEngineID
    • contextName
    • securityModel
    • securityName
    • securityLevel
    • Type de PDU

  2. Recherche dans snmpProxyTable en utilisant ces paramètres comme clé. Recherche spécifiquement une entrée où :

    • snmpProxyType est read(1) pour les PDU de classe lecture (Get, GetNext, GetBulk) ou write(2) pour les PDU de classe écriture (Set)
    • snmpProxyContextEngineID correspond au contextEngineID entrant
    • snmpProxyContextName correspond au contextName entrant
    • snmpProxyTargetParamsIn référence des paramètres cibles correspondant aux paramètres de sécurité entrants

  3. Si aucune entrée correspondante n'est trouvée :

    • Génère une réponse d'erreur indiquant que la requête ne peut pas être transférée.
    • L'erreur spécifique dépend de la version SNMP et des circonstances (par ex. authorizationError, genErr).

  4. Si une entrée correspondante est trouvée :

    • Extrait la valeur snmpProxySingleTargetOut ou snmpProxyMultipleTargetOut.

7.1.2. Transfert de la requête​

Après avoir trouvé une entrée snmpProxyTable correspondante :

Transfert vers cible unique​

Si snmpProxySingleTargetOut est spécifié :

  1. Recherche dans snmpTargetAddrTable en utilisant snmpProxySingleTargetOut comme snmpTargetAddrName.

  2. Extrait les informations d'adresse cible :

    • snmpTargetAddrTDomain (domaine de transport)
    • snmpTargetAddrTAddress (adresse de transport)
    • snmpTargetAddrParams (référence à snmpTargetParamsTable)

  3. Recherche dans snmpTargetParamsTable en utilisant snmpTargetAddrParams.

  4. Extrait les paramètres de sécurité cibles :

    • snmpTargetParamsMPModel (modèle de traitement de message)
    • snmpTargetParamsSecurityModel
    • snmpTargetParamsSecurityName
    • snmpTargetParamsSecurityLevel

  5. Détermine le contexte cible :

    • Si snmpProxyContextEngineID est vide, utilise le contextEngineID entrant.
    • Sinon, utilise snmpProxyContextEngineID.
    • De même pour snmpProxyContextName.

  6. Traduit la PDU si nécessaire :

    • Si les versions SNMP entrante et sortante diffèrent, traduit le format PDU et les codes d'erreur.
    • Pour SNMPv1 vers SNMPv2 : Mappe les codes d'erreur, convertit les formats de trap.
    • Pour SNMPv2 vers SNMPv1 : Mappe les codes d'erreur (par ex. noAccess → genErr), gère les valeurs d'exception.

  7. Transfère la requête en utilisant la primitive send PDU du sous-système de traitement de message avec les paramètres cibles.

Transfert vers cibles multiples​

Si snmpProxyMultipleTargetOut est spécifié :

  1. Recherche dans snmpTargetAddrTable toutes les entrées où snmpTargetAddrTagList contient l'étiquette spécifiée dans snmpProxyMultipleTargetOut.

  2. Pour chaque adresse cible correspondante :

    • Suit les étapes 2-7 du transfert vers cible unique.
    • Note que la requête originale est dupliquée et envoyée à plusieurs adresses cibles.

  3. Gestion de réponse pour cibles multiples :

    • Le transfert vers cibles multiples est généralement utilisé uniquement pour les opérations de lecture.
    • Le proxy peut avoir besoin d'agréger les réponses ou de retourner la première réponse réussie.
    • Le comportement spécifique dépend de l'implémentation.

7.1.3. Transfert de la réponse​

Lorsque le proxy forwarder reçoit une réponse du répondeur de commande cible :

  1. Traduit la PDU de réponse si nécessaire pour correspondre au format attendu par le demandeur original.

  2. Mappe le contextEngineID et contextName vers les valeurs attendues par le demandeur original.

  3. Retourne la réponse en utilisant la primitive return response PDU du sous-système de traitement de message.

7.2. Notification Forwarding​

Le transfert de notification implique la réception d'une notification d'un émetteur de notification et son transfert vers un ou plusieurs récepteurs de notification.

7.2.1. Traitement d'une notification entrante​

Lorsqu'un proxy forwarder reçoit une notification :

  1. Extrait les paramètres entrants :

    • contextEngineID
    • contextName
    • securityModel
    • securityName
    • securityLevel
    • Type de notification (trap ou inform)

  2. Recherche dans snmpProxyTable en utilisant ces paramètres. Recherche une entrée où :

    • snmpProxyType est trap(3) pour les notifications trap ou inform(4) pour les notifications inform
    • snmpProxyContextEngineID correspond au contextEngineID entrant (ou est vide pour correspondre à n'importe lequel)
    • snmpProxyContextName correspond au contextName entrant (ou est vide pour correspondre à n'importe lequel)
    • snmpProxyTargetParamsIn référence des paramètres cibles correspondant aux paramètres de sécurité entrants (ou est vide pour correspondre à n'importe lequel)

  3. Si aucune entrée correspondante n'est trouvée :

    • La notification n'est pas transférée.
    • Le proxy peut enregistrer cet événement localement.

  4. Si une entrée correspondante est trouvée :

    • Extrait la valeur snmpProxyMultipleTargetOut (le transfert de notification utilise toujours le transfert vers cibles multiples).

7.2.2. Transfert de la notification​

Après avoir trouvé une entrée snmpProxyTable correspondante :

  1. Recherche dans snmpTargetAddrTable toutes les entrées où snmpTargetAddrTagList contient l'étiquette spécifiée dans snmpProxyMultipleTargetOut.

  2. Pour chaque adresse cible correspondante :

    a. Recherche snmpTargetAddrParams dans snmpTargetParamsTable.

    b. Extrait les paramètres cibles.

    c. Détermine s'il faut envoyer comme trap ou inform en se basant sur snmpNotifyTable (si référencé) ou utilise le même type que la notification entrante.

    d. Traduit la PDU de notification si nécessaire :

    • Trap SNMPv1 vers trap SNMPv2 : Convertit le format PDU, ajoute sysUpTime.0 et snmpTrapOID.0.
    • Trap SNMPv2 vers trap SNMPv1 : Convertit le format PDU, extrait enterprise, agent-addr, generic-trap, specific-trap.

    e. Transfère la notification en utilisant la primitive send PDU du sous-système de traitement de message.

  3. Si la notification sortante est une requête inform :

    • Attend une réponse de chaque cible.
    • Si la notification entrante était également un inform, agrège les réponses.
    • Retourne une réponse à l'émetteur de notification original uniquement après avoir reçu des réponses de toutes (ou un sous-ensemble configuré de) cibles.

Exemples de traduction​

Exemple 1 : Traduction de requête SNMPv3 vers SNMPv1​

Requête entrante :

  • contextEngineID: 0x80001F8880
  • contextName: "publicView"
  • securityModel: 3 (USM)
  • securityName: "admin"
  • securityLevel: authPriv
  • PDU: GetRequest

Entrée snmpProxyTable :

  • snmpProxyType: read(1)
  • snmpProxyContextEngineID: 0x80001F8880
  • snmpProxyContextName: "publicView"
  • snmpProxyTargetParamsIn: "snmpv3Params"
  • snmpProxySingleTargetOut: "legacyDevice"

Entrée snmpTargetAddrTable (legacyDevice) :

  • snmpTargetAddrTDomain: snmpUDPDomain
  • snmpTargetAddrTAddress: 192.0.2.10:161
  • snmpTargetAddrParams: "snmpv1Params"

Entrée snmpTargetParamsTable (snmpv1Params) :

  • snmpTargetParamsMPModel: 0 (SNMPv1)
  • snmpTargetParamsSecurityModel: 1 (SNMPv1)
  • snmpTargetParamsSecurityName: "public"
  • snmpTargetParamsSecurityLevel: noAuthNoPriv

Requête sortante :

  • Transport: UDP vers 192.0.2.10:161
  • Version SNMP: SNMPv1
  • Community: "public"
  • PDU: GetRequest (mêmes variable-bindings)

Traduction de réponse :

  • La réponse SNMPv1 entrante est retraduite au format SNMPv3.
  • La réponse est chiffrée et authentifiée en utilisant USM.
  • Retournée au demandeur original.

Exemple 2 : Traduction de trap SNMPv1 vers trap SNMPv2​

Trap SNMPv1 entrant :

  • Community: "public"
  • enterprise: 1.3.6.1.4.1.9
  • agent-addr: 192.0.2.1
  • generic-trap: linkDown(2)
  • specific-trap: 0
  • time-stamp: 12345

Entrée snmpProxyTable :

  • snmpProxyType: trap(3)
  • snmpProxyContextEngineID: "" (correspondre à n'importe lequel)
  • snmpProxyContextName: "" (correspondre à n'importe lequel)
  • snmpProxyTargetParamsIn: "" (correspondre à n'importe lequel)
  • snmpProxyMultipleTargetOut: "snmpv2Targets"

Entrées snmpTargetAddrTable avec étiquette "snmpv2Targets" : Plusieurs entrées avec paramètres SNMPv2c ou SNMPv3.

Traps SNMPv2/v3 sortants :

  • snmpTrapOID.0: 1.3.6.1.6.3.1.1.5.3 (linkDown)
  • sysUpTime.0: 12345
  • Variable-bindings supplémentaires du trap original.

Considérations particulières​

Traduction de contexte​

La snmpProxyTable permet la traduction de contexte :

  • Un snmpProxyContextEngineID ou snmpProxyContextName vide dans l'entrée de table signifie "utiliser la valeur entrante."
  • Une valeur non vide signifie "mapper le contexte entrant vers ce contexte sortant."

Cela permet au proxy de mapper plusieurs contextes entrants vers un seul contexte sortant, ou vice versa.

Prévention de la dégradation de sécurité​

Lors de la traduction d'un niveau de sécurité supérieur vers un niveau inférieur (par ex. SNMPv3 authPriv vers SNMPv1 noAuthNoPriv), le proxy devrait :

  1. Enregistrer la dégradation de sécurité à des fins d'audit.
  2. Appliquer des contrôles d'accès supplémentaires pour limiter quelles opérations peuvent être dégradées.
  3. Envisager de chiffrer le transport (par ex. en utilisant IPsec ou TLS) pour compenser la sécurité réduite au niveau SNMP.

Gestion des erreurs​

Les proxies doivent gérer les erreurs avec soin :

  • Erreurs de traduction : Si une PDU ne peut pas être traduite (par ex. valeurs d'exception SNMPv2 en SNMPv1), retourner une erreur appropriée.
  • Erreurs de transfert : Si la cible est inaccessible, retourner un timeout ou erreur réseau au demandeur original.
  • Erreurs de traduction de réponse : Si une réponse ne peut pas être retraduite, enregistrer l'erreur et retourner un genErr au demandeur original.

Optimisation de performance​

Le transfert par proxy peut être optimisé par :

  1. Mise en cache des recherches de table : Cache les recherches snmpProxyTable, snmpTargetAddrTable et snmpTargetParamsTable pour les chemins fréquemment utilisés.
  2. Pré-compilation des règles : Convertit les entrées de table en un format interne optimisé au moment de la configuration.
  3. Pooling de connexions : Pour le transport basé TCP, maintient des connexions persistantes vers les cibles fréquemment accédées.

5. Identification des cibles de gestion dans les émetteurs de notifications​

Une application émetteur de notification utilise snmpTargetAddrTable et snmpTargetParamsTable pour identifier les cibles de gestion auxquelles les notifications doivent être envoyées, et pour déterminer quelle version SNMP et quels paramètres de sécurité doivent être utilisés lors de l'envoi de notifications.

Lorsqu'un événement se produit qui déclenche la génération d'une notification, l'émetteur de notification :

  1. Consulte snmpNotifyTable pour déterminer quelles étiquettes de notification doivent être utilisées pour cette notification. Chaque entrée dans snmpNotifyTable associe une valeur d'étiquette à un type de notification (trap ou inform).

  2. Sélectionne les adresses cibles depuis snmpTargetAddrTable en faisant correspondre les étiquettes de notification. Pour chaque entrée dans snmpTargetAddrTable :

    a. L'objet snmpTargetAddrTagList contient une liste de valeurs d'étiquette.

    b. Si l'une des valeurs d'étiquette dans snmpTargetAddrTagList correspond à une étiquette spécifiée dans snmpNotifyTable, cette adresse cible est sélectionnée.

  3. Récupère les paramètres de transport pour chaque adresse cible sélectionnée :

    a. snmpTargetAddrTDomain spécifie le domaine de transport (par ex. snmpUDPDomain, snmpTCPDomain).

    b. snmpTargetAddrTAddress spécifie l'adresse de transport (par ex. adresse IP et port).

  4. Récupère les paramètres SNMP pour chaque adresse cible sélectionnée :

    a. L'objet snmpTargetAddrParams référence une entrée dans snmpTargetParamsTable.

    b. À partir de l'entrée snmpTargetParamsTable référencée, l'émetteur de notification récupère :

    • snmpTargetParamsMPModel (modèle de traitement de message)
    • snmpTargetParamsSecurityModel (modèle de sécurité)
    • snmpTargetParamsSecurityName (nom de sécurité)
    • snmpTargetParamsSecurityLevel (niveau de sécurité)

  5. Génère et envoie la notification pour chaque cible de gestion sélectionnée en utilisant les paramètres récupérés.

Exemple de configuration​

Considérons un émetteur de notification qui doit envoyer une notification linkDown. La configuration pourrait inclure :

Entrée snmpNotifyTable :​

  • snmpNotifyName: "linkDownNotify"
  • snmpNotifyTag: "criticalDevices"
  • snmpNotifyType: trap(1)

Entrées snmpTargetAddrTable :​

Entrée 1 :

  • snmpTargetAddrName: "mgmtStation1"
  • snmpTargetAddrTDomain: snmpUDPDomain
  • snmpTargetAddrTAddress: 192.0.2.1:162
  • snmpTargetAddrTagList: "criticalDevices monitoring"
  • snmpTargetAddrParams: "snmpv3Params"

Entrée 2 :

  • snmpTargetAddrName: "mgmtStation2"
  • snmpTargetAddrTDomain: snmpUDPDomain
  • snmpTargetAddrTAddress: 192.0.2.2:162
  • snmpTargetAddrTagList: "criticalDevices"
  • snmpTargetAddrParams: "snmpv2cParams"

Entrées snmpTargetParamsTable :​

Entrée snmpv3Params :

  • snmpTargetParamsMPModel: 3 (SNMPv3)
  • snmpTargetParamsSecurityModel: 3 (USM)
  • snmpTargetParamsSecurityName: "operator"
  • snmpTargetParamsSecurityLevel: authPriv(3)

Entrée snmpv2cParams :

  • snmpTargetParamsMPModel: 1 (SNMPv2c)
  • snmpTargetParamsSecurityModel: 2 (SNMPv2c)
  • snmpTargetParamsSecurityName: "public"
  • snmpTargetParamsSecurityLevel: noAuthNoPriv(1)

Lorsqu'un événement linkDown se produit :

  1. L'émetteur de notification consulte snmpNotifyTable et constate que les notifications avec l'étiquette "criticalDevices" doivent être envoyées en tant que traps.

  2. Il parcourt snmpTargetAddrTable et trouve deux entrées avec "criticalDevices" dans leurs listes d'étiquettes : "mgmtStation1" et "mgmtStation2".

  3. Pour mgmtStation1, il envoie un trap SNMPv3 à 192.0.2.1:162 en utilisant la sécurité USM avec niveau authPriv et nom de sécurité "operator".

  4. Pour mgmtStation2, il envoie un trap SNMPv2c à 192.0.2.2:162 avec la chaîne de communauté "public".

Timeout et nouvelle tentative pour les requêtes inform​

Lorsque le type de notification est inform (InformRequest-PDU), snmpTargetAddrTable fournit également des paramètres de timeout et de nouvelle tentative :

  • snmpTargetAddrTimeout : Spécifie le temps (en centièmes de seconde) à attendre pour une réponse avant de considérer la requête comme expirée.

  • snmpTargetAddrRetryCount : Spécifie le nombre de fois à réessayer d'envoyer la requête inform si aucune réponse n'est reçue.

L'émetteur de notification utilise ces paramètres pour implémenter une livraison de notification fiable pour les requêtes inform.

Par exemple, si snmpTargetAddrTimeout est 1500 (15 secondes) et snmpTargetAddrRetryCount est 3, l'émetteur de notification va :

  1. Envoyer la requête inform.
  2. Attendre jusqu'à 15 secondes pour une réponse.
  3. Si aucune réponse n'est reçue, réessayer jusqu'à 3 fois supplémentaires.
  4. Abandonner après 4 tentatives totales (initiale + 3 nouvelles tentatives) ou 60 secondes (4 × 15 secondes), selon ce qui arrive en premier.

Considérations de sécurité pour l'identification des cibles de gestion​

Lors de l'identification des cibles de gestion pour les notifications :

  1. Authentification de la configuration : La configuration des cibles de gestion (snmpTargetAddrTable, snmpTargetParamsTable et snmpNotifyTable) devrait être protégée par un contrôle d'accès pour empêcher toute modification non autorisée.

  2. Informations sensibles : Les noms de sécurité, en particulier lorsqu'ils sont utilisés avec SNMPv1 ou SNMPv2c (chaînes de communauté), devraient être protégés contre la divulgation. snmpTargetParamsTable ne devrait être accessible qu'aux utilisateurs autorisés.

  3. Filtrage de notification : Sans filtrage de notification approprié (décrit dans la section suivante), toutes les cibles de gestion configurées recevront toutes les notifications, exposant potentiellement des informations sensibles à des destinataires non autorisés.

  4. Sélection d'étiquette : L'utilisation d'étiquettes permet un regroupement flexible des cibles de gestion, mais il faut veiller à ce que les étiquettes soient appliquées correctement pour éviter les notifications mal dirigées.

6. Filtrage des notifications​

Le filtrage de notification fournit un mécanisme pour envoyer sélectivement des notifications aux cibles de gestion en fonction du contenu de la notification. Cela permet un contrôle précis sur quelles cibles de gestion reçoivent quels types de notifications.

Le filtrage de notification utilise trois tables MIB :

  • snmpNotifyFilterProfileTable : Associe un nom de profil de filtre à un ensemble de paramètres cibles.
  • snmpNotifyFilterTable : Définit les règles de filtre réelles basées sur le contenu de notification.
  • snmpTargetParamsTable : Contient les noms de paramètres cibles référencés par la table de profil de filtre.

Algorithme de traitement de filtre​

Lorsqu'un émetteur de notification génère une notification pour une cible de gestion, il applique le filtrage de notification comme suit :

  1. Récupère le nom des paramètres cibles de l'objet snmpTargetAddrParams pour la cible de gestion.

  2. Recherche le profil de filtre dans snmpNotifyFilterProfileTable en utilisant le nom des paramètres cibles comme index.

  3. Si aucun profil de filtre n'est trouvé, la notification est envoyée (aucun filtrage n'est appliqué).

  4. Si un profil de filtre est trouvé, le snmpNotifyFilterProfileName identifie un ensemble d'entrées de filtre dans snmpNotifyFilterTable.

  5. Pour chaque variable-binding dans la notification :

    a. Recherche snmpNotifyFilterTable pour les entrées correspondant au nom de profil de filtre.

    b. Les entrées sont traitées dans l'ordre lexicographique de leurs indices.

    c. Pour chaque entrée de filtre, vérifie si le sous-arbre spécifié par snmpNotifyFilterSubtree correspond à l'identifiant d'objet de la variable.

    d. Une correspondance se produit si l'OID de la variable est dans ou égal au sous-arbre du filtre, en tenant compte de snmpNotifyFilterMask si spécifié.

    e. Si une correspondance est trouvée :

    • Si snmpNotifyFilterType est included(1), continue à vérifier les autres variables.
    • Si snmpNotifyFilterType est excluded(2), n'envoie pas la notification à cette cible de gestion.

    f. Si aucune correspondance n'est trouvée pour une variable après avoir vérifié toutes les entrées de filtre, n'envoie pas la notification.

  6. Si tous les variable-bindings passent le filtre, envoie la notification à la cible de gestion.

Sémantique du masque de filtre​

L'objet snmpNotifyFilterMask fournit un contrôle au niveau des bits sur la correspondance de sous-arbre. C'est un masque de bits avec la sémantique suivante :

  • Chaque octet dans le masque correspond à un sous-identifiant dans l'OID du sous-arbre du filtre.
  • Chaque bit dans un octet correspond à un bit dans le sous-identifiant.
  • Si un bit dans le masque est 1, le bit correspondant dans le sous-identifiant doit correspondre à l'OID de la variable.
  • Si un bit dans le masque est 0, le bit correspondant dans le sous-identifiant est ignoré (joker).

Un masque de longueur zéro (par défaut) signifie que tous les sous-identifiants doivent correspondre exactement.

Exemple d'utilisation de masque :​

Sous-arbre de filtre : 1.3.6.1.2.1.2.2.1.8
Masque : 0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFE

Ce masque permet de faire correspondre à la fois 1.3.6.1.2.1.2.2.1.8 (ifOperStatus) et 1.3.6.1.2.1.2.2.1.9 (ifLastChange), car le dernier bit du sous-identifiant final est un joker.

Exemples de configuration​

Exemple 1 : Envoi de toutes les notifications à une cible de gestion​

Pour envoyer toutes les notifications à une cible de gestion sans filtrage :

  1. Ne pas créer d'entrée dans snmpNotifyFilterProfileTable pour le nom de paramètre de la cible.

OU

  1. Créer un profil de filtre avec un seul filtre inclusif :
    • snmpNotifyFilterSubtree: 1 (ou n'importe quel OID racine)
    • snmpNotifyFilterMask: "" (vide)
    • snmpNotifyFilterType: included(1)

Exemple 2 : Envoi uniquement de notifications liées aux interfaces​

Pour envoyer uniquement les notifications liées aux interfaces (ifTable) :

Entrée snmpNotifyFilterProfileTable :

  • snmpNotifyFilterProfileName: "interfaceFilter"
  • Associé au nom de paramètres cibles: "stationAParams"

Entrées snmpNotifyFilterTable :

Entrée 1 :

  • snmpNotifyFilterProfileName: "interfaceFilter"
  • snmpNotifyFilterSubtree: 1.3.6.1.2.1.2
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: included(1)

Cette configuration permet d'envoyer des notifications contenant des variables du groupe interfaces (1.3.6.1.2.1.2), tout en filtrant toutes les autres notifications.

Exemple 3 : Exclusion de notifications spécifiques​

Pour envoyer toutes les notifications sauf celles liées à la table de connexion TCP :

Entrée snmpNotifyFilterProfileTable :

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • Associé au nom de paramètres cibles: "stationBParams"

Entrées snmpNotifyFilterTable :

Entrée 1 :

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • snmpNotifyFilterSubtree: 1
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: included(1)

Entrée 2 :

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • snmpNotifyFilterSubtree: 1.3.6.1.2.1.6.13
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: excluded(2)

Cette configuration inclut toutes les notifications (Entrée 1), mais exclut explicitement celles contenant des variables de tcpConnTable (Entrée 2).

Considérations d'implémentation​

Performance​

Le filtrage de notification nécessite des comparaisons d'OID pour chaque variable-binding contre potentiellement plusieurs entrées de filtre. Les implémentations devraient optimiser ce processus :

  • Utiliser des structures de données efficaces (par ex. tries ou tables de hachage) pour les recherches d'OID.
  • Mettre en cache les recherches de profil de filtre pour les cibles de gestion fréquemment utilisées.
  • Envisager de pré-compiler les règles de filtre au moment de la configuration.

Ordre de filtre​

Les entrées de filtre sont traitées dans l'ordre lexicographique de leurs indices. Cela signifie :

  • Les exclusions plus spécifiques (OID plus long) devraient être configurées de manière appropriée par rapport aux inclusions plus larges.
  • L'ordre des entrées de filtre peut affecter le résultat du filtrage.

Comportement par défaut​

Si aucun profil de filtre n'existe pour les paramètres d'une cible :

  • Le comportement par défaut est d'envoyer la notification (pas de filtrage).
  • Cela assure la rétrocompatibilité avec les systèmes qui n'utilisent pas de filtrage de notification.

Exigences de variable-binding​

RFC 3416 exige que les notifications incluent au moins deux variable-bindings :

  1. sysUpTime.0
  2. snmpTrapOID.0

Ces variable-bindings obligatoires doivent passer le filtre pour que la notification soit envoyée. Si le filtre exclut ces OID, la notification ne sera pas envoyée à cette cible de gestion.

Considérations de sécurité​

Le filtrage de notification peut impacter la sécurité de plusieurs façons :

  1. Prévention de la divulgation d'informations : Le filtrage peut empêcher l'envoi d'informations sensibles à des stations de gestion non autorisées.

  2. Protection de la configuration : Les tables de configuration de filtre (snmpNotifyFilterProfileTable et snmpNotifyFilterTable) devraient être protégées par un contrôle d'accès pour empêcher toute modification non autorisée.

  3. Contournement de filtre : Une configuration de filtre inappropriée (par ex. règles d'inclusion trop larges) peut permettre l'envoi de notifications non intentionnelles.

  4. Déni de service : Des règles de filtre trop complexes peuvent consommer des ressources de traitement excessives, causant potentiellement un déni de service.

Il est recommandé d'utiliser le filtrage de notification en conjonction avec un contrôle d'accès approprié (tel que VACM) et les fonctionnalités de sécurité SNMPv3 pour assurer une sécurité complète.