23. Security Considerations (Considérations de sécurité)
23. Security Considerations (Considérations de sécurité)
Les menaces contre DHCP sont essentiellement des menaces internes (en supposant que le réseau est correctement configuré et que les ports DHCPv6 sont bloqués sur les passerelles de périmètre d'entreprise). Cependant, les attaques potentielles par des initiés et des étrangers sont les mêmes, quelle que soit la configuration de la passerelle.
L'utilisation d'IPsec avec des clés pré-partagées configurées manuellement entre les agents relais et les serveurs ne fournit pas de défense contre les messages DHCP rejoués. Les messages rejoués peuvent représenter une attaque DOS en épuisant les ressources de traitement, mais ne peuvent pas représenter une mauvaise configuration ou l'épuisement d'autres ressources (telles que les adresses assignables).
Une attaque spécifique contre les clients DHCP est l'établissement d'un serveur malveillant dans l'intention de fournir de fausses informations de configuration aux clients. La motivation pour ce faire peut être d'effectuer une attaque "homme du milieu", amenant les clients à communiquer avec un serveur malveillant plutôt qu'avec des serveurs valides pour certains services (tels que DNS ou NTP). Un serveur malveillant peut également lancer une attaque de déni de service en mal configurant les clients, causant l'échec de toutes les communications réseau des clients.
Les clients DHCP font également face à une autre menace de serveurs DHCP mal ou accidentellement configurés qui répondent aux requêtes des clients DHCP avec des paramètres de configuration incorrects inattendus.
Les clients DHCP peuvent également être soumis à une attaque en recevant un message Reconfigure d'un serveur malveillant qui amène le client à obtenir de fausses informations de configuration de ce serveur. Notez que bien que le client envoie sa réponse (message Renew ou Information-request) via un agent relais, de sorte que la réponse ne sera reçue que par le serveur vers lequel le message DHCP a été relayé, un serveur malveillant peut envoyer un message Reconfigure au client, puis (après un délai approprié) envoyer un message Reply qui sera accepté par le client. Par conséquent, un serveur malveillant qui n'est pas sur le chemin réseau entre le client et le serveur peut toujours lancer une attaque de reconfiguration contre le client. L'utilisation d'ID de transaction cryptographiquement sûrs et non facilement prévisibles réduira également la probabilité de succès de telles attaques.
Une menace spécifique contre les serveurs DHCP est des clients invalides se faisant passer pour des clients valides. La motivation pour ce faire peut être le vol de service, ou pour éviter l'audit pour tout nombre de fins malveillantes.
Une menace commune aux clients et serveurs est les attaques de "déni de service" (DoS) des ressources. Ces attaques impliquent généralement l'épuisement des adresses disponibles, ou l'épuisement du CPU ou de la bande passante réseau, et existent chaque fois qu'il y a des ressources partagées.
Dans le cas où un agent relais ajoute des options supplémentaires à un message Relay-forward, les messages échangés entre les agents relais et les serveurs peuvent être utilisés pour lancer des attaques "homme du milieu" ou de déni de service.
Ce modèle de menace ne considère pas la confidentialité du contenu des messages DHCP comme importante. DHCP n'est pas utilisé pour échanger des informations d'authentification ou de configuration qui doivent être secrètes pour d'autres nœuds réseau.
L'authentification DHCP fournit l'authentification de l'identité des clients et serveurs DHCP, ainsi que l'intégrité des messages délivrés entre les clients et serveurs DHCP. L'authentification DHCP ne fournit aucune confidentialité pour le contenu des messages DHCP.
Le protocole d'authentification différée décrit dans la section 21.4 utilise une clé partagée entre le client et le serveur. L'utilisation d'un "royaume DHCP" dans la clé partagée permet l'identification d'un domaine d'administration afin que le client puisse sélectionner la clé ou les clés appropriées lors de la navigation entre les domaines d'administration. Cependant, le protocole d'authentification différée ne définit aucun mécanisme de partage de clés, de sorte que le client peut avoir besoin de clés séparées pour chaque domaine d'administration qu'il rencontre. L'utilisation de clés partagées peut ne pas bien évoluer et ne fournit pas de déni pour les clés compromises. Ce protocole se concentre sur la résolution de problèmes intra-domaines où l'échange hors bande de clés partagées est réalisable.
En raison de l'opportunité d'attaque via les messages Reconfigure, les clients DHCP doivent rejeter tout message Reconfigure qui ne contient pas d'authentification ou qui ne passe pas le processus de validation du protocole d'authentification.
Le protocole de clé de reconfiguration décrit dans la section 21.5 fournit une protection contre l'utilisation de messages Reconfigure par un serveur DHCP malveillant pour lancer des attaques de déni de service ou d'homme du milieu contre le 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 les serveurs et les agents relais, et entre les agents relais, peut être protégée en utilisant IPSec, comme décrit dans la section 21.1. Dans ce cas, l'utilisation de la configuration manuelle et de l'installation de clés statiques est acceptable car les agents relais et les serveurs appartiendront au même domaine d'administration et l'agent relais nécessitera d'autres configurations spécifiques (telles que la configuration de l'adresse du serveur DHCP) ainsi que la configuration IPSec.