Passa al contenuto principale

Applicazioni SNMP (Simple Network Management Protocol)

  • Stato: Internet Standard
  • Pubblicato: December 2002
  • Stream: IETF
  • Sostituisce: RFC2573
  • Errata: Nessun errata

Stato di questo memo​

Questo documento specifica un protocollo di standard Internet per la comunità Internet e richiede discussioni e suggerimenti per miglioramenti. Si prega di fare riferimento all'edizione corrente di "Internet Official Protocol Standards" (STD 1) per lo stato di standardizzazione e lo stato di questo protocollo. La distribuzione di questo memo è illimitata.

Sommario​

Questo documento descrive cinque tipi di applicazioni SNMP (Simple Network Management Protocol) che utilizzano un motore SNMP come descritto in STD 62, RFC 3411. I tipi di applicazioni descritti sono Generatori di comandi, Risponditori di comandi, Originatori di notifiche, Ricevitori di notifiche e Inoltratori proxy.

Questo documento definisce anche moduli MIB (Management Information Base) per specificare gli obiettivi delle operazioni di gestione, per il filtraggio delle notifiche e per l'inoltro proxy. Questo documento rende obsoleto RFC 2573.

7. Traduzione dei target di gestione nelle applicazioni proxy forwarder​

Le applicazioni proxy forwarder eseguono la traduzione dei management target quando inoltrano messaggi SNMP. Questa traduzione implica il mapping dei parametri del messaggio in entrata (contextEngineID, contextName, securityModel, securityName, securityLevel) a parametri del messaggio in uscita adatti al motore SNMP target.

La snmpProxyTable definisce le regole di traduzione utilizzate dai proxy forwarder.

7.1. Request Forwarding​

Il request forwarding implica la ricezione di una richiesta di comando da un command generator, la traduzione dei parametri della richiesta e l'inoltro della richiesta a un command responder.

7.1.1. Processamento di una Richiesta in Entrata​

Quando un proxy forwarder riceve una richiesta:

  1. Estrae i parametri in entrata dal messaggio ricevuto:

    • contextEngineID
    • contextName
    • securityModel
    • securityName
    • securityLevel
    • Tipo di PDU

  2. Cerca in snmpProxyTable utilizzando questi parametri come chiave. Cerca specificamente una voce dove:

    • snmpProxyType è read(1) per PDU di classe read (Get, GetNext, GetBulk) o write(2) per PDU di classe write (Set)
    • snmpProxyContextEngineID corrisponde al contextEngineID in entrata
    • snmpProxyContextName corrisponde al contextName in entrata
    • snmpProxyTargetParamsIn riferisce parametri target che corrispondono ai parametri di sicurezza in entrata

  3. Se non viene trovata alcuna voce corrispondente:

    • Genera una risposta di errore indicando che la richiesta non può essere inoltrata.
    • L'errore specifico dipende dalla versione SNMP e dalle circostanze (ad es. authorizationError, genErr).

  4. Se viene trovata una voce corrispondente:

    • Estrae il valore snmpProxySingleTargetOut o snmpProxyMultipleTargetOut.

7.1.2. Inoltro della Richiesta​

Dopo aver trovato una voce snmpProxyTable corrispondente:

Inoltro a Target Singolo​

Se snmpProxySingleTargetOut è specificato:

  1. Cerca in snmpTargetAddrTable utilizzando snmpProxySingleTargetOut come snmpTargetAddrName.

  2. Estrae le informazioni dell'indirizzo target:

    • snmpTargetAddrTDomain (dominio di trasporto)
    • snmpTargetAddrTAddress (indirizzo di trasporto)
    • snmpTargetAddrParams (riferimento a snmpTargetParamsTable)

  3. Cerca in snmpTargetParamsTable utilizzando snmpTargetAddrParams.

  4. Estrae i parametri di sicurezza target:

    • snmpTargetParamsMPModel (message processing model)
    • snmpTargetParamsSecurityModel
    • snmpTargetParamsSecurityName
    • snmpTargetParamsSecurityLevel

  5. Determina il contesto target:

    • Se snmpProxyContextEngineID è vuoto, utilizza il contextEngineID in entrata.
    • Altrimenti, utilizza snmpProxyContextEngineID.
    • Similmente per snmpProxyContextName.

  6. Traduce la PDU se necessario:

    • Se le versioni SNMP in entrata e in uscita differiscono, traduce il formato PDU e i codici di errore.
    • Per SNMPv1 a SNMPv2: Mappa i codici di errore, converte i formati trap.
    • Per SNMPv2 a SNMPv1: Mappa i codici di errore (ad es. noAccess → genErr), gestisce i valori di eccezione.

  7. Inoltra la richiesta utilizzando la primitiva send PDU del sottosistema di processamento dei messaggi con i parametri target.

Inoltro a Target Multipli​

Se snmpProxyMultipleTargetOut è specificato:

  1. Cerca in snmpTargetAddrTable tutte le voci dove snmpTargetAddrTagList contiene il tag specificato in snmpProxyMultipleTargetOut.

  2. Per ogni indirizzo target corrispondente:

    • Segue i passi 2-7 dell'inoltro a target singolo.
    • Nota che la richiesta originale è duplicata e inviata a più indirizzi target.

  3. Gestione della risposta per target multipli:

    • L'inoltro a target multipli è tipicamente utilizzato solo per operazioni di lettura.
    • Il proxy potrebbe dover aggregare le risposte o restituire la prima risposta riuscita.
    • Il comportamento specifico è dipendente dall'implementazione.

7.1.3. Inoltro della Risposta​

Quando il proxy forwarder riceve una risposta dal command responder target:

  1. Traduce la PDU di risposta se necessario per corrispondere al formato atteso dal richiedente originale.

  2. Mappa il contextEngineID e contextName ai valori attesi dal richiedente originale.

  3. Restituisce la risposta utilizzando la primitiva return response PDU del sottosistema di processamento dei messaggi.

7.2. Notification Forwarding​

Il notification forwarding implica la ricezione di una notifica da un notification originator e il suo inoltro a uno o più notification receiver.

7.2.1. Processamento di una Notifica in Entrata​

Quando un proxy forwarder riceve una notifica:

  1. Estrae i parametri in entrata:

    • contextEngineID
    • contextName
    • securityModel
    • securityName
    • securityLevel
    • Tipo di notifica (trap o inform)

  2. Cerca in snmpProxyTable utilizzando questi parametri. Cerca una voce dove:

    • snmpProxyType è trap(3) per notifiche trap o inform(4) per notifiche inform
    • snmpProxyContextEngineID corrisponde al contextEngineID in entrata (o è vuoto per corrispondere a qualsiasi)
    • snmpProxyContextName corrisponde al contextName in entrata (o è vuoto per corrispondere a qualsiasi)
    • snmpProxyTargetParamsIn riferisce parametri target che corrispondono ai parametri di sicurezza in entrata (o è vuoto per corrispondere a qualsiasi)

  3. Se non viene trovata alcuna voce corrispondente:

    • La notifica non viene inoltrata.
    • Il proxy può registrare questo evento localmente.

  4. Se viene trovata una voce corrispondente:

    • Estrae il valore snmpProxyMultipleTargetOut (l'inoltro delle notifiche usa sempre l'inoltro a target multipli).

7.2.2. Inoltro della Notifica​

Dopo aver trovato una voce snmpProxyTable corrispondente:

  1. Cerca in snmpTargetAddrTable tutte le voci dove snmpTargetAddrTagList contiene il tag specificato in snmpProxyMultipleTargetOut.

  2. Per ogni indirizzo target corrispondente:

    a. Cerca snmpTargetAddrParams in snmpTargetParamsTable.

    b. Estrae i parametri target.

    c. Determina se inviare come trap o inform basandosi su snmpNotifyTable (se riferita) o utilizza lo stesso tipo della notifica in entrata.

    d. Traduce la PDU di notifica se necessario:

    • Trap SNMPv1 a trap SNMPv2: Converte formato PDU, aggiunge sysUpTime.0 e snmpTrapOID.0.
    • Trap SNMPv2 a trap SNMPv1: Converte formato PDU, estrae enterprise, agent-addr, generic-trap, specific-trap.

    e. Inoltra la notifica utilizzando la primitiva send PDU del sottosistema di processamento dei messaggi.

  3. Se la notifica in uscita è un inform request:

    • Attende una risposta da ogni target.
    • Se la notifica in entrata era anche un inform, aggrega le risposte.
    • Restituisce una risposta al notification originator originale solo dopo aver ricevuto risposte da tutti (o un sottoinsieme configurato di) target.

Esempi di Traduzione​

Esempio 1: Traduzione di Richiesta SNMPv3 a SNMPv1​

Richiesta in Entrata:

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

Voce snmpProxyTable:

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

Voce snmpTargetAddrTable (legacyDevice):

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

Voce snmpTargetParamsTable (snmpv1Params):

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

Richiesta in Uscita:

  • Trasporto: UDP a 192.0.2.10:161
  • Versione SNMP: SNMPv1
  • Community: "public"
  • PDU: GetRequest (stessi variable-binding)

Traduzione della Risposta:

  • La risposta SNMPv1 in entrata viene ritradotta in formato SNMPv3.
  • La risposta viene crittografata e autenticata utilizzando USM.
  • Restituita al richiedente originale.

Esempio 2: Traduzione di Trap SNMPv1 a Trap SNMPv2​

Trap SNMPv1 in Entrata:

  • 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

Voce snmpProxyTable:

  • snmpProxyType: trap(3)
  • snmpProxyContextEngineID: "" (corrisponde a qualsiasi)
  • snmpProxyContextName: "" (corrisponde a qualsiasi)
  • snmpProxyTargetParamsIn: "" (corrisponde a qualsiasi)
  • snmpProxyMultipleTargetOut: "snmpv2Targets"

Voci snmpTargetAddrTable con tag "snmpv2Targets": Più voci con parametri SNMPv2c o SNMPv3.

Trap SNMPv2/v3 in Uscita:

  • snmpTrapOID.0: 1.3.6.1.6.3.1.1.5.3 (linkDown)
  • sysUpTime.0: 12345
  • Variable-binding aggiuntivi dal trap originale.

Considerazioni Speciali​

Traduzione di Contesto​

La snmpProxyTable permette la traduzione di contesto:

  • Un snmpProxyContextEngineID o snmpProxyContextName vuoto nella voce di tabella significa "utilizza il valore in entrata."
  • Un valore non vuoto significa "mappa il contesto in entrata a questo contesto in uscita."

Questo permette al proxy di mappare più contesti in entrata a un singolo contesto in uscita, o viceversa.

Prevenzione della Degradazione di Sicurezza​

Quando si traduce da un livello di sicurezza superiore a uno inferiore (ad es. SNMPv3 authPriv a SNMPv1 noAuthNoPriv), il proxy dovrebbe:

  1. Registrare la degradazione di sicurezza per scopi di audit.
  2. Applicare controlli degli accessi aggiuntivi per limitare quali operazioni possono essere degradate.
  3. Considerare di crittografare il trasporto (ad es. utilizzando IPsec o TLS) per compensare la sicurezza ridotta a livello SNMP.

Gestione degli Errori​

I proxy devono gestire gli errori con attenzione:

  • Errori di Traduzione: Se una PDU non può essere tradotta (ad es. valori di eccezione SNMPv2 in SNMPv1), restituisce un errore appropriato.
  • Errori di Inoltro: Se il target è irraggiungibile, restituisce un timeout o errore di rete al richiedente originale.
  • Errori di Traduzione della Risposta: Se una risposta non può essere ritradotta, registra l'errore e restituisce un genErr al richiedente originale.

Ottimizzazione delle Performance​

L'inoltro proxy può essere ottimizzato:

  1. Caching delle ricerche di tabella: Cache le ricerche di snmpProxyTable, snmpTargetAddrTable e snmpTargetParamsTable per percorsi utilizzati frequentemente.
  2. Pre-compilazione delle regole: Converte le voci di tabella in un formato interno ottimizzato al momento della configurazione.
  3. Connection pooling: Per il trasporto basato su TCP, mantiene connessioni persistenti ai target acceduti frequentemente.

5. Identificazione dei target di gestione negli originatori di notifiche​

Un'applicazione notification originator utilizza snmpTargetAddrTable e snmpTargetParamsTable per identificare i management target a cui le notifiche dovrebbero essere inviate, e per determinare quale versione SNMP e quali parametri di sicurezza dovrebbero essere utilizzati quando si inviano notifiche.

Quando si verifica un evento che attiva la generazione di una notifica, il notification originator:

  1. Consulta snmpNotifyTable per determinare quali tag di notifica dovrebbero essere utilizzati per questa notifica. Ogni voce in snmpNotifyTable associa un valore di tag con un tipo di notifica (trap o inform).

  2. Seleziona gli indirizzi target da snmpTargetAddrTable confrontando i tag di notifica. Per ogni voce in snmpTargetAddrTable:

    a. L'oggetto snmpTargetAddrTagList contiene una lista di valori di tag.

    b. Se uno qualsiasi dei valori di tag in snmpTargetAddrTagList corrisponde a un tag specificato in snmpNotifyTable, questo indirizzo target viene selezionato.

  3. Recupera i parametri di trasporto per ogni indirizzo target selezionato:

    a. snmpTargetAddrTDomain specifica il dominio di trasporto (ad es. snmpUDPDomain, snmpTCPDomain).

    b. snmpTargetAddrTAddress specifica l'indirizzo di trasporto (ad es. indirizzo IP e porta).

  4. Recupera i parametri SNMP per ogni indirizzo target selezionato:

    a. L'oggetto snmpTargetAddrParams riferisce una voce in snmpTargetParamsTable.

    b. Dalla voce snmpTargetParamsTable riferita, il notification originator recupera:

    • snmpTargetParamsMPModel (message processing model)
    • snmpTargetParamsSecurityModel (security model)
    • snmpTargetParamsSecurityName (security name)
    • snmpTargetParamsSecurityLevel (security level)

  5. Genera e invia la notifica per ogni management target selezionato utilizzando i parametri recuperati.

Configurazione di Esempio​

Si consideri un notification originator che deve inviare una notifica linkDown. La configurazione potrebbe includere:

Voce snmpNotifyTable:​

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

Voci snmpTargetAddrTable:​

Voce 1:

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

Voce 2:

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

Voci snmpTargetParamsTable:​

Voce snmpv3Params:

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

Voce snmpv2cParams:

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

Quando si verifica un evento linkDown:

  1. Il notification originator consulta snmpNotifyTable e trova che le notifiche con tag "criticalDevices" dovrebbero essere inviate come trap.

  2. Scansiona snmpTargetAddrTable e trova due voci con "criticalDevices" nelle loro liste di tag: "mgmtStation1" e "mgmtStation2".

  3. Per mgmtStation1, invia un trap SNMPv3 a 192.0.2.1:162 utilizzando sicurezza USM con livello authPriv e security name "operator".

  4. Per mgmtStation2, invia un trap SNMPv2c a 192.0.2.2:162 con stringa community "public".

Timeout e Retry per Inform Request​

Quando il tipo di notifica è inform (InformRequest-PDU), snmpTargetAddrTable fornisce anche parametri di timeout e retry:

  • snmpTargetAddrTimeout: Specifica il tempo (in centesimi di secondo) da attendere per una risposta prima di considerare la richiesta scaduta.

  • snmpTargetAddrRetryCount: Specifica il numero di volte per ritentare l'invio della richiesta inform se non viene ricevuta alcuna risposta.

Il notification originator utilizza questi parametri per implementare la consegna affidabile delle notifiche per gli inform request.

Ad esempio, se snmpTargetAddrTimeout è 1500 (15 secondi) e snmpTargetAddrRetryCount è 3, il notification originator:

  1. Invierà la richiesta inform.
  2. Attenderà fino a 15 secondi per una risposta.
  3. Se non viene ricevuta alcuna risposta, ritenterà fino a 3 volte aggiuntive.
  4. Rinuncerà dopo 4 tentativi totali (iniziale + 3 retry) o 60 secondi (4 × 15 secondi), a seconda di quale si verifica prima.

Considerazioni di Sicurezza per l'Identificazione dei Management Target​

Quando si identificano i management target per le notifiche:

  1. Autenticazione della Configurazione: La configurazione dei management target (snmpTargetAddrTable, snmpTargetParamsTable e snmpNotifyTable) dovrebbe essere protetta dal controllo degli accessi per prevenire modifiche non autorizzate.

  2. Informazioni Sensibili: I security name, specialmente quando utilizzati con SNMPv1 o SNMPv2c (stringhe community), dovrebbero essere protetti dalla divulgazione. snmpTargetParamsTable dovrebbe essere accessibile solo agli utenti autorizzati.

  3. Filtraggio delle Notifiche: Senza un appropriato filtraggio delle notifiche (descritto nella sezione successiva), tutti i management target configurati riceveranno tutte le notifiche, potenzialmente esponendo informazioni sensibili a destinatari non autorizzati.

  4. Selezione dei Tag: L'uso dei tag permette un raggruppamento flessibile dei management target, ma si dovrebbe prestare attenzione affinché i tag siano applicati correttamente per prevenire notifiche mal indirizzate.

6. Filtraggio delle notifiche​

Il filtraggio delle notifiche fornisce un meccanismo per inviare selettivamente notifiche ai management target in base al contenuto della notifica. Questo permette un controllo granulare su quali management target ricevono quali tipi di notifiche.

Il filtraggio delle notifiche utilizza tre tabelle MIB:

  • snmpNotifyFilterProfileTable: Associa un nome di profilo di filtro con un insieme di parametri target.
  • snmpNotifyFilterTable: Definisce le regole di filtro effettive basate sul contenuto della notifica.
  • snmpTargetParamsTable: Contiene i nomi dei parametri target riferiti dalla tabella del profilo di filtro.

Algoritmo di Processamento del Filtro​

Quando un notification originator genera una notifica per un management target, applica il filtraggio delle notifiche come segue:

  1. Recupera il nome dei parametri target dall'oggetto snmpTargetAddrParams per il management target.

  2. Cerca il profilo di filtro in snmpNotifyFilterProfileTable utilizzando il nome dei parametri target come indice.

  3. Se non viene trovato alcun profilo di filtro, la notifica viene inviata (nessun filtraggio viene applicato).

  4. Se viene trovato un profilo di filtro, snmpNotifyFilterProfileName identifica un insieme di voci di filtro in snmpNotifyFilterTable.

  5. Per ogni variable-binding nella notifica:

    a. Cerca snmpNotifyFilterTable per le voci che corrispondono al nome del profilo di filtro.

    b. Le voci vengono processate in ordine lessicografico dei loro indici.

    c. Per ogni voce di filtro, controlla se il sottoalbero specificato da snmpNotifyFilterSubtree corrisponde all'identificatore di oggetto della variabile.

    d. Si verifica una corrispondenza se l'OID della variabile è all'interno o uguale al sottoalbero del filtro, considerando snmpNotifyFilterMask se specificato.

    e. Se viene trovata una corrispondenza:

    • Se snmpNotifyFilterType è included(1), continua a controllare altre variabili.
    • Se snmpNotifyFilterType è excluded(2), non invia la notifica a questo management target.

    f. Se non viene trovata alcuna corrispondenza per una variabile dopo aver controllato tutte le voci di filtro, non invia la notifica.

  6. Se tutti i variable-binding passano il filtro, invia la notifica al management target.

Semantica della Maschera di Filtro​

L'oggetto snmpNotifyFilterMask fornisce un controllo a livello di bit sul matching del sottoalbero. È una maschera di bit con la seguente semantica:

  • Ogni ottetto nella maschera corrisponde a un sotto-identificatore nell'OID del sottoalbero del filtro.
  • Ogni bit in un ottetto corrisponde a un bit nel sotto-identificatore.
  • Se un bit nella maschera è 1, il bit corrispondente nel sotto-identificatore deve corrispondere all'OID della variabile.
  • Se un bit nella maschera è 0, il bit corrispondente nel sotto-identificatore viene ignorato (wildcard).

Una maschera di lunghezza zero (predefinita) significa che tutti i sotto-identificatori devono corrispondere esattamente.

Esempio di Uso della Maschera:​

Sottoalbero del Filtro: 1.3.6.1.2.1.2.2.1.8
Maschera: 0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFE

Questa maschera permette il matching sia di 1.3.6.1.2.1.2.2.1.8 (ifOperStatus) che di 1.3.6.1.2.1.2.2.1.9 (ifLastChange), perché l'ultimo bit del sotto-identificatore finale è wildcard.

Esempi di Configurazione​

Esempio 1: Invio di Tutte le Notifiche a un Management Target​

Per inviare tutte le notifiche a un management target senza filtraggio:

  1. Non creare una voce in snmpNotifyFilterProfileTable per il nome dei parametri del target.

OPPURE

  1. Creare un profilo di filtro con un singolo filtro inclusivo:
    • snmpNotifyFilterSubtree: 1 (o qualsiasi OID radice)
    • snmpNotifyFilterMask: "" (vuoto)
    • snmpNotifyFilterType: included(1)

Esempio 2: Invio Solo di Notifiche Relative alle Interfacce​

Per inviare solo notifiche relative alle interfacce (ifTable):

Voce snmpNotifyFilterProfileTable:

  • snmpNotifyFilterProfileName: "interfaceFilter"
  • Associato al nome dei parametri target: "stationAParams"

Voci snmpNotifyFilterTable:

Voce 1:

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

Questa configurazione permette l'invio di notifiche contenenti variabili dal gruppo interfaces (1.3.6.1.2.1.2), mentre filtra tutte le altre notifiche.

Esempio 3: Esclusione di Notifiche Specifiche​

Per inviare tutte le notifiche eccetto quelle relative alla tabella di connessione TCP:

Voce snmpNotifyFilterProfileTable:

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • Associato al nome dei parametri target: "stationBParams"

Voci snmpNotifyFilterTable:

Voce 1:

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

Voce 2:

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

Questa configurazione include tutte le notifiche (Voce 1), ma esclude esplicitamente quelle contenenti variabili da tcpConnTable (Voce 2).

Considerazioni di Implementazione​

Performance​

Il filtraggio delle notifiche richiede confronti di OID per ogni variable-binding contro potenzialmente più voci di filtro. Le implementazioni dovrebbero ottimizzare questo processo:

  • Utilizzare strutture dati efficienti (ad es. trie o tabelle hash) per le ricerche di OID.
  • Memorizzare nella cache le ricerche di profili di filtro per management target utilizzati frequentemente.
  • Considerare la pre-compilazione delle regole di filtro al momento della configurazione.

Ordine dei Filtri​

Le voci di filtro vengono processate in ordine lessicografico dei loro indici. Questo significa:

  • Le esclusioni più specifiche (OID più lungo) dovrebbero essere configurate appropriatamente rispetto alle inclusioni più ampie.
  • L'ordine delle voci di filtro può influenzare il risultato del filtraggio.

Comportamento Predefinito​

Se non esiste alcun profilo di filtro per i parametri di un target:

  • Il comportamento predefinito è di inviare la notifica (nessun filtraggio).
  • Questo assicura la retrocompatibilità con sistemi che non utilizzano il filtraggio delle notifiche.

Requisiti Variable-Binding​

RFC 3416 richiede che le notifiche includano almeno due variable-binding:

  1. sysUpTime.0
  2. snmpTrapOID.0

Questi variable-binding obbligatori devono passare il filtro affinché la notifica venga inviata. Se il filtro esclude questi OID, la notifica non verrà inviata a quel management target.

Considerazioni di Sicurezza​

Il filtraggio delle notifiche può impattare la sicurezza in diversi modi:

  1. Prevenzione della Divulgazione di Informazioni: Il filtraggio può prevenire l'invio di informazioni sensibili a stazioni di gestione non autorizzate.

  2. Protezione della Configurazione: Le tabelle di configurazione del filtro (snmpNotifyFilterProfileTable e snmpNotifyFilterTable) dovrebbero essere protette dal controllo degli accessi per prevenire modifiche non autorizzate.

  3. Bypass del Filtro: Una configurazione del filtro inappropriata (ad es. regole di inclusione troppo ampie) può permettere l'invio di notifiche non intenzionali.

  4. Denial of Service: Regole di filtro eccessivamente complesse possono consumare risorse di processamento eccessive, causando potenzialmente un denial of service.

Si raccomanda di utilizzare il filtraggio delle notifiche in congiunzione con un appropriato controllo degli accessi (come VACM) e le funzionalità di sicurezza SNMPv3 per garantire una sicurezza completa.