Mitigation de DDoS
La mitigation de DDoS est la pratique consistant Ă supprimer ou rĂ©duire l'impact d'attaques par dĂ©ni de service distribuĂ©es (DDoS). Afin de pouvoir permettre aux services attaquĂ©s de rester disponibles, sa mise en place se dĂ©cline en plusieurs mĂ©canismes diffĂ©rant quant Ă leur angle de protection. Ces mĂ©canismes se classent selon leur cible de protection, leur emplacement sur le rĂ©seau ainsi que l'instant auquel ils interviennent. Cette mitigation Ă©tant difficile Ă rĂ©aliser en se basant sur une seule technologie, plusieurs mĂ©canismes de catĂ©gories diffĂ©rentes doivent parfois ĂȘtre utilisĂ©s dans le but de mener efficacement une mitigation de DDoS.
Problématique
La croissance, tant en nombre qu'en puissance, des attaques par dĂ©ni de service distribuĂ©es (DDoS) est devenue un problĂšme considĂ©rable pour un grand nombre d'entitĂ©s : en 2017, le nombre d'organisations ayant fait face Ă ce type d'attaque Ă©tait estimĂ© Ă 33 %, contre 17 % en 2016[1]. Ces attaques, visant Ă envoyer un grand nombre de requĂȘtes afin de perturber les performances d'un service[1] - [2], ne sont pas sans consĂ©quences : en 2015, la part des victimes faisant face Ă des dĂ©lais anormaux de chargement de page (pouvant nĂ©cessiter jusqu'Ă plusieurs jours) a Ă©tĂ© Ă©valuĂ©e Ă 58 %, et Ă 24 % le nombre d'organisations ayant fait face Ă une coupure totale de leurs services[3].
Les victimes de ces attaques font communément face à des attaques volumétriques et/ou applicatives et les vecteurs d'attaque sont souvent similaires : inondation (flooding) UDP, ICMP et TCP et/ou exploitation abusive des protocoles applicatifs[4]. Cependant, la défense face à ces attaques doit faire face à plusieurs problÚmes :
- la difficulté de traçabilité, ceci du notamment à l'emploi de méthodes d'usurpation d'adresse IP par l'attaquant[4] ;
- l'évolution en complexité de ces attaques avec le temps et l'apparition de nouveaux vecteurs, permettant d'outrepasser les mécanismes de mitigation mis en place[3] ;
- la baisse des coûts de déploiement de telles attaques[5], les rendant accessibles à plus d'attaquants potentiels.
Bien qu'il n'existe Ă priori pas de solution Ă l'Ă©preuve de tout DDoS[6], plusieurs mĂ©canismes existent et peuvent ĂȘtre mis en place afin de tenter de contrer et mitiger ce type d'attaque.
Classification des mécanismes de mitigation
DĂ©fense d'infrastructure
La dĂ©fense d'infrastructure vise Ă prĂ©venir contre les attaques dirigĂ©es vers le matĂ©riel des couches basses du modĂšle OSI et ayant pour but le dĂ©ni d'accĂšs lĂ©gitime aux ressources. Ces mĂ©canismes de mitigation tentent d'empĂȘcher la surcharge de la bande passante de la victime et la mise hors-service du matĂ©riel de routage[6].
Parmi les attaques contre lesquelles ces mécanismes tentent de protéger, on retient notamment les SYN-Flood (TCP-UDP) et les attaques par rebond (ICMP, TCP-UDP)[7].
DĂ©fense d'application
La défense d'application vise à prévenir contre l'exploitation de vulnérabilités systÚme et applicatives au niveau 7 du modÚle OSI. Ces mécanismes tiennent compte du fait que l'attaquant imite un comportement lambda et tente de tirer parti de failles systÚme, mises-à -jour non-effectuées et mauvaises configurations du serveur[6].
Le besoin de mécanismes de défense d'application est réel car de nombreux attaquants, s'étant heurtés aux mécanismes de défense d'infrastructure, se tournent vers l'attaque des couches logicielles et l'exploitation de faiblesses d'applications[2].
Les cibles Ă dĂ©fendre sont principalement des services Web rĂ©pondant Ă des requĂȘtes HTTP et faisant face Ă des montĂ©es en charge anormales. De tels mĂ©canismes empĂȘchent la saturation de ces services, notamment en tentant d'identifier les canaux sources de ces attaques[8].
Emplacement
Basé à la source
Les mĂ©canismes de dĂ©fense basĂ©s Ă la source visent Ă dĂ©tecter et filtrer le trafic le plus prĂšs possible de l'attaquant. Ils sont toutefois peu efficaces face aux attaques de DDoS par inondation (flooding) pour plusieurs raisons. Tout d'abord, les sources de telles attaques peuvent ĂȘtre Ă©clatĂ©es en plusieurs domaines, pouvant rendre la dĂ©tection prĂ©cise de flux anormaux Ă la source difficile. De plus, la diffĂ©renciation du trafic lĂ©gitime et anormal Ă la source est compliquĂ©e Ă©tant donnĂ© que ces attaques reposent sur un nombre de sources dispersĂ©es. De ce fait, le volume de l'attaque n'est dĂ©tectable qu'Ă proximitĂ© de la victime, lĂ oĂč les attaques se rejoignent[9].
Pour finir, les motivations au dĂ©ploiement Ă la source reposent sur des bases instables quant Ă qui paierait l'installation de tels mĂ©canismes de dĂ©fense. En effet, les FAI et systĂšmes autonomes Ă la source ont peu d'intĂ©rĂȘt Ă allouer des ressources (et/ou perdre en performance) afin de protĂ©ger les victimes chez d'autres FAI[10] - [6] - [11].
L'endroit idĂ©al pour mitiger une attaque DDoS reste nĂ©anmoins son point de dĂ©part, en empĂȘchant l'attaquant de pouvoir atteindre sa cible et mĂȘme d'autres rĂ©seaux. Ces filtres permettent ainsi d'empĂȘcher le gaspillage de bande passante sur le chemin jusqu'Ă la cible[9].
Basé à la destination
Les mécanismes basés à la destination sont plus faciles à implémenter. En effet, de par leur localisation à proximité de la victime, ils sont capables de voir le trafic à destination de la cible dans son entiÚreté et mieux l'analyser pour détecter une attaque[9].
Toutefois, ces mĂ©canismes n'entrant en jeu qu'Ă destination, certains considĂšrent que cette intervention tardive cause un gaspillage de bande passante sur le chemin jusqu'Ă la cible[9]. Se trouvant Ă©galement sur le chemin du flux agrĂ©gĂ©, ils peuvent devenir eux-mĂȘmes l'objet d'une attaque visant Ă saturer leurs liens rĂ©seau[11].
Basé dans le réseau
Le réseau, dans sa globalité, peut également constituer un point d'implantation de mécanismes de défense. Toutefois, le matériel de transport de paquets opÚre à la couche 2 et 3 du modÚle OSI et ne permet donc pas un filtrage des flux visant le DDoS d'une application à la couche 7[12].
Hybrides
Chaque mécanisme à emplacement unique précédent possédant des inconvénients, leur mitigation ne constitue pas une défense efficace contre toutes les attaques[13], alors que l'approche visant à faire communiquer ces composants prétend offrir une meilleure efficacité[10] - [11].
La défense Hybride vise à combiner les points forts de chaque solution en déployant des mécanismes de défense à plusieurs endroits tels que la source, la destination ou le réseau intermédiaire et en les faisant interagir. Un mécanisme hybride consiste généralement en la combinaison d'un filtrage à hauteur de la source et une limitation de la bande passante pour le trafic attaquant à hauteur de la cible[10].
Les points en défaveur de cette organisation sont néanmoins similaires à ceux des mécanismes précédents : ajout de complexité et besoin supplémentaire de ressources afin de pouvoir communiquer entre les dispositifs placés, manque d'incitants à la coopération entre les points de déploiement et besoin de confiance envers les mécanismes placés par autrui[9].
Instant d'intervention
L'intervention peut avoir lieu en trois temps. Cependant, en l'absence de solution à toute épreuve, une défense complÚte ne devrait pas se limiter à l'intervention en un seul temps pour contrer un DDoS[12].
Antérieur à l'attaque
Le meilleur moment pour interrompre une attaque DDoS est avant son lancement. En d'autres termes, la prĂ©vention est la meilleure dĂ©fense contre le DDoS. La plupart des mĂ©canismes de prĂ©vention visent Ă fixer les vulnĂ©rabilitĂ©s de la cible (protocoles faillibles, authentifications vulnĂ©rables, failles systĂšme ou rĂ©seau...) qui pourraient ĂȘtre exploitĂ©es au lancement d'une attaque DDoS[9].
Durant l'attaque
L'Ă©tape suivante dans la dĂ©fense contre une attaque DDoS est la dĂ©tection de l'attaque, qui a lieu au moment oĂč l'attaque survient[9]. Certains mĂ©canismes dĂ©tectent des flux d'attaque lorsque les liens de communication atteignent un certain niveau de congestion. D'autres dĂ©tectent des attaques par inondation (flooding) en constatant des comportements inhabituels sur les couches transport et applicatives[9].
Postérieur à l'attaque
Une fois l'attaque détectée, le mécanisme de défense doit pouvoir effectuer deux actions : trouver la source et entreprendre une réponse à l'attaque.
Les mécanismes visant à identifier la source doivent trouver un moyen de remonter le trafic. Ils tentent pour cela de traverser les routeurs en ordre inverse, et marquent les sources fiables (non-spoofées) de paquets afin de pouvoir identifier les paquets spoofés (usurpés) à l'aide de mécanismes comme le hop-count filtering[9].
Ceux visant à entreprendre une réponse ont pour objectif de mettre fin à l'attaque. La plupart des outils de mitigation de DDoS appliquent des politiques de limitation (throttling) ou mettent en place des filtrages de paquets le plus en amont possible afin de pouvoir bannir les sources de l'attaque (history-based IP filtering)[9].
Techniques proposées
Le tableau ci-dessous liste non-exhaustivement différentes techniques de mitigation existantes selon leurs critÚres de classification.
Intitulé | Cible | Emplacement | Instant d'intervention | Situation OSI |
---|---|---|---|---|
Filtrage Ingress/Egress | Infrastructure | Source | Pendant l'attaque | Routeurs (RĂ©seau) |
D-WARD | Infrastructure | Source | Pendant l'attaque | Routeurs (RĂ©seau) |
MULTOPS | Infrastructure | Source | Pendant l'attaque | Routeurs (RĂ©seau) |
Pare-feu inversé | Infrastructure | Source | Pendant l'attaque | Pare-feu (Réseau) |
Random Port Hopping | Application | Hybride (Source - Destination) | (Avant +) Pendant l'attaque | Applicatif |
Challenge | Application | Destination | (Avant +) Pendant l'attaque | Applicatif |
Patchs de sécurité | Application | Destination | Avant l'attaque | Applicatif |
Random Port Hopping
La technique proposĂ©e par le Random Port Hopping consiste Ă forcer le client Ă utiliser des numĂ©ros de port spĂ©cifiques afin de pouvoir joindre le serveur, si le client n'utilise pas le bon port, le serveur jettera ses paquets. En pratique, le serveur envoie tout d'abord une clĂ© cryptographique qui permet au client de dĂ©terminer le port sur lequel le contacter pour un certain laps de temps. Au-delĂ de ce laps de temps, le port change et le client doit le rĂ©-obtenir via le calcul avec la clĂ© du serveur[14] - [15]. Les ports Ă©tant inconnus, ce mĂ©canisme permet de se prĂ©munir contre les botnets envoyant sans cesse des requĂȘtes[14].
Challenge
Les protocoles de DĂ©fi-RĂ©ponse (PDR) ont pour but la confirmation de la prĂ©sence d'un utilisateur lĂ©gitime. La technique de prĂ©vention d'accĂšs illĂ©gitime la plus commune consiste en un test de Turing sous la forme d'un CAPTCHA, cette mĂ©thode est dĂšs lors devenue une catĂ©gorie de protocoles DĂ©fi-RĂ©ponse favorite. Ces puzzles doivent ĂȘtre incontournables et rĂ©solus en un temps imparti, et le serveur doit pouvoir vĂ©rifier la solution proposĂ©e en utilisant le moins de ressources possibles. Les PDRs peuvent prendre d'autres formes tels que des tests graphiques, Ă©galement populaires et invitant l'utilisateur Ă rĂ©agir Ă la prĂ©sentation d'une image au lieu de texte (qui pourrait ĂȘtre interprĂ©tĂ©). Ces images sont parfois distordues, incomplĂštes ou floutĂ©es afin de rendre la rĂ©solution du dĂ©fi inaccessible Ă une machine participant au DDoS[16].
Les attaquants reposant souvent sur de larges rĂ©seaux de bots. De ce fait, un challenge, bien que simple en principe, constitue un moyen efficace de contrer les attaques basĂ©es sur des requĂȘtes Ă haute frĂ©quence comme le DDoS[16].
Filtrage Ingress/Egress
Les mĂ©canismes de filtrage Ingress/Egress ont Ă©tĂ© proposĂ©s afin de dĂ©tecter et filtrer les paquets avec une IP usurpĂ©e (spoofed) au niveau des routeurs source sur base de groupes d'adresses IP internes marquĂ©s comme valides. Cette technique peut aisĂ©ment ĂȘtre implĂ©mentĂ©e au niveau des FAI pour mitiger leur trafic sortant[15]. Cependant, le filtre ne dĂ©tectera pas les paquets usurpĂ©s si leur adresse source se trouve toujours dans la liste autorisĂ©e[10].
Avec la tendance visant Ă utiliser des botnets comme support d'attaque DDoS, les attaquants n'ont cependant pas Ă se soucier d'usurpation d'IP : ils peuvent en effet utiliser des zombies utilisant leur adresse IP authentique, ces zombies n'ayant pas le moyen de remonter jusqu'au maĂźtre[10].
D-WARD
Ce mĂ©canisme, installĂ© Ă la source, vise Ă dĂ©tecter les inondations DDoS en surveillant Ă la fois le trafic entrant et sortant d'un ensemble d'adresses pour le comparer avec les caractĂ©ristiques d'un trafic normal prĂ©dĂ©fini. D-WARD tente d'arrĂȘter le trafic d'attaque en provenance d'un rĂ©seau interne Ă la bordure de ce rĂ©seau. Les flux d'attaque sont identifiĂ©s et filtrĂ©s et ralentis s'ils ne correspondent pas aux modĂšles prĂ©dĂ©finis[10]. Il permet ainsi de protĂ©ger l'extĂ©rieur mais surtout de privilĂ©gier un trafic interne lĂ©gitime lors d'une attaque[11].
Cependant, comme de nombreux mĂ©canismes Ă la source, les FAI ne sont pas incitĂ©s Ă dĂ©ployer D-WARD afin de protĂ©ger d'autres rĂ©seaux que les leurs. De plus, D-WARD peut ĂȘtre contournĂ© par des attaquants pouvant contrĂŽler leur trafic pour satisfaire les rĂšgles du trafic normal prĂ©dĂ©fini[10].
Pare-feu inversé
à l'inverse des pare-feu traditionnels qui protÚgent un réseau interne de paquets venant de l'extérieur, un pare-feu inversé protÚge l'extérieur d'attaques par inondation de paquets originaires d'un réseau interne. Ces pare-feu inversés limitent le ratio de paquets pouvant sortir et n'étant pas des réponses à d'autres paquets[10].
Cette solution prĂ©sente le mĂȘme inconvĂ©nient que les autres solutions basĂ©es Ă la source : le rĂ©seau source ne tire aucun bĂ©nĂ©fice du fait de dĂ©ployer un pare-feu inversĂ© coĂ»teux[10].
MULTOPS
La technique MULTOPS est placée sur les équipements réseaux de la source et se base sur des analyses heuristiques afin de détecter et filtrer les attaques DDoS. Lors de communications sur Internet, le matériel compare les quantités entrantes/sortantes et sortantes/entrantes[11]. Si des ratios disproportionnés atteignent certaines limites, le mécanisme interprÚte que le réseau interne est soit la source soit la cible d'une attaque[11].
MULTOPS n'est cependant pas adaptĂ© Ă toutes les situations, le trafic des rĂ©ponses serveur Ă©tant gĂ©nĂ©ralement supĂ©rieur Ă celui des requĂȘtes. On peut penser aux flux de donnĂ©es multimĂ©dia qui, bien que lĂ©gitimes, ont un ratio envoi/rĂ©ception inĂ©gal[10]. Ă ce haut taux de faux nĂ©gatifs s'ajoute la vulnĂ©rabilitĂ© aux attaques visant l'Ă©puisement de la mĂ©moire du matĂ©riel dĂ» Ă l'utilisation de structures de donnĂ©es dynamiques[11].
Autres techniques
Ăchelonnage des ressources
L'Ă©chelonnage dynamique des ressources constitue une fonctionnalitĂ© majeure des clouds. Il s'agit Ă©galement d'un des meilleurs outil de mitigation d'attaque DDoS car il permet de garder une disponibilitĂ© des serveurs en modifiant l'allocation de ressources. L'Ă©chelonnage dynamique peut ĂȘtre fait horizontalement, en dĂ©marrant de nouvelles instances de service sur le mĂȘme ou d'autres serveurs physiques afin de pouvoir rĂ©pondre Ă davantage de requĂȘtes jusqu'Ă surmonter l'attaque ; et peut Ă©galement ĂȘtre fait verticalement, en allouant davantage de puissance de calcul, de mĂ©moire vive ou de disque Ă une machine virtuelle. Ces accroissements de ressources permettent Ă la victime de faire face Ă l'attaque et continuer Ă proposer ses services[17].
Utilisation de FPGA
Tout d'abord présenté en tant qu'étude[18], l'utilisation de FPGA en tant que filtre DDoS a montré sa capacité à faire face à une attaque sans précédent de 1 Tbit/s ayant atteint l'hébergeur français OVH en [19].
Les avantages présentés par les FPGA dans le cadre de la mitigation de DDoS, sont :
- leurs résultats : les expériences réalisées sur FPGA atteignent des taux de 100 % de détection, 0 % de faux négatif et maximum 0,41 % de faux positifs[18] ;
- leur capacitĂ© Ă ĂȘtre reprogrammĂ©s en temps rĂ©el pour s'adapter aux attaques[20] ;
- leur flexibilité permettant d'intégrer divers mécanismes de mitigation (Hop-count filtering et Ingress/Egress par exemple)[20].
DDoS Mitigation as a Service (DMaaS)
Afin de répondre au problÚme de coûts liés au déploiement de matériel de sécurité, certaines compagnies se spécialisent en offre de mitigation DDoS à travers leurs cloud et datacenters. Les clients souhaitant acquérir une protection DDoS redirigent alors leur trafic entrant vers ces services de mitigation, aussi appelés DMaaS (pour DDoS Mitigation as a Service)[8]. Le prestataire de service de mitigation renvoie ensuite un flux de données filtré par des mécanismes de mitigation[21].
Un grand nombre de ces solutions cloud se basent sur la technique d'Ă©chelonnage dynamique de ressources Ă l'aide du grand nombre de machines disponibles dans leurs datacenters[22].
Les inconvénients d'une telle solution existent néanmoins :
- certaines données à caractÚre sensible ou confidentiel peuvent poser problÚme quant à leur partage avec le prestataire de service[8] ;
- le coût de telles solutions et la prévision de budgets permettant de faire face à des attaques parfois persistantes, occasionnelles ou répétitives[22] - [8] ;
- la redirection de trafic et son traitement entraßne une latence supplémentaire[21].
Références
- Kaspersky 2017.
- Bronte 2017, p. 693-694.
- Kaspersky 2015.
- Cardigliano 2016, p. 523-524.
- Ndibwile 2015, p. 261-262.
- Bhardwaj 2016, p. 796-797.
- Talpur 2016, p. 980.
- Somani 2017, p. 43-44.
- Zargar 2013, p. 2059-2061.
- Zargar 2013, p. 2053-2056.
- Jog 2015, p. 1-2.
- Zargar 2013, p. 2052.
- Jog 2015, p. 6.
- Praveen 2015, p. 3-4.
- Rai 2016, p. 97-99.
- Somani 2017, p. 35-36.
- Somani 2017, p. 41-42.
- Cuong 2017, p. 19.
- Silicon 2016.
- Cuong 2017, p. 14-15.
- Alharbi 2017, p. 2.
- Somani 2017, p. 2.
Liens externes
- (en) « Kaspersky Lab Research Shows DDoS Devastation on Organizations Continues to Climb », sur usa.kaspersky.com (consulté le )
- OVH, « Mitigation d'une attaque DDoS - OVH », sur www.ovh.com (consulté le )
- (en) « Global IT Security risks survey 2015 », sur media.kaspersky.com (consulté le )
Bibliographie
- (en) A. Cardigliano, L. Deri et T. Lundstrom, « Commoditising DDoS mitigation », 2016 International Wireless Communications and Mobile Computing Conference (IWCMC),â , p. 523â528 (DOI 10.1109/iwcmc.2016.7577112, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) T. Alharbi, A. Aljuhani et Hang Liu, « Holistic DDoS mitigation using NFV », 2017 IEEE 7th Annual Computing and Communication Workshop and Conference (CCWC),â , p. 1â4 (DOI 10.1109/ccwc.2017.7868480, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) P. Daffu et A. Kaur, « Mitigation of DDoS attacks in cloud computing », 2016 5th International Conference on Wireless Networks and Embedded Systems (WECON),â , p. 1â5 (DOI 10.1109/wecon.2016.7993478, lire en ligne, consultĂ© le )
- (en) M. Guri, Y. Mirsky et Y. Elovici, « 9-1-1 DDoS: Attacks, Analysis and Mitigation », 2017 IEEE European Symposium on Security and Privacy (EuroS P),â , p. 218â232 (DOI 10.1109/eurosp.2017.23, lire en ligne, consultĂ© le )
- (en) A. Bhardwaj, G. V. B. Subrahmanyam, V. Avasthi et H. Sastry, « DDoS attacks, new DDoS taxonomy and mitigation solutions #x2014; A survey », 2016 International Conference on Signal Processing, Communication, Power and Embedded System (SCOPES),â , p. 793â798 (DOI 10.1109/scopes.2016.7955549, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) Mattijs Jonker, Anna Sperotto, Roland van Rijswijk-Deij et Ramin Sadre, « Measuring the Adoption of DDoS Protection Services », Proceedings of the 2016 Internet Measurement Conference, ACM, iMC '16,â , p. 279â285 (ISBN 9781450345262, DOI 10.1145/2987443.2987487, lire en ligne, consultĂ© le )
- (en) Cuong Pham-Quoc, Biet Nguyen et Tran Ngoc Thinh, « FPGA-based Multicore Architecture for Integrating Multiple DDoS Defense Mechanisms », SIGARCH Comput. Archit. News, vol. 44, no 4,â , p. 14â19 (ISSN 0163-5964, DOI 10.1145/3039902.3039906, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) Robert Bronte, Hossain Shahriar et Hisham M. Haddad, « Mitigating Distributed Denial of Service Attacks at the Application Layer », Proceedings of the Symposium on Applied Computing, ACM, sAC '17,â , p. 693â696 (ISBN 9781450344869, DOI 10.1145/3019612.3019919, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) Rui Zhuang, Scott A. DeLoach et Xinming Ou, « Towards a Theory of Moving Target Defense », Proceedings of the First ACM Workshop on Moving Target Defense, ACM, mTD '14,â , p. 31â40 (ISBN 9781450331500, DOI 10.1145/2663474.2663479, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) V. Kansal et M. Dave, « Proactive DDoS attack detection and isolation », 2017 International Conference on Computer, Communications and Electronics (Comptelix),â , p. 334â338 (DOI 10.1109/comptelix.2017.8003989, lire en ligne, consultĂ© le )
- (en) G. Somani, M. S. Gaur, D. Sanghi et M. Conti, « Scale Inside-out: Rapid Mitigation of Cloud DDoS Attacks », IEEE Transactions on Dependable and Secure Computing, vol. PP, no 99,â , p. 1â1 (ISSN 1545-5971, DOI 10.1109/tdsc.2017.2763160, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) A. Rai et R. K. Challa, « Survey on Recent DDoS Mitigation Techniques and Comparative Analysis », 2016 Second International Conference on Computational Intelligence Communication Technology (CICT),â , p. 96â101 (DOI 10.1109/cict.2016.27, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) G. Somani, M. S. Gaur, D. Sanghi et M. Conti, « Combating DDoS Attacks in the Cloud: Requirements, Trends, and Future Directions », IEEE Cloud Computing, vol. 4, no 1,â , p. 22â32 (ISSN 2325-6095, DOI 10.1109/mcc.2017.14, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) Sonia Laskar et Dhirendra Mishra, « Qualified Vector Match and Merge Algorithm (QVMMA) for DDoS Prevention and Mitigation », Procedia Computer Science, vol. 79,â , p. 41â52 (ISSN 1877-0509, DOI 10.1016/j.procs.2016.03.007, lire en ligne, consultĂ© le )
- (en) Ć Apiecionek et W. Makowski, « Firewall rule with token bucket as a DDoS protection tool », 2015 IEEE 13th International Scientific Conference on Informatics,â , p. 32â35 (DOI 10.1109/informatics.2015.7377803, lire en ligne, consultĂ© le )
- (en) V. S. M. Huang, R. Huang et M. Chiang, « A DDoS Mitigation System with Multi-stage Detection and Text-Based Turing Testing in Cloud Computing », 2013 27th International Conference on Advanced Information Networking and Applications Workshops,â , p. 655â662 (DOI 10.1109/waina.2013.94, lire en ligne, consultĂ© le )
- (en) J. D. Ndibwile, A. Govardhan, K. Okada et Y. Kadobayashi, « Web Server Protection against Application Layer DDoS Attacks Using Machine Learning and Traffic Authentication », 2015 IEEE 39th Annual Computer Software and Applications Conference, vol. 3,â , p. 261â267 (DOI 10.1109/compsac.2015.240, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) B. Wang, Y. Zheng, W. Lou et Y. T. Hou, « DDoS Attack Protection in the Era of Cloud Computing and Software-Defined Networking », 2014 IEEE 22nd International Conference on Network Protocols,â , p. 624â629 (DOI 10.1109/icnp.2014.99, lire en ligne, consultĂ© le )
- (en) O. Demir et K. Ghose, « Real-time protection against DDoS attacks using active gateways », 25th IEEE International Conference on Distributed Computing Systems Workshops,â , p. 224â231 (DOI 10.1109/icdcsw.2005.118, lire en ligne, consultĂ© le )
- (en) B. Rashidi, C. Fung et E. Bertino, « A Collaborative DDoS Defence Framework Using Network Function Virtualization », IEEE Transactions on Information Forensics and Security, vol. 12, no 10,â , p. 2483â2497 (ISSN 1556-6013, DOI 10.1109/tifs.2017.2708693, lire en ligne, consultĂ© le )
- (en) S. Ezhilarasi, « DDTA- DDoS defense techniques and attributes to integrate Smart Grid and Cloud », 2016 Online International Conference on Green Engineering and Technologies (IC-GET),â , p. 1â6 (DOI 10.1109/get.2016.7916677, lire en ligne, consultĂ© le )
- (en) S. T. Zargar, J. Joshi et D. Tipper, « A Survey of Defense Mechanisms Against Distributed Denial of Service (DDoS) Flooding Attacks », IEEE Communications Surveys Tutorials, vol. 15, no 4,â fourth 2013, p. 2046â2069 (ISSN 1553-877X, DOI 10.1109/surv.2013.031413.00127, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) V. Kambhampati, C. Papadopoulos et D. Massey, « A taxonomy of capabilities based DDoS defense architectures », 2011 9th IEEE/ACS International Conference on Computer Systems and Applications (AICCSA),â , p. 157â164 (DOI 10.1109/aiccsa.2011.6126615, lire en ligne, consultĂ© le )
- (en) T. Booth et K. Andersson, « Critical infrastructure network DDoS defense, via cognitive learning », 2017 14th IEEE Annual Consumer Communications Networking Conference (CCNC),â , p. 1â6 (DOI 10.1109/ccnc.2017.8013423, lire en ligne, consultĂ© le )
- (en) S. R. Talpur et T. Kechadi, « A survey on DDoS attacks: Router-based threats and defense mechanism in real-world data centers », 2016 Future Technologies Conference (FTC),â , p. 978â984 (DOI 10.1109/ftc.2016.7821722, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) S. Venkatesan, M. Albanese, K. Amin et S. Jajodia, « A moving target defense approach to mitigate DDoS attacks against proxy-based architectures », 2016 IEEE Conference on Communications and Network Security (CNS),â , p. 198â206 (DOI 10.1109/cns.2016.7860486, lire en ligne, consultĂ© le )
- (en) M. Ăzçelik, N. Chalabianloo et G. GĂŒr, « Software-Defined Edge Defense Against IoT-Based DDoS », 2017 IEEE International Conference on Computer and Information Technology (CIT),â , p. 308â313 (DOI 10.1109/cit.2017.61, lire en ligne, consultĂ© le )
- (en) Q. Yan, F. R. Yu, Q. Gong et J. Li, « Software-Defined Networking (SDN) and Distributed Denial of Service (DDoS) Attacks in Cloud Computing Environments: A Survey, Some Research Issues, and Challenges », IEEE Communications Surveys Tutorials, vol. 18, no 1,â firstquarter 2016, p. 602â622 (ISSN 1553-877X, DOI 10.1109/comst.2015.2487361, lire en ligne, consultĂ© le )
- (en) Gaurav Somani, Manoj Singh Gaur, Dheeraj Sanghi et Mauro Conti, « DDoS attacks in cloud computing: Issues, taxonomy, and future directions », Computer Communications, vol. 107,â , p. 30â48 (DOI 10.1016/j.comcom.2017.03.010, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) B. S. Kiruthika Devi, G. Preetha, G. Selvaram et S. Mercy Shalinie, « An impact analysis: Real time DDoS attack detection and mitigation using machine learning », 2014 International Conference on Recent Trends in Information Technology,â , p. 1â7 (DOI 10.1109/icrtit.2014.6996133, lire en ligne, consultĂ© le )
- (en) M. Jog, M. Natu et S. Shelke, « Distributed capabilities-based DDoS defense », 2015 International Conference on Pervasive Computing (ICPC),â , p. 1â6 (DOI 10.1109/pervasive.2015.7086993, lire en ligne, consultĂ© le ) : document utilisĂ© comme source pour la rĂ©daction de cet article.
- (en) R. Praveen Kumar, Jagdish Babu, T. Guna Sekhar et S. Barath Bushan, « Mitigating Application DDoS Attacks using Random Port Hopping Technique », International Journal of Emerging Research in Management &Technology,â (lire en ligne) : document utilisĂ© comme source pour la rĂ©daction de cet article.