11. Considerazioni sulla Sicurezza

11.1. Pratiche Raccomandate

Questa sezione descrive le pratiche che contribuiscono al funzionamento sicuro ed efficace dei meccanismi definiti in questo memorandum.

• Un motore SNMP deve scartare i messaggi di risposta SNMP che non corrispondono ad alcun messaggio di richiesta attualmente in sospeso. È responsabilità del modulo di elaborazione dei messaggi occuparsi di questo. Ad esempio, può utilizzare un msgID per questo scopo.

  Un'applicazione generatore di comandi SNMP deve scartare qualsiasi PDU di classe di risposta per cui non esiste un PDU di classe confermata attualmente in sospeso; ad esempio per i PDU SNMPv2 [RFC3416], il componente request-id nel PDU può essere utilizzato per correlare le risposte alle richieste in sospeso.

  Sebbene sarebbe tipico per un motore SNMP e un'applicazione generatore di comandi SNMP fare questo come questione di routine, quando si utilizzano questi protocolli di sicurezza è significativo a causa della possibilità di duplicazione dei messaggi (malevola o meno).

• Se un motore SNMP utilizza un msgID per correlare i messaggi di risposta ai messaggi di richiesta in sospeso, allora DEVE utilizzare msgID diversi in tutti i messaggi di richiesta che invia durante un periodo di finestra temporale (150 secondi).

  Un'applicazione generatore di comandi o originatore di notifiche DEVE utilizzare request-id diversi in tutti i PDU di richiesta che invia durante un periodo di finestra temporale (150 secondi).

  Questo deve essere fatto per proteggersi dalla possibilità di duplicazione dei messaggi (malevola o meno).

  Ad esempio, iniziare le operazioni con un valore msgID e/o request-id di zero non è una buona idea. Inizializzarli con un numero imprevedibile (in modo che non partano dallo stesso valore dopo ogni riavvio) e quindi incrementarli di uno sarebbe accettabile.

• Un motore SNMP dovrebbe eseguire la sincronizzazione temporale utilizzando messaggi autenticati per proteggersi dalla possibilità di duplicazione dei messaggi (malevola o meno).

• Quando si inviano messaggi che alterano lo stato a un motore SNMP autoritativo gestito, un'applicazione generatore di comandi dovrebbe ritardare l'invio di messaggi successivi a quel motore SNMP gestito fino a quando non viene ricevuto un riconoscimento positivo per il messaggio precedente o fino a quando il messaggio precedente scade.

  Nessun ordinamento dei messaggi è imposto da SNMP. I messaggi possono essere ricevuti in qualsiasi ordine relativo al loro tempo di generazione e ognuno verrà elaborato nell'ordine ricevuto. Si noti che quando un messaggio autenticato viene inviato a un motore SNMP gestito, sarà valido per un periodo di tempo di circa 150 secondi in circostanze normali ed è soggetto a riproduzione durante questo periodo. Infatti, un motore SNMP e applicazioni generatore di comandi SNMP devono far fronte alla perdita e al riordino dei messaggi derivanti da anomalie nella rete come questione di routine.

  Tuttavia, un oggetto gestito, snmpSetSerialNo [RFC3418], è specificamente definito per l'uso con operazioni SNMP Set al fine di fornire un meccanismo per garantire che l'elaborazione dei messaggi SNMP avvenga in un ordine specifico.

• La frequenza con cui i segreti di un utente del modello di sicurezza basato sull'utente dovrebbero essere modificati è indirettamente correlata alla frequenza del loro uso.

  Proteggere i segreti dalla divulgazione è fondamentale per la sicurezza complessiva dei protocolli. L'uso frequente di un segreto fornisce una fonte continua di dati che può essere utile a un crittoanalista nello sfruttare debolezze note o percepite in un algoritmo. Cambiamenti frequenti al segreto evitano questa vulnerabilità.

  Cambiare un segreto dopo ogni uso è generalmente considerato la pratica più sicura, ma può essere associato a una quantità significativa di overhead.

  Si noti, inoltre, in un ambiente locale la minaccia di divulgazione può essere meno significativa, e come tale il cambio dei segreti può essere meno frequente. Tuttavia, quando vengono utilizzate reti dati pubbliche come percorsi di comunicazione, è prudente maggiore cautela.

11.2 Definizione degli Utenti

I meccanismi definiti in questo documento impiegano la nozione di utenti per conto dei quali vengono inviati i messaggi. Come vengono definiti gli "utenti" è soggetto alla politica di sicurezza dell'amministrazione di rete. Ad esempio, gli utenti potrebbero essere individui (ad es., "joe" o "jane"), o un ruolo particolare (ad es., "operator" o "administrator"), o una combinazione (ad es., "joe-operator", "jane-operator" o "joe-admin"). Inoltre, un utente può essere un'entità logica, come un'applicazione SNMP o un insieme di applicazioni SNMP, che agisce per conto di un individuo o ruolo, o insieme di individui, o insieme di ruoli, incluse le combinazioni.

L'appendice A descrive un algoritmo per mappare una "password" utente su un valore di 16/20 ottetti da utilizzare come chiave di autenticazione o chiave di privacy (o entrambe) di un utente. Si noti tuttavia che l'utilizzo della stessa password (e quindi della stessa chiave) sia per l'autenticazione che per la privacy è una pratica di sicurezza molto scarsa e dovrebbe essere fortemente scoraggiato. Le password sono spesso generate, ricordate e inserite da un essere umano. Le password generate dall'uomo possono essere inferiori ai 16/20 ottetti richiesti dai protocolli di autenticazione e privacy, e gli attacchi a forza bruta possono essere piuttosto facili su un set di caratteri ASCII relativamente breve. Pertanto, l'algoritmo nell'appendice A esegue una trasformazione sulla password. Se viene utilizzato l'algoritmo dell'appendice A, le implementazioni SNMP (e le applicazioni di configurazione SNMP) devono garantire che le password siano di almeno 8 caratteri di lunghezza. Si prega di notare che password più lunghe con stringhe ripetitive possono risultare esattamente nella stessa chiave. Ad esempio, una password 'bertbert' risulterà esattamente nella stessa chiave della password 'bertbertbert'.

Poiché l'algoritmo dell'appendice A utilizza tali password (quasi) direttamente, è molto importante che non siano facilmente indovinabili. Si suggerisce che siano composte da caratteri alfanumerici maiuscoli e minuscoli e di punteggiatura che non formino parole o frasi che potrebbero essere trovate in un dizionario. Password più lunghe migliorano la sicurezza del sistema. Gli utenti potrebbero voler inserire frasi composte da più parole per rendere la loro stringa di password più lunga garantendo al contempo che sia memorabile.

Poiché è infeasibile per gli utenti umani mantenere password diverse per ogni motore SNMP, ma i requisiti di sicurezza scoraggiano fortemente di avere la stessa chiave per più di un motore SNMP, il modello di sicurezza basato sull'utente impiega un compromesso proposto in [Localized-key]. Deriva le chiavi utente per i motori SNMP dalla password dell'utente in modo tale che sia praticamente impossibile determinare la password dell'utente o la chiave dell'utente per un altro motore SNMP da qualsiasi combinazione di chiavi dell'utente sui motori SNMP.

Si noti tuttavia che se la password dell'utente viene divulgata, la localizzazione delle chiavi non aiuterà e la sicurezza della rete potrebbe essere compromessa in questo caso. Pertanto la password di un utente o la chiave non localizzata NON DEVE essere memorizzata su un dispositivo/nodo gestito. Invece la chiave localizzata DEVE essere memorizzata (se del tutto), in modo che, nel caso in cui un dispositivo venga compromesso, nessun altro dispositivo gestito o di gestione venga compromesso.

11.3. Conformità

Per essere definita un'"implementazione SNMP sicura" basata sul modello di sicurezza basato sull'utente, un'implementazione SNMP DEVE:

• implementare uno o più protocolli di autenticazione. I protocolli di autenticazione HMAC-MD5-96 e HMAC-SHA-96 definiti in questo memorandum sono esempi di tali protocolli.

• nella massima misura possibile, proibire l'accesso ai segreti di ciascun utente di cui mantiene informazioni in un archivio dati di configurazione locale (LCD) in tutte le circostanze tranne quando richiesto per generare e/o convalidare i messaggi SNMP rispetto a quell'utente.

• implementare il meccanismo di localizzazione delle chiavi.

• implementare lo SNMP-USER-BASED-SM-MIB.

Inoltre, un motore SNMP autoritativo DOVREBBE fornire la configurazione iniziale in conformità con l'appendice A.1.

L'implementazione di un protocollo di privacy (il protocollo di crittografia simmetrica DES definito in questo memorandum è uno di questi protocolli) è facoltativa.

11.4. Uso dei Rapporti

L'uso di rapporti non sicuri (cioè, inviarli con un securityLevel di noAuthNoPriv) espone potenzialmente un motore SNMP non autoritativo a qualche forma di attacco. Alcune persone considerano questi attacchi di tipo denial of service, altre no. Un'installazione dovrebbe valutare il rischio coinvolto prima di distribuire PDU di rapporto non sicuri.

11.5 Accesso allo SNMP-USER-BASED-SM-MIB

Gli oggetti in questo MIB possono essere considerati sensibili in molti ambienti. Specificamente gli oggetti nella usmUserTable contengono informazioni sugli utenti e sui loro protocolli di autenticazione e privacy. È importante controllare strettamente (sia in lettura che in scrittura) l'accesso a questi oggetti MIB utilizzando modelli di controllo degli accessi configurati in modo appropriato (ad esempio il modello di controllo degli accessi basato sulla vista come specificato in [RFC3415]).