Routage et sécurité Quagga

J'ai un routeur quagga avec deux voisins de transit et annonçant mon propre espace IP. J'ai récemment rejoint un échange de peering public (IXP) et je fais donc partie de leur réseau local (/ 24), avec tous les autres participants. Jusqu'à présent, tout fonctionne bien.

Maintenant pour des raisons de sécurité, je me demande si les autres participants ne pourraient pas simplement acheminer tout leur trafic sortant à travers moi? Par exemple, que se passe-t-il si un autre participant pointe une route par défaut vers mon IP IXP. Si je comprends bien tout le trafic sortant de ce participant irait alors à mon routeur qui l'acheminerait vers Internet en utilisant ma liaison montante de transit, non?

Je me demande donc si je dois prendre des mesures contre cela. Mes idées sont:

1. Configurez des règles de pare-feu (iptables) de sorte que seul le trafic avec une destination de mon propre espace IP soit accepté par un autre participant IXP. Supprimez tout autre trafic provenant des participants IXP.

2. D'une manière ou d'une autre, quagga utilise une table de routage du noyau différente pour chaque voisin (ou groupe de pairs). La table de routage pour les voisins IXP ne contiendrait aucune entrée à l'exception de mon propre espace IP et donc aucun routage utilisant mes liaisons montantes de transit IP ne se produirait. En regardant la sortie des ip rule showémissions, quagga ne le fait pas automatiquement?

Suis-je sur la bonne voie? Pourquoi n'est-il pas 2. implémenté directement dans Quagga? Comment les routeurs matériels (Cisco, Juniper, ..) gèrent-ils ce problème?

Vous avez raison, si vous ne prenez aucune mesure, cela pourrait arriver. C'est une violation de la politique d'utilisation acceptable de la plupart des IXP que je connais, mais vous voulez toujours empêcher que cela se produise.

Votre première solution est une bonne chose à faire et résoudra votre problème. Assurez-vous simplement de ne pas suivre l'état de la session dans iptables, cela tuera probablement les performances ou même votre routeur.

Vous pouvez également envisager de faire un filtrage sortant de la même manière: n'autorisez pas les paquets à quitter votre réseau en provenance de sources inconnues. Cela empêchera les hôtes de votre réseau d'envoyer des paquets IP usurpés, qui sont couramment utilisés dans les attaques DDoS.

Je n'implémenterais pas la deuxième solution. C'est compliqué et n'évolue pas bien si vous avez plusieurs routeurs gérant vos transits et vos pairs ou si vous avez un grand nombre de sessions d'appairage (quelques centaines sur un IXP ne sont pas rares).

Sur toutes les plates-formes de routeur matériel, je sais que ce problème est résolu dans la configuration en configurant RPF sur l'interface sortante et / ou en écrivant des filtres.

Si vous exécutez Quagga sur une machine Linux, vous pouvez activer RPF en définissant le paramètre du noyau net.ipv4.conf.default.rp_filtersur 1 ou 2.

Veuillez consulter cette page pour plus de détails: http://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filtering

Pour autant que je comprends, vous avez 2 connexions à des fournisseurs de transit et 1 connexion à un point de peering, dans cette situation, je suppose que vous utilisez BGP pour homologue avec vos fournisseurs de transit et avec un routeur IXP.

Le fonctionnement de BGP est que les autres ne peuvent atteindre que les destinations que vous leur annoncez. Ainsi, par exemple, vous avez un / 24 et vous en ferez la publicité auprès de vos fournisseurs de transit afin que les hôtes sur Internet puissent vous joindre par vos pairs de transit et vous feriez également la publicité de votre / 24 au point de peering afin que les hôtes connectés au point de peering puissent vous joindre directement sans passer par Internet (car cela serait considéré comme le meilleur chemin).

Pour les sessions BGP, vous filtreriez normalement ce que vous annoncez à vos pairs et ce qu'ils vous annoncent (si vous avez des pairs en aval) avec une liste de préfixes par exemple. En règle générale, vous ne filtrerez pas les entrées de l'échange de peering car l'échange ne vous enverra que des itinéraires de personnes connectées à l'échange. Ceci est similaire à vos fournisseurs de transit, sauf qu'ils vous enverront généralement la table de routage globale complète (toutes les destinations sur Internet).

Dans cette situation, vous ajouteriez une liste de préfixes correspondant à une ACL dans le sens sortant sur la session BGP connectée au point de peering pour publier uniquement votre préfixe / 24, cela permettra aux hôtes de l'échange de peering d'atteindre uniquement les IP de votre / 24 via votre routeur (ce que vous voulez).

Si quelqu'un vous annonce un itinéraire par défaut et que vous l'acceptez, vous n'allez pas prendre son trafic et l'envoyer sur Internet. Dans cette situation, vous verriez un itinéraire vers Internet via eux, car votre routeur verra un itinéraire vers 0.0.0.0/0 (Internet) via eux, car ils vous l'ont annoncé.

La seule fois où les hôtes connectés à l'échange de peering verront Internet via vous, c'est si vous annoncez vous-même un itinéraire par défaut sur l'échange. La seule autre fois où vous pouvez être utilisé comme «AS de transit» est si vous avez des clients qui sont des pairs en aval avec vous et qui vous demandent d'annoncer leur espace IP à l'IXP afin qu'ils puissent atteindre la bourse par votre intermédiaire.