23. Security Considerations (Considérations de sécurité)
23. Security Considerations (Considérations de sécurité)
La menace pour DHCP est intrinsèquement une menace interne (en supposant un réseau correctement configuré où les ports DHCPv6 sont bloqués sur les passerelles périphériques de l'entreprise). Indépendamment de la configuration de la passerelle, cependant, les attaques potentielles par des acteurs internes et externes sont les mêmes.
L'utilisation de clés pré-partagées configurées manuellement pour IPsec entre les agents de relais et les serveurs ne défend pas contre les messages DHCP rejoués. Les messages rejoués peuvent représenter une attaque DOS via l'épuisement des ressources de traitement, mais pas via une mauvaise configuration ou l'épuisement d'autres ressources telles que les adresses attribuables.
Une attaque spécifique à un client DHCP est la création d'un serveur malveillant dans le but de fournir de mauvaises informations de configuration au client. La raison de le faire peut être de monter une attaque « man in the middle » qui amène le client à communiquer avec un serveur malveillant au lieu d'un serveur valide pour certains services tels que DNS ou NTP. Le serveur malveillant peut également monter une attaque par déni de service via une mauvaise configuration du client qui provoque l'échec de toutes les communications réseau du client.
Il existe une autre menace pour les clients DHCP constituée par des serveurs DHCP configurés par erreur ou accidentellement qui répondent aux requêtes des clients DHCP avec des paramètres de configuration involontairement erronés.
Un client DHCP peut également être la cible d'une attaque via la réception d'un message Reconfigure provenant d'un serveur malveillant qui amène le client à obtenir de mauvaises informations de configuration de ce serveur. Notez que bien qu'un client envoie sa propre réponse (message Renew ou Information-request) via un agent de relais et, par conséquent, cette réponse ne sera reçue que par les serveurs vers lesquels les messages DHCP sont relayés, un serveur malveillant pourrait envoyer un message Reconfigure à un client, suivi (après un délai approprié) d'un message Reply qui serait accepté par le client. Ainsi, un serveur malveillant ne se trouvant pas sur le chemin réseau entre le client et le serveur peut néanmoins être en mesure de monter une attaque Reconfigure sur un client. L'utilisation d'ID de transaction qui sont valides cryptographiquement et non facilement prévisibles réduira également la probabilité qu'une telle attaque réussisse.
La menace spécifique pour un serveur DHCP est un client non valide qui usurpe l'identité d'un client valide. La raison de le faire peut être le vol de service, ou pour contourner l'enregistrement pour un nombre quelconque de buts malveillants.
La menace commune tant au client qu'au serveur est l'attaque par « déni de service » (DoS) sur les ressources. Ces attaques impliquent typiquement l'épuisement des adresses disponibles, ou l'épuisement du CPU ou de la bande passante réseau, et sont présentes chaque fois qu'il y a une ressource partagée.
Dans le cas où les agents de relais ajoutent des options supplémentaires aux messages Relay Forward, les messages échangés entre agents de relais et serveurs peuvent être utilisés pour monter une attaque « man in the middle » ou par déni de service.
Ce modèle de menace ne considère pas la confidentialité des contenus des messages DHCP comme importante. DHCP n'est pas utilisé pour échanger des informations d'authentification ou de configuration qui doivent rester secrètes à d'autres nœuds réseau.
L'authentification DHCP fournit l'authentification de l'identité des clients et serveurs DHCP, et l'intégrité des messages remis entre clients et serveurs DHCP. L'authentification DHCP ne fournit aucune confidentialité pour les contenus des messages DHCP.
Le protocole d'authentification retardée décrit dans la section 21.4 utilise une clé secrète partagée entre un client et un serveur. L'utilisation d'un « DHCP realm » dans la clé partagée permet l'identification des domaines administratifs afin qu'un client puisse sélectionner la ou les clés appropriées lorsqu'il se déplace entre domaines administratifs. Cependant, le protocole d'authentification retardée ne définit aucun mécanisme pour le partage des clés, donc un client peut nécessiter des clés séparées pour chaque domaine administratif qu'il rencontre. L'utilisation de clés partagées pourrait ne pas bien passer à l'échelle et ne fournit pas de répudiation des clés compromises. Ce protocole est axé sur la résolution du problème intra-domaine où l'échange out-of-band d'une clé partagée est réalisable.
En raison de la possibilité d'attaque via le message Reconfigure, un client DHCP DOIT ignorer tout message Reconfigure qui n'inclut pas l'authentification ou qui ne réussit pas le processus de validation pour le protocole d'authentification.
Le protocole de clé Reconfigure décrit dans la section 21.5 fournit une protection contre l'utilisation d'un message Reconfigure par un serveur DHCP malveillant pour monter une attaque par déni de service ou man-in-the-middle sur un client. Ce protocole peut être compromis par un attaquant capable d'intercepter le message initial dans lequel le serveur DHCP envoie la clé au client.
La communication entre un serveur et un agent de relais, et la communication entre agents de relais, peuvent être protégées via l'utilisation d'IPSec, comme décrit dans la section 21.1. L'utilisation d'une configuration manuelle et l'installation de clés statiques sont acceptables dans ce cas car les agents de relais et le serveur appartiendront au même domaine administratif et les agents de relais nécessiteront d'autre configuration spécifique (par exemple, configuration de l'adresse du serveur DHCP) au-delà de la configuration IPSec.