La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: maximushugus le 02 mai 2022 à 17:56:01
-
Bonjour,
Je viens de découvrir (ce n'est probablement pas un scoop pour beaucoup d'entre vous) que sur le réseau de mon opérateur (RED SFR FTTH) je peux envoyer des packets via une autre IP que celle qui m'est attribuée, et que ces packets sont bien routés par mon FAI.
Je m'explique. J'ai remplacé la box de mon opérateur par un routeur pfSense. Sur ce dernier, pour divers raisons, je disposes "d'IP virtuelles" routables sur internet.
Je me suis rendu compte par hasard, que si je fais un ping vers une destination en passant pas le réseau de mon opérateur mais en utilisant une de ces IP mais non fournie par ce dernier, les packets étaient bien routés vers la destination (vérifié par capture réseau sur la destination en question).
Bien évidemment la réponse du ping depuis la destination ne se fait pas vers moi via l'opérateur en question, mais est bien redirigée vers l'opérateur de l'IP utilisée.
C'est probablement la base des DDOS.
Néanmoins je m'étonne de voir qu'un FAI, ici SFR, route des IP sources qui n'appartiennent pas à leur client.
Qu'en pensez vous ?
-
...
C'est probablement la base des DDOS.
Ca fait partie des techniques, mais pour que les attaques en DDOS soient vraiment efficaces, il faut mettre aussi en place des techniques "d'amplification", notamment avec des botnets.
Néanmoins je m'étonne de voir qu'un FAI, ici SFR, route des IP sources qui n'appartiennent pas à leur client.
Qu'en pensez vous ?
C'est le principe du routage : la décision d'acheminement d'un paquet (vers la cible ou le routeur suivant) se fait en étudiant l'adresse destination - pas l'adresse source.
Le fait de filtrer les adresses sources n'est plus du routage - c'est du filtrage :D.
A ma connaissance, les FAI n'ont pas du tout l'obligation de vérifier que les paquets qu'ils injectent sur d'autres réseaux sont "légitimes" du point de vue de leurs adresses IP sources.
-
Ca s'appelle le reverse path filtering , ou aussi abrégé rp_filter.
C'est étonnant que le FAI ne le pratique pas, mais ce n'est pas une obligation en effet.
-
Je peux confirmer, après avoir fait un test similaire sur ma connexion Milkywan, que les packets ne sont pas routés vers la destination si je spoof une IP qui n'est pas la mienne
-
Ca s'appelle le reverse path filtering , ou aussi abrégé rp_filter.
C'est étonnant que le FAI ne le pratique pas, mais ce n'est pas une obligation en effet.
Pourtant, ce n'est pas nouveau, le RFC 2267 (https://datatracker.ietf.org/doc/rfc2267/) en parlait déjà en 1998 comme une solution pour "empêcher les attaques en déni de service utilisant du spoofing d'adresse IP" !
C'est disponible sur tous les systèmes et équipements réseau, encore faut-il que le FAI le mette en place (correctement).
Voir par exemple pour Linux la rubrique rp_filter de https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
-
C'est disponible sur tous les systèmes et équipements réseau, encore faut-il que le FAI le mette en place (correctement).
Alors c'est pas si simple ^^
Typiquement sur nos Arista, il faut changer le profil TCAM pour activer uRPF, ce qui réduit le nombre de routes max de l'équipement.
Sur nos Brocade, uRPF n'existe pas en IPv6.
Chez MilkyWan, on a activé uRPF partout où c'était possible, ça me semble être la base d'un réseau de FAI.
-
Alors c'est pas si simple ^^
Typiquement sur nos Arista, il faut changer le profil TCAM pour activer uRPF, ce qui réduit le nombre de routes max de l'équipement.
Sur nos Brocade, uRPF n'existe pas en IPv6.
Chez MilkyWan, on a activé uRPF partout où c'était possible, ça me semble être la base d'un réseau de FAI.
Tu justifies ainsi pourquoi certains FAI ne le font pas : il faut que l'ingéniérie soit bien faite, c'est compliqué à implémenter, ça peut créer des limitations ou des problèmes de performance (et ça peut également compliquer les diagnostics).
Et encore, vous n'aviez pas un historique à gérer.
-
Je ne justifie pas, j'explique. SFR a le budget pour faire les choses bien si ils s'en donnent la peine ;)
-
En tout cas j'imagine que c'est quand même la porte ouverte à des failles de sécurité
-
Oh le spoofing c'est pas non plus l'affaire du siècle, ça sert surtout à faire de l'amplification, et donc du déni de service
-
A ma connaissance, les FAI n'ont pas du tout l'obligation de vérifier que les paquets qu'ils injectent sur d'autres réseaux sont "légitimes" du point de vue de leurs adresses IP sources.
En tout cas, sur Covage, il y a des ACL lié au relais DHCP qui coupent au bout de 5 minutes la connexion si IP fixe sans demande DHCP.
Pas possible de spoofer sa propre adresse plus de 5 minutes.
Je n'ai jamais testé avec une autre...
-
Il me semble que sur le réseau FttH de Bouygues Telecom, le reverse path filtering est bien activé.
-
C'est assez logique que cela puisse avoir un impact sur la TCAM d'un équipement, si on regarde ce qu'il se passe avec uRPF d'activé, le paquet arrive et au lieu d'un seul lookup de l'IP de destination dans la TCAM l'équipement fait un second lookup avec l'IP source et drop le paquet si le paquet arrive sur une interface qui n'est pas dans les résultats du lookup. Et de fait le lookup n'est pas exactement le même, dans un cas on cherche juste une interface de sortie et dans l'autre cas on cherche à savoir si une l'interface d'entrée est une route possible vis-à-vis de l'IP source du paquet entrant et pas exclusivement la meilleur route.
Après est-ce que le spoofing est "juste" possible pour des IPs du bloc CIDR des abonnées du coin ou est-ce que c'est openbar complet et un paquet avec n'importe quoi comme source est routé vers la sortie ?
-
Sans uRPF ou ip access list, tu peux envoyer n'importe quoi
-
Je ne suis pas concerné par ce problème sur une connexion FttH Red
Peut-être un stagging historique ?
-
Je ne suis pas concerné par ce problème sur une connexion FttH Red
Peut-être un stagging historique ?
Pour information je suis sur une connexion FTTH chez Red By SFR sur une infrastructure qui semble assez ancienne avec du IPv4 only
-
Après est-ce que le spoofing est "juste" possible pour des IPs du bloc CIDR des abonnées du coin ou est-ce que c'est openbar complet et un paquet avec n'importe quoi comme source est routé vers la sortie ?
Normalement l'opérateur est censé filtrer au plus près de la source par le premier équipement capable de faire de l'IP.
Pour information je suis sur une connexion FTTH chez Red By SFR sur une infrastructure qui semble assez ancienne avec du IPv4 only
Même sur des installations récentes il y a des zones IPv4-only chez SFR. (ex. Connect76.)
-
Après est-ce que le spoofing est "juste" possible pour des IPs du bloc CIDR des abonnées du coin ou est-ce que c'est openbar complet et un paquet avec n'importe quoi comme source est routé vers la sortie ?
J'ai essayé avec une IP au hasard n'appartenant pas du tout à SFR et c'est open bar
-
Les zones chez SFR avec de l'IPv4 only sont sur des équipements de collecte (on ne parle pas de l'OLT mais au-dessus) anciens, même si la zone FttH vient d'ouvrir. Il y a des problèmes de stabilité en activant IPv6 d'où la suppression d'IPv6 natif. Il me semble que les nom des équipements en question a été donné dans un sujet ici, mais je ne retrouve plus, il y a tellement de sujets parlant de l'IPv6 chez SFR.
Les équipements récents (en gros la moitié du parc) supportent l'IPv6.
-
Normalement l'opérateur est censé filtrer au plus près de la source par le premier équipement capable de faire de l'IP.
Ah mais ça je sais bien. Mais dans une infra qui semble hétérogène comme celle d'SFR, je m'imagine très bien des bout de collecte avec quelques BNG/BRAS/BAS qui envoient vers le core un trafic qui n'a pas été filtré avec uRPF (pour quelque raison que ce soit) et qu'a un moment plus au haut dans le réseau uRPF soit actif, ça autoriserait du spoofing de toute les IPs des blocs utilisés pour les abonnés en question et pas n'importe quelle IP, sauf peut être entre abonnés qui partageraient cette infra et pourrait alors utiliser n'importe qu'elle IP source tant que le trafic ne remonte pas jusqu'à un équipement avec uRPF d'activé.
-
Non, mais franchement, lol
Pour la France, dernier en date
https://spoofer.caida.org/report.php?sessionid=1357331
-
Pour la France, dernier en date
https://spoofer.caida.org/report.php?sessionid=1357331
212.237.123.0/24 AS206206 K-NET (Kurdistan Net), IRAQ
-
Petite update 1 an plus tard concernant le problème sur une ligne SFR : le problème est toujours présent
Voici le test en question : https://spoofer.caida.org/report.php?sessionid=1566351
Ne pas tenir compte sur ce test de l'IPv6 qui n'est pas chez SFR.
A noter qu'il s'agit d'une ligne SFR sur laquelle j'ai bypassé la box, et le test est réalisé depuis le VLAN "LAN" de mon réseau sur lequel il n'y a aucun blocage de packet sortant au niveau du parefeu.
Peut etre que SFR base sa sécurité sur sa box concernant l'usurpation d'IP.
-
Tiens, je vois que notre antispoof a nous marche bien 8)
-
Tiens, je vois que notre antispoof a nous marche bien 8)
En IPv6 oui c'est sur que sur le réseau Milkywan l'antispoof fonctionne.
Pour l'IPv4 il semble également mais je ne sais pas si le test que jai fait hier soir sur IPv4 Milkywan est réellement interprétable car j'ai une règle NAT de remplacement de l'IPv4 source par celle attribuée par Milkywan en sortie de mon routeur/parefeu