1.5. Protection against Message Replay, Delay and Redirection (Schutz vor Nachrichtenwiederholung, Verzögerung und Umleitung)
1.5. Protection against Message Replay, Delay and Redirection (Schutz vor Nachrichtenwiederholung, Verzögerung und Umleitung)
Das benutzerbasierte Sicherheitsmodell bietet Schutz vor mehreren Arten nachrichtenbasierter Angriffe.
Message Replay (Nachrichtenwiederholung)
Bedrohung (Threat): Ein Angreifer erfasst eine gültige authentifizierte SNMP-Nachricht und überträgt sie zu einem späteren Zeitpunkt erneut, um eine nicht autorisierte Wirkung zu erzielen.
Schutzmechanismus (Protection Mechanism): USM verwendet einen zeitbasierten Mechanismus, um wiederholte Nachrichten zu erkennen und abzulehnen. Jede SNMP-Engine verwaltet:
- snmpEngineBoots: Ein Zähler, der bei jeder Reinitialisierung der SNMP-Engine inkrementiert wird
- snmpEngineTime: Ein Zähler der Sekunden seit dem letzten Engine-Neustart
Diese Werte sind in den Feldern msgAuthoritativeEngineBoots und msgAuthoritativeEngineTime authentifizierter Nachrichten enthalten. Die empfangende Engine überprüft, ob diese Werte innerhalb eines akzeptablen Zeitfensters liegen.
Zeitfenster (Time Window): Nachrichten werden als authentisch betrachtet, wenn:
|msgAuthoritativeEngineTime - snmpEngineTime| ≤ 150 Sekunden
Und:
msgAuthoritativeEngineBoots = snmpEngineBoots
Nachrichten außerhalb dieses Fensters werden als potenzielle Wiederholungen abgelehnt.
Message Delay (Nachrichtenverzögerung)
Bedrohung (Threat): Ein Angreifer verzögert die Zustellung einer gültigen Nachricht, damit sie zu einem unangemessenen Zeitpunkt verarbeitet wird.
Schutzmechanismus (Protection Mechanism): Derselbe Zeitfenstermechanismus, der vor Wiederholung schützt, schützt auch vor erheblicher Nachrichtenverzögerung. Nachrichten, die um mehr als 150 Sekunden verzögert werden, werden abgelehnt.
Einschränkungen (Limitations):
- Verzögerungen innerhalb des 150-Sekunden-Fensters können nicht erkannt werden
- Dies wird für die meisten Netzwerkverwaltungsanwendungen als akzeptabel angesehen
- Anwendungen, die strengere Zeitsteuerung erfordern, müssen zusätzliche Mechanismen implementieren
Message Redirection (Nachrichtenumleitung)
Bedrohung (Threat): Ein Angreifer fängt eine Nachricht ab, die für eine SNMP-Engine bestimmt ist, und leitet sie an eine andere SNMP-Engine um.
Schutzmechanismus (Protection Mechanism): USM enthält die msgAuthoritativeEngineID im authentifizierten Teil der Nachricht. Dieser Wert identifiziert die beabsichtigte Empfänger-Engine. Eine empfangende Engine lehnt Nachrichten ab, bei denen:
msgAuthoritativeEngineID ≠ snmpEngineID (der empfangenden Engine)
Zusätzlicher Schutz (Additional Protection): Die Kombination von engineID, engineBoots und engineTime bietet starken Schutz, weil:
- Jede Engine eine eindeutige
snmpEngineIDhat - Schlüssel auf bestimmte Engines lokalisiert sind (siehe Abschnitt 2.6)
- Der Authentifizierungs-Digest die engineID abdeckt, was eine Änderung ohne Erkennung unmöglich macht
Interaction of Protection Mechanisms (Interaktion der Schutzmechanismen)
Die drei Werte (msgAuthoritativeEngineID, msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime) arbeiten zusammen, um umfassenden Schutz zu bieten:
- engineID verhindert Umleitung zu verschiedenen Engines
- engineBoots verhindert Wiederholung von Nachrichten von vor dem letzten Engine-Neustart
- engineTime verhindert Wiederholung aktueller Nachrichten und erkennt erhebliche Verzögerungen
Limitations and Considerations (Einschränkungen und Überlegungen)
Clock Synchronization (Uhrsynchronisation)
Der Zeitfenstermechanismus erfordert, dass:
- SNMP-Engines einigermaßen genaue Uhren haben
- Uhren nicht erheblich über die Zeit driften
- Zeitsynchronisation zwischen kommunizierenden Engines aufrechterhalten wird
Auswirkungen von Uhrproblemen (Impact of Clock Issues):
- Schnelle Uhr: Kann dazu führen, dass gültige Nachrichten abgelehnt werden
- Langsame Uhr: Kann dazu führen, dass wiederholte Nachrichten akzeptiert werden
- Uhr zurückgesetzt: Erfordert Inkrementierung von
snmpEngineBoots
Time Window Size (Zeitfenstergröße)
Das 150-Sekunden-Fenster stellt ein Gleichgewicht dar zwischen:
- Sicherheit: Kleineres Fenster = weniger Gelegenheit zur Wiederholung
- Betriebliche Flexibilität: Größeres Fenster = mehr Toleranz für Uhrdrift und Netzwerkverzögerungen
Begründung für 150 Sekunden (Rationale for 150 seconds):
- Berücksichtigt typische Netzwerklatenzen
- Toleriert moderate Uhrdrift
- Bietet angemessenen Wiederholungsschutz für Verwaltungsverkehr
Notification Messages (Benachrichtigungsnachrichten)
Für Benachrichtigungsnachrichten (Traps und Informs):
- Die autoritative Engine ist der Benachrichtigungsinitiator
- Der Benachrichtigungsempfänger muss sich mit der Zeit des Initiators synchronisieren
- Dies ist das Gegenteil des Befehlsresponder-Modells
Discovery and Time Synchronization (Entdeckung und Zeitsynchronisation)
Bevor sichere Kommunikation stattfinden kann:
- Die nicht-autoritative Engine muss die
snmpEngineIDder autoritativen Engine entdecken - Die nicht-autoritative Engine muss ihre zwischengespeicherten Zeitwerte mit der autoritativen Engine synchronisieren
Diese Prozesse werden ausführlich in Abschnitt 4 (Entdeckung) und Abschnitt 2.3 (Zeitsynchronisation) beschrieben.
Security Analysis (Sicherheitsanalyse)
Der zeitbasierte Wiederholungsschutz von USM bietet:
Starker Schutz vor (Strong Protection Against):
- Exakter Wiederholung alter Nachrichten
- Umleitung zu verschiedenen Engines
- Langzeitspeicher- und Wiederholungsangriffen
Begrenzter Schutz vor (Limited Protection Against):
- Wiederholung innerhalb des 150-Sekunden-Fensters
- Angreifern mit der Fähigkeit, die Uhren beider Endpunkte zu manipulieren
Nicht geschützt (Not Protected):
- Echtzeit-Nachrichtenduplizierung (dieselbe Nachricht zweimal innerhalb des Fensters gesendet)
- Wiederholung auf Anwendungsebene (Angreifer initiiert eine legitime neue Anfrage mit demselben Inhalt)
Diese Einschränkungen sind für die beabsichtigten Anwendungsfälle von SNMP akzeptabel, bei denen Verwaltungsoperationen im Allgemeinen idempotent sind oder bei denen Mechanismen auf Anwendungsebene Duplikate erkennen können.