1.5. Protection against Message Replay, Delay and Redirection (Protezione contro replay, ritardo e reindirizzamento dei messaggi)

Il modello di sicurezza basato sull'utente fornisce protezione contro diversi tipi di attacchi basati sui messaggi.

Message Replay (Replay dei messaggi)

Minaccia (Threat): Un attaccante cattura un messaggio SNMP autenticato valido e lo ritrasmette in un momento successivo per ottenere un effetto non autorizzato.

Meccanismo di protezione (Protection Mechanism): L'USM utilizza un meccanismo basato sul tempo per rilevare e rifiutare i messaggi riprodotti. Ogni motore SNMP mantiene:

snmpEngineBoots: Un contatore che si incrementa ogni volta che il motore SNMP si reinizializza
snmpEngineTime: Un contatore di secondi dall'ultimo riavvio del motore

Questi valori sono inclusi nei campi msgAuthoritativeEngineBoots e msgAuthoritativeEngineTime dei messaggi autenticati. Il motore ricevente verifica che questi valori rientrino in una finestra temporale accettabile.

Finestra temporale (Time Window): I messaggi sono considerati autentici se:

|msgAuthoritativeEngineTime - snmpEngineTime| ≤ 150 secondi

msgAuthoritativeEngineBoots = snmpEngineBoots

I messaggi al di fuori di questa finestra vengono rifiutati come potenziali replay.

Message Delay (Ritardo dei messaggi)

Minaccia (Threat): Un attaccante ritarda la consegna di un messaggio valido per farlo elaborare in un momento inappropriato.

Meccanismo di protezione (Protection Mechanism): Lo stesso meccanismo di finestra temporale che protegge contro il replay protegge anche contro ritardi significativi dei messaggi. I messaggi ritardati di oltre 150 secondi verranno rifiutati.

Limitazioni (Limitations):

I ritardi all'interno della finestra di 150 secondi non possono essere rilevati
Questo è considerato accettabile per la maggior parte delle applicazioni di gestione di rete
Le applicazioni che richiedono una sincronizzazione più rigorosa devono implementare meccanismi aggiuntivi

Message Redirection (Reindirizzamento dei messaggi)

Minaccia (Threat): Un attaccante intercetta un messaggio destinato a un motore SNMP e lo reindirizza a un motore SNMP diverso.

Meccanismo di protezione (Protection Mechanism): L'USM include il msgAuthoritativeEngineID nella parte autenticata del messaggio. Questo valore identifica il motore destinatario previsto. Un motore ricevente rifiuterà i messaggi dove:

msgAuthoritativeEngineID ≠ snmpEngineID (del motore ricevente)

Protezione aggiuntiva (Additional Protection): La combinazione di engineID, engineBoots ed engineTime fornisce una protezione forte perché:

Ogni motore ha un snmpEngineID unico
Le chiavi sono localizzate su motori specifici (vedere Sezione 2.6)
Il digest di autenticazione copre l'engineID, rendendo impossibile la modifica senza rilevamento

Interaction of Protection Mechanisms (Interazione dei meccanismi di protezione)

I tre valori (msgAuthoritativeEngineID, msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime) lavorano insieme per fornire una protezione completa:

engineID impedisce il reindirizzamento a motori diversi
engineBoots impedisce il replay di messaggi precedenti all'ultimo riavvio del motore
engineTime impedisce il replay di messaggi recenti e rileva ritardi significativi

Limitations and Considerations (Limitazioni e considerazioni)

Clock Synchronization (Sincronizzazione dell'orologio)

Il meccanismo della finestra temporale richiede che:

I motori SNMP abbiano orologi ragionevolmente accurati
Gli orologi non derivino significativamente nel tempo
La sincronizzazione temporale sia mantenuta tra i motori comunicanti

Impatto dei problemi di orologio (Impact of Clock Issues):

Orologio veloce: Può causare il rifiuto di messaggi validi
Orologio lento: Può consentire l'accettazione di messaggi riprodotti
Ripristino dell'orologio all'indietro: Richiede l'incremento di snmpEngineBoots

Time Window Size (Dimensione della finestra temporale)

La finestra di 150 secondi rappresenta un equilibrio tra:

Sicurezza: Finestra più piccola = meno opportunità di replay
Flessibilità operativa: Finestra più grande = maggiore tolleranza per la deriva dell'orologio e i ritardi di rete

Motivazione per 150 secondi (Rationale for 150 seconds):

Accomoda le latenze di rete tipiche
Tollera una deriva moderata dell'orologio
Fornisce una protezione ragionevole contro il replay per il traffico di gestione

Notification Messages (Messaggi di notifica)

Per i messaggi di notifica (trap e inform):

Il motore autorevole è l'iniziatore della notifica
Il ricevitore della notifica deve sincronizzarsi con il tempo dell'iniziatore
Questo è l'opposto del modello di risponditore di comandi

Discovery and Time Synchronization (Scoperta e sincronizzazione temporale)

Prima che possa avvenire una comunicazione sicura:

Il motore non autorevole deve scoprire lo snmpEngineID del motore autorevole
Il motore non autorevole deve sincronizzare i suoi valori temporali memorizzati nella cache con il motore autorevole

Questi processi sono descritti in dettaglio nella Sezione 4 (Scoperta) e nella Sezione 2.3 (Sincronizzazione temporale).

Security Analysis (Analisi della sicurezza)

La protezione contro il replay basata sul tempo dell'USM fornisce:

Protezione forte contro (Strong Protection Against):

Replay esatto di vecchi messaggi
Reindirizzamento a motori diversi
Attacchi di archiviazione a lungo termine e replay

Protezione limitata contro (Limited Protection Against):

Replay all'interno della finestra di 150 secondi
Attaccanti con la capacità di manipolare gli orologi di entrambi gli endpoint

Non protetto (Not Protected):

Duplicazione di messaggi in tempo reale (stesso messaggio inviato due volte all'interno della finestra)
Replay a livello di applicazione (l'attaccante avvia una nuova richiesta legittima con lo stesso contenuto)

Queste limitazioni sono accettabili per i casi d'uso previsti di SNMP, dove le operazioni di gestione sono generalmente idempotenti o dove i meccanismi a livello di applicazione possono rilevare i duplicati.