Les routeurs actuels empêchent-ils les faux en-têtes IP?

Je sais que les gens peuvent modifier les en-têtes IP et changer l'adresse IP source, mais il devrait être simple pour les périphériques réseau de détecter ces messages. S'ils ne le font pas, pourquoi est-ce si difficile? Cela ajoute-t-il trop de frais généraux?

Je sais que les gens peuvent modifier les en-têtes IP et changer l'adresse IP source, mais il devrait être simple pour les périphériques réseau de détecter ces messages.

Les fausses adresses source IP dans les en-têtes peuvent être détectées et bloquées dans les équipements du réseau commercial; d'autres faux en-têtes IPv4 peuvent être un peu plus difficiles à identifier. La plupart des gens se réfèrent à la fonction pour détecter les fausses adresses IP source en tant que "Forward Path Forwarding Unicast", qui est abrégé uRPF ; uRPF est défini dans la RFC 3704 et est considéré comme une meilleure pratique actuelle sur Internet . uRPF doit être appliqué sur le premier routeur à partir de l'équipement du client, ou sur le routeur de périphérie dans un réseau d'entreprise.

S'ils ne le font pas, pourquoi est-ce si difficile? Cela ajoute-t-il trop de frais généraux?

Tant que le routeur n'est pas un routeur basé sur le processeur, il n'y a pas de pénalité de performance. Beaucoup de routeurs / commutateurs utilisés par les FAI ont cette fonctionnalité intégrée dans un ASIC dans le matériel; normalement, il n'y a pas de pénalité de performance énorme pour l'activer. Parfois, il y a des conflits de fonctionnalités, mais là encore, ce n'est pas énorme dans la plupart des cas.

Les politiques et les compétences du personnel d'ingénierie / opérationnel des FSI varient, et de nombreux FSI (en particulier dans les petits pays) sont tellement occupés à faire fonctionner les choses qu'ils n'ont pas de cycles pour faire fonctionner les choses correctement.

La prévention du changement d'adresse IP source nécessite des listes d'accès (ACL) ou un filtrage de chemin inverse unicast (uRPF).

Ni venir gratuitement. uRPF nécessite généralement une recherche supplémentaire ou une recherche unique plus complexe, de sorte qu'il pourrait même réduire de moitié les performances de votre recherche sur certaines plates-formes. ACL ralentit la recherche et utilise la mémoire.

uRPF ne nécessite aucun entretien, il vous suffit de le configurer une fois et de l'oublier. ACL a besoin d'un système qui sait quelles adresses se trouvent derrière l'interface et s'assure que l'ACL reste à jour.

ACL plus largement pris en charge que uRPF, uRPF est une fonctionnalité relativement rare dans les périphériques de niveau commutateur L3. Dans les routeurs «réels», les deux fonctionnalités sont généralement disponibles.

Même si les deux fonctionnalités sont disponibles, configurer uRPF au mauvais endroit du réseau peut casser le réseau, ne pas comprendre les limitations ACL spécifiques à la plate-forme peut provoquer des pannes.

Habituellement, vous-même ne bénéficiez pas de la prévention de l'usurpation d'adresse source, c'est principalement Internet dans son ensemble qui en bénéficie. Vous portez un risque différent de zéro en essayant de le faire, car vous pourriez finir par casser des choses. Et vos clients ne gagneront aucun avantage, personne ne vous paiera plus pour les mettre en œuvre. La récompense est donc faible à le faire.

Un fournisseur de services responsable le fait, car c'est la bonne chose à faire, mais il est irréaliste de s'attendre à ce que nous obtenions l'antispoofing dans une grande partie des appareils d'accès déployés. Un objectif beaucoup plus réaliste est, si nous faisons l'ACL dans les connexions de transit IP, car il n'y a qu'environ 6000 numéros AS tronqués.

Ce problème est même dû aux attaques de réflexion UDP, qui peuvent être corrigées par des protocoles tels que QUIC et MinimaLT qui garantissent que la réflexion n'a aucun gain, car la requête entrante est garantie d'être plus grande que la réponse sortante, de sorte que l'usurpation d'identité perd son avantage.

Il est à nouveau récemment devenu très populaire d'utiliser la réflexion UDP comme attaque DDoS. Il y a beaucoup de serveurs DNS ouverts dans les appareils CPE grand public que les consommateurs ne connaissent pas, donc ces consommateurs souffrent car leur connexion à domicile est encombrée car elle est utilisée pour refléter l'attaque. Et c'est aussi un moyen facile d'obtenir une amplification significative. Une petite requête de dizaines d'octets peut donner une réponse importante de plus de mille octets. Il y a eu des attaques DDoS par réflexion qui sont de plusieurs centaines de gigabits par seconde, et plus petites sont quotidiennes, juste dimanche soir, nous avons transporté une attaque de 43 Gbps à l'un de nos clients.

Le filtrage des adresses source n'est pas trivial dans le monde réel, car le routage Internet est asymétrique, donc en principe nous avons besoin d'une supposition éclairée si un paquet de cette source est susceptible d'apparaître sur cette interface entrante.

Il n'y a pas de formule facile pour cela, car pour chaque règle qui fonctionne dans presque tous les cas, il existe également un cas d'utilisation qui a un sens commercial et qui serait alors rompu.

Le filtrage de chemin inverse fonctionne très bien sur les routeurs de périphérie, où il existe une définition claire de "à l'intérieur" et "à l'extérieur" - vous n'autorisez pas les étrangers à utiliser des adresses "à l'intérieur" et vice versa. Cela devient plus compliqué dès que je commence à utiliser plusieurs routeurs de périphérie pour la redondance.

Pour les routeurs de dorsale, la seule façon d'implémenter le filtrage de chemin inverse est d'autoriser les paquets entrants lorsque l'homologue annonce une route de travail (indépendamment du fait que ce soit notre préférence). Ce serait une recherche prohibitive, facilement contournée et casse le cas d'utilisation où j'achète délibérément du transport en commun mais n'annonce pas mon préfixe sur ce lien.