{"id":31924,"date":"2019-10-31T21:44:01","date_gmt":"2019-10-31T18:44:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy\/"},"modified":"2019-10-31T21:44:01","modified_gmt":"2019-10-31T18:44:01","slug":"ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS \u00e0 la rescousse : comment nous r\u00e9alisons des tests de charge et de stress","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nLa soci\u00e9t\u00e9 Variti d\u00e9veloppe des protections contre les bots et les attaques DDoS, ainsi que des tests de r\u00e9sistance et de charge. Lors de la conf\u00e9rence HighLoad++ 2018, nous avons expliqu\u00e9 comment s\u00e9curiser les ressources contre diff\u00e9rents types d'attaques. En r\u00e9sum\u00e9 : isolez les parties du syst\u00e8me, utilisez des services cloud et des CDN, et mettez-vous r\u00e9guli\u00e8rement \u00e0 jour. Mais sans des entreprises sp\u00e9cialis\u00e9es en protection, vous ne pourrez pas vous en sortir \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nAvant de lire le texte, vous pouvez consulter un bref r\u00e9sum\u00e9 sur le site de la conf\u00e9rence<\/a><\/noindex>.
\nEt si vous n'aimez pas lire ou souhaitez simplement regarder une vid\u00e9o, l'enregistrement de notre pr\u00e9sentation se trouve ci-dessous dans le spoiler.<\/p>\n

Enregistrement de la pr\u00e9sentation<\/b>

\r\n \"Lire\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

De nombreuses entreprises savent d\u00e9j\u00e0 effectuer des tests de charge, mais peu r\u00e9alisent des tests de stress. Certains de nos clients pensent que leur site est invuln\u00e9rable parce qu'ils disposent d'un syst\u00e8me haute charge, qui les prot\u00e8ge bien des attaques. Nous montrons que ce n'est pas tout \u00e0 fait vrai.
\nBien s\u00fbr, avant d'effectuer des tests, nous obtenons l'autorisation du client, avec une signature et un cachet, et avec notre aide, il est impossible de lancer une attaque DDoS contre quiconque. Les tests sont r\u00e9alis\u00e9s \u00e0 la demande du client, \u00e0 un moment o\u00f9 la fr\u00e9quentation de sa ressource est minimale, et o\u00f9 des probl\u00e8mes d'acc\u00e8s n'impacteront pas les clients. De plus, comme des impr\u00e9vus peuvent survenir pendant les tests, nous maintenons un contact constant avec le client. Cela permet non seulement de communiquer les r\u00e9sultats obtenus, mais aussi d'apporter des modifications au cours des tests. \u00c0 l'issue des tests, nous r\u00e9digeons toujours un rapport mentionnant les d\u00e9fauts identifi\u00e9s et fournissons des recommandations pour corriger les points faibles du site. <\/p>\n

Comment nous travaillons<\/h3>\n

\nLors des tests, nous \u00e9muleons un botnet. Comme nous travaillons avec des clients qui ne se trouvent pas dans nos r\u00e9seaux, pour \u00e9viter que le test ne s'arr\u00eate d\u00e8s la premi\u00e8re minute \u00e0 cause des limitations ou de la protection, nous g\u00e9n\u00e9rons la charge non pas \u00e0 partir d'une seule IP, mais de notre propre sous-r\u00e9seau. De plus, pour cr\u00e9er une charge significative, nous avons notre propre serveur de test assez puissant.<\/p>\n

Postulats<\/h3>\n

<\/p>\n

Beaucoup \u2014 ne signifie pas bien<\/b>
\nPlus la charge que nous pourrons mettre sur le syst\u00e8me avant qu'il ne cesse de fonctionner est faible, mieux ce sera. S'il est possible de faire en sorte que le site cesse de fonctionner avec une requ\u00eate par seconde, voire une requ\u00eate par minute, c'est parfait. Car, selon la loi de Murphy, les utilisateurs ou les attaquants tomberont par hasard sur cette vuln\u00e9rabilit\u00e9. <\/p><\/blockquote>\n

Une panne partielle est pr\u00e9f\u00e9rable \u00e0 une panne totale<\/b>
\nNous conseillons toujours de rendre les syst\u00e8mes h\u00e9t\u00e9rog\u00e8nes. De plus, il est important de les s\u00e9parer au niveau physique, et pas seulement par la conteneurisation. En cas de s\u00e9paration physique, m\u00eame si quelque chose \u00e9choue sur le site, il y a de fortes chances qu'il ne cesse pas compl\u00e8tement de fonctionner, et que les utilisateurs puissent encore acc\u00e9der \u00e0 une partie des fonctionnalit\u00e9s.<\/p><\/blockquote>\n

Une architecture correcte est la cl\u00e9 de la r\u00e9silience<\/b>
\nLa r\u00e9silience d'une ressource et sa capacit\u00e9 \u00e0 r\u00e9sister aux attaques et aux charges doivent \u00eatre int\u00e9gr\u00e9es d\u00e8s la phase de conception, en fait, d\u00e8s l'\u00e9tape de dessin des premiers diagrammes dans un carnet. Parce que si des erreurs fatales s'immiscent, il est possible de les corriger par la suite, mais c'est tr\u00e8s difficile.<\/p><\/blockquote>\n

Le code doit \u00eatre bon, tout comme la configuration<\/b>
\nBeaucoup pensent qu'une bonne \u00e9quipe de d\u00e9veloppement garantit la r\u00e9silience du service. Une bonne \u00e9quipe de d\u00e9veloppement est effectivement n\u00e9cessaire, mais une bonne exploitation est \u00e9galement requise, ainsi qu'un bon DevOps. Cela signifie qu'il faut des sp\u00e9cialistes capables de configurer correctement Linux et le r\u00e9seau, d'\u00e9crire correctement les configurations dans nginx, de d\u00e9finir les limites, etc. Sinon, la ressource fonctionnera bien en test, mais en production, \u00e0 un moment donn\u00e9, tout s'effondrera.<\/p><\/blockquote>\n

Diff\u00e9rences entre les tests de charge et de stress<\/b>
\nLes tests de charge permettent de d\u00e9terminer les limites de fonctionnement du syst\u00e8me. Les tests de stress visent \u00e0 identifier les points faibles du syst\u00e8me et sont utilis\u00e9s pour tenter de le briser et observer son comportement lors de la d\u00e9faillance de certaines parties. De plus, la nature de la charge reste g\u00e9n\u00e9ralement inconnue pour le client avant le d\u00e9but des tests de stress.<\/p><\/blockquote>\n

<\/p>\n

Caract\u00e9ristiques distinctives des attaques de niveau 7<\/h3>\n

\nNous classifions g\u00e9n\u00e9ralement les charges en charges de niveau L7 et L3&4. L7 fait r\u00e9f\u00e9rence \u00e0 la charge au niveau des applications, le plus souvent entendue comme \u00e9tant uniquement HTTP, mais nous entendons ici toute charge au niveau du protocole TCP.
\nLes attaques L7 pr\u00e9sentent certaines caract\u00e9ristiques distinctives. Premi\u00e8rement, elles vont directement vers l'application, ce qui rend leur att\u00e9nuation par des moyens r\u00e9seau peu probable. Ces attaques exploitent la logique, ce qui leur permet de consommer efficacement des ressources CPU, m\u00e9moire, disque, base de donn\u00e9es et autres, m\u00eame avec un faible trafic.<\/p>\n

HTTP Flood<\/h3>\n

\nDans le cas de toute attaque, il est plus facile de g\u00e9n\u00e9rer une charge que de la traiter, et cela est \u00e9galement vrai pour L7. Le trafic d'attaque n'est pas toujours facile \u00e0 distinguer du trafic l\u00e9gitime, et il est souvent possible de le faire en fonction de la fr\u00e9quence. Cependant, si tout est bien planifi\u00e9, il est impossible de comprendre, \u00e0 partir des logs, o\u00f9 se trouve l'attaque et o\u00f9 se trouvent les requ\u00eates l\u00e9gitimes.
\nPour donner un premier exemple, prenons l'attaque HTTP Flood. Le graphique montre que ces attaques sont g\u00e9n\u00e9ralement tr\u00e8s puissantes ; dans l'exemple ci-dessous, le nombre de requ\u00eates a d\u00e9pass\u00e9 600 000 par minute au pic.<\/p>\n

\"DDoS
\n
\nHTTP Flood est la mani\u00e8re la plus simple de g\u00e9n\u00e9rer une charge. G\u00e9n\u00e9ralement, un outil de test de charge, comme ApacheBench, est utilis\u00e9, et une requ\u00eate et une cible sont d\u00e9finies. Avec cette approche simple, il y a un risque \u00e9lev\u00e9 de rencontrer des probl\u00e8mes de mise en cache du serveur, mais cette situation peut \u00eatre facilement contourn\u00e9e. Par exemple, en ajoutant des cha\u00eenes al\u00e9atoires \u00e0 la requ\u00eate, ce qui obligera le serveur \u00e0 d\u00e9livrer constamment des pages fra\u00eeches.
\nIl ne faut pas non plus oublier le user-agent lors de la cr\u00e9ation de la charge. De nombreux user-agents des outils de test populaires sont filtr\u00e9s par les administrateurs syst\u00e8me, et dans ce cas, la charge peut tout simplement ne pas atteindre le backend. On peut consid\u00e9rablement am\u00e9liorer les r\u00e9sultats en ins\u00e9rant dans la requ\u00eate un en-t\u00eate plus ou moins valide d'un navigateur.
\nMalgr\u00e9 la simplicit\u00e9 de l'attaque, les HTTP Flood ont \u00e9galement leurs inconv\u00e9nients. Premi\u00e8rement, un important potentiel est n\u00e9cessaire pour g\u00e9n\u00e9rer la charge. Deuxi\u00e8mement, ces attaques sont tr\u00e8s faciles \u00e0 d\u00e9tecter, surtout si elles proviennent d'une m\u00eame adresse. En fin de compte, les requ\u00eates commencent imm\u00e9diatement \u00e0 \u00eatre filtr\u00e9es soit par des administrateurs syst\u00e8me, soit m\u00eame au niveau du fournisseur. <\/p>\n

Que rechercher<\/h3>\n

\nPour r\u00e9duire le nombre de requ\u00eates par seconde tout en maintenant l'efficacit\u00e9, il faut faire preuve d'un peu d'imagination et explorer le site. On peut ainsi charger non seulement le canal ou le serveur, mais aussi des parties sp\u00e9cifiques de l'application, comme les bases de donn\u00e9es ou les syst\u00e8mes de fichiers. On peut \u00e9galement rechercher des endroits sur le site qui effectuent de grands calculs : calculateurs, pages de s\u00e9lection de produits, etc. Enfin, il arrive souvent qu'il existe un script php sur le site qui g\u00e9n\u00e8re une page \u00e0 partir de plusieurs centaines de milliers de lignes. Un tel script surcharge \u00e9galement consid\u00e9rablement le serveur et peut devenir une cible pour une attaque.<\/p>\n

O\u00f9 chercher<\/h3>\n

\nLorsque nous scannons une ressource avant de proc\u00e9der \u00e0 un test, nous examinons d'abord le site lui-m\u00eame. Nous cherchons divers champs de saisie, des fichiers lourds \u2014 en gros tout ce qui peut poser des probl\u00e8mes \u00e0 la ressource et ralentir son fonctionnement. Des outils de d\u00e9veloppement simples dans Google Chrome et Firefox, montrant les temps de r\u00e9ponse de la page, sont utiles \u00e0 cet \u00e9gard.
\nNous scannons \u00e9galement les sous-domaines. Par exemple, un certain magasin en ligne, abc.com, a un sous-domaine admin.abc.com. Il s'agit tr\u00e8s probablement d'un panneau d'administration avec authentification, mais si nous y appliquons une charge, cela peut poser des probl\u00e8mes au site principal.
\nLe site peut avoir un sous-domaine api.abc.com. Il s'agit probablement d'une ressource pour les applications mobiles. L'application peut \u00eatre trouv\u00e9e dans l'App Store ou Google Play, \u00e9tablir un point d'acc\u00e8s sp\u00e9cial, examiner l'API et enregistrer des comptes de test. Le probl\u00e8me est que les gens pensent souvent que tout ce qui est prot\u00e9g\u00e9 par une authentification est invuln\u00e9rable aux attaques par d\u00e9ni de service. On pr\u00e9tend que l'authentification est le meilleur CAPTCHA, mais ce n'est pas le cas. Cr\u00e9er 10-20 comptes de test est facile, et une fois cr\u00e9\u00e9s, nous avons acc\u00e8s \u00e0 des fonctionnalit\u00e9s complexes et non prot\u00e9g\u00e9es.
\nNaturellement, nous examinons l'historique, le robots.txt et WebArchive, ViewDNS, \u00e0 la recherche de vieilles versions de la ressource. Il arrive parfois que les d\u00e9veloppeurs aient d\u00e9ploy\u00e9, disons, mail2.yandex.net, tandis qu'une ancienne version, mail.yandex.net, soit rest\u00e9e. Ce mail.yandex.net ne re\u00e7oit plus de support, les ressources de d\u00e9veloppement ne lui sont plus consacr\u00e9es, mais il continue \u00e0 consommer des donn\u00e9es de la base. Par cons\u00e9quent, nous pouvons efficacement exploiter les ressources de backend et tout ce qui se cache derri\u00e8re le codage avec une ancienne version. Bien s\u00fbr, ce n'est pas toujours le cas, mais nous y faisons face assez souvent.
\n\u00c9videmment, nous allons analyser tous les param\u00e8tres de la requ\u00eate, la structure des cookies. On peut, par exemple, injecter dans un tableau JSON \u00e0 l'int\u00e9rieur des cookies une certaine valeur, cr\u00e9er une grande hi\u00e9rarchie et faire en sorte que la ressource fonctionne de mani\u00e8re incroyablement lente.<\/p>\n

Charge dans la recherche<\/h3>\n

\nLa premi\u00e8re chose qui vient \u00e0 l'esprit lors de l'exploration d'un site est de surcharger la base de donn\u00e9es, car presque tout le monde a une fonction de recherche, et malheureusement, presque tout le monde la prot\u00e8ge mal. Pour une raison quelconque, les d\u00e9veloppeurs ne portent pas assez attention \u00e0 la recherche. Cependant, il y a une recommandation : ne pas effectuer de requ\u00eates identiques, car cela peut entra\u00eener une mise en cache, tout comme dans le cas d'une inondation HTTP.
\nEffectuer des requ\u00eates al\u00e9atoires sur la base de donn\u00e9es n'est pas toujours efficace non plus. Il est beaucoup mieux de cr\u00e9er une liste de mots cl\u00e9s pertinents pour la recherche. Reprenons l'exemple d'un site de commerce en ligne : supposons que le site vend des pneus de voiture et permet de d\u00e9finir le diam\u00e8tre des pneus, le type de voiture et d'autres param\u00e8tres. Par cons\u00e9quent, des combinaisons de mots pertinents obligeront la base de donn\u00e9es \u00e0 fonctionner dans des conditions beaucoup plus complexes.
\nDe plus, il est recommand\u00e9 d'utiliser la pagination : il est beaucoup plus difficile pour le moteur de recherche de rendre l'avant-derni\u00e8re page de r\u00e9sultats que la premi\u00e8re. Ainsi, gr\u00e2ce \u00e0 la pagination, on peut l\u00e9g\u00e8rement diversifier la charge.
\nDans l'exemple ci-dessous, nous montrons la charge dans la recherche. On voit qu'\u00e0 partir de la premi\u00e8re seconde du test, avec une vitesse de dix requ\u00eates par seconde, le site s'est effondr\u00e9 et ne r\u00e9pondait plus.<\/p>\n

\"DDoS
\n<\/p>\n

Et s'il n'y a pas de recherche ?<\/h3>\n

\nS'il n'y a pas de recherche, cela ne signifie pas que le site ne contient pas d'autres champs d'entr\u00e9e vuln\u00e9rables. Un de ces champs peut \u00eatre l'authentification. Actuellement, les d\u00e9veloppeurs aiment cr\u00e9er des hachages complexes pour prot\u00e9ger la base de connexions contre les attaques par tables de hachage. C'est une bonne chose, mais ces hachages consomment beaucoup de ressources CPU. Un grand flot de fausses authentifications conduit \u00e0 un refus du processeur, et par cons\u00e9quent, le site cesse de fonctionner.
\nLa pr\u00e9sence sur le site de diverses formulaires pour les commentaires et les retours est une occasion d'envoyer de tr\u00e8s grands textes ou simplement de cr\u00e9er un flot massif. Parfois, les sites acceptent des fichiers joints, y compris au format gzip. Dans ce cas, nous prenons un fichier de 1 To, le compressons avec gzip jusqu'\u00e0 quelques octets ou kilooctets et l'envoyons sur le site. Ensuite, il est d\u00e9compress\u00e9, ce qui produit un effet tr\u00e8s int\u00e9ressant. <\/p>\n

Rest API<\/h3>\n

\nIl conviendrait de consacrer un peu d'attention \u00e0 des services aujourd'hui aussi populaires que Rest API. Prot\u00e9ger un Rest API est beaucoup plus compliqu\u00e9 qu'un simple site web. M\u00eame les m\u00e9thodes de protection les plus \u00e9l\u00e9mentaires contre les tentatives de mot de passe ou d'autres activit\u00e9s ill\u00e9gitimes ne fonctionnent pas pour un Rest API.
\nUn Rest API est tr\u00e8s facile \u00e0 compromettre, car il acc\u00e8de directement \u00e0 la base de donn\u00e9es. De plus, une panne de ce service entra\u00eene des cons\u00e9quences assez graves pour l'entreprise. En effet, un Rest API est g\u00e9n\u00e9ralement li\u00e9 non seulement au site principal, mais aussi \u00e0 des applications mobiles, ainsi qu'\u00e0 certains ressources internes de l'entreprise. Et si tout cela tombe en panne, l'effet est bien plus important que dans le cas d'un simple site. <\/p>\n

Charge sur le contenu lourd<\/h3>\n

\nLorsque l'on nous propose de tester un type d'application ordinaire comme une page d'accueil, un site vitrine ou tout autre site d\u00e9pourvu de fonctionnalit\u00e9s complexes, nous recherchons un contenu lourd. Par exemple, de grandes images fournies par le serveur, des fichiers binaires, de la documentation PDF \u2014 nous essayons de tout t\u00e9l\u00e9charger. Ces tests sollicitent bien le syst\u00e8me de fichiers et saturent les canaux, ce qui les rend efficaces. M\u00eame si vous ne parvenez pas \u00e0 faire tomber le serveur en t\u00e9l\u00e9chargeant un gros fichier \u00e0 des vitesses faibles, vous saturerez simplement le canal du serveur cible, entra\u00eenant par la suite une d\u00e9faillance de service.
\n\u00c0 titre d'exemple de ce test, on voit qu'\u00e0 une vitesse de 30 RPS, le site a cess\u00e9 de r\u00e9pondre, ou a renvoy\u00e9 des erreurs serveur de type 500.<\/p>\n

\"DDoS
\n
\nN'oublions pas non plus la configuration des serveurs. On rencontre souvent des situations o\u00f9 une personne a achet\u00e9 une machine virtuelle, y a install\u00e9 Apache, a tout configur\u00e9 par d\u00e9faut, et a d\u00e9pos\u00e9 une application PHP, et ci-dessous on peut voir le r\u00e9sultat. <\/p>\n

\"DDoS
\n
\nIci, la charge \u00e9tait tr\u00e8s faible, seulement 10 RPS. Nous avons attendu 5 minutes, et le serveur a plant\u00e9. En fin de compte, il est difficile de dire pourquoi il a \u00e9chou\u00e9, mais on suppose qu'il a tout simplement satur\u00e9 sa m\u00e9moire, ce qui a caus\u00e9 son inactivit\u00e9.<\/p>\n

Bas\u00e9 sur les vagues<\/h3>\n

\nAu cours des derni\u00e8res ann\u00e9es, les attaques par vague sont devenues assez populaires. Cela est d\u00fb au fait que de nombreuses organisations ach\u00e8tent du mat\u00e9riel pour se prot\u00e9ger contre les attaques DDoS, ce qui n\u00e9cessite un certain temps pour accumuler des statistiques avant de commencer \u00e0 filtrer l'attaque. Cela signifie qu'elles ne filtrent pas l'attaque durant les 30 \u00e0 40 premi\u00e8res secondes, car elles collectent des donn\u00e9es et s'entra\u00eenent. Par cons\u00e9quent, durant ces 30 \u00e0 40 secondes, on peut lancer suffisamment d'attaques sur le site pour qu'il reste hors ligne pendant un certain temps, le temps que toutes les requ\u00eates soient trait\u00e9es.
\nDans le cas de l'attaque ci-dessous, il y a eu un intervalle de 10 minutes, apr\u00e8s quoi une nouvelle s\u00e9rie modifi\u00e9e d'attaques a eu lieu.<\/p>\n

\"DDoS
\n
\nC'est-\u00e0-dire que la protection a appris, a commenc\u00e9 \u00e0 filtrer, mais une nouvelle attaque totalement diff\u00e9rente est arriv\u00e9e, et la protection a recommenc\u00e9 son apprentissage. En fait, le filtrage cesse de fonctionner, la protection devient inefficace et le site devient inaccessible.
\nLes attaques par vague se caract\u00e9risent par des valeurs tr\u00e8s \u00e9lev\u00e9es au pic, pouvant atteindre des centaines de milliers ou des millions de requ\u00eates par seconde, dans le cas de L7. En ce qui concerne L3&4, il peut y avoir des centaines de gigabits de trafic, ou, par cons\u00e9quent, des centaines de mpps si on les compte en paquets.
\nLe probl\u00e8me de ces attaques r\u00e9side dans la synchronisation. Les attaques proviennent d'un botnet, et pour cr\u00e9er un pic unique tr\u00e8s important, un haut niveau de synchronisation est n\u00e9cessaire. Et cette coordination n'est pas toujours facile \u00e0 obtenir : parfois, le r\u00e9sultat est une sorte de pic parabolique qui semble plut\u00f4t lamentable.<\/p>\n

Pas que HTTP<\/h3>\n

\nEn plus de HTTP au niveau L7, nous aimons exploiter d'autres protocoles. En g\u00e9n\u00e9ral, un site web ordinaire, surtout un h\u00e9bergement classique, expose des protocoles de messagerie et MySQL. Les protocoles de messagerie sont moins susceptibles d'\u00eatre soumis \u00e0 des charges que les bases de donn\u00e9es, mais ils peuvent \u00e9galement \u00eatre charg\u00e9s de mani\u00e8re assez efficace, entra\u00eenant une surcharge du CPU du serveur.
\nNous avons r\u00e9ussi, gr\u00e2ce \u00e0 une vuln\u00e9rabilit\u00e9 SSH de 2016. Actuellement, cette vuln\u00e9rabilit\u00e9 est presque corrig\u00e9e chez tous, mais cela ne signifie pas qu'on ne peut pas soumettre de charge via SSH. On peut. Il suffit de soumettre une \u00e9norme charge d'autorisations. SSH consomme presque tout le CPU du serveur et le site web est d\u00e9j\u00e0 compromis avec une ou deux requ\u00eates par seconde. Par cons\u00e9quent, ces une ou deux requ\u00eates ne peuvent \u00eatre distingu\u00e9es des charges l\u00e9gitimes dans les journaux.
\nIl reste de nombreux connexions que nous ouvrons sur les serveurs. Auparavant, c'\u00e9tait un probl\u00e8me avec Apache, et maintenant, cela concerne \u00e9galement nginx, car il est souvent configur\u00e9 par d\u00e9faut. Le nombre de connexions que nginx peut maintenir ouvertes est limit\u00e9, donc lorsque nous atteignons ce nombre de connexions, nginx n'accepte plus de nouvelles connexions, ce qui entra\u00eene un dysfonctionnement du site.
\nNotre cluster de test dispose d'un CPU suffisant pour attaquer le handshake SSL. En pratique, les botnets aiment aussi parfois faire cela. D'une part, il est clair que l'on ne peut pas se passer du SSL, en raison de l'affichage Google, du r\u00e9f\u00e9rencement et de la s\u00e9curit\u00e9. D'autre part, malheureusement, le SSL a un probl\u00e8me avec le CPU. <\/p>\n

L3&4<\/h3>\n

\nLorsque nous parlons d'attaques aux niveaux L3&4, nous faisons g\u00e9n\u00e9ralement r\u00e9f\u00e9rence \u00e0 des attaques au niveau du canal. Cette charge est presque toujours distinguable d'une charge l\u00e9gitime, sauf s'il s'agit d'une attaque SYN-flood. Le probl\u00e8me des attaques SYN-flood pour les moyens de protection r\u00e9side dans leur volume important. La taille maximale des attaques L3&4 \u00e9tait de 1,5 \u00e0 2 Tbit\/s. Ce type de trafic est tr\u00e8s difficile \u00e0 traiter, m\u00eame pour de grandes entreprises telles qu'Oracle et Google.
\nSYN et SYN-ACK sont des paquets utilis\u00e9s lors de l'\u00e9tablissement d'une connexion. Par cons\u00e9quent, il est difficile de distinguer une SYN-flood d'une charge l\u00e9gitime : il n'est pas clair s'il s'agit d'une SYN destin\u00e9e \u00e0 \u00e9tablir une connexion ou d'une partie du flood.<\/p>\n

UDP-flood<\/h3>\n

\nEn g\u00e9n\u00e9ral, les attaquants n'ont pas les capacit\u00e9s que nous avons, donc pour organiser des attaques, une amplification peut \u00eatre utilis\u00e9e. Cela signifie que l'attaquant scanne Internet et trouve soit des serveurs vuln\u00e9rables, soit mal configur\u00e9s, qui, par exemple, r\u00e9pondent \u00e0 un seul paquet SYN par trois SYN-ACK. En falsifiant l'adresse source de l'adresse du serveur cible, on peut, avec un seul paquet, multiplier la puissance par trois et rediriger le trafic vers la victime.<\/p>\n

\"DDoS
\n
\nLe probl\u00e8me des amplifications r\u00e9side dans leur d\u00e9tection complexe. Parmi les derniers exemples, on peut citer le cas m\u00e9diatis\u00e9 du memcached vuln\u00e9rable. De plus, il existe maintenant de nombreux appareils IoT, des cam\u00e9ras IP, qui sont \u00e9galement principalement configur\u00e9s par d\u00e9faut, et g\u00e9n\u00e9ralement de mani\u00e8re incorrecte, c'est pourquoi les attaquants utilisent souvent ces appareils pour mener des attaques. <\/p>\n

\"DDoS
\n<\/p>\n

Une SYN-flood compliqu\u00e9e<\/h3>\n

\nL'attaque SYN-flood est probablement la plus int\u00e9ressante de toutes les attaques du point de vue des d\u00e9veloppeurs. Le probl\u00e8me est que souvent, les administrateurs syst\u00e8mes utilisent le blocage par IP pour se prot\u00e9ger. De plus, gr\u00e2ce \u00e0 ce blocage par IP, ne souffrent pas seulement les sysadmins qui agissent selon des scripts, mais malheureusement aussi certains syst\u00e8mes de protection qui sont achet\u00e9s \u00e0 prix \u00e9lev\u00e9.
\nCette m\u00e9thode peut se retourner contre eux, car si des attaquants substituent adresses IP<\/a>, l'entreprise va bloquer son propre sous-r\u00e9seau. Lorsque le pare-feu bloque son propre cluster, les interactions externes vont \u00e9chouer, et la ressource sera hors service.
\nIl est d'ailleurs facile d'atteindre le blocage de son propre r\u00e9seau. Si le bureau du client dispose d'un r\u00e9seau Wi-Fi, ou si la fonctionnalit\u00e9 des ressources est mesur\u00e9e \u00e0 l'aide de divers outils de monitoring, alors nous prenons l'adresse IP de ce syst\u00e8me de monitoring ou du client Wi-Fi du bureau et l'utilisons comme source. En sortie, la ressource semble accessible, mais les adresses IP cibles sont bloqu\u00e9es. Ainsi, le r\u00e9seau Wi-Fi de la conf\u00e9rence HighLoad, o\u00f9 un nouveau produit de l'entreprise est pr\u00e9sent\u00e9, peut \u00eatre bloqu\u00e9, ce qui entra\u00eene certains co\u00fbts commerciaux et \u00e9conomiques.
\nLors des tests, nous ne pouvons pas utiliser l'amplification via memcached avec des ressources externes, car il y a des accords pour l'envoi de trafic uniquement vers des adresses IP autoris\u00e9es. Par cons\u00e9quent, nous utilisons l'amplification via SYN et SYN-ACK, o\u00f9 pour l'envoi d'un SYN, le syst\u00e8me r\u00e9pond par deux ou trois SYN-ACK, et au final, l'attaque est multipli\u00e9e par deux ou trois. <\/p>\n

Outils<\/h3>\n

\nL'un des principaux outils que nous utilisons pour la charge au niveau L7 est Yandex-tank. En particulier, un phantom est utilis\u00e9 comme arme, plus il y a plusieurs scripts pour g\u00e9n\u00e9rer des munitions et analyser les r\u00e9sultats.
\nPour analyser le trafic r\u00e9seau, nous utilisons Tcpdump, et pour l'analyse du serveur \u2014 Nmap. Pour cr\u00e9er une charge au niveau L3&4, nous utilisons OpenSSL et un peu de notre propre magie avec la biblioth\u00e8que DPDK. DPDK est une biblioth\u00e8que d'Intel qui permet de travailler avec l'interface r\u00e9seau, en contournant la pile Linux, ce qui augmente ainsi l'efficacit\u00e9. Bien entendu, nous utilisons DPDK non seulement au niveau L3&4, mais aussi au niveau L7, car elle permet de g\u00e9n\u00e9rer un tr\u00e8s fort flux de charge, atteignant plusieurs millions de requ\u00eates par seconde depuis une seule machine.
\nNous utilisons \u00e9galement certains g\u00e9n\u00e9rateurs de trafic et des outils sp\u00e9ciaux que nous d\u00e9veloppons pour des tests sp\u00e9cifiques. En se souvenant de la vuln\u00e9rabilit\u00e9 sous SSH, le jeu d'outils mentionn\u00e9 ci-dessus ne peut pas \u00eatre exploit\u00e9. Si nous attaquons le protocole de messagerie, nous utilisons des utilitaires de messagerie ou simplement nous \u00e9crivons des scripts pour eux.<\/p>\n

\n

Conclusions<\/h3>\n

\nEn guise de conclusion, je voudrais dire :<\/p>\n