Zum Hauptinhalt springen

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:

  1. snmpEngineBoots: Ein Zähler, der bei jeder Reinitialisierung der SNMP-Engine inkrementiert wird
  2. 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:

  1. Jede Engine eine eindeutige snmpEngineID hat
  2. Schlüssel auf bestimmte Engines lokalisiert sind (siehe Abschnitt 2.6)
  3. 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:

  1. engineID verhindert Umleitung zu verschiedenen Engines
  2. engineBoots verhindert Wiederholung von Nachrichten von vor dem letzten Engine-Neustart
  3. 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:

  1. Die nicht-autoritative Engine muss die snmpEngineID der autoritativen Engine entdecken
  2. 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.