Anti-Spoofing (Français)

GUIDE DE MISE EN ŒUVRE DE MANRS

• Introduction
• Coordination
• Validation globale
• anti-Spoofing
• filtrage
• résumé et listes de contrôle
• informations supplémentaires

4.3. Anti-Spoofing-prévention du trafic avec des adresses IP source usurpées

actions attendues de Manrs pertinentes:

• L’opérateur réseau implémente un système qui permet la validation des adresses source pour au moins les réseaux de clients à domicile unique, leurs propres utilisateurs finaux et leur infrastructure., L’opérateur réseau met en œuvre un filtrage anti-usurpation pour empêcher les paquets avec une adresse IP source incorrecte d’entrer et de quitter le réseau.

l’usurpation D’adresse source IP est la pratique consistant à créer des datagrammes IP avec des adresses sources autres que celles attribuées à l’hôte d’origine. En termes simples, l’hôte prétend être un autre hôte. Ceci peut être exploité de diverses manières, notamment pour exécuter des attaques de réflexion-amplification de déni de service (DoS) qui provoquent un hôte de réflecteur pour envoyer le trafic à l’adresse usurpée.,

Il existe de nombreuses recommandations pour empêcher L’usurpation D’adresse IP par filtrage d’entrée, par exemple en vérifiant les adresses source des datagrammes IP proches de la périphérie du réseau. La plupart des fournisseurs d’équipement prennent en charge le filtrage d’entrée sous une forme ou une autre. Depuis 2005, le déploiement de techniques anti-spoofing n’a pas été une limitation des performances de l’équipement. Cela a été une limitation du désir et de la volonté de déployer et de maintenir la configuration anti-usurpation.

ironiquement, les attaques D’amplification DoS importantes peuvent être coûteuses pour les fournisseurs de services., Les coûts nuisent à la marque, endommagent les opérations des clients et ont un impact opérationnel/coût collatéral sur les autres clients. Ces attaques D’amplification DoS sont évitables. Ils seraient impossibles sans usurpation.

cela démontre que le filtrage d’entrée n’est certainement pas suffisamment déployé. Malheureusement, il n’y a aucun avantage pour un fournisseur de Services (SP) qui déploie le filtrage d’entrée. Il existe également une croyance largement répandue selon laquelle le filtrage d’entrée n’aide que lorsqu’il est déployé universellement.,

Les approches communes à ce problème ont impliqué des caractéristiques logicielles telles que SAV (Validation D’adresse Source) sur des réseaux de câble – modem ou la validation stricte d’uRPF (expédition de chemin inverse d’unicast) sur des réseaux de routeur. Ces méthodes peuvent alléger les frais généraux d’administration dans les cas où le routage et la topologie sont relativement dynamiques. Une autre approche pourrait être d’utiliser des informations de filtre de préfixe entrant pour créer un filtre de paquets, qui autoriserait uniquement les paquets avec des adresses IP source pour lesquelles le réseau pourrait légitimement annoncer l’accessibilité.,

pour la plupart des architectures réseau plus petites et plus simples, le moyen le plus simple d’empêcher l’usurpation est d’utiliser le RPF Unicast (uRPF) en mode Strict. Pour filtrer les adresses source utilisées par les périphériques sur un domaine de couche 2, les améliorations de Validation D’adresse Source (SAVI) peuvent être utilisées. Sur les équipements où les fonctionnalités de filtrage automatique ne sont pas disponibles, vous pouvez utiliser les listes de contrôle d’accès (ACL) pour implémenter manuellement un filtrage équivalent. Toutes ces technologies sont expliquées ci-dessous.

4.3.1., Principes directeurs pour les Architectures Anti-Spoofing

Pour être aussi efficaces que possible, les techniques anti-spoofing doivent être appliquées aussi près que possible de la source. Dans les réseaux d’entreprise, les adresses sources utilisées par chaque périphérique sont souvent contrôlées et appliquées afin que les audits de sécurité puissent identifier exactement quel périphérique a envoyé quel paquet.

pour une implémentation réussie de MANRS, une granularité aussi fine au niveau du périphérique n’est pas nécessaire car MANRS se concentre sur la sécurité du routage et l’anti-usurpation au niveau du réseau., Par conséquent, les architectures anti-usurpation courantes se concentrent sur le fait que les clients n’envoient pas de paquets avec les mauvaises adresses source.

L’application de l’utilisation d’adresses source valides au niveau client présente l’avantage que les clients ne peuvent pas usurper les adresses de l’autre, ce qui les empêche de se causer des problèmes difficiles à déboguer.

Si, pour une raison quelconque, il n’est pas possible d’appliquer l’utilisation de l’adresse source par client, une alternative consiste à l’appliquer aux points d’agrégation afin que les clients soient au moins limités dans les adresses qu’ils peuvent usurper., Au minimum, il devrait y avoir une anti-usurpation au niveau du FAI afin que les clients ne puissent pas usurper les adresses d’autres organisations et causer des problèmes à L’échelle D’Internet.

4.3.2. Unicast RPF

BCP38 uRPF Strict Mode with rfc1998++ style of multihoming (un BCP pour multihoming) est une approche qui fonctionne dans des configurations symétriques (single homed) et asymétriques (multihomed BGP), et a été déployée pour la première fois en 2002. Oui, nombreux sont ceux qui pensent que « uRPF ne fonctionne pas à cause de l’asymétrie de routage”, mais ce n’est pas vrai., Documentation de 2001, le livre blanc ISP Essentials (Google pour la version 2.9) et le livre ISP Essentials (ISBN 1587050412) ainsi que des déploiements dans plusieurs SPs majeurs ont démontré que le mode strict uRPF est une technique viable.

il existe quatre algorithmes pour le mode uRPF – Strict (vérifier l’IP source et la contiguïté), le mode Loose (vérifier uniquement L’IP source), le chemin faisable (vérifier L’IP source avec les alternatives du FIB) et le mode VRF (autoriser / refuser la vérification de la source dans une table séparée du FIB)., Chacune de ces options uRPF est conçue pour des fonctions « anti-spoofing” spécifiques dans différentes parties du réseau.

• mode strict uRPF – BCP38 sur le bord client-SP. Chaque paquet entrant est testé contre le FIB et si l’interface entrante n’est pas le meilleur chemin inverse, le paquet est rejeté.
• mode lâche uRPF-sRTBH n’importe où dans le réseau – mais vérifiez seulement si l’itinéraire est dans le FIB. Si ce n’est pas dans le FIB, laissez tomber. Si c’est dans le FIB, alors passez. Bon pour sRTBH et atténuer un certain trafic usurpé sur le bord de peering.,
• uRPF chemin réalisable-sRTBH partout dans le réseau et BCP38 pour les clients multihomed et les itinéraires asymétriques. Dans le mode réalisable le FIB maintient des routes alternatives à une adresse IP donnée. Si l’interface entrante correspond à l’une des routes associées à l’adresse IP, le paquet est transféré. Sinon, le paquet est rejeté.
• mode uRPF VRF-application de la stratégie D’appairage basée sur BGP ou sRTBH plus granulaire (remarque le mode VRF peut être utilisé comme BCP38, mais n’a pas été prouvé sur le plan opérationnel)

uRPF peut être utile dans de nombreux endroits du réseau., Il est le plus souvent utilisé sur les bords des réseaux où les clients, les serveurs et/ou les clients sont connectés car le mode Strict y fonctionne bien. Les opérateurs de réseau hésitent à utiliser uRPF au cœur de leurs réseaux en raison de la peur de laisser tomber accidentellement le trafic valide qui a pris un chemin inattendu à travers leur réseau. le mode de chemin possible uRPF devrait résoudre de tels problèmes.

Cisco et Juniper mettent en application le mode strict et le mode lâche. Nous montrons comment utiliser le mode strict., Configurez le mode strict d’uRPF sur des interfaces vers des clients avec:

Cisco:

 ip verify unicast source reachable-via rx ipv6 verify unicast source reachable-via rx

Juniper:

 family inet { rpf-check; } family inet6 { rpf-check; }

qui s’assurera que le client peut seulement utiliser les adresses IP que vous conduisez vers eux. Dans les situations où vous êtes le client d’un autre ISP où vous avez une route par défaut pointant vers ce ISP vous devriez utiliser:

Cisco:

 ip verify unicast source reachable-via rx allow-default ipv6 verify unicast source reachable-via rx allow-default

Juniper:

Les routeurs Juniper adaptent automatiquement leur filtrage uRPF basé sur où toutes les routes par défaut pointent vers. Utilisez simplement les mêmes commandes que ci-dessus.,

l’option allow-default est nécessaire car par défaut, les adresses source ne seront appariées qu’avec des routes spécifiques, ignorant la route par défaut. Alors que la correspondance avec la route par défaut semble être la même que d’autoriser quoi que ce soit, ce n’est pas le cas. cela garantit que votre amont ne vous envoie pas de trafic pour lequel vous avez d’autres routes plus spécifiques pointant dans une direction différente, telles que vos propres réseaux et les réseaux de vos clients. Cela vous protégera contre le trafic usurpé des autres.

4.3.3., Liste d’accès dynamique (Radius & Diamètre)

la façon standard de définir des listes d’accès pour les utilisateurs authentifiés par Radius est par L’attribut Radius 11 (Filter-Id). Avec cet attribut, vous pouvez indiquer au routeur d’appliquer une liste d’accès préexistante à la connexion de l’utilisateur. Cela nécessite cependant une méthode hors bande pour provisionner tous les routeurs avec les listes d’accès correctes.

certains fournisseurs ont des options Radius supplémentaires qui peuvent être utilisées pour provisionner dynamiquement la liste d’accès elle-même via Radius., Cisco par exemple fournit la fonctionnalité supplémentaire par des attributs de cisco-avpair:

 cisco-avpair = "ip:inacl#5=permit ip 192.0.2.0 0.0.0.255 any" cisco-avpair = "ip:inacl#99=deny ip any any"

ceci permettrait seulement des paquets du client qui ont une adresse source dans la gamme 192.0.2.0/24.

4.3.4. SAVI

SAVI est le nom du groupe de travail de L’IETF qui travaille sur les améliorations de la Validation des adresses Source. Pour la validation de l’adresse source d’un client, la solution SAVI pour DHCP dans la RFC 7513 est couramment utilisée., Cette version de SAVI garde une trace de toutes les adresses IP qui ont été attribuées à chaque périphérique en fouinant sur les échanges de messages DHCPv4 et DHCPv6 sur le commutateur réseau auquel le client est connecté. Si un client utilise une adresse source non autorisée, le commutateur supprimera le paquet.

Les fournisseurs utilisent souvent leur propre terminologie pour décrire les fonctionnalités SAVI. Sur les périphériques Cisco ces caractéristiques sont appelées DHCP Snooping, Source Guard et Prefix Guard.

4.3.5., IP vérifient les réseaux Ethernet de la Source

sont des domaines d’émission, et par défaut il n’y a aucune validation de qui est autorisé à envoyer des paquets avec quelles adresses. Pour configurer des commutateurs Cisco pour vérifier les adresses source utilisées par les périphériques connectés, le paramètre « IP verify source » peut être utilisé.,

Il existe trois variantes de cette fonction:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security

La première variante vérifie l’adresse IP source, la deuxième variante permet également de vérifier l’adresse MAC source et la troisième variante, les pistes les liaisons entre adresse IP et adresse MAC. Pour empêcher les clients d’utiliser l’adresse MAC d’un autre client, la dernière variante est recommandée. Tous ceux-ci basent leur décision sur des données DHCP fouinées.,

avant de pouvoir vérifier les adresses source, le commutateur doit être configuré pour fouiner le trafic DHCP pour collecter des données sur lesquelles baser ses décisions avecip dhcp snooping. Pour garder une trace du port ethernet qui se connecte à chaque client DHCP, utilisez L’option DHCP 82 avec ip dhcp snooping information option. Ceci est nécessaire parce qu’avec vérifiez la port-sécurité le commutateur n’apprendra pas des adresses MAC jusqu’à ce que le serveur DHCP ait assigné une adresse IP au périphérique connecté. L’Option 82 est donc nécessaire pour rappeler au commutateur où le client a été connecté.,

plusieurs étapes sont nécessaires pour activer le suivi sécurisé des périphériques et vérifier leurs adresses source. La première étape consiste à activer le « suivi des périphériques ip” globalement sur le commutateur. Ceci s’assure que le commutateur peut dépister quelle adresse IP appartient à quelle adresse MAC. Ensuite, sur chaque interface, définissez le nombre de périphériques autorisés à se connecter avec ip device tracking maximum num où num peut être un nombre compris entre 1 et 10. Activez maintenant switchport port-security sur chaque interface pour vous assurer que seules les adresses MAC autorisées sont utilisées., Et enfin activez la fonctionnalité de vérification qui relie tous ces éléments avec ip verify source tracking port-security.

maintenant, le commutateur a toutes les informations dont il a besoin pour fouiner le trafic DHCP, lier les adresses IP aux adresses MAC et vérifier que tous les paquets envoyés par le commutateur sont conformes à l’état collecté qui est basé sur les réponses du serveur DHCP. Les paquets qui ne sont pas conformes à ce que le serveur DHCP a assigné seront abandonnés.

4.3.6. Source de câble-vérifiez

les réseaux de modem câble sont à bien des égards semblables aux réseaux ethernet., Sauf configuration contraire, les utilisateurs peuvent usurper les adresses source ou voler les adresses d’autres utilisateurs sur le réseau câblé. La caractéristique de Cisco cable source-verify permet à L’opérateur CMTS de limiter quelles adresses de source un utilisateur est autorisé à utiliser.

Il existe deux variantes de cette fonction:

● cable source-verify
● cable source-verify dhcp

les Deux variantes, d’affecter des adresses du câble sous-réseau du réseau sont autorisés à être utilisés. La première variante empêche uniquement les utilisateurs de voler les adresses des autres et n’est donc pas suffisante pour les MANRS., Nous allons regarder la deuxième variante.

la configuration decable source-verify dhcp indique au CMTS que toutes les adresses source doivent être vérifiées par rapport aux baux DHCP que le CMTS a vus. Si un paquet est envoyé avec une source différente, le CMTS le déposera. Cela empêchera les utilisateurs d’utiliser des adresses qui ne leur sont pas attribuées via DHCP .

des problèmes peuvent survenir lorsque le CMTS est rechargé. Dans un tel cas, le CMTS ne connaîtra pas tous les baux DHCP de ses utilisateurs et pourrait laisser tomber le trafic légitime. Pour résoudre ce problème, le CMTS peut être configuré pour utiliser le protocole DHCP LeaseQuery., Ceci permet au CMTS de demander au serveur DHCP au sujet des baux pour le trafic qu’il voit. Une fois que le serveur DHCP confirme qu’il existe un bail légitime pour cette adresse, le CMTS l’ajoutera à son cache et autorisera le trafic.

pour configurer le CMTS pour ne pas faire confiance à ARP sur le réseau câblé, configurez-le avecno cable arp. Cela garantira que seules les informations apprises à partir de DHCP et LeaseQuery sont fiables lors de la vérification des adresses source.

la fonctioncable source-verify protège UNIQUEMENT le sous-réseau du réseau câblé lui-même., Pour empêcher les utilisateurs d’usurper d’autres adresses et pour autoriser le trafic des clients qui ont un sous-réseau routé qu’ils sont autorisés à utiliser, configurez également ip verify unicast source reachable-via rx pour activer le mode strict uRPF sur le réseau câblé. Cela vérifiera toutes les adresses source qui ne sont pas directement sur le réseau câblé et permettra de valider par exemple les routes statiques pour les sous-réseaux routés vers les clients.

4.3.7., Liste de contrôle d’accès (ACL)

Les ACL sont généralement déployées sur la frontière Provider Edge (PE) – Customer Edge (Ce), mais sont également très utiles dans d’autres endroits comme vers les propres réseaux de serveur, de client et d’infrastructure du fournisseur pour empêcher les périphériques de se comporter mal. La stratégie ACL optimisée consisterait à placer un filtre d’autorisation explicite sur l’interface client. Les filtres d’autorisation explicites autorisent des plages d’adresses spécifiques, puis refusent tout le reste. Par exemple, si le client de L’opérateur est attribué 192.0.2.0/24, L’ACL BCP 38 autoriserait toutes les adresses source de 192.0.2.,0/24 et puis refusez tous les paquets dont l’adresse source n’est pas 192.0.2.0/24.

sur les interfaces en aval du FAI, il devrait y avoir des filtres qui vérifient les adresses source utilisées par ses clients. Si uRPF ne peut pas être utilisé, des ACL manuelles sont nécessaires. Prenons le premier client à partir de l’exemple du diagramme ci-dessus:

Cisco:

Genévrier:

4.3.7.1., Points d’agrégation

lorsque les ACL à la limite PE-CE ne sont pas possibles, par exemple parce que plusieurs clients sont connectés à un seul réseau layer-2 et que les périphériques layer-2 ne disposent pas des fonctionnalités nécessaires pour filtrer les informations layer-3, le filtrage à un point d’agrégation est la deuxième meilleure solution.

Dans cet exemple, il est (pour une raison quelconque) pas possible de filtrer sur l’ /24 pour chaque client. Dans ce cas, filtrage sur 192.0.2.0/23 et 198.51.100.,0/23 (et de même pour IPv6) à un point d’agrégation proche des connexions client limiterait au moins les possibilités d’usurpation pour ce groupe de clients à une petite plage d’adresses.

la Configuration est faite de la même manière que montrée dans la section précédente, excepté maintenant elle est faite sur un routeur différent dans un emplacement plus central dans le réseau.

4.3.8. Carrier Grade NAT-Nat est-il un outil Anti-usurpation?

par défaut, de nombreuses implémentations NAT ne filtrent pas l’adresse source des clients., Prenez par exemple une configuration NAT simple sur un routeur Cisco comme:

 ip nat inside source list INSIDE pool OUTSIDE overload

Cette règle NAT traduira les paquets avec une adresse source dans la liste d’accès à l’intérieur et changera l’adresse source en une adresse dans le pool à l’extérieur. Cependant, les paquets qui ont une adresse source usurpée qui n’est pas incluse dans la liste D’accès interne seront transférés sans aucune traduction, ce qui entraîne des paquets usurpés sur Internet., Lorsqu’un paquet usurpé correspond à la liste d’accès, il sera traduit à l’aide du pool spécifié, de sorte que le monde extérieur ne voit pas d’adresse source usurpée, mais il sera impossible pour l’opérateur NAT de retracer les paquets usurpés jusqu’à leur auteur.

cela montre que NAT n’est pas un outil anti-usurpation. Même lors de l’utilisation de NAT, les adresses sources utilisées par les clients doivent être vérifiées aussi près que possible du client, tout comme dans les cas sans NAT indiqués précédemment dans ce chapitre. Ce n’est qu’alors que les paquets usurpés et/ou introuvables peuvent être empêchés d’atteindre Internet.

4.3.9., Lecture supplémentaire