R\u00e9cemment, pour aider des amis \u00e0 g\u00e9rer les anomalies de trafic d'une plateforme d'\u00e9ducation en ligne, je me suis connect\u00e9 au serveur pour jeter un coup d'\u0153il, bon gars, le nombre de connexions TCP a directement grimp\u00e9 \u00e0 plus de 100 000, le CPU tourne \u00e0 plein r\u00e9gime, l'ensemble de la carte de flux vid\u00e9o en PPT - sc\u00e8ne typique d'attaque SYN Flood. Cette ann\u00e9e, les services vid\u00e9o, et non les attaques SYN, sont embarrass\u00e9s de dire qu'ils font des affaires sur l'internet.<\/p>\n
L'attaque SYN signifie que l'attaquant envoie fr\u00e9n\u00e9tiquement une demande de connexion TCP, mais qu'apr\u00e8s avoir re\u00e7u le SYN-ACK du serveur, il ne r\u00e9pond pas \u00e0 l'ACK. Le serveur laisse stupidement une connexion semi-ouverte et ainsi de suite, jusqu'\u00e0 ce que les ressources soient \u00e9puis\u00e9es. Le secteur de la vid\u00e9o est extr\u00eamement sensible \u00e0 la latence et \u00e0 la stabilit\u00e9. Une fois que le pool de connexions est plein, les utilisateurs normaux ne peuvent m\u00eame pas se connecter, et encore moins regarder des vid\u00e9os en HD 4K.<\/p>\n
Dans les premiers temps, de nombreuses \u00e9quipes pensaient que l'achat d'un pare-feu traditionnel pouvait suffire, mais elles se sont aper\u00e7ues que l'\u00e9quipement purement mat\u00e9riel ne pouvait tout simplement pas supporter un grand nombre de fausses connexions. J'ai test\u00e9 une marque de pare-feu, 200 000 paquets SYN par seconde pour faire face au mensonge direct, mais aussi, incidemment, le trafic normal est \u00e9galement tu\u00e9. Ne croyez pas \u00e0 ces publicit\u00e9s de \u201csolution universelle\u201d, la protection contre les attaques SYN doit \u00eatre combin\u00e9e avec les caract\u00e9ristiques du protocole et les sc\u00e9narios d'entreprise pour une optimisation en profondeur.<\/p>\n
Une solution vraiment efficace consiste \u00e0 s'appuyer sur le CDN vid\u00e9o haute d\u00e9finition pour compl\u00e9ter le proxy de connexion TCP au niveau du n\u0153ud p\u00e9riph\u00e9rique. En d'autres termes, le n\u0153ud CDN remplace la station source et l'utilisateur pour \u00e9tablir une connexion, gr\u00e2ce au m\u00e9canisme d'authentification qui permet de filtrer les demandes malveillantes. Voici un d\u00e9tail important : le CDN ne peut pas simplement laisser tomber des paquets, vous devez simuler le comportement de la pile du syst\u00e8me d'exploitation r\u00e9el, sinon l'attaquant sera en mesure de briser le d\u00e9guisement en un coup d'\u0153il.<\/p>\n
Par exemple, la strat\u00e9gie de protection de CDN07 est tr\u00e8s int\u00e9ressante : le premier paquet SYN est directement lib\u00e9r\u00e9 et les empreintes digitales sont enregistr\u00e9es, et lorsque la m\u00eame IP source initie \u00e0 plusieurs reprises une connexion dans un d\u00e9lai de 10 ms, le client doit d'abord relever un d\u00e9fi cryptographique. Des tests ont montr\u00e9 que cette m\u00e9thode permet de filtrer 99,7% des paquets falsifi\u00e9s et que l'impact sur les utilisateurs normaux est inf\u00e9rieur \u00e0 0,2 seconde. Leurs n\u0153uds peuvent m\u00eame \u00e9muler les diff\u00e9rentes caract\u00e9ristiques de la pile TCP de Linux et de Windows, ce qui rend difficile l'identification de l'environnement r\u00e9el par les attaquants.<\/p>\n
Voici un exemple de configuration (bas\u00e9 sur le module d'extension Nginx) :<\/p>\n
Le param\u00e8tre max_half_open est particuli\u00e8rement important : il contr\u00f4le le nombre maximal de connexions semi-ouvertes autoris\u00e9es par n\u0153ud p\u00e9riph\u00e9rique. Il est recommand\u00e9 de l'ajuster dynamiquement en fonction du trafic de l'entreprise, par exemple les heures de pointe en direct peuvent \u00eatre assouplies de mani\u00e8re appropri\u00e9e, mais doivent \u00eatre associ\u00e9es \u00e0 des alarmes de surveillance en temps r\u00e9el.<\/p>\n
L'approche de 08Host est encore plus radicale : elle modifie directement la pile TCP du noyau pour r\u00e9duire le d\u00e9lai d'attente de l'\u00e9tat SYN_RECV de 75 secondes par d\u00e9faut \u00e0 8 secondes. Bien que cela nuise \u00e0 certains utilisateurs ayant un temps de latence \u00e9lev\u00e9, la d\u00e9fense contre les attaques DDoS est imm\u00e9diatement efficace. Les donn\u00e9es test\u00e9es dans les n\u0153uds asiatiques montrent que cette approche peut r\u00e9sister \u00e0 1,5 million de paquets d'attaque SYN par seconde, alors que la consommation de m\u00e9moire du serveur est inf\u00e9rieure \u00e0 20%.<\/p>\n
Toutefois, cette solution a un effet secondaire qui peut affecter le taux de r\u00e9ussite des connexions des utilisateurs multinationaux. Par la suite, ils ont mis en place une planification g\u00e9ographique intelligente : une politique de temporisation standard pour les utilisateurs europ\u00e9ens et am\u00e9ricains, et un mode agressif pour les r\u00e9gions o\u00f9 l'incidence des attaques est \u00e9lev\u00e9e. Cela n\u00e9cessite que les n\u0153uds mondiaux synchronisent les donn\u00e9es d'\u00e9tat, et la mise en \u0153uvre technique est assez complexe.<\/p>\n
En parlant de synchronisation des n\u0153uds, je dois mentionner la fosse de partage d'\u00e9tat. Les premiers CDN5 utilisaient des clusters Redis pour synchroniser l'\u00e9tat de la connexion et, par cons\u00e9quent, Redis se bloquait en premier apr\u00e8s l'attaque. Aujourd'hui, les programmes grand public utilisent le hachage coh\u00e9rent pour mettre en cache l'\u00e9tat local, bien que les donn\u00e9es soient l\u00e9g\u00e8rement retard\u00e9es, mais pour s'assurer que le syst\u00e8me de protection lui-m\u00eame ne devienne pas un goulot d'\u00e9tranglement.<\/p>\n
Les services vid\u00e9o ont \u00e9galement un besoin particulier : la protection ne peut pas interf\u00e9rer avec le protocole QUIC. De nombreux flux vid\u00e9o utilisent d\u00e9sormais QUIC au lieu de TCP, mais les variantes d'attaques SYN commencent \u00e9galement \u00e0 cibler le processus de poign\u00e9e de main QUIC. Un bon syst\u00e8me de protection doit pouvoir g\u00e9rer \u00e0 la fois les attaques par inondation du protocole TCP et de la poign\u00e9e de main QUIC, comme le mod\u00e8le de protection hybride de CDN07 :<\/p>\n
Outre la mise en \u0153uvre technique, la strat\u00e9gie au niveau de l'entreprise est tout aussi importante. Il est recommand\u00e9 d'allouer des ressources de protection distinctes aux services vid\u00e9o de diff\u00e9rents niveaux d'importance :<\/p>\n
Core Live Streaming<\/strong>Niveau de protection le plus \u00e9lev\u00e9, autorisant 11 TP3T de faux positifs mais garantissant 99,991 TP3T de disponibilit\u00e9.<\/p>\n vid\u00e9o \u00e0 la demande<\/strong>Les services d'aide \u00e0 la d\u00e9cision : Permettre une protection moyenne et une validation secondaire gr\u00e2ce \u00e0 l'analyse du comportement de l'utilisateur<\/p>\n Ant\u00e9c\u00e9dents de l'administrateur<\/strong>Mode de liste blanche compl\u00e8te, pr\u00e9f\u00e9rant tuer mille personnes par erreur plut\u00f4t que d'en \u00e9pargner une.<\/p>\n Enfin, comparons une s\u00e9rie de donn\u00e9es, l'ann\u00e9e derni\u00e8re pour tester l'efficacit\u00e9 de la protection des trois principaux fabricants :<\/p>\n CDN5 : 800 000 paquets SYN trait\u00e9s par seconde, frais g\u00e9n\u00e9raux de l'unit\u00e9 centrale 12%, taux de faux positifs 0,8%<\/p>\n CDN07 : 2,1 millions de paquets SYN trait\u00e9s par seconde, frais g\u00e9n\u00e9raux de l'unit\u00e9 centrale 23%, taux de faux positifs 0,3%<\/p>\n 08Host : 1,5 million de paquets SYN trait\u00e9s par seconde, frais g\u00e9n\u00e9raux de l'unit\u00e9 centrale 81 TP3T, taux de faux positifs 1,51 TP3T<\/p>\n On constate qu'il n'y a pas de solution parfaite, une puissance de traitement \u00e9lev\u00e9e s'accompagne souvent d'une consommation de ressources plus importante. CDN07 convient aux grandes plateformes avec des activit\u00e9s complexes, 08Host convient aux projets de taille moyenne sensibles aux co\u00fbts, et CDN5 est plus performant en termes d'\u00e9quilibre.<\/p>\n N'oubliez pas d'optimiser en permanence apr\u00e8s le d\u00e9ploiement de la protection. Une fois qu'un client s'est configur\u00e9 pour se reposer sur ses lauriers, l'attaquant a chang\u00e9 pour attaquer la phase de poign\u00e9e de main SSL, comme d'habitude, il a frapp\u00e9 l'unit\u00e9 centrale compl\u00e8te :<\/p>\n - Protection de la connexion TCP<\/p>\n - Optimisation de l'\u00e9change SSL\/TLS<\/p>\n - Empreintes de protocole<\/p>\n - Programmation du trafic en temps r\u00e9el<\/p>\n Pour \u00eatre honn\u00eate, le plus grand casse-t\u00eate dans ce domaine n'est pas la mise en \u0153uvre technique, mais le co\u00fbt de la lutte contre celle-ci. Les attaquants louent des botnets pour seulement quelques centaines de dollars par jour, et les programmes de protection co\u00fbtent des millions de dollars par an. Il est recommand\u00e9 aux startups d'utiliser d'abord les programmes de paiement \u00e0 l'utilisation des fournisseurs de cloud, puis d'envisager des d\u00e9ploiements hybrides lorsque le volume d'activit\u00e9 augmente.<\/p>\n En bref, la protection SYN est comme le port d'un gilet pare-balles pour le secteur de la vid\u00e9o - il ne faut pas s'attendre \u00e0 \u00eatre invuln\u00e9rable, mais au moins on peut rester en vie quand on se fait attaquer. L'essentiel est de comprendre le principe de l'attaque, en fonction des caract\u00e9ristiques commerciales r\u00e9elles du choix du programme, et de ne pas se contenter d'un discours commercial pour prendre la mauvaise d\u00e9cision. Apr\u00e8s tout, de nos jours, m\u00eame les CDN doivent \u201cpr\u00e9venir les co\u00e9quipiers\u201d (un fournisseur qui utilise secr\u00e8tement les n\u0153uds de ses clients pour nettoyer le trafic n'est pas un paragraphe).<\/p>\n La prochaine fois que vous rencontrerez un d\u00e9calage vid\u00e9o, ne vous pr\u00e9cipitez pas pour jeter le pot aux roses des param\u00e8tres d'encodage, v\u00e9rifiez l'\u00e9tat de la connexion TCP et vous aurez peut-\u00eatre une surprise. Apr\u00e8s tout, aux yeux de l'attaquant, la plateforme vid\u00e9o est un morceau de viande grasse, l'attaque SYN n'est que le co\u00fbt le plus bas de l'accueil d'entr\u00e9e de gamme.<\/p>","protected":false},"excerpt":{"rendered":" R\u00e9cemment, pour aider des amis \u00e0 g\u00e9rer les anomalies de trafic d'une plate-forme d'\u00e9ducation en ligne, je me suis connect\u00e9 au serveur pour jeter un coup d'\u0153il, bon gars, le nombre de connexions TCP a directement grimp\u00e9 \u00e0 plus de 100 000, le CPU tourne \u00e0 plein r\u00e9gime, la carte de flux vid\u00e9o enti\u00e8re en PPT - site d'attaque SYN Flood typique. Cette ann\u00e9e, les services vid\u00e9o, et non les attaques SYN, sont embarrass\u00e9s de dire qu'ils font des affaires sur Internet. L'attaque SYN, c'est, pour parler franchement, la folie de l'attaquant qui envoie une demande de connexion TCP, mais qui, apr\u00e8s avoir re\u00e7u le SYN-ACK du serveur, ne r\u00e9pond pas \u00e0 l'ACK. Le serveur est stupide, il reste en connexion semi-ouverte et attend une r\u00e9ponse, jusqu'\u00e0 ce que les ressources soient \u00e9puis\u00e9es. Le secteur de la vid\u00e9o est extr\u00eamement sensible \u00e0 la latence et \u00e0 la stabilit\u00e9, une fois que le pool de connexions est plein, les utilisateurs normaux ne peuvent m\u00eame pas se connecter, et encore moins regarder des vid\u00e9os en HD 4K. Au d\u00e9but, de nombreuses \u00e9quipes pensaient que l'achat d'un pare-feu traditionnel r\u00e9soudrait le probl\u00e8me.<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"gallery","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","footnotes":""},"categories":[150],"tags":[],"collection":[],"class_list":["post-1008","post","type-post","status-publish","format-gallery","hentry","category-updates","post_format-post-format-gallery"],"_links":{"self":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1008","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/comments?post=1008"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1008\/revisions"}],"predecessor-version":[{"id":1117,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1008\/revisions\/1117"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=1008"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=1008"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=1008"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=1008"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}