Magic Transit rend votre réseau plus intelligent, meilleur, plus fort et moins coûteux à exploiter

Aujourd’hui, nous sommes ravis d’annoncer Cloudflare Magic Transit. Magic Transit fournit une connectivité IP sécurisée, performante et fiable à Internet. Prêt à l'emploi, Magic Transit déployé devant votre réseau sur site le protège des attaques DDoS et permet de fournir une suite complète de fonctions de réseau virtuel, notamment des outils avancés de filtrage de paquet, d'équilibrage de charge et de gestion du trafic.

Magic Transit est construit sur les normes et les primitives de réseau que vous connaissez bien, mais est fourni à partir du réseau périphérique mondial de Cloudflare en tant que service. Le trafic est absorbé par le réseau Cloudflare avec anycast et BGP, annonçant l’espace d’adresse IP de votre société et étendant votre présence réseau à l’échelle mondiale. Aujourd'hui, notre réseau périphérique anycast couvre 193 villes dans plus de 90 pays du monde.

Une fois que les paquets ont touché notre réseau, le trafic est inspecté pour détecter les attaques, filtré, dirigé, accéléré et envoyé à l'origine. Magic Transit se reconnectera à votre infrastructure d'origine via des tunnels d’Encapsulation de routage générique (GRE), des interconnexions de réseau privé (PNI) ou d'autres formes de peering.

Les entreprises sont souvent obligées de choisir entre performances et sécurité lors du déploiement de services de réseau IP. Magic Transit est conçu dès le départ pour minimiser ces compromis : performance et sécurité vont de paire. Magic Transit déploie des services de sécurité IP sur l'ensemble de notre réseau mondial. Cela signifie qu'il ne faut plus rediriger le trafic vers un petit nombre de « centres de nettoyage » distants, ni compter sur du matériel sur site pour limiter les attaques de votre infrastructure.

Nous préparons le terrain pour Magic Transit depuis que Cloudflare existe, depuis 2010. La mise à l'échelle et la sécurisation du réseau IP sur lequel Cloudflare est construit a nécessité un outillage qui aurait été impossible d’obtenir ou dont le prix d'achat aurait été exorbitant. Nous avons donc construit les outils nous-mêmes ! Nous avons grandi à l'ère du software-defined networking et de la virtualisation des fonctions réseau, et les principes à la base de ces concepts modernes régissent tout ce que nous faisons.

Lorsque nous discutons avec nos clients qui gèrent des réseaux sur site, nous entendons toujours quelques remarques : la construction et la gestion de leurs réseaux est coûteuse et pénible, et ces réseaux sur site ne sont pas prêts de disparaître.

Généralement, les CIO essayant de connecter leurs réseaux IP à Internet le font en deux étapes :

1. Connectivité source à Internet à partir de fournisseurs de transit (ISP).

2. Acheter, exploiter et entretenir des dispositifs matériels propres aux fonctions réseau. Penser aux équilibreurs de charge matérielle, aux pare-feux, aux équipements d’atténuation des attaques DDoS, à l’optimisation du WAN, et plus encore.

L’entretien de chacune de ces boîtes coûte du temps et de l'argent, sans parler des personnes qualifiées et coûteuses nécessaires pour les faire fonctionner correctement. Chaque lien supplémentaire dans la chaîne rend un réseau plus difficile à gérer.

Tout cela nous semblait familier. Nous avons eu un moment de satisfaction : nous avons eu les mêmes problèmes pour gérer nos réseaux de centres de données qui alimentent l’ensemble de nos produits, et nous avions consacré beaucoup de temps et d’efforts à la recherche de solutions à ces problèmes. Neuf ans plus tard, nous disposions d'un ensemble d'outils performants que nous pourrions transformer en produits destinés à nos propres clients.

Magic Transit a pour objectif d'intégrer le modèle matériel traditionnel de centre de données dans le cloud, de regrouper les transits avec tout le « matériel » de réseau dont vous pourriez avoir besoin pour maintenir votre réseau rapide, fiable et sécurisé. Une fois déployé, Magic Transit permet un provisionnement transparent des fonctions réseau virtualisées, notamment des services de routage, d’atténuation des attaques DDoS, de pare-feux, d’équilibrage de la charge et d’accélération du trafic.

Magic Transit offre des avantages en termes de connectivité, de sécurité et de performance en servant de « porte d'entrée » à votre réseau IP. Cela signifie qu'il accepte les paquets IP destinés à votre réseau, les traite, puis les envoie à votre infrastructure source.

La connexion à Internet via Cloudflare offre de nombreux avantages. En commençant par le plus élémentaire, Cloudflare est l’un des réseaux les plus largement connectés d’Internet. Nous travaillons avec des partenaires opérateurs, des centraux Internet et de peering dans le monde entier pour nous assurer qu'un bit placé sur notre réseau atteindra sa destination rapidement et de manière fiable, quelle que soit sa destination.

Voyons comment un client peut déployer Magic Transit. Le client Acme Corp. est propriétaire du préfixe IP 203.0.113.0/24, qu’il utilise pour s’adresser à un rack de matériel qu’il exécute dans son propre centre de données physiques. Acme annonce actuellement des itinéraires vers Internet à partir de son équipement à l'abonné (CPE, aka ou routeur situé à la périphérie de son centre de données), en indiquant au monde que 203.0.113.0/24 est accessible depuis son numéro de système autonome, AS64512. Acme dispose d’appareils de protection contre les attaques DDoS et de pare-feux sur site.

Acme souhaite se connecter au réseau Cloudflare pour améliorer la sécurité et les performances de son propre réseau. Plus précisément, ils ont été la cible d’attaques de déni de service distribué et souhaitent se reposer la nuit sans recourir à du matériel sur site. C'est là qu'intervient Cloudflare.

Déployer Magic Transit devant leur réseau est simple :

1. Cloudflare utilise le Border Gateway Protocol (BGP) pour annoncer le préfixe 203.0.113.0/24 d’Acme à partir du périphérique de Cloudflare, avec l’autorisation de Acme.

2. Cloudflare commence à ingérer les paquets destinés au préfixe Acme IP.

3. Magic Transit applique les règles d'atténuation des attaques DDoS et de pare-feux au trafic réseau. Une fois qu'il est ingéré par le réseau Cloudflare, le trafic qui doit bénéficier de la mise en cache HTTPS et de l'inspection WAF peut être « mis à niveau » vers notre pipeline HTTPS de couche 7 sans générer de sauts de réseau supplémentaires.

4. Acme aimerait que Cloudflare utilise l’Encapsulation de routage générique (GRE) pour réacheminer le trafic du réseau Cloudflare jusqu'au centre de données d'Acme. Les tunnels GRE sont lancés à partir des points de terminaison anycast et retournent chez Acme. Grâce à la magie d'anycast, les tunnels sont connectés en permanence et simultanément à des centaines d'emplacements de réseau, garantissant ainsi une grande disponibilité et une grande résilience des tunnels aux pannes de réseau qui pourraient détruire les tunnels GRE habituellement formés.

5. Cloudflare livre les paquets destinés à Acme sur ces tunnels GRE.

Voyons maintenant comment fonctionne l’atténuation des attaques DDoS incluse dans Magic Transit.

Les clients qui déploient Cloudflare Magic Transit ont instantanément accès au même système de protection contre les attaques DDoS de couche IP qui protège le réseau Cloudflare depuis 9 ans. C'est le même système d'atténuation qui a tué dans l’œuf une attaque de 942 Gbps, en quelques secondes. C’est le même système d’atténuation qui a su arrêter les attaques par amplification memcached plusieurs jours a_vant_ qu’une attaque de 1,3 Tbps ne détruise Github, qui n’était pas protégé par Cloudflare. C’est la même atténuation que nous utilisons tous les jours pour protéger Cloudflare. Et elle protège désormais votre réseau.

Cloudflare a toujours protégé les applications HTTP et HTTPS de la couche 7 contre les attaques de toutes les couches du modèle de couche OSI. La protection contre les attaques DDoS que nos clients ont appris à connaître et à aimer repose sur un mélange de techniques, mais peut être décomposée en quelques défenses complémentaires :

1. Anycast et une présence réseau dans 193 villes du monde entier permettent à notre réseau de se rapprocher des utilisateurs et des pirates, nous aidant ainsi à absorber le trafic à proximité de la source sans introduire de latence importante.

2. Une capacité de réseau de plus de 30 Tbps nous permet d’absorber beaucoup de trafic à proximité de la source. Le réseau de Cloudflare dispose d'une plus grande capacité pour arrêter les attaques DDoS que celles d'Akamai Prolexic, Imperva, Neustar et Radware, toutes combinées.

3. Notre proxy inverse HTTPS absorbe les attaques L3 (couche IP) et L4 (couche TCP) en mettant fin aux connexions et en les rétablissant à l'origine. Cela empêche la plupart des transmissions de paquets parasites et empêche ainsi à ces derniers de s'approcher du serveur d'origine du client.

4. Les atténuations de la couche 7 et les flux limites de la couche d’application HTTPS.

En regardant attentivement la description ci-dessus, vous remarquerez peut-être quelque chose : nos serveurs proxy inverses protègent nos clients en mettant fin aux connexions, mais notre réseau et nos serveurs sont toujours fermés par les attaques L3 et 4 que nous arrêtons pour le compte de nos clients. Comment protégeons-nous notre propre infrastructure contre ces attaques ?

Entrez dans Gatebot !

Gatebot est un ensemble de logiciels exécutés sur chacun de nos serveurs dans chacun de nos centres de données situés dans les 193 villes que nous exploitons, analysant et bloquant en permanence le trafic des attaques. Une partie de la beauté de Gatebot réside dans son architecture simple. Il attend en silence, échantillonne les paquets au fur et à mesure qu'ils passent de la carte réseau au noyau, puis dans l'espace utilisateur. Gatebot n'a pas de période d'apprentissage ou d’échauffement. Dès qu'il détecte une attaque, il demande au noyau de la machine sur laquelle il est exécuté de supprimer le paquet, de consigner sa décision et continuer.

Par le passé, si vous vouliez protéger votre réseau contre les attaques DDoS, vous deviez peut-être acheter un matériel spécialisé pour le placer à la périphérie de votre réseau. Cette boîte matérielle (appelons-la « boîte de protection contre les attaques DDoS ») aurait été incroyablement chère, jolie à regarder (aussi jolie qu'une boîte matérielle 2U pourrait l'être), et nécessiterait beaucoup d'efforts permanents et beaucoup d'argent pour son entretien, maintenir sa licence à jour et garder son système de détection d’attaques précis et adapté.

D'une part, il faudrait la surveiller attentivement pour s'assurer qu'elle arrête les attaques mais pas le trafic légitime. D'autre part, si un pirate réussissait à générer suffisamment de trafic pour saturer les liens de transit de votre centre de données vers Internet, vous n'aviez aucune chance. Aucune boîte à l'intérieur de votre centre de données ne peut vous protéger d'une attaque générant suffisamment de trafic pour encombrer les liens allant du monde extérieur au centre de données lui-même.

Dès le début, Cloudflare a envisagé d’acheter la ou les boîte(s) de protection contre les attaques DDoS, afin de protéger nos différents emplacements réseau, mais les a rapidement écartés. L’achat de matériel aurait entraîné des coûts et une complexité considérables. De plus, l'achat, le nettoyage de grille et la gestion de matériel spécialisé rendent un réseau difficile à déployer. Il devait y avoir un meilleur moyen. Nous avons entrepris de résoudre ce problème nous-mêmes, à partir des principes de base et de la technologie moderne.

Pour que notre approche moderne d’atténuation des attaques DDoS fonctionne, nous avons dû inventer un ensemble d’outils et de techniques nous permettant d’effectuer une mise en réseau ultra-performante sur un serveur générique x86 fonctionnant sous Linux.

Au cœur de notre plan de données réseau se trouvent eXpress Data Path (XDP) et le filtre de paquets de Berkeley (eBPF), un ensemble d’API qui nous permettent de créer des applications réseau extrêmement performantes dans le noyau Linux. Mes collègues ont longuement écrit sur comment nous utilisons XDP et eBPF pour arrêter les attaques DDoS:

• L4Drop : Atténuations XDP DDoS

• xdpcap : Capture de paquet XDP

• Présentation d'atténuation DoS basée sur XDP

• XDP en pratique : intégration de XDP dans notre pipeline d’atténuation des attaques DDoS (PDF)

• Architecture Cloudflare et comment BPF ronge le monde

À la fin de nos travaux, nous avons abouti à un système d’atténuation des attaques DDoS qui :

• est livré par l'ensemble de notre réseau, réparti dans 193 villes du monde entier. En d'autres termes, notre réseau n'intègre pas le concept de « centres de nettoyage ». Chacun de nos sites réseau atténue constamment les attaques. Cela signifie une réduction plus rapide des attaques et un effet minimal sur la latence pour vos utilisateurs.

• doté des temps d’une rapidité exceptionnelle pour atténuer, la plupart des attaques étant atténuées en 10 secondes ou moins.

• a été construit en interne, ce qui nous a permis de mieux comprendre son comportement et de développer rapidement de nouvelles atténuations à mesure que de nouveaux types d'attaques se manifestent.

• est déployé en tant que service et est évolutif sur le plan mondial. L'ajout de matériel x86 exécutant notre pile logicielle de réduction des attaques DDoS dans un centre de données (ou l'ajout d'un autre emplacement réseau) fournit instantanément une plus grande capacité de réduction des attaques DDoS en ligne.

Gatebot est conçu pour protéger l'infrastructure Cloudflare contre les attaques. Et, aujourd'hui, dans le cadre de Magic Transit, les clients exploitant leurs propres réseaux et infrastructures IP peuvent compter sur Gatebot pour protéger leur propre réseau.

Nous avons expliqué comment Cloudflare Magic Transit connecte votre réseau à Internet et comment il vous protège des attaques DDoS. Si vous utilisiez votre réseau à l’ancienne, c’est ici que vous allez cesser d’acheter du matériel de pare-feu et peut-être une autre boîte pour équilibrer la charge.

Avec Magic Transit, vous n’avez pas besoin de ces boîtes. Nous avons une longue expérience en matière de fourniture de fonctions réseau communes (pare-feu, équilibreurs de charge, etc.) à titre de service. Jusqu’à présent, les clients qui déployaient nos services s’appuyaient sur le système DNS pour acheminer le trafic jusqu’à notre périphérie, après quoi nos piles de couche 3 (IP), couche 4 (TCP & UDP) et couche 7 (HTTP, HTTPS et DNS) prennent le relais et garantissent la performance et la sécurité à nos clients.

Magic Transit est conçu pour gérer l’ensemble de votre réseau, mais n’impose pas une approche unique pour déterminer quels services doivent être appliqués à quelle partie de votre trafic. Pour revisiter Acme, notre exemple de client cité ci-dessus, ils ont transféré 203.0.113.0/24 sur le réseau Cloudflare. Cela représente 256 adresses IPv4, dont certaines (par exemple, 203.0.113.8/30) peuvent charger frontalement des équilibreurs de charge et des serveurs HTTP, d'autres, les serveurs de messagerie et d'autres encore, des applications UDP personnalisées.

Chacune de ces sous-plages peut avoir différentes exigences en matière de sécurité et de gestion du trafic. Magic Transit vous permet de configurer des adresses IP spécifiques avec leur propre ensemble de services ou d'appliquer la même configuration à de grandes portions (ou à toutes) de votre bloc.

En prenant l’exemple ci-dessus, Acme peut souhaiter que le bloc 203.0.113.8/30 contenant les services HTTP précédés d’un équilibreur de charge matériel traditionnel déploie plutôt l’équilibreur de charge Cloudflare et souhaiter également que le trafic HTTP soit analysé avec le WAF de Cloudflare et le contenu mis en cache par notre CDN. Avec Magic Transit, le déploiement de ces fonctions réseau est simple : en quelques clics dans notre tableau de bord ou grâce à quelques appels API, votre trafic sera traité sur une couche d'abstraction réseau supérieure, avec tous les « attendant goodies » appliquant l’équilibrage de la charge au niveau de l’application, le pare-feu et la logique de mise en cache.

Ce n'est qu'un exemple de déploiement que les clients pourraient rechercher. Nous avons travaillé avec plusieurs personnes qui ne souhaitent que le relais IP pur, avec l’atténuation des attaques DDoS appliquée à des adresses IP spécifiques. Volez-vous ça ? Nous vous tenons !

Lorsque vous connectez votre réseau à Cloudflare Magic Transit, vous accédez à l’ensemble du réseau Cloudflare. Cela signifie que tous nos emplacements réseau deviennent vos emplacements réseau. La capacité de notre réseau devient la capacité de votre réseau, à votre disposition pour alimenter vos expériences, livrer votre contenu et limiter les attaques de votre infrastructure.

Quelle est l'étendue du réseau Cloudflare ? Nous sommes situés dans 193 villes du monde, avec plus de 30Tbps de capacité de réseau réparties à travers celles-ci. Cloudflare fonctionne en moins de 100 millisecondes de 98 % de la population connectée à Internet dans les pays développés et 93 % de la population connectée à Internet dans le monde (pour mieux comprendre, le clin d’œil est de 300 à 400 millisecondes).

Zones du globe situées à moins de 100 millisecondes d’un centre de données Cloudflare.

Tout comme nous avons construit nos propres produits en interne, nous avons également construit notre réseau en interne. Chaque produit s'exécute dans chaque centre de données, ce qui signifie que l'ensemble de notre réseau fournit tous nos services. Ce n’aurait peut-être pas été le cas si notre portefeuille de produits avait été assemblé de manière parcellaire par le biais d’acquisitions ou si nous n’avions pas une vision complète lorsque nous avons décidé de créer notre gamme de services actuelle.

Le résultat final pour les clients de Magic Transit : une présence réseau à travers le monde dès votre intégration. Accès complet à un ensemble diversifié de services dans le monde entier. Tous livrés avec latence et performance.

Nous communiquerons beaucoup plus de détails techniques sur comment nous livrons Magic Transit au cours des semaines et des mois à venir.

Les services de réseau traditionnels ne sont pas bon marché. Ils nécessitent des dépenses en capital élevées au départ, des investissements en personnel pour fonctionner et des contrats de maintenance en cours pour rester fonctionnelles. Tout comme notre produit vise à révolutionner sur le plan technique, nous voulons également révolutionner les structures de coût de réseau traditionnelles.

Magic Transit est livré et facturé en tant que service. Vous payez pour ce que vous utilisez et vous pouvez ajouter des services à tout moment. Votre équipe vous remerciera pour sa gestion facile, votre direction vous remerciera pour sa facilité de comptabilité. Cela nous paraît bien !

Au cours des neuf dernières années, nous avons travaillé sans relâche pour que notre réseau, nos outils de gestion et nos fonctions de réseau deviennent un service dans l'état où ils se trouvent aujourd'hui. Nous sommes ravis de fournir aux clients les outils que nous utilisons tous les jours.

Donc, cela nous amène au nom. Lorsque nous avons montré cela aux clients, le mot le plus couramment utilisé était « whoa ». Lorsque nous les avons questionné sur ce qu'ils entendaient par là, ils ont presque tous dit : « C’est tellement mieux que toutes les solutions que nous avons vues auparavant. C'est magique ! » Il semble donc tout à fait naturel, si cela est un peu ringard, que nous appelions ce produit ce qu’il est : Magic Transit.

Tout comme vous, nous pensons que tout cela est assez magique. Contactez notre équipe commerciale dès aujourd'hui.