Une faille sérieuse de la sécurité dans
l'
Mettons que ma machine soit connectée à l'Internet, via un
L'adresse source étant usurpée, l'attaquant ne recevra en
général pas la réponse mais, pour certains protocoles, comme
Et cela permet des attaques intéressantes, comme les
Encore pire, les attaques par réflexion avec amplification, qui permettent à l'attaquant d'obtenir un débit sur sa victime supérieur à celui que l'attaquant doit lui-même fournir. Les récentes attaques DNS, utilisant comme tiers des relais DNS récursifs ouverts, appartiennent à cette catégorie. Ces attaques sont décrites en et une approche du problème est en .
Notre RFC propose donc de tenter de mettre fin à ces
usurpations. Cela peut se faire chez les
Le principe est simple (notre RFC est d'ailleurs très court car,
techniquement, il n'y a pas grand'chose à dire) : sur les
iptables --insert FORWARD --out-interface eth1 --source \! 172.20.128.0/22 --jump LOG --log-prefix "IP spoofing"
iptables --insert FORWARD --out-interface eth1 --source \! 172.20.128.0/22 --jump DROP
Naturellement, il faut bien vérifier qu'on couvre tous les cas :
beaucoup d'opérateurs ont du mal à compiler une liste exacte de tous
leurs préfixes, ce qui explique en partie le peu de déploiement de ce
RFC.
Notons que, comme toute mesure de sécurité, celle-ci a des faux
positifs (le RFC cite le cas des mobiles) et qu'elle peut bloquer ou
bien rendre très difficiles des
usages parfaitement légitimes (le RFC cite le cas du
Notre RFC date de presque six ans et ne semble toujours pas largement déployé : cela donne une idée de la difficulté du problème. En effet, déployer ce RFC (aussi connu sous son numéro de bonne pratique, BCP38), coûte de l'argent au FAI et en fait économiser aux autres opérateurs de l'Internet, par les attaques que cela leur épargne. On conçoit que le simple bon sens économique et l'absence de régulation autre que celle du marché limitent la mise en œuvre de ce RFC.