8. Security Considerations
8. Security Considerations
Il existe un certain nombre d'objets de gestion définis dans ce module MIB avec une clause MAX-ACCESS de read-write et/ou read-create. De tels objets peuvent être considérés comme sensibles ou vulnérables dans certains environnements réseau. Le support des opérations SET dans un environnement non sécurisé sans protection appropriée peut avoir un effet négatif sur les opérations réseau. Voici les tables et objets et leur sensibilité/vulnérabilité:
ipForwarding et ipv6IpForwarding - ces objets permettent à un gestionnaire d'activer ou de désactiver les fonctions de routage sur l'entité. En désactivant les fonctions de routage, un attaquant pourrait éventuellement refuser le service aux utilisateurs. En activant les fonctions de routage, un attaquant pourrait ouvrir un conduit vers une zone. Cela pourrait résulter en ce que la zone fournisse un transit pour des paquets qu'elle ne devrait pas ou pourrait permettre à l'attaquant d'accéder à la zone en contournant les protections de sécurité.
ipDefaultTTL et ipv6IpDefaultHopLimit - ces objets permettent à un gestionnaire de déterminer le diamètre de la zone valide pour un paquet. En diminuant la valeur de ces objets, un attaquant pourrait causer le rejet des paquets avant qu'ils n'atteignent leurs destinations.
ipv4InterfaceEnableStatus et ipv6InterfaceEnableStatus - ces objets permettent à un gestionnaire d'activer ou de désactiver IPv4 et IPv6 sur une interface spécifique. En activant un protocole sur une interface, un attaquant pourrait être capable de créer un chemin non sécurisé vers un nœud (ou à travers celui-ci si le routage est également activé). En désactivant un protocole sur une interface, un attaquant pourrait être capable de forcer les paquets à être routés via une autre interface ou de refuser l'accès à tout ou partie du réseau via ce protocole.
ipAddressTable - les objets de cette table spécifient les adresses en cours d'utilisation sur ce nœud. En modifiant ces informations, un attaquant peut amener un nœud à ignorer les messages qui lui sont destinés ou à accepter (au moins au niveau de la couche IP) des messages qu'il ignorerait autrement. L'utilisation de filtrage ou d'associations de sécurité peut réduire les dommages potentiels dans ce dernier cas.
ipv6RouterAdvertTable - les objets de cette table spécifient les informations qu'un routeur devrait propager dans ses messages d'annonce de routeur. En modifiant ces informations, un attaquant peut interférer avec l'auto-configuration de tous les hôtes sur le lien. La plupart des modifications de cette table entraîneront un déni de service pour certains ou tous les hôtes sur le lien. Cependant, deux objets, ipv6RouterAdvertManagedFlag et ipv6RouterAdvertOtherConfigFlag, indiquent si un hôte devrait acquérir des informations de configuration d'une autre source. En activant ceux-ci, un attaquant pourrait être capable de faire en sorte qu'un hôte récupère ses informations de configuration d'une source compromise.
ipNetToPhysicalPhysAddress et ipNetToPhysicalType - ces objets spécifient les informations utilisées pour traduire une adresse réseau (IP) en une adresse dépendante du média. En modifiant ces objets, un attaquant pourrait désactiver la communication avec un nœud ou détourner des messages d'un nœud vers un autre. Cependant, l'attaquant peut être capable de mener une attaque similaire en répondant simplement à la requête ARP ou ND faite par le nœud cible.
Certains des objets lisibles dans ce module MIB (c'est-à-dire les objets avec un MAX-ACCESS autre que not-accessible) peuvent être considérés comme sensibles ou vulnérables dans certains environnements réseau. Il est donc important de contrôler même l'accès GET à ces objets et éventuellement de chiffrer les valeurs de ces objets lors de leur envoi sur le réseau via SNMP.
Voici les tables et objets et leur sensibilité/vulnérabilité:
Essentiellement, tous les objets de cette MIB pourraient être considérés comme sensibles car ils rapportent l'état des modules IP au sein d'un système. Cependant, la ipSystemStatsTable, la ipIfStatsTable et la ipAddressTable sont susceptibles d'être les plus intéressantes pour un attaquant. Les tables de statistiques fournissent des informations sur la quantité et le type de trafic que ce nœud traite et, en particulier pour les fournisseurs de transit, peuvent être considérées comme sensibles. La table d'adresses fournit une liste pratique de toutes les adresses utilisées par ce nœud. Chaque adresse isolément est banale, cependant, la liste totale permettrait à un attaquant de corréler un trafic autrement non lié. Par exemple, un attaquant pourrait être capable de corréler une adresse privée RFC 3041 [15] avec des adresses publiques connues, contournant ainsi les intentions de la RFC 3041.
Les versions SNMP antérieures à SNMPv3 n'incluaient pas de sécurité adéquate. Même si le réseau lui-même est sécurisé (par exemple en utilisant IPSec), même alors, il n'y a aucun contrôle sur qui sur le réseau sécurisé est autorisé à accéder et GET/SET (lire/modifier/créer/supprimer) les objets dans ce module MIB.
Il est RECOMMANDÉ que les implémenteurs considèrent les fonctionnalités de sécurité fournies par le framework SNMPv3 (voir [9], section 8), y compris le support complet des mécanismes cryptographiques SNMPv3 (pour l'authentification et la confidentialité).
De plus, le déploiement de versions SNMP antérieures à SNMPv3 n'est PAS RECOMMANDÉ. Au lieu de cela, il est RECOMMANDÉ de déployer SNMPv3 et d'activer la sécurité cryptographique. Il incombe alors au client/opérateur de s'assurer que l'entité SNMP donnant accès à une instance de ce module MIB est correctement configurée pour donner accès aux objets uniquement aux principaux (utilisateurs) qui ont des droits légitimes pour effectivement GET ou SET (modifier/créer/supprimer) ceux-ci.