Zum Hauptinhalt springen

6. Notification Filtering

Benachrichtigungsfilterung bietet einen Mechanismus zur selektiven Sendung von Benachrichtigungen an Management Targets basierend auf dem Inhalt der Benachrichtigung. Dies ermöglicht eine feinkörnige Kontrolle darüber, welche Management Targets welche Arten von Benachrichtigungen erhalten.

Benachrichtigungsfilterung verwendet drei MIB-Tabellen:

  • snmpNotifyFilterProfileTable: Verknüpft einen Filterprofil-Namen mit einem Satz von Target-Parametern.
  • snmpNotifyFilterTable: Definiert die tatsächlichen Filterregeln basierend auf Benachrichtigungsinhalten.
  • snmpTargetParamsTable: Enthält die Target-Parameter-Namen, die von der Filterprofil-Tabelle referenziert werden.

Filterverarbeitungsalgorithmus​

Wenn ein Notification Originator eine Benachrichtigung für ein Management Target erzeugt, wendet er die Benachrichtigungsfilterung wie folgt an:

  1. Ruft den Target-Parameter-Namen aus dem snmpTargetAddrParams-Objekt für das Management Target ab.

  2. Sucht das Filterprofil in der snmpNotifyFilterProfileTable unter Verwendung des Target-Parameter-Namens als Index.

  3. Falls kein Filterprofil gefunden wird, wird die Benachrichtigung gesendet (keine Filterung wird angewendet).

  4. Falls ein Filterprofil gefunden wird, identifiziert der snmpNotifyFilterProfileName einen Satz von Filtereinträgen in der snmpNotifyFilterTable.

  5. Für jedes variable-binding in der Benachrichtigung:

    a. Durchsucht die snmpNotifyFilterTable nach Einträgen, die mit dem Filterprofil-Namen übereinstimmen.

    b. Einträge werden in lexikografischer Reihenfolge ihrer Indizes verarbeitet.

    c. Für jeden Filtereintrag überprüft, ob der durch snmpNotifyFilterSubtree angegebene Subtree mit dem Objektidentifikator der Variablen übereinstimmt.

    d. Eine Übereinstimmung tritt auf, wenn die OID der Variablen innerhalb oder gleich dem Filter-Subtree ist, unter Berücksichtigung der snmpNotifyFilterMask, falls angegeben.

    e. Falls eine Übereinstimmung gefunden wird:

    • Falls snmpNotifyFilterType included(1) ist, fährt mit der Überprüfung anderer Variablen fort.
    • Falls snmpNotifyFilterType excluded(2) ist, sendet die Benachrichtigung nicht an dieses Management Target.

    f. Falls keine Übereinstimmung für eine Variable nach Überprüfung aller Filtereinträge gefunden wird, sendet die Benachrichtigung nicht.

  6. Falls alle variable-bindings den Filter passieren, sendet die Benachrichtigung an das Management Target.

Filter-Masken-Semantik​

Das snmpNotifyFilterMask-Objekt bietet Bit-Level-Kontrolle über Subtree-Matching. Es ist eine Bit-Maske mit der folgenden Semantik:

  • Jedes Oktett in der Maske entspricht einem Sub-Identifikator in der Filter-Subtree-OID.
  • Jedes Bit in einem Oktett entspricht einem Bit im Sub-Identifikator.
  • Falls ein Bit in der Maske 1 ist, muss das entsprechende Bit im Sub-Identifikator mit der OID der Variablen übereinstimmen.
  • Falls ein Bit in der Maske 0 ist, wird das entsprechende Bit im Sub-Identifikator ignoriert (Wildcard).

Eine Maske der Länge Null (Standard) bedeutet, dass alle Sub-Identifikatoren genau übereinstimmen müssen.

Beispiel Maskenverwendung:​

Filter-Subtree: 1.3.6.1.2.1.2.2.1.8
Maske: 0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFE

Diese Maske ermöglicht das Matching sowohl von 1.3.6.1.2.1.2.2.1.8 (ifOperStatus) als auch 1.3.6.1.2.1.2.2.1.9 (ifLastChange), da das letzte Bit des finalen Sub-Identifikators als Wildcard verwendet wird.

Konfigurationsbeispiele​

Beispiel 1: Senden aller Benachrichtigungen an ein Management Target​

Um alle Benachrichtigungen ohne Filterung an ein Management Target zu senden:

  1. Erstellen Sie keinen Eintrag in der snmpNotifyFilterProfileTable für den Parameter-Namen des Targets.

ODER

  1. Erstellen Sie ein Filterprofil mit einem einzelnen inklusiven Filter:
    • snmpNotifyFilterSubtree: 1 (oder eine beliebige Wurzel-OID)
    • snmpNotifyFilterMask: "" (leer)
    • snmpNotifyFilterType: included(1)

Beispiel 2: Nur Interface-bezogene Benachrichtigungen senden​

Um nur Benachrichtigungen zu senden, die sich auf Interfaces (ifTable) beziehen:

snmpNotifyFilterProfileTable-Eintrag:

  • snmpNotifyFilterProfileName: "interfaceFilter"
  • Verknüpft mit Target-Parameter-Name: "stationAParams"

snmpNotifyFilterTable-Einträge:

Eintrag 1:

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

Diese Konfiguration erlaubt das Senden von Benachrichtigungen, die Variablen aus der Interfaces-Gruppe (1.3.6.1.2.1.2) enthalten, während alle anderen Benachrichtigungen herausgefiltert werden.

Beispiel 3: Bestimmte Benachrichtigungen ausschließen​

Um alle Benachrichtigungen außer solchen zu senden, die sich auf die TCP-Connection-Tabelle beziehen:

snmpNotifyFilterProfileTable-Eintrag:

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • Verknüpft mit Target-Parameter-Name: "stationBParams"

snmpNotifyFilterTable-Einträge:

Eintrag 1:

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

Eintrag 2:

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

Diese Konfiguration schließt alle Benachrichtigungen ein (Eintrag 1), schließt aber explizit solche aus, die Variablen aus der tcpConnTable enthalten (Eintrag 2).

Implementierungsüberlegungen​

Leistung​

Benachrichtigungsfilterung erfordert OID-Vergleiche für jedes variable-binding gegen potenziell mehrere Filtereinträge. Implementierungen sollten diesen Prozess optimieren:

  • Verwenden Sie effiziente Datenstrukturen (z.B. Tries oder Hash-Tabellen) für OID-Lookups.
  • Cachen Sie Filterprofil-Lookups für häufig verwendete Management Targets.
  • Erwägen Sie die Vorkompilierung von Filterregeln zur Konfigurationszeit.

Filterreihenfolge​

Filtereinträge werden in lexikografischer Reihenfolge ihrer Indizes verarbeitet. Dies bedeutet:

  • Spezifischere (längere OID) Ausschlüsse sollten im Verhältnis zu breiteren Einschlüssen angemessen konfiguriert werden.
  • Die Reihenfolge der Filtereinträge kann das Ergebnis der Filterung beeinflussen.

Standardverhalten​

Falls kein Filterprofil für die Parameter eines Targets existiert:

  • Das Standardverhalten ist das Senden der Benachrichtigung (keine Filterung).
  • Dies gewährleistet Rückwärtskompatibilität mit Systemen, die keine Benachrichtigungsfilterung verwenden.

Variable-Binding-Anforderungen​

RFC 3416 erfordert, dass Benachrichtigungen mindestens zwei variable-bindings enthalten:

  1. sysUpTime.0
  2. snmpTrapOID.0

Diese obligatorischen variable-bindings müssen den Filter passieren, damit die Benachrichtigung gesendet wird. Falls der Filter diese OIDs ausschließt, wird die Benachrichtigung nicht an dieses Management Target gesendet.

Sicherheitsüberlegungen​

Benachrichtigungsfilterung kann die Sicherheit auf mehrere Weisen beeinflussen:

  1. Verhinderung von Informationsoffenlegung: Filterung kann verhindern, dass sensible Informationen an nicht autorisierte Management-Stationen gesendet werden.

  2. Konfigurationsschutz: Die Filterkonfigurations-Tabellen (snmpNotifyFilterProfileTable und snmpNotifyFilterTable) sollten durch Zugriffskontrolle geschützt werden, um nicht autorisierte Modifikation zu verhindern.

  3. Filter-Umgehung: Unsachgemäße Filterkonfiguration (z.B. zu weit gefasste Einschlussregeln) kann dazu führen, dass unbeabsichtigte Benachrichtigungen gesendet werden.

  4. Denial of Service: Übermäßig komplexe Filterregeln können übermäßige Verarbeitungsressourcen verbrauchen, was möglicherweise zu einem Denial of Service führt.

Es wird empfohlen, Benachrichtigungsfilterung in Verbindung mit ordnungsgemäßer Zugriffskontrolle (wie VACM) und SNMPv3-Sicherheitsfunktionen zu verwenden, um umfassende Sicherheit zu gewährleisten.