6. Notification Filtering

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

2. 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.