1.5. Protection against Message Replay, Delay and Redirection (Protection contre la relecture, le délai et la redirection des messages)

1.5. Protection against Message Replay, Delay and Redirection (Protection contre la relecture, le délai et la redirection des messages)

Le modèle de sécurité basé sur l'utilisateur fournit une protection contre plusieurs types d'attaques basées sur les messages.

Message Replay (Relecture de message)

Menace (Threat): Un attaquant capture un message SNMP authentifié valide et le retransmet ultérieurement pour obtenir un effet non autorisé.

Mécanisme de protection (Protection Mechanism): L'USM utilise un mécanisme basé sur le temps pour détecter et rejeter les messages rejoués. Chaque moteur SNMP maintient:

1. snmpEngineBoots: Un compteur qui s'incrémente chaque fois que le moteur SNMP se réinitialise
2. snmpEngineTime: Un compteur de secondes depuis le dernier redémarrage du moteur

Ces valeurs sont incluses dans les champs msgAuthoritativeEngineBoots et msgAuthoritativeEngineTime des messages authentifiés. Le moteur récepteur vérifie que ces valeurs se situent dans une fenêtre temporelle acceptable.

Fenêtre temporelle (Time Window): Les messages sont considérés comme authentiques si:

|msgAuthoritativeEngineTime - snmpEngineTime| ≤ 150 secondes

Et:

msgAuthoritativeEngineBoots = snmpEngineBoots

Les messages en dehors de cette fenêtre sont rejetés comme rejeux potentiels.

Message Delay (Délai de message)

Menace (Threat): Un attaquant retarde la livraison d'un message valide pour qu'il soit traité à un moment inapproprié.

Mécanisme de protection (Protection Mechanism): Le même mécanisme de fenêtre temporelle qui protège contre la relecture protège également contre un délai de message significatif. Les messages retardés de plus de 150 secondes seront rejetés.

Limitations:

• Les délais dans la fenêtre de 150 secondes ne peuvent pas être détectés
• Ceci est considéré comme acceptable pour la plupart des applications de gestion de réseau
• Les applications nécessitant une synchronisation plus stricte doivent implémenter des mécanismes supplémentaires

Message Redirection (Redirection de message)

Menace (Threat): Un attaquant intercepte un message destiné à un moteur SNMP et le redirige vers un moteur SNMP différent.

Mécanisme de protection (Protection Mechanism): L'USM inclut le msgAuthoritativeEngineID dans la partie authentifiée du message. Cette valeur identifie le moteur destinataire prévu. Un moteur récepteur rejettera les messages où:

msgAuthoritativeEngineID ≠ snmpEngineID (du moteur récepteur)

Protection supplémentaire (Additional Protection): La combinaison de engineID, engineBoots et engineTime fournit une protection solide car:

1. Chaque moteur a un snmpEngineID unique
2. Les clés sont localisées à des moteurs spécifiques (voir Section 2.6)
3. Le résumé d'authentification couvre le engineID, rendant impossible la modification sans détection

Interaction of Protection Mechanisms (Interaction des mécanismes de protection)

Les trois valeurs (msgAuthoritativeEngineID, msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime) travaillent ensemble pour fournir une protection complète:

1. engineID empêche la redirection vers différents moteurs
2. engineBoots empêche la relecture des messages d'avant le dernier redémarrage du moteur
3. engineTime empêche la relecture des messages récents et détecte les délais significatifs

Limitations and Considerations (Limitations et considérations)

Clock Synchronization (Synchronisation d'horloge)

Le mécanisme de fenêtre temporelle exige que:

• Les moteurs SNMP aient des horloges raisonnablement précises
• Les horloges ne dérivent pas significativement avec le temps
• La synchronisation temporelle soit maintenue entre les moteurs communicants

Impact des problèmes d'horloge (Impact of Clock Issues):

• Horloge rapide: Peut entraîner le rejet de messages valides
• Horloge lente: Peut permettre l'acceptation de messages rejoués
• Réinitialisation de l'horloge en arrière: Nécessite l'incrémentation de snmpEngineBoots

Time Window Size (Taille de la fenêtre temporelle)

La fenêtre de 150 secondes représente un équilibre entre:

• Sécurité: Fenêtre plus petite = moins d'opportunité de relecture
• Flexibilité opérationnelle: Fenêtre plus grande = plus de tolérance pour la dérive d'horloge et les délais réseau

Justification des 150 secondes (Rationale for 150 seconds):

• Accommode les latences réseau typiques
• Tolère une dérive d'horloge modérée
• Fournit une protection raisonnable contre la relecture pour le trafic de gestion

Notification Messages (Messages de notification)

Pour les messages de notification (traps et informs):

• Le moteur autorisé est l'initiateur de notification
• Le récepteur de notification doit se synchroniser avec le temps de l'initiateur
• Ceci est l'inverse du modèle de répondeur de commandes

Discovery and Time Synchronization (Découverte et synchronisation temporelle)

Avant qu'une communication sécurisée puisse se produire:

1. Le moteur non autorisé doit découvrir le snmpEngineID du moteur autorisé
2. Le moteur non autorisé doit synchroniser ses valeurs de temps mises en cache avec le moteur autorisé

Ces processus sont décrits en détail dans la Section 4 (Découverte) et la Section 2.3 (Synchronisation temporelle).

Security Analysis (Analyse de sécurité)

La protection contre la relecture basée sur le temps de l'USM fournit:

Protection forte contre (Strong Protection Against):

• La relecture exacte d'anciens messages
• La redirection vers différents moteurs
• Les attaques de stockage à long terme et de relecture

Protection limitée contre (Limited Protection Against):

• La relecture dans la fenêtre de 150 secondes
• Les attaquants capables de manipuler les horloges des deux points de terminaison

Non protégé (Not Protected):

• La duplication de messages en temps réel (même message envoyé deux fois dans la fenêtre)
• La relecture au niveau de l'application (l'attaquant initie une nouvelle requête légitime avec le même contenu)

Ces limitations sont acceptables pour les cas d'utilisation prévus de SNMP, où les opérations de gestion sont généralement idempotentes ou où les mécanismes au niveau de l'application peuvent détecter les doublons.