Internet s’est toujours appuyé sur la coopération et le partage pour fonctionner. Il est donc important d’avoir une communauté qui se mette d’accord sur des principes de fonctionnement et d’échanges d’informations. Plusieurs documents formalisent ces principes et définissent les bonnes pratiques opérationnelles (BCOP en anglais). Afin de soutenir la croissance d’Internet malgré les attaques et les incidents, une nouvelle BCOP est en cours d’élaboration. Il s’agit de MANRS (Mutually Agreed Norms for Routing Security, normes adoptées mutuellement pour la sécurité du routage) et elle définit 4 principes :

  • Reconnaître l’interdépendance vis-à-vis des autres opérateurs, par la nature même d’Internet, et le rôle que chacun doit jouer pour conserver un réseau en état de fonctionnement.
  • Intégrer et appliquer les bonnes pratiques relatives à la sécurité globale du réseau.
  • S’astreindre à prévenir, détecter, réduire l’apparition, la durée et la portée les incidents de routage et collaborer avec les autres
    opérateurs.
  • Encourager et former ses clients et partenaires à l’adoption de ces bonnes pratiques opérationnelles.

Le document publié début octobre met en avant plusieurs actions.

Documentation

Le but de ces actions est de faciliter la communication avec les autres opérateurs.

C’est probablement l’aspect le plus important car toute personne configurant un réseau peut effectuer des mauvaises manipulations sans s’en apercevoir immédiatement et un œil extérieur doit pouvoir donner l’alerte pour corriger.

Maintenir les bases IRR à jour

Les bases IRR (Internet Routing Registry) permettent à tous les utilisateurs de savoir à qui appartient une adresse IP, un réseau ou un numéro d’AS mais également quel(s) réseau(x) annonce un ASN et d’avoir un contact en cas d’incident. Typiquement la base de données de RIPE NCC est un IRR.

Avoir des enregistrements à jour permet à tous les opérateurs de construire des filtres (avec bgpq3 par exemple) afin de réduire l’effet d’une erreur de configuration qui déclencherait l’annonce de toutes les routes d’Internet à tous les opérateurs voisins.

Avoir des contacts à jour dans ces bases permet de faciliter la prise de contact en cas d’incident et donc de corriger plus rapidement un problème.

Maintenir un compte PeeringDB

PeeringDB est un service permettant de publier ses informations de peering (POP, politique, etc.). Avoir un compte à jour permet aux autres opérateurs de gagner du temps dans la recherche du bon contact (accès au NOC ou demande de peering).

Filtrage

Le but de ces actions est de limiter la propagation d’une erreur de routage.

Filtrer en entrée

Il y’a deux niveaux de filtrage en entrée.

Le premier concerne BGP. Les préfixes reçus par BGP doivent être valides (ASx est légitime pour annoncer le préfixe Y), de même que l’AS-PATH (pas d’ASN privé dans le chemin). De plus, un pair qui n’est sensé envoyer qu’un faible nombre de routes doit être limité grâce à une directive de type maximum-prefix.

Le second niveau de filtrage se fait sur les interfaces des routeurs avec des ACL. Il est également conseillé d’activer uRPF. Les ACL doivent permettre de s’assurer que les IP sources sont légitimes (anti-usurpation) et que toutes les IP destinations vont pouvoir être acheminées (anti-rebond).

Les serveurs de routes d’AuvernIX annoncent des préfixes filtrés.

Filtrer en sortie

Comme pour le filtrage en entrée, les deux mêmes niveaux sont applicables.

Au niveau BGP, seuls les préfixes légitimes sont annoncés aux pairs (les préfixes IXP ne doivent pas êtres annoncés). Les communautés « trou noir » doivent être respectées.

Le filtrage des paquets par ACL en sortie est identique au filtrage en entrée (anti-usurpation d’IP source et IP de destination légitime).

Validation

Le but de cette action est de permettre aux autres opérateurs de valider les réseaux annoncés par un ASN afin de vérifier que ce ne sont pas des erreurs ni des détournements.

Grâce à une infrastructure à clé publique (RPKI) gérée par les RIR typiquement, les opérateurs signent numériquement leurs annonces BGP (ROA). Ainsi chaque routeur peut déterminer si une route reçue est légitime et le cas-échéant prendre la décision d’accepter, refuser ou prioriser une route. Dans le cas où un administrateur réseau utilisant RPKI+ROA fait une erreur de configuration, l’annonce ne sera pas propagée.

 


Sources :