Le cadre SAVI (Source Address Validation
Improvement), décrit dans le RFC 7039,
vise à rendre plus difficile l'usurpation d'adresses IP. SAVI fournit un cadre général et
plusieurs solutions techniques concrètes sont ensuite développées
selon le type de réseau et selon le niveau de sécurité qu'on désire et
qu'on est prêt à « payer ». Ainsi, le RFC 6620
décrivait un mécanisme où le réseau d'accès assurait que le premier
titulaire d'une adresse IP puisse la garder. Ce nouveau
RFC décrit un autre mécanisme, où c'est via
l'utilisation de DHCP qu'on contrôle les
adresses : le réseau d'accès va empêcher l'utilisation d'adresses qui
n'ont pas été allouées par le serveur DHCP. (Ce mécanisme est
largement déployé depuis des années, sous divers noms, comme « DHCP snooping », mais n'avait pas été formellement
décrit dans un RFC.)
L'usurpation d'adresse IP est à la base de nombreuses attaques sur
l'Internet, comme les attaques par réflexion.
Il existe depuis longtemps des techniques pour limiter l'usurpation
d'adresses IP (le RFC 2827 est un exemple
classique, qui permet de protéger un réseau contre l'usurpation par un
autre). Celles de SAVI visent surtout le réseau local (réseau
d'accès pour un FAI) en limitant le risque
d'usurpation interne (qu'un utilisateur du réseau local usurpe
l'adresse d'un autre). Ici, dans ce RFC 7513, l'allocation
d'une adresse IP via DHCP va créer un lien
(binding) entre cette adresse et des informations
qui permettront au réseau de filtrer les usurpateurs. Par exemple, en
retenant le port physique du commutateur comme lien, le
commutateur peut bloquer les paquets dont
l'adresse IP source n'est pas celle qui a été allouée à la machine
connectée à ce port. Un tel mécanisme est souvent présent dans les
commutateurs existants, souvent sous le nom de DHCP snooping mais attention :
parfois, ce DHCP snooping se limite à bloquer les
réponses DHCP arrivant sur un port inattendu, et n'intégre pas
forcément la protection contre l'usurpation d'adresses IP, le but
principal de ce RFC. Vérifiez avec votre commutateur !
Ce mécanisme de lien (binding
anchor) est décrit en section 3 du RFC 7039 et rappelé en section 3 de notre RFC. Un lien doit être un attribut caractéristique, et
difficile à changer (un contre-exemple est l'adresse
MAC, facile à changer sur beaucoup de systèmes, et
pourtant citée par notre RFC). C'est le cas du port physique du
commutateur Ethernet cité plus haut, ou bien
d'une association de sécurité WiFi (la section
3.2 du RFC 7039 donne d'autres exemples).
SAVI-DHCP va donc surveiller le trafic DHCP, notant les requêtes et
réponses DHCP et les associant aux liens. Notez que cela marche avec
le DHCP avec état (RFC 2131 pour IPv4 et RFC 3315 pour IPv6), pas avec le DHCP sans état du
RFC 3736, qui ne s'occupe pas d'allocation d'adresses
IP. De même, SAVI-DHCP ne gère évidemment pas le cas des réseaux où
les adresses IP sont obtenues par un autre moyen que DHCP, par exemple
le SLAAC du RFC 4862. Idem pour les adresses
locales au lien (RFC 4291, section 2.5.6). Dans ces deux derniers cas, il faut utiliser une
autre technique SAVI, le FCFS
du RFC 6620.
Bon, maintenant, les détails. La section 4 précise quels acteurs
sont considérés : un serveur DHCP évidemment, des clients DHCP, et les
machines SAVI, typiquement des commutateurs,
qui vont faire respecter les règles SAVI (il y a aussi quelques
commutateurs non-SAVI dans le réseau d'exemple, pour mieux refléter la
réalité). La machine SAVI va avoir besoin d'une certaine
configuration. Par exemple, si le réseau contient un serveur DHCP
menteur, la machine SAVI ne peut pas le deviner, et il faut lui dire
sur quel port est attaché le vrai serveur DHCP (attribut SAVI
DHCP-trust, cf. par exemple cette
documentation Cisco, la commande ip dhcp snooping
trust indiquera qu'un serveur DHCP légitime opère sur cette
interface). De même, certains
ports physiques ne doivent pas valider les adresses IP (attribut SAVI
Trust, par exemple un
port attaché au routeur de sortie, port sur
lequel on verra passer, et c'est normal, plusieurs adresses IP) et il
faudra donc indiquer à la machine SAVI sur quels ports elle doit
surveiller (ceux où ne se trouve normalement qu'une ou plusieurs
machines obtenant des adresses par DHCP).
SAVI sépare le réseau en deux, la partie de confiance et le
reste. Dans la partie de confiance, on peut être raisonnablement sûr
que les adresses IP source sont authentiques : tous les commutateurs
valident. SAVI ne prétend pas sécuriser tout l'Internet. Et, même dans
le réseau local, une partie du réseau peut être non-SAVI et ne sera
donc pas de confiance. Cette notion de périmètre (séparant la partie
de confiance et le reste) est essentielle pour configurer SAVI, et
pour savoir ce qu'on peut attendre de cette technique. Par exemple,
des réponses DHCP venues d'un serveur situé en dehors du périmètre ne
seront pas utilisées par SAVI : puisque cette zone n'est pas de
confiance, il peut parfaitement s'agir d'un serveur pirate (section
4.3.3 du RFC, un bon exemple de l'utilisation de la notion de
périmètre, avec un schéma d'exemple).
La sécurité de SAVI-DHCP dépend évidemment de la sécurité des
liens. Il faut notamment s'assurer que les attributs utilisés pour
construire le lien sont difficiles à usurper. Un port physique du
commutateur est un bon exemple. A contrario, une adresse
MAC est un mauvais attribut (trop facile à changer) et
même un attribut fort peut être affaibli par certains usages. Par
exemple, si on utilise le port physique du commutateur Ethernet comme
binding anchor, mais que ce dernier est connecté à
des commutateurs non-SAVI en cascade, les nombreuses machines qui
partagent ce port physique peuvent encore usurper leurs adresses IP
entre elles.
Ces liens et les adresses IP associées doivent être stockées dans
la mémoire de la machine SAVI, dans un structure de données dite BST
(Binding State Table, section 5). Chaque ligne de
cette table stocke également la durée de vie du lien et l'état du lien
(établi, en cours d'établissement, inconnu).
La BST se remplit en « espionnant » (snooping)
le trafic DHCP (section 6). En résumant (beaucoup) : la machine SAVI
voit passer une requête DHCP et la réponse arrive depuis un port
marqué comme DHCP-trust. On stocke alors dans la
BST le port d'où est venu la requête (le lien, le binding
anchor), l'adresse IP dans la réponse, le fait que le lien
est établi, et sa durée de vie (typiquement la durée du bail
DHCP). Désormais, si on voit un paquet IP arriver par le port d'où
venait la requête DHCP, on pourra regarder son adresse IP source, et
jeter le paquet si elle ne correspond pas à ce qui est dans la
BST (ce filtrage est décrit en section 8). Sur un
Juniper, on peut afficher cette BST avec
show dhcp snooping binding. Cet exemple est tiré
d'une documentation Juniper :
user@switch> show dhcp snooping binding
DHCP Snooping Information:
MAC Address IP Address Lease Type VLAN Interface
----------------- ---------- ----- ------- ---- ---------
00:00:01:00:00:03 192.0.2.0 640 dynamic guest ge-0/0/12.0
00:00:01:00:00:04 192.0.2.1 720 dynamic guest ge-0/0/12.0
00:00:01:00:00:05 192.0.2.5 800 dynamic guest ge-0/0/13.0
Attention, il y a quelques pièges. Par exemple, s'il existe
plusieurs chemins entre le client et le serveur DHCP, et que la
machine SAVI n'est que sur un seul de ces chemins, elle risque de
rater le dialogue DHCP. Autre cas problématique si une machine se
déplace d'un port à un autre sans refaire une requête DHCP.
La section 7 propose des solutions à ces problèmes de faux
positifs. L'idée est de noter le trafic rejeté par SAVI-DHCP et de
vérifier activement si le paquet a été rejeté à tort (le mal nommé
« Data Snooping Process »). Par exemple, en IPv4, on peut envoyer des requêtes
ARP (RFC 826 et RFC 5227) pour déterminer si deux machines (la vraie
et l'usurpatrice) utilisent la même adresse IP (s'il n'y a qu'une
machine, la vraie, on ne recevra qu'une réponse). En IPv6, on peut
utiliser un message DAD (Duplicate Address
Detection, cf. RFC 4862, section 5.4)
pour faire le même test.
On peut aussi, si on a raté ou qu'on pense avoir raté le dialogue
DHCP, demander directement au serveur DHCP, avec un message
DHCPLEASEQUERY (RFC 4388)
en IPv4 et LEASEQUERY (RFC 5007) en IPv6.
Bref, comme toujours en sécurité, on n'a pas de repas gratuit :
SAVI-DHCP protège contre bien des usurpations mais, comme toute
technique de filtrage, il peut mener au rejet de messages légitimes.
Le mécanisme de SAVI-DHCP nécessite de mémoriser un état, la BST
(Binding State Table, décrite en section 5). Si
elle est gardée en RAM et qu'on redémarre, la
liste des liens est perdue et tous les paquets seront rejetés (c'est
pourquoi, en général, IP déconseille de garder
de l'état dans le réseau). La section 9 rappelle ce problème et
demande donc que la BST soit stockée dans une mémoire qui survit aux
redémarrages. (On pourrait récupérer un bon bout de la BST par les
méthodes de la section 7 mais ça prendrait un temps fou.) À noter que,
sur un Juniper, ce n'est pas fait par défaut (il faut la directive
dhcp-snooping-file pour stocker la BST).
Terminons ce résumé du RFC avec la section 11, consacrée aux
questions de sécurité. D'abord, les risques que crée le Data
Snooping process de la section 7. Comme ce processus est
coûteux en nombre de paquets envoyés, un attaquant pourrait être tenté
de le déclencher afin de réaliser une attaque par déni de
service. Pour cela, il aurait juste à envoyer quelques
paquets usurpés. Le processus doit donc avoir une limitation de
trafic.
Plusieurs autres attaques sont possibles contre ce mécanisme de
sécurité complexe qu'est SAVI-DHCP (réutiliser l'adresse d'un client
qui est parti et ne peut donc plus se défendre en cas de détection
d'adresse dupliquée, créer de nombreux liens pour remplir la BST et
faire une attaque par déni de service, etc). Il y a aussi un risque
sur la vie privée, puisque la BST stocke de nombreuses informations
sur l'arrivée et le départ des machines des utilisateurs. Elle ne doit
donc pas être archivée. L'idée est qu'aucune information ne devrait
être gardée sur les machines qui n'usurpent jamais d'adresse IP (ne
pas fliquer les gens honnêtes).
À noter que Cisco prétend avoir inventé la
technique et a un
brevet sur l'idée, mais propose une licence (avec clause de représailles).
Merci à Cécile Grange pour des indications sur les solutions Juniper.
