Rapport annuel sur la sécurité et la disponibilité du réseau de Qrator Labs



Nous avons une tradition dans les laboratoires Qrator - au début, et février n'est certainement pas la fin, publions chaque année un rapport sur l'année précédente.

Comme toute entité pérenne, elle est entourée de nombreuses histoires liées. Par exemple, il est déjà devenu un "bon" présage lorsqu'au début du mois de janvier une autre attaque DDoS arrive sur nos pages d'entreprise, que nous n'avons pas le temps de discerner dans le rapport. 2020 était la moitié de l'exception - nous avons réussi à décrire le vecteur d'attaque (amplification TCP SYN-ACK), mais c'est pour nous, sur qrator.net, que l'invité est venu (et pas un) seulement le 18 janvier, mais immédiatement avec les invités: 116 Gbps à 26 Mpps.

Il faut avouer que raconter les événements de l'année écoulée est un genre spécifique. Par conséquent, nous avons décidé dans le processus de réflexion de nous concentrer sur ce qui se passera - principalement avec notre équipe et nos produits - cette année, alors ne soyez pas surpris de lire nos plans de développement.

Nous allons commencer par deux des sujets les plus intéressants pour nous l'année dernière: les amplifications SYN-ACK et les «optimisations» BGP.

Amplification TCP SYN-ACK et autres protocoles


La croissance du marché de l'IoT, entre autres, signifie que les attaquants peuvent exploiter les appareils vulnérables s'ils le souhaitent, créant une bande passante d'attaque importante - comme cela s'est produit au milieu de l'année lorsque le protocole WSDD a été utilisé pour causer des dommages visibles. Le protocole Apple ARMS, qui a été utilisé pour obtenir un coefficient d'amplification de l'ordre de 35,5, était également visible lors d'attaques contre le réseau de filtrage Qrator Labs.

En 2019, le public a également entendu parler de nouveaux amplificateurs (PCAP) et a personnellement vu le vecteur d'attaque connu depuis longtemps impliquant TCP - SYN-ACK. La principale différence entre cette méthode et l'amplification UDP typique est que le vecteur SYN-ACK n'utilise pas une réponse plus grande que la demande - à la place, il essaie seulement de répondre à la demande TCP plusieurs fois, créant ainsi un coefficient d'amplification notable. Étant donné que les clouds publics sur Internet répondent aux paquets en usurpant l'adresse source, les attaques impliquant le vecteur d'amplification SYN-ACK sont devenues l'une des menaces réseau les plus graves. L'apogée s'est produite lorsqu'un important fournisseur d' hébergement cloud Servers.com s'est tourné vers Qrator Labsavec une demande d'aide pour neutraliser les attaques DDoS, y compris le vecteur SYN-ACK.

Tout à fait intéressant est le fait que la méthode de réaction la plus souvent utilisée dans le passé sous la forme de dumping de tout le trafic UDP, qui neutralise pratiquement la part du lion des attaques utilisant l'amplification, n'aide pas du tout à neutraliser le vecteur SYN-ACK. Les petites sociétés Internet ont d'énormes difficultés à neutraliser ces menaces, car cela nécessite l'utilisation de mesures complètes pour lutter contre les attaques DDoS.


Bien que l'amplification TCP SYN-ACK ne soit pas nouvelle, elle est restée jusqu'à présent un vecteur d'attaque relativement inconnu. Un attaquant envoie des paquets SYN à tous les services TCP publics sur Internet, en remplaçant l'adresse source par l'adresse de la victime, et chacun de ces services répond à son tour plusieurs fois pour tenter d'établir une connexion - généralement de 3 à 5. Pendant très longtemps, ce vecteur d'attaque a été considéré sans signification, et ce n'est qu'en juillet 2019 que nous avons vu que les attaquants étaient en mesure de générer suffisamment de bande passante d'attaque pour ébranler même des infrastructures de réseau très étendues et distribuées. Ceci est particulièrement inhabituel, compte tenu du fait déjà mentionné de l'absence d'une «amplification de la réponse» en tant que telle et de l'utilisation de la seule possibilité de reconnexion inhérente au protocole en cas d'échec. Pour ceux,toute personne intéressée par d'autres protocoles ayant des «capacités» similaires, vous pouvez pointer vers le protocole QUIC, qui offre déjà au serveur la possibilité de répondre à la demande d'un client avec une réponse élargie (bien que le projet de protocole «recommande» également de ne pas envoyer de réponse plus de trois fois la taille de la demande).

L'amplification a cessé d'être une menace avec des coefficients d'environ 100x - il est évident que 3-5x est assez aujourd'hui. La solution à ce problème est presque impossible sans éliminer le phénomène du trafic «usurpé» en tant que catégorie - un attaquant ne devrait pas être en mesure de simuler l'identifiant réseau d'une personne et de l'inonder de trafic provenant de sources de contenu légitime. BCP38 (un ensemble de meilleures pratiques généralement acceptées pour la mise en place de réseaux et la résolution de situations problématiques) ne fonctionne pas du tout et les créateurs de nouveaux protocoles de transport - tels que QUIC - évaluent mal le danger posé par des capacités d'amplification même très petites. Ils sont de l'autre côté.

Les réseaux ont besoin d'un moyen fiable pour rejeter ou au moins limiter le trafic usurpé - et cet outil devrait avoir suffisamment d'informations sur la légitimité de la source de la demande. Les réseaux cloud appartenant à des sociétés telles qu'Amazon, Akamai, Google et Azure sont aujourd'hui une cible presque parfaite pour l'amplification TCP - ils ont beaucoup de matériel puissant qui peut satisfaire presque tous les objectifs d'un attaquant.



Il est difficile d'éliminer les conséquences de telles attaques sur l'Internet moderne. Comme déjà mentionné, les frontends et les backends modernes des applications et des bibliothèques utilisées pour les créer sont mutuellement intégrés. L'utilisation des capacités des solutions logicielles open source situées à l'intérieur de grands nuages ​​dans leur propre pile de développement peut entraîner de graves problèmes à la suite d'une attaque utilisant l'amplification SYN-ACK à partir du même nuage. Les référentiels cassés et les fichiers de configuration non mis à jour à la suite du blocage (en raison d'une fausse adresse de la source de la demande, votre adresse) du côté du fournisseur de services cloud est une situation dans laquelle personne ne veut être. Au cours de 2019, nous avons fait face à cette situation à plusieurs reprises, en traitant les plaintes des entreprises concernées,découvert pour la première fois des dépendances critiques inimaginables au cours de leur existence et de leur développement.

La poursuite du développement du protocole BGP est nécessaire pour l'utiliser dans la lutte contre l'usurpation d'identité dans la pile de protocoles TCP / IP. Les tables de routage sont fondamentalement différentes des tables de sous-réseau, et nous devons apprendre au réseau à isoler et à éliminer rapidement un paquet illégitime - en d'autres termes, à fournir une authentification au niveau de l'infrastructure du réseau. Il convient de prêter attention non pas à «l'adresse de destination», mais à «l'adresse source» afin de la faire correspondre avec les informations contenues dans la table de routage.


BGP - «optimiseurs»


Les incidents BGP sont toujours en cours. Selon l'ampleur actuelle des incidents de réseau, les fuites de route et les interceptions de sous-réseaux annoncés qui se sont propagés suffisamment loin représentent le principal danger en termes d'étendue de la propagation et de temps nécessaire pour éliminer les conséquences. Cela est peut-être dû au fait que le développement du composant réseau lui-même a été beaucoup plus lent que le reste du monde à développer de nouveaux matériels et logiciels. Pendant longtemps, cela a été vrai - il est temps d'abandonner cet héritage. Il est nécessaire d'investir du temps et de l'argent dans les logiciels et le matériel réseau, ainsi que dans les personnes qui configurent les filtres BGP.

Les incidents de 2019 impliquant des optimiseurs BGP ont montré que les statistiques BGP sur lesquelles tout le monde s'appuie ont beaucoup de problèmes. Le fait est que dans l'annonce BGP reçue du pair, vous pouvez modifier presque tout le contenu avant qu'il ne soit à nouveau annoncé - le protocole est très flexible. C'est exactement ce que l'optimiseur utilise: des préfixes de réseau plus ou moins grands, ainsi que des filtres inactifs et l'option pref locale. Si quelqu'un désagrège le préfixe en deux plus petits, il remportera généralement le concours pour le droit de transmettre du trafic. Les optimiseurs prennent la bonne route et annoncent sa partie la plus simple - assez simplement. Et cela fonctionne en brisant les grandes parties d'Internet.

Les optimiseurs BGP existent parce qu'un grand nombre d'entreprises souhaitent contrôler automatiquement le flux de trafic sortant, sans penser au trafic en tant que tel. Accepter des itinéraires qui ne devraient pas exister est une énorme erreur, car il n’existe pas de tels itinéraires au point d’origine.

De nombreux textes ont été écrits pour 2019, notamment par notre entreprise., sur les risques de «l'optimisation BGP». Dans le cas de Verizon, bien sûr, la création d'une nouvelle politique de filtrage pour chaque nouveau consommateur du service est désagréable. Et il est également connu que Verizon n'a pas de filtres, car il a emprunté des centaines de routes problématiques au propre client d'AS396531, qui est un «stub» - un système autonome avec une seule connexion. De plus, le géant des télécommunications n'avait pas non plus de limite de sous-réseau pour cette connexion. Il n'y avait même pas de vérification de base de la présence d'autres opérateurs de niveau 1 sur le chemin du consommateur (ce type de vérification est démarré par défaut et ne nécessite ni assistance ni modification).


Dans la presse, cet incident, y compris Verizon et Cloudflare, a été discuté assez vigoureusement. En plus de l'action possible de Verizon, beaucoup ont noté les avantages du RPKI et un record maximum strict en ROA. Mais qu'en est-il de maxLength? Il est connu qu'avec un contrôle strict de la longueur d'enregistrement maximale, toutes les annonces avec une indication de sous-réseaux plus petits deviennent incorrectes lors de la vérification du ROA. Il est également connu qu'il existe une politique de réinitialisation des chemins non valides. Il existe également un brouillon au sein de l'IETF, indiquant que maxLength doit être égal à la longueur du préfixe de réseau.

Cloudflare suit les meilleures pratiques. Cependant, il y a un petit problème. Verizon ne prend pas en charge la stratégie de réinitialisation pour les itinéraires non valides. Peut-être qu'il n'avait aucune vérification du RPKI du tout. En conséquence, toutes les routes avec des sous-réseaux plus petits se sont propagées encore plus loin, même si elles étaient incorrectes du point de vue de la validation de l'origine de la route et attiraient tout le trafic sur elles-mêmes. Dans le même temps, malgré le statut Invalid, Cloudflare ne pouvait pas annoncer les mêmes routes lui-même, car ses fournisseurs les supprimeraient comme incorrectes.

Une fuite de route peut être éliminée en manipulant simplement l'attribut AS_PATH sous la forme: ASx AS396531 ASx (où ASx est le numéro du système source autonome) lors de la création de l'annonce - cela aidera à éviter les fuites en utilisant le mécanisme de détection de boucle tandis que le problème est résolu par d'autres moyens. Bien qu'à chaque fois avec une telle manipulation, il sera nécessaire de garder ces politiques à l'esprit.

Le plus souvent dans la vie réelle, la méthode standard est utilisée - la plainte. Ce qui se traduit par des heures d'attente supplémentaires. La communication peut être douloureuse, et nous ne pouvons pas blâmer Cloudflare pour cela - ils ont fait tout ce qu'ils pouvaient, compte tenu des circonstances.


Quel est le résultat? Parfois, on nous demande à quel point il est difficile d'utiliser BGP pour organiser quelque chose de mauvais. Supposons que vous soyez un méchant novice. Il est nécessaire de se connecter à un grand opérateur de télécommunications, ce qui est mauvais avec les paramètres de filtrage. Sélectionnez ensuite n'importe quelle cible et prenez ses préfixes de réseau en annonçant leurs plus petites parties. N'oubliez pas non plus de jeter tous les paquets de transit. Toutes nos félicitations! Vous venez de créer un trou noir sur Internet pour tout le trafic de transit de ce service via votre fournisseur. La victime perdra de l'argent réel en raison d'un tel déni de service et, très probablement, subira des pertes de réputation importantes. Il faut au moins une heure pour trouver les causes d'un tel incident, et une heure est nécessaire pourramener tout à la normale - à condition qu'une telle situation ne soit pas intentionnelle et qu'il y ait une bonne volonté de résolution parmi tous les participants.

En mars 2019, il y a eu un autre cas , que nous n'avions pas à un moment donné associé à l'optimisation BGP. Cependant, il mérite également attention.

Imaginez que vous êtes un fournisseur de transport en commun annonçant des sous-réseaux de vos propres clients. Si ces clients ont plusieurs fournisseurs, et pas vous, vous ne recevrez qu'une partie de leur trafic. Mais plus il y a de trafic, plus les bénéfices sont importants. Vous décidez donc de publier des sous-réseaux plus petits de ces réseaux avec le même attribut AS_PATH pour obtenir tout le trafic pour ces réseaux. Avec l'argent restant, bien sûr.

Le ROA sera-t-il utile dans ce cas? Peut-être que oui, mais seulement si vous décidez de ne pas utiliser du tout maxLength et que vous n'avez pas d'enregistrements ROA avec des préfixes qui se croisent. Pour certains opérateurs télécoms, cette option n'est pas envisageable.

Si nous parlons d'autres mécanismes de sécurité BGP, alors ASPA n'aiderait pas dans ce type d'interception, car AS_PATH appartient au chemin correct. BGPSec est actuellement inefficace en raison du manque de support et de la capacité restante à mener des attaques de déclassement.

Il reste un motif d'augmentation de la rentabilité en raison de la réception de tout le trafic de systèmes autonomes avec plusieurs fournisseurs et de l'absence de tout moyen de protection.


Nombre total de boucles statiques dans le réseau.

Que peut-on encore faire? L'étape la plus évidente et la plus radicale consiste à revoir les politiques de routage actuelles. Cela vous aidera à diviser l'espace d'adressage en les plus petites parties possibles (sans intersections) que vous souhaitez annoncer. Signez un ROA uniquement pour ces itinéraires à l'aide de l'option maxLength. La validation ROV actuelle peut vous sauver d'une telle attaque. Mais encore une fois, certains ne peuvent pas se permettre d'utiliser uniquement les plus petits sous-réseaux.

En utilisant Radar.Qrator, vous pouvez suivre de tels événements. Pour ce faire, nous avons besoin d'informations de base sur vos préfixes. Vous pouvez établir une session BGP avec un collecteur et fournir des informations sur votre visibilité sur Internet. Nous apprécions également positivement ceux qui sont prêts à nous envoyer une table de routage complète (vue complète) - cela permet de suivre l'étendue des incidents, mais pour votre propre avantage et en commençant à utiliser l'outil, une liste de routes ne suffit que pour vos préfixes. Si vous avez déjà une session avec Radar.Qrator, veuillez vérifier que vous envoyez des itinéraires. Pour la détection et la notification automatiques des attaques sur votre espace d'adressage, ces informations sont nécessaires.

Nous répétons - si une situation similaire est détectée, vous pouvez essayer de la contrer. La première approche est l'auto-annonce des chemins avec des préfixes de sous-réseaux plus petits. Lors de la prochaine attaque contre ces préfixes - répétez. La deuxième approche consiste à punir l'attaquant en refusant au système autonome l'accès à vos chemins. Comme décrit précédemment, ceci est réalisé en ajoutant le numéro de système autonome de l'attaquant à AS_PATH de vos anciens chemins, ce qui permet à la protection contre les boucles de fonctionner.

Banques




En 2019, nous avons mené une étude en Russie , qui a montré que les institutions financières ont enregistré une augmentation de l'importance de la sécurité de l'information et ont commencé à donner à ces investissements une priorité plus élevée.

Les banques interrogées identifient les atteintes financières et à la réputation comme les conséquences les plus graves des atteintes à la sécurité de l'information.

La plupart des institutions financières interrogées considèrent les solutions hybrides comme le moyen le plus efficace de lutter contre les attaques par déni de service distribué.

La dynamique des deux dernières années indique clairement que le domaine de la sécurité de l'information se développe à un rythme énorme: au cours des 2 dernières années, la plupart des banques ont augmenté leurs investissements dans la sécurité de l'information. La cybersécurité est déjà devenue visible au niveau de la direction de l'entreprise. Les chefs d'entreprise commencent à accorder plus d'attention aux processus de mise en œuvre des politiques de sécurité, et le poste de directeur de la sécurité de l'information a acquis un nouveau rôle. Les responsables SI se transforment progressivement en conseillers clés pour les cadres supérieurs des organisations financières, introduisant des tactiques commerciales et des stratégies de sécurité conformes aux besoins de l'entreprise.

Commerce électronique




Une étude similaire a été menée dans le domaine du commerce électronique, où nous avons constaté que les attaques DDoS restent une menace importante pour le commerce de détail russe, en particulier pour le développement de canaux de services numériques. Le nombre d'attaques dans ce segment continue de croître.

Dans certains segments du marché, malgré sa stabilisation et sa consolidation globales, la confiance dans la propreté des concurrents est encore faible. Dans le même temps, les grandes boutiques en ligne font généralement confiance à leurs consommateurs et ne considèrent pas les motivations personnelles des clients comme une cause grave de cyberattaques.

En règle générale, les moyennes et grandes entreprises de commerce électronique ne se renseignent sur leur état de préparation aux attaques DDoS qu'en pratique, en réussissant un «test de bataille». La nécessité d'une évaluation préliminaire des risques de la préparation des projets est loin d'être reconnue par tous, et encore moins d'entreprises réalisent réellement une telle évaluation. Les principales raisons du piratage, les répondants considèrent un dysfonctionnement du magasin, ainsi que le vol de la base d'utilisateurs.

En général, le niveau de maturité du commerce de détail dans les approches visant à garantir la cybersécurité augmente. Ainsi, tous les répondants utilisent certains moyens de protection DDoS et WAF.
Dans d'autres études, il est prévu d'inclure un échantillon représentatif de petites entreprises en ligne parmi les répondants et d'étudier en détail ce segment de marché, ses risques et le niveau de sécurité actuel.

DNS sur HTTPS vs DNS sur TLS


L'un des sujets les plus chauds de 2019 a été le débat sur la technologie du futur - DoH ou DoT. La contradiction initiale est due à la fois à des différences importantes entre les différentes législatures (RGPD de l'UE par rapport aux lois fédérales et étatiques aux États-Unis) et à la concurrence sur le marché principal des navigateurs: Google Chrome et Mozilla Firefox, ainsi qu'Apple Safari. Nous ne sommes pas prêts à dire si l'introduction de l'une de ces technologies réduira le nombre d'amplificateurs sur Internet. Cependant, avec l'option DoT, cela semble plus possible d'un point de vue architectural en raison de la création de connexions sécurisées entre les résolveurs DNS. Concernant les autres prévisions, nous attendrons une décision que le marché prendra.


Les industries les plus attaquées en 2019.

Vulnérabilités de reconnaissance TCP


En juin 2019, les premiers détails sur l'existence de vulnérabilités graves sont apparus dans certaines implémentations de la pile de protocoles TCP / IP, comme rapporté par Netflix . Vraisemblablement, le problème a été découvert à l'origine dans le système d'exploitation FreeBSD, après quoi notre société a reçu la confirmation de la présence de la même vulnérabilité et d'autres vulnérabilités dans Linux.

Le CVE-2019-11477 le plus dangereux (panique SACK), qui peut permettre à un attaquant d'appeler la panique du noyau à l'aide d'une séquence de packages spécialement formés. Trois autres vulnérabilités peuvent entraîner une consommation excessive de ressources, ce qui pourrait entraîner un déni de service.

La désactivation de la fonctionnalité SACK peut entraîner une augmentation de la latence, cependant, cela protégera les serveurs contre d'éventuelles attaques par déni de service - une diminution temporaire des performances TCP / IP, selon Qrator Labs, est un moyen raisonnable de neutraliser une vulnérabilité grave. Les correctifs couvrant ces vulnérabilités sont disponibles depuis longtemps et sont recommandés pour l'installation.

L'avenir du routage BGP


À la fin de 2019, Radar.Qrator est la plus grande plateforme mondiale de collecte et d'analyse de routage BGP avec plus de 650 sessions établies.

L'équipe Radar.Qrator travaille à améliorer la convivialité et la fiabilité du service, en améliorant le modèle de relation BGP, qui est la base d'un service payant pour surveiller un système autonome en temps réel.

En 2019, de gros efforts ont été faits pour accélérer le processus de traitement des données et la mise en œuvre du SLA, qui garantit la qualité du flux de données analytiques. Aujourd'hui, Radar est la plus grande plate-forme analytique et collecteur BGP au monde, avec plus de 600 sessions établies, et nous espérons utiliser pleinement les données afin d'informer les consommateurs de la partie payante du service de tous les événements se produisant dans le routage BGP sans délai.

Radar.Qrator croît plus rapidement que prévu - à la fois en termes de nombre de visiteurs du site Web et de nombre d'abonnés en même temps. En 2020, grâce aux retours des clients, plusieurs améliorations significatives seront présentées à la fois, dont un nouveau stockage des incidents pour chaque système autonome.

L'un des problèmes que nous avons rencontrés était le temps de réponse attendu dans l'interface Web Radar, accessible à chaque visiteur du site. Avec l'augmentation de la quantité de données, il est devenu nécessaire de mettre à jour à la fois le modèle de stockage des données et l'architecture des demandes des utilisateurs. Le radar devrait être en mesure d'expédier rapidement toutes les données pour la période demandée à tout visiteur.


Le schéma proposé du mécanisme ASPA.

Nous espérons également qu'au cours de cette année, l' ASPAdeviendra RFC - une norme de réseau approuvée. La nécessité d'une solution plus large que la combinaison IRR / RPKI et plus légère que la solution BGPSec est évidente pour tout le monde dans l'industrie. En 2019, il est devenu clair comment une configuration BGP incorrecte peut entraîner des fuites de route avec des conséquences terribles sous la forme de l'indisponibilité d'un grand nombre de services impliquant les plus grands fournisseurs de services Internet. Étonnamment, ces incidents ont une fois de plus prouvé qu'il n'y a pas de solution miracle qui puisse surmonter tous les scénarios possibles de leur développement.

Les plus grands fournisseurs Internet du monde doivent soutenir le mouvement initial. Faire participer de grandes communautés qui peuvent aider à trouver la source du détournement de route est la prochaine étape. En termes simples, ASPA est une nouvelle entité qui combine les capacités actuelles de ROA et RPKI - elle met en œuvre le principe simple: "Connaissez votre fournisseur." Le propriétaire d'AS n'a besoin de connaître que son amont afin de mettre en œuvre un moyen suffisamment fiable pour se protéger contre les incidents de routage BGP.

Comme dans le cas du ROA, ASPA vous permet de filtrer les itinéraires pour n'importe quelle connexion: avec un fournisseur supérieur, un voisin ou, bien sûr, un consommateur. La combinaison du ROA et de l'ASPA peut résoudre la part du lion des tâches de sécurité du réseau sans avoir besoin de modifications fondamentales du protocole lui-même, filtrant les attaques intentionnelles et les erreurs liées au facteur humain. Cependant, il sera également nécessaire d'attendre le soutien des fabricants de logiciels et de matériel - même s'il est certain que le support open source ne tardera pas à venir.

L'un des principaux avantages de l'ASPA est qu'il s'agit d'une idée très simple. En 2020, il est prévu d'achever les travaux sur un projet de protocole, et en cas de succès, l'IETF et les co-auteurs du projet parviendront à un consensus sur la consolidation du statut du protocole.



Développement actuel et futur du réseau de filtration Qrator

Logique de filtrage


Au cours des deux dernières années, nous avons investi beaucoup de temps et d'efforts dans l'amélioration de la logique de filtrage, qui est la base du service d'atténuation des attaques que nous fournissons. À ce jour, ils travaillent déjà sur l'ensemble du réseau, montrant une augmentation significative de l'efficacité opérationnelle et une diminution de la charge sur la mémoire et le processeur central aux points de présence. De nouveaux filtres vous permettent également d'analyser de manière synchrone les demandes et de fournir une variété de tâches JavaScript pour vérifier la légitimité du visiteur, améliorant ainsi la qualité de la détection des attaques.

La principale raison de la mise à jour de la logique de filtrage est la nécessité de détecter toute une classe de bots dès la première requête. Qrator Labs utilise des combinaisons de contrôles avec et sans mémorisation d'état, et uniquement après confirmation de la légitimité de l'utilisateur, envoie la demande au serveur protégé. Par conséquent, il est nécessaire que les filtres fonctionnent très rapidement - les attaques DDoS modernes passent avec une intensité de dizaines de millions de paquets par seconde, et certains d'entre eux peuvent être des demandes uniques et uniques.

En 2020, dans le cadre de ce processus, des changements importants seront également apportés au processus de trafic «onboarding», c'est-à-dire le démarrage des travaux avec un nouveau service protégé. Le trafic de chaque service est unique à sa manière et nous nous efforçons de faire en sorte que, quoi qu'il arrive, les nouveaux clients reçoivent rapidement la neutralisation complète de tous les types d'attaques, même si le modèle n'est pas bien formé. En conséquence, nous assurerons une inclusion plus fluide du filtrage lorsqu'ils sont connectés sous attaque, et le début du filtrage sera accompagné de moins de faux positifs. Tout cela est important lorsque le service et les personnes derrière lui sont au milieu de la lutte pour la survie sous les attaques massives du réseau.


Répartition des attaques DDoS pour 2019 par bande utilisée.

HTTP / 2


Les problèmes d'implémentation du protocole HTTP / 2 (vulnérabilités de déni de service) ont été principalement résolus en 2019, ce qui nous a permis d'activer la prise en charge de ce protocole au sein du réseau de filtrage Qrator.

Maintenant, le travail se poursuit activement afin de fournir une protection HTTP / 2 à chaque client, complétant ainsi une période de test longue et approfondie. Parallèlement à la prise en charge de HTTP / 2, TLS 1.3 a introduit la possibilité d'utiliser eSNI avec l'émission automatisée de certificats de sécurité Let's Encrypt.

Actuellement, HTTP / 2 est disponible sur demande comme option supplémentaire.

Conteneurs et orchestration


Les tendances actuelles de conteneurisation sont peu compatibles avec nos approches de sécurité. Cela signifie que travailler avec Kubernetes doit surmonter une variété de défis. La sécurité et l'accessibilité sont parmi les plus hautes priorités, ce qui ne nous permet pas de compter sur des pratiques courantes parmi ceux qui travaillent avec Kubernetes, donnant principalement au processus d'orchestration un contrôle total sur le système d'exploitation avec toutes les fonctionnalités - cela nous laisserait exclusivement à la merci des développeurs et des modules complémentaires de Kubernetes. Jusqu'à présent, Kubernetes ne dispose pas de toutes les capacités nécessaires, et certaines sont même cachées à l'état «utiliser tel quel, il n'y a aucune garantie» et ne peuvent pas être étudiées en détail. Mais tout cela ne se détourne pas de travaux supplémentaires sur la mise en œuvre de Kubernetes dans la gestion du réseau de filtrage,l'adapter progressivement à nos besoins et en faire un élément assez important de l'infrastructure interne.

L'avenir du développement et du développement de réseaux distribués et tolérants aux pannes nécessite l'introduction d'outils appropriés (CI / CD et tests automatiques en font partie) et la capacité de l'utiliser pour créer et gérer un système stable et fiable. Comme la quantité de données ne fait qu'augmenter, les efforts de surveillance devraient s'accroître après eux. Le moyen le plus naturel de créer une surveillance est de fournir une méthode de communication sûre et facilement observable pour les applications. Nous pensons que Kubernetes a déjà prouvé sa polyvalence et son applicabilité, et sa spécialisation supplémentaire pour les besoins de l'infrastructure luttant contre les attaques DDoS est la réalité de travailler avec n'importe quelle solution open source.


Changement de la durée moyenne des attaques DDoS de 2018 à 2019.

Yandex.Cloud et Ingress 2.0


En 2019, en collaboration avec Yandex.Cloud, nous avons présenté une version mise à jour de notre service pour filtrer le trafic entrant - Ingress, élargissant considérablement ses capacités de filtrage et de configuration, offrant à l'utilisateur final des interfaces de gestion claires. La nouvelle version du service fonctionne déjà sur le réseau de filtrage Qrator Labs, ainsi que sur le réseau Yandex.Cloud.

L'équipe Yandex.Cloud a parcouru un long chemin avec nous, combinant deux infrastructures utilisant des nœuds physiques de Qrator Labs situés à l'intérieur de l'infrastructure du partenaire travaillant sur son trafic.

Enfin, après une période de tests approfondis, la nouvelle version d'Ingress est prête à l'emploi. Avec l'aide de Yandex, nous avons pu créer l'une des meilleures solutions pour filtrer le trafic entrant, créée spécifiquement pour les besoins de services générant beaucoup de contenu.

Nous considérons également comme un grand succès que la nouvelle version du service soit intuitive pour l'utilisateur final et vous permette de configurer de manière plus flexible les paramètres de filtrage.

Certificats TLS 1.3 et ECDSA


Au début de 2019, Qrator Labs a écrit sur la prise en charge de TLS version 1.3 tout en désactivant SSL v.3. En raison de la disponibilité du service de neutralisation DDoS sans divulguer les clés de chiffrement, des améliorations supplémentaires ont été apportées à ce schéma de filtrage, augmentant la vitesse et la fiabilité de la traduction syslog. Rappelons les résultats des mesures de performances .
Type de signaturePoignées de main par seconde
ECDSA (prime256v1 / nistp256)3358,6
RSA 2048972,5

Comme vous pouvez le voir, sur un seul cœur du processeur Intel® Xeon® Silver 4114 à 2,20 GHz (publié au troisième trimestre de 17), la différence totale entre les performances ECDSA et le RSA généralement accepté avec une longueur de clé de 2048 bits est de 3,5 fois.

Examinons les résultats de l'exécution de la commande openssl -speed pour ECDSA et RSA sur le même processeur.
Type de signature
signe
Vérifier
signe / sec
vérifier / sec
RSA 2048 bits
717 μs
20,2 μs
1393,9
49458.2
ECDSA 256 bits (nistp256) 
25,7 μs
81,8 μs
38971.6
12227.1

Ici, nous pouvons trouver la confirmation d'une thèse précédemment écrite sur la façon dont les opérations de calcul d'une signature et sa vérification diffèrent entre ECC et RSA. Actuellement, armée de TLS 1.3, la cryptographie basée sur des courbes elliptiques permet une augmentation significative des performances du serveur avec un niveau de protection supérieur à RSA. C'est la raison principale pour laquelle nous, chez Qrator Labs, recommandons et encourageons fortement les clients qui sont également prêts à utiliser les certificats ECDSA. Sur les processeurs modernes, le gain de performances en faveur de l'ECDSA est 5x.

Petites améliorations


L'une des petites innovations discrètes mais néanmoins importantes de 2019 a été l'introduction du processus de vérification active de l'état de l'amont. Si, pour une raison quelconque, quelque chose se produit pendant l'une des connexions supérieures de notre client pendant l'attaque, le service de filtrage sera le premier à le savoir, mettant la connexion hors service jusqu'à ce que le problème soit résolu. En cela, il aide non seulement à surveiller les erreurs et les conditions de circulation, mais également à mettre en place une interface spéciale de vérification de l'accessibilité, qui se fait en collaboration avec le consommateur de services.

Fin 2019, une grande mise à jour de l'interface utilisateur du service de filtrage a été effectuée. Et bien que la possibilité d'utiliser l'ancienne version de votre compte personnel soit offerte, de nouvelles fonctionnalités sont déjà en cours de développement dans la partie mise à jour, qui offre des fonctionnalités plus larges, par exemple, la gestion des certificats TLS.

Alors que l'ancienne version du compte personnel utilisait le rendu côté serveur, la version mise à jour dans les meilleures traditions du Web moderne est une application JavaScript qui s'exécute sur un client qui communique avec le serveur via l'API REST. Cette approche vous permettra de fournir rapidement de nouvelles fonctions à l'utilisateur, tout en offrant des opportunités plus profondes pour les paramètres individuels de chaque compte personnel d'un consommateur individuel. L'une de ces choses est la section Analytics, où il est possible de personnaliser des mesures individuelles, dont le nombre augmente constamment.


Comparaison des deux principaux groupes de classification des attaques DDoS pour 2019.

IPv6


Qrator Labs se prépare activement à commencer à utiliser IPv6 dans le cadre des services de filtrage du trafic. Pour toute entreprise de cybersécurité, une telle transition ne peut être élémentaire. En raison de la nature des attaques DDoS, la neutralisation des attaques réseau utilisant IPv6 nécessite un changement radical d'approche, car il n'est plus possible de traiter toute forme de «liste» lorsqu'il s'agit d'une limite théorique de 2 128 adresses IP. Et il ne s'agit que de TCP, sans considérer UDP.

Pour nous, 2020 sera l'année de l'IPv6. Avec l'épuisement de l'espace d'adressage IPv4 gratuit, il n'y a pas d'autre moyen de développer un réseau qui réponde aux exigences futures. Nous espérons pouvoir répondre efficacement à tous les défis auxquels nous sommes confrontés dans le cadre de la neutralisation des attaques IPv6. Tout d'abord, cela signifie que nous pourrons annoncer le sous-réseau IPv6 des services de filtrage grand public utilisant notre réseau, tout en offrant un service de cybersécurité de première classe.

Antibot


En 2019, l'industrie a observé une bataille acharnée entre les empreintes digitales (identification des visiteurs) et les tentatives de les limiter. Le désir des propriétaires et des développeurs de services Internet de limiter ou de séparer les demandes des utilisateurs légitimes des demandes automatisées des robots est compréhensible. D'un autre côté, il n'y a rien d'étrange dans la volonté des développeurs de navigateurs de sécuriser les utilisateurs de logiciels. Pendant des années, Qrator Labs a rappelé au marché que si certaines informations sont accessibles au public et qu'aucune autorisation n'est requise pour les recevoir, la probabilité de les protéger de l'analyse automatisée tend à zéro. Dans le même temps, nous rappelons aux propriétaires de l'entreprise numérique qu'ils ont le droit de choisir quoi faire avec les demandes envoyées au serveur. Une approche proactive dans certaines situations permet d'évaluer et d'identifier la menace.

Comme les bots génèrent une part croissante du trafic, nous pouvons nous attendre à un moment futur où les grands services créeront des interfaces spéciales pour les bons bots, leur donnant des informations légitimes. Le reste sera bloqué. Même maintenant, au début de 2020, on peut affirmer qu'un utilisateur 100% légitime ne pourra pas accéder immédiatement à aucune ressource sur Internet - beaucoup ne le permettront pas si, par exemple, vous changez simplement l'agent utilisateur du navigateur en un arbitraire.

Au sein de Qrator Labs, le service antibot se développe activement depuis plusieurs années et, en 2020, nous prévoyons de l'offrir à nos premiers clients dans le cadre du service bêta. Ce service fonctionnera en modes semi et automatique, permettant d'identifier et de définir des règles de sécurité contre un certain nombre de demandes automatisées ou sortantes de bots.


Équipement


Après avoir testé les nouveaux processeurs AMD, les employés responsables de la société étaient tellement intrigués qu'au premier trimestre 2020, Qrator Labs mettra en service un nouveau point de présence à Osaka, au Japon, entièrement construit sur des processeurs AMD. PCI Express de 4e génération, disponible avec les processeurs AMD, promet de doubler la bande passante entre le processeur et l'interface réseau. Au cours de l'année, l'utilisation de ce ligament dans les scénarios les plus stressants sera testée et évaluée. Le canal entre l'interface réseau et le processeur devient progressivement un col étroit avec une augmentation de la quantité de données transmises dans les réseaux. La combinaison de cœurs supplémentaires, d'un cache plus grand et de la nouvelle version de PCI Express promet d'apporter un bon résultat.

Une autre raison d'utiliser le processeur AMD est la nécessité de diversifier l'architecture du réseau, bien qu'il s'agisse du premier point de présence pour Qrator Labs, entièrement basé sur le nouveau processeur.

Nous attendons avec impatience le début des travaux de nouveaux équipements, dont le lancement sera communiqué séparément début 2020. Nous espérons que la combinaison de processeurs AMD et de cartes réseau hautes performances utilisant PCI Express 4 répondra à nos exigences. Le marché asiatique est l'un des secteurs à la croissance la plus rapide, et j'aimerais apprécier les nouvelles perspectives de neutralisation des attaques DDoS avec de nouveaux équipements.

Dans le même temps, l'arrivée d'une nouvelle génération de processeurs Intel est également attendue - Ice Lake. Leur utilisation ultérieure dans notre infrastructure dépendra largement des résultats de leurs tests et de leur comparaison.

Outre les processeurs, l'ensemble de l'industrie attend la sortie des cartes réseau Intel série 800. En 2020, nous essaierons de les trouver application au sein de l'infrastructure du réseau de filtration.

En ce qui concerne les commutateurs - Qrator Labs continue de travailler avec Mellanox, qui s'est avéré à plusieurs reprises être un fournisseur et un partenaire fiable.

Dire que ce n'est pas facile, mais alors que Broadcom domine le marché des équipements de réseau, nous espérons que la fusion avec NVidia donnera à Mellanox une chance pour une concurrence digne.

Améliorations futures du réseau de filtrage


En 2020, notre entreprise prévoit d'approfondir considérablement son partenariat avec les fournisseurs d'une grande variété de services et de services, tels que le pare-feu d'application Web et le réseau de distribution de contenu au sein du réseau de filtrage. Nous avons toujours essayé d'intégrer une variété de fournisseurs dans l'infrastructure pour fournir les meilleures combinaisons de services possibles aux consommateurs. D'ici la fin de 2020, il est prévu d'annoncer la disponibilité d'un certain nombre de nouveaux fournisseurs de services en collaboration avec Qrator.

2019 a également révélé un certain nombre de questions concernant la protection de la technologie WebSockets. Sa prévalence et sa popularité ne font que croître et la complexité d'une protection adéquate n'est pas réduite. En 2020, nous prévoyons de travailler avec certains de nos clients à l'aide de la technologie WebSockets pour trouver le meilleur moyen de le protéger, même si nous envoyons des données arbitraires (inconnues).

Ce que nous faisons n'est pas du savoir-faire ni de la révélation. L'entreprise est arrivée sur ce marché plus tard que de nombreux concurrents. L'équipe fait de grands efforts pour faire quelque chose d'unique et de fonctionnel. Une partie de cette opportunité réside également dans le véritable intérêt des salariés de l'entreprise pour la recherche académique et scientifique dans les principaux domaines d'efforts, ce qui nous permet de nous préparer à des événements «soudains».

Depuis que vous avez lu jusqu'à la fin, voici le .pdf pour la distribution . N'oubliez pas la sécurité du réseau vous-même - et ne la confiez pas à d'autres.

Source: https://habr.com/ru/post/undefined/


All Articles