22. Considerations de securite
Cette section conserve le texte de la RFC relatif a DHCPv6, notamment les echanges de messages, le comportement des relais, les DUID, IA_NA, IA_TA, IA_PD, les options DHCP, l'authentification RKAP, les registres IANA, les exigences normatives et les matrices d'apparition des options en annexe.
Texte original de la RFC
22. Considerations de securite
Cette section traite des considerations de securite qui ne sont pas
liees a la vie privee. Voir la Section 23 pour une discussion
consacree a la vie privee.
La menace pesant sur DHCP est intrinsequement une menace interne (en
supposant un reseau correctement configure, ou les ports DHCP sont
bloques sur les passerelles perimetriques de l'entreprise). Quelle
que soit la configuration de la passerelle, cependant, les attaques
potentielles par des acteurs internes et externes sont les memes.
DHCP ne dispose pas de chiffrement de bout en bout entre clients et
serveurs; par consequent, les attaques par detournement, alteration et
ecoute passive sont toutes possibles. Certains environnements reseau
(discutes ci-dessous) peuvent etre securises par divers moyens afin de
reduire ces attaques.
La menace commune au client et au serveur est l'attaque DoS par
"epuisement des ressources". Ces attaques impliquent typiquement
l'epuisement des adresses attribuees disponibles ou des prefixes
delegables, ou l'epuisement du CPU ou de la bande passante reseau; elles
existent chaque fois qu'une ressource est partagee. Certaines formes
de ces attaques par epuisement peuvent etre partiellement attenuees par
une politique de serveur appropriee, par exemple en limitant le nombre
maximal de baux qu'un client peut obtenir, en limitant le nombre de baux
qu'un client peut refuser et en limitant le nombre de messages qu'un
seul client peut transmettre pendant une periode donnee.
22.1. Considerations de securite relatives au client
Une attaque propre a un client DHCP consiste a etablir un serveur
malveillant dans le but de fournir au client des informations de
configuration incorrectes. La motivation peut etre de monter une
attaque de type "man-in-the-middle" qui amene le client a communiquer
avec un serveur malveillant au lieu d'un serveur valide pour un service
donne (tel que DNS ou NTP). Le serveur malveillant peut aussi monter
une attaque DoS par mauvaise configuration du client; cette attaque
ferait echouer toutes les communications reseau du client.
Un serveur DHCP malveillant pourrait amener un client a definir ses
parametres SOL_MAX_RT et INF_MAX_RT sur une valeur deraisonnablement
elevee avec les options SOL_MAX_RT (voir Section 21.24) et INF_MAX_RT
(voir Section 21.25); cela peut provoquer un delai excessif avant que
le client acheve sa transaction de protocole DHCP lorsqu'aucune autre
reponse valide n'est recue. Si l'on suppose que le client recoit aussi
une reponse d'un serveur DHCP valide, de grandes valeurs de SOL_MAX_RT
et INF_MAX_RT n'auront aucun effet.
Une autre menace visant les clients DHCP provient de serveurs DHCP
configures par erreur ou accidentellement, qui repondent aux requetes
des clients DHCP avec des parametres de configuration incorrects de
facon non intentionnelle.
Si une implementation cliente prend en charge le mecanisme reconfigure,
voir la Section 22.3.
22.2. Considerations de securite relatives au serveur
La menace propre a un serveur DHCP est un client non valide se faisant
passer pour un client valide. La motivation peut etre le vol de service
ou le contournement de l'audit a diverses fins malveillantes.
Les messages echanges entre agents relais et serveurs peuvent etre
utilises pour monter une attaque man-in-the-middle ou DoS. La
communication entre un serveur et un agent relais, ainsi que la
communication entre agents relais, peut etre authentifiee et chiffree
au moyen d'IPsec, comme decrit dans [RFC8213].
Cependant, l'utilisation de cles prepartagees configurees manuellement
pour IPsec entre agents relais et serveurs ne protege pas contre les
messages DHCP rejoues. Les messages rejoues peuvent constituer une
attaque DoS par epuisement des ressources de traitement, mais pas par
mauvaise configuration ni par epuisement d'autres ressources telles que
les adresses attribuables et les prefixes delegables.
Si une implementation serveur prend en charge le mecanisme reconfigure,
voir la Section 22.3.
22.3. Considerations de securite relatives a Reconfigure
RKAP, decrit dans la Section 20.4, fournit une protection contre
l'utilisation d'un message Reconfigure par un serveur DHCP malveillant
pour monter une attaque DoS ou man-in-the-middle contre un client. Ce
protocole peut etre compromis par un attaquant capable d'intercepter le
message initial dans lequel le serveur DHCP envoie la cle en clair au
client.
En raison de la possibilite d'attaque via le message Reconfigure, un
client DHCP MUST rejeter tout message Reconfigure qui n'inclut pas
d'authentification ou qui ne reussit pas le processus de validation du
protocole d'authentification.
Un client DHCP peut aussi etre soumis a une attaque lorsqu'il recoit un
message Reconfigure d'un serveur malveillant qui l'amene a obtenir des
informations de configuration incorrectes aupres de ce serveur. Noter
que, bien qu'un client envoie sa reponse (message Renew, Rebind ou
Information-request) via un agent relais et que, par consequent, cette
reponse ne soit recue que par les serveurs vers lesquels les messages
DHCP sont relayes, un serveur malveillant pourrait envoyer un message
Reconfigure a un client, suivi (apres un delai approprie) d'un message
Reply qui serait accepte par le client. Ainsi, un serveur malveillant
qui ne se trouve pas sur le chemin reseau entre le client et le serveur
peut tout de meme etre capable de monter une attaque Reconfigure contre
un client. L'utilisation d'identifiants de transaction
cryptographiquement solides et difficilement previsibles reduira
egalement la probabilite de succes d'une telle attaque.
22.4. Considerations d'attenuation
Divers environnements reseau offrent aussi des niveaux de securite
lorsqu'ils sont deployes comme decrit ci-dessous.
* Dans les reseaux d'entreprise et d'usine, l'utilisation de
l'authentification selon [IEEE8802.1x] peut empecher les clients
inconnus ou non fiables de se connecter au reseau. Toutefois, cela
ne garantit pas necessairement que le client connecte agira
correctement comme acteur DHCP ou reseau.
* Pour les reseaux cables ou les clients sont typiquement connectes a
un port de commutateur, l'ecoute furtive du trafic DHCP multicast
(ou unicast) devient difficile, car les commutateurs limitent le
trafic livre a un port. Les messages DHCP du client (multicast vers
All_DHCP_Relay_Agents_and_Servers) ne sont transmis qu'au port du
commutateur du serveur DHCP (ou du relais), et non a tous les ports.
De meme, les reponses unicast du serveur (ou du relais) ne sont
livrees qu'au port du client cible, et non a tous les ports.
* Dans les reseaux publics (par exemple un reseau Wi-Fi dans un cafe
ou un aeroport), d'autres personnes a portee radio peuvent espionner
DHCP et d'autres trafics. Mais dans ces environnements, il y a tres
peu, voire rien, a apprendre du trafic DHCP lui-meme (que ce soit du
client vers le serveur ou du serveur vers le client) si les
considerations relatives a la vie privee fournies dans la Section 23
sont suivies. Meme pour les appareils qui ne suivent pas ces
considerations, il y a peu d'informations a apprendre qui ne
seraient pas de toute facon disponibles dans les communications
subsequentes (comme l'adresse Media Access Control (MAC) de
l'appareil). De plus, puisque tous les clients recoivent
typiquement des details de configuration similaires, un acteur
malveillant qui initie lui-meme une requete DHCP peut apprendre une
grande partie de ces informations. Comme mentionne ci-dessus, une
menace est que la cle RKAP d'un client puisse etre apprise (si
l'echange initial Solicit/Advertise/Request/Reply est surveille) et
declenche une reconfiguration prematuree; cela est toutefois assez
facilement empeche en interdisant la communication directe de client
a client sur ces reseaux ou en utilisant [RFC7610] et [RFC7513].
Beaucoup des attaques par serveurs indelicats peuvent etre attenuees en
utilisant les mecanismes decrits dans [RFC7610] et [RFC7513].