Trois garde-fous qui empêchent une passerelle BGP client de fuir des routes

Une passerelle dédiée par client, que nous construisons et exploitons, en peering interne avec notre passerelle de politique sur des numéros d'AS privés, est la bonne conception : isolation, une politique qui leur appartient, et un routage qui s'adapte de lui-même. Le BGP est interne à notre plateforme, pas une session que le client exploite. Cela signifie aussi que vous faites désormais tourner beaucoup de petits speakers BGP, et qu'un seul réglage imprudent sur l'un d'eux peut annoncer des routes qu'il ne devrait jamais annoncer. Cet article explique comment cela arrive et les trois garde-fous que nous posons sur chaque passerelle client pour que ce soit impossible.

Pourquoi les passerelles par client parlent BGP

Un concentrateur VPN partagé avec des routes statiques paraît plus simple, jusqu'au jour où il faut ajouter un sous-réseau, déplacer un client entre firewalls, ou survivre à la panne d'une passerelle. Avec une passerelle dédiée par client, chacune exécutant un AS privé à l'intérieur de notre plateforme et en peering avec une passerelle de politique centrale, ajouter un réseau est une annonce, et perdre un chemin est un retrait qui converge tout seul. La politique du client reste à la périphérie du client, et la politique de transit reste centrale.

Le prix est que chaque passerelle est désormais capable d'influencer le routage pour tout le monde. Il lui faut donc des garde-fous qui ne dépendent de la prudence de personne.

Comment les fuites se produisent réellement

Dans la plupart des post-mortems publiés, la cause d'une fuite de routes depuis un équipement de périphérie est rarement un bug BGP exotique. C'est la redistribution. Quelqu'un active « redistribute connected » ou « redistribute static » pour s'épargner de la frappe, et la passerelle se met à annoncer son propre lien WAN, son pool de tunnels VPN, un sous-réseau de gestion, ou une route apprise ailleurs. Sur un firewall open source avec un démon de routage, cette option est souvent à une case à cocher de distance.

Une fois qu'une route fuitée est acceptée en amont, le trafic pour ce préfixe peut être attiré vers la mauvaise passerelle, ou le réseau d'un client peut devenir joignable depuis des endroits où il ne devrait pas l'être. Rien ne plante ; le trafic va simplement quelque part d'inattendu.

Garde-fou un : annoncer avec des instructions network explicites

Une passerelle doit annoncer exactement les préfixes qui appartiennent au client, listés un par un, et rien d'autre. Dans FRR, qui se trouve sous bien des plugins de routage de firewalls, cela ressemble à :

router bgp 64601
 bgp router-id 10.0.0.2
 neighbor 10.0.0.1 remote-as 64600
 address-family ipv4 unicast
  network 198.51.100.0/27
  neighbor 10.0.0.1 prefix-list CUSTOMER-OUT out
 exit-address-family

L'instruction network n'annonce un préfixe que s'il est réellement présent dans la table de routage, donc une faute de frappe n'annonce rien plutôt que quelque chose de faux.

Garde-fou deux : une prefix-list sortante qui correspond

Ceinture et bretelles. Même avec des instructions network explicites, une prefix-list sortante n'autorise que les propres préfixes du client et refuse tout le reste :

ip prefix-list CUSTOMER-OUT seq 10 permit 198.51.100.0/27
ip prefix-list CUSTOMER-OUT seq 100 deny any

Si quelque chose tente un jour d'annoncer davantage, cette liste le rejette à la sortie. Reflétez-la aussi du côté récepteur : la passerelle centrale n'accepte de chaque client que les préfixes assignés à ce client.

Garde-fou trois : aucune redistribution, et vérifier qu'elle le reste

La redistribution est désactivée, et cela fait partie de la configuration que vous vérifiez, pas d'une hypothèse. Sur FRR, la vérification tient en une ligne :

vtysh -c 'show running-config' | grep -i redistribute

Un résultat vide est le seul résultat acceptable. Parce que certaines interfaces de firewall exposent la redistribution comme une case à cocher pratique, cette vérification appartient à votre validation de construction, pas seulement à la conception d'origine.

Comparez à une passerelle connue comme bonne avant la livraison

Trois garde-fous empêchent les fuites. Ils n'empêchent pas l'autre défaillance courante des passerelles par client : un réglage qui diffère des passerelles qui fonctionnent, provoquant un VPN qui « ne se connecte pas » ou qui se connecte sans rien atteindre. Une règle pass manquante pour le port VPN sur l'interface WAN, un NAT sortant laissé en mode automatique, une règle d'interface plus restrictive que prévu, une option d'authentification subtilement différente : chacune est facile à manquer à l'œil.

Le remède est mécanique. Configurez chaque passerelle par son API, jamais à la main, puis tirez les mêmes réglages d'une passerelle de référence éprouvée et de la nouvelle et comparez-les champ par champ :

• Réglages de l'instance VPN : protocole, port, chiffrements, mode d'authentification, routes et DNS poussés.
• Règles de firewall WAN pour le port VPN et les diagnostics.
• Règles sur l'interface VPN elle-même.
• Mode et règles du NAT sortant.
• Configuration BGP, y compris le champ de redistribution.

Toute différence qui n'est pas explicitement attendue pour ce client bloque la livraison. Aucun identifiant ne quitte le bâtiment tant que la comparaison n'est pas propre. Cela prend quelques secondes et remplace un après-midi de dépannage à distance avec un utilisateur qui veut juste travailler.

Un accès par personne, fait correctement

Un certificat client par personne, signé par une autorité de certification qui appartient au client, plus un identifiant, signifie qu'un portable perdu est un certificat révoqué et que personne d'autre n'est affecté. Une adresse de tunnel fixe par personne permet à la politique du firewall de suivre un individu d'un appareil à l'autre.

Liste de contrôle pour vos propres passerelles

• Chaque préfixe client est-il annoncé par une instruction network explicite ?
• Y a-t-il une prefix-list sortante sur chaque session client, et une entrante correspondante au centre ?
• Un grep de redistribute revient-il vide sur chaque passerelle ?
• Les passerelles sont-elles configurées par une API, avec le résultat comparé à une référence connue comme bonne avant la livraison ?
• L'accès distant est-il par personne, avec des certificats que vous pouvez révoquer individuellement ?

Chaque passerelle client que nous construisons porte ces garde-fous, sur son propre segment et son propre firewall. Si vous voulez un accès privé à votre plateforme construit de cette façon, nous vous aiderons volontiers.

Parler à un ingénieur

Related (rows[1])

Voir aussi : Connectivité privée : passerelles VPN et liaisons louées · Firewalls de périmètre infogérés · Backbone chiffré multi-sites : le maillage DMVPN