10. Security Considerations

Ce document définit des mécanismes de configuration du comportement des applications SNMP. Ces applications peuvent être associées à un moteur SNMP qui fournit une communication sécurisée lors de l'utilisation des fonctionnalités de sécurité SNMPv3.

Cependant, plusieurs considérations de sécurité doivent être prises en compte :

10.1. Sécurité de configuration

Les modules MIB définis dans ce document (SNMP-TARGET-MIB, SNMP-NOTIFICATION-MIB et SNMP-PROXY-MIB) contiennent des informations de configuration qui affectent directement la posture de sécurité des communications SNMP :

Objets sensibles

Plusieurs objets contiennent ou référencent des informations de sécurité sensibles :

• snmpTargetParamsSecurityName : Contient des informations d'identification de sécurité (chaînes de communauté pour SNMPv1/v2c, noms d'utilisateur pour SNMPv3).
• snmpTargetParamsSecurityModel et snmpTargetParamsSecurityLevel : Définissent les mécanismes de sécurité et les niveaux de protection utilisés.
• snmpProxyTargetParamsIn : Référence les paramètres de sécurité pour les messages entrants vers le proxy.

Ces objets devraient être protégés avec des contrôles d'accès appropriés pour empêcher :

• Divulgation non autorisée : Lecture de noms de sécurité/chaînes de communauté.
• Modification non autorisée : Modification des paramètres de sécurité pour affaiblir la sécurité ou rediriger le trafic.

Contrôle d'accès recommandé

Il est RECOMMANDÉ que les entités SNMP implémentant les modules MIB dans ce document :

1. Utilisent les fonctionnalités de sécurité SNMPv3 (USM) pour tous les accès de gestion à ces objets MIB.
2. Configurent VACM (View-based Access Control Model) pour restreindre l'accès à ces objets aux administrateurs de sécurité autorisés uniquement.
3. Utilisent l'authentification et le chiffrement (niveau de sécurité authPriv) lors de l'accès à des objets sensibles à la sécurité.

10.2. Sécurité de notification

Divulgation d'informations

Les notifications peuvent contenir des informations sensibles sur le système géré. Une configuration inappropriée des cibles de notification peut conduire à :

• L'envoi de notifications à des destinataires non autorisés.
• L'exposition de données opérationnelles sensibles ou d'événements de sécurité.
• La fuite d'informations sur la topologie réseau ou les vulnérabilités.

Atténuation :

• Utiliser le filtrage de notification pour contrôler quelles informations sont envoyées à quelles cibles.
• Configurer les cibles de notification pour utiliser SNMPv3 avec authentification et chiffrement.
• Auditer régulièrement snmpTargetAddrTable pour s'assurer que les notifications sont uniquement envoyées à des stations de gestion autorisées.

Usurpation de notification

Sans sécurité appropriée, les notifications peuvent être usurpées par des attaquants :

• Les fausses notifications peuvent causer de fausses alarmes ou masquer de réels incidents de sécurité.
• Les acteurs malveillants peuvent manipuler les systèmes de gestion en envoyant des notifications falsifiées.

Atténuation :

• Les récepteurs de notification devraient utiliser les fonctionnalités de sécurité SNMPv3 pour authentifier la source des notifications.
• Utiliser les requêtes inform (plutôt que les traps) pour assurer une livraison fiable et permettre l'authentification.
• Implémenter la limitation de débit et la détection d'anomalies pour identifier les motifs de notification suspects.

10.3. Sécurité du transfert par proxy

Les proxy forwarders introduisent des considérations de sécurité supplémentaires :

Dégradation du niveau de sécurité

Les proxies peuvent traduire entre différentes versions SNMP, dégradant potentiellement la sécurité :

• SNMPv3 (authPriv) vers SNMPv1 (pas de sécurité) : Expose le trafic authentifié et chiffré en texte clair.
• Perte d'authentification : La cible ne peut pas vérifier la vraie source de la requête.

Atténuation :

• Éviter les dégradations de sécurité autant que possible. Déployer SNMPv3 de bout en bout.
• Si la dégradation est nécessaire, utiliser des contrôles compensatoires (par ex. IPsec, sécurité physique).
• Enregistrer toutes les dégradations de sécurité à des fins d'audit.
• Restreindre quelles opérations peuvent être dégradées en utilisant le contrôle d'accès.

Attaques de l'homme du milieu

Les proxies se trouvent dans le chemin de communication et pourraient potentiellement :

• Intercepter et lire des informations sensibles.
• Modifier les requêtes ou réponses.
• Usurper l'identité du générateur de commandes ou du répondeur de commandes.

Atténuation :

• Les proxies devraient être déployés dans des environnements sécurisés et contrôlés.
• Utiliser la sécurité SNMPv3 des deux côtés du proxy (générateur de commandes vers proxy, proxy vers répondeur de commandes).
• Implémenter des contrôles d'accès stricts sur la configuration du proxy.
• Surveiller et auditer l'activité du proxy.

Vulnérabilités de traduction de contexte

Une traduction de contexte inappropriée dans les proxies peut conduire à :

• Accéder à des informations de gestion non intentionnelles.
• Contourner les contrôles d'accès si différents contextes ont des politiques d'accès différentes.

Atténuation :

• Configurer soigneusement les entrées snmpProxyTable pour assurer une cartographie de contexte correcte.
• Appliquer des politiques de contrôle d'accès cohérentes dans tous les contextes.
• Réviser et auditer régulièrement les règles de traduction de contexte.

10.4. Considérations de déni de service

Les fonctionnalités définies dans ce document peuvent être abusées pour causer un déni de service :

Épuisement des ressources

• Notifications excessives : Configurer de nombreuses cibles de notification peut submerger l'émetteur de notification.
• Règles de filtrage complexes : Les opérations de filtre coûteuses en calcul peuvent consommer un CPU excessif.
• Amplification proxy : Une seule requête à un proxy configuré avec transfert vers cibles multiples peut générer de nombreuses requêtes sortantes.

Atténuation :

• Implémenter la limitation de débit sur la génération de notification et le transfert par proxy.
• Définir des limites raisonnables sur le nombre de cibles configurées.
• Optimiser le traitement des filtres et envisager de limiter la complexité des filtres.
• Surveiller l'utilisation des ressources et alerter sur les anomalies.

Inondation réseau

• Les cibles de notification mal configurées peuvent inonder le réseau de trafic.
• Les boucles de proxy (où les proxies transfèrent l'un vers l'autre) peuvent causer des tempêtes de messages.

Atténuation :

• Valider les adresses cibles lors de la configuration.
• Implémenter des mécanismes de détection de boucle dans les proxy forwarders.
• Utiliser des mécanismes TTL ou de comptage de sauts pour empêcher le transfert infini.

10.5. Considérations de version SNMP

Limitations de SNMPv1 et SNMPv2c

SNMPv1 et SNMPv2c utilisent des chaînes de communauté pour l'authentification :

• Les chaînes de communauté sont transmises en texte clair et sont vulnérables à l'écoute.
• L'authentification basée sur la communauté est faible et facilement compromise.
• Pas de protection d'intégrité : Les messages peuvent être modifiés en transit sans détection.

Recommandation :

Il est FORTEMENT RECOMMANDÉ que les déploiements utilisent SNMPv3 avec USM pour toutes les communications SNMP. SNMPv1 et SNMPv2c ne devraient être utilisés que dans des environnements contrôlés où :

• Le réseau est physiquement sécurisé.
• Le trafic est protégé par d'autres moyens (par ex. VPN, IPsec).
• Les dispositifs hérités ne peuvent pas être mis à niveau vers SNMPv3.

Sécurité SNMPv3

SNMPv3 avec USM fournit :

• Authentification : Vérifie la source des messages en utilisant HMAC-MD5 ou HMAC-SHA.
• Chiffrement : Protège la confidentialité des messages en utilisant DES ou AES.
• Fraîcheur : Protège contre les attaques par rejeu en utilisant des horodatages.

Cependant, la sécurité SNMPv3 dépend d'une configuration appropriée :

• Utiliser des protocoles d'authentification forts (HMAC-SHA préféré à HMAC-MD5).
• Utiliser un chiffrement fort (AES préféré à DES).
• Gérer correctement les clés cryptographiques (clés fortes, rotation régulière).
• Synchroniser les horloges pour empêcher l'exploitation de la fenêtre de fraîcheur.

10.6. Résumé des recommandations de sécurité

1. Utiliser SNMPv3 avec USM pour toutes les communications SNMP impliquant les modules MIB définis dans ce document.

2. Configurer VACM pour restreindre l'accès aux objets sensibles à la sécurité aux administrateurs autorisés uniquement.

3. Utiliser l'authentification et le chiffrement (authPriv) lors de l'accès ou de la transmission d'informations sensibles.

4. Configurer soigneusement les cibles de notification et utiliser le filtrage de notification pour empêcher la divulgation d'informations.

5. Éviter les dégradations de sécurité dans les proxy forwarders ; si inévitable, utiliser des contrôles compensatoires et auditer toutes les dégradations.

6. Déployer les proxies dans des environnements sécurisés avec des contrôles d'accès stricts et une surveillance.

7. Implémenter la limitation de débit pour empêcher les attaques par déni de service.

8. Auditer régulièrement la configuration des cibles, notifications, filtres et règles de proxy.

9. Utiliser les requêtes inform au lieu des traps pour les notifications critiques afin d'assurer une livraison fiable et authentifiée.

10. Suivre les meilleures pratiques de sécurité telles que décrites dans RFC 3410 (Applicability Statements for the Internet-Standard Management Framework).