Mitigation de DDoS
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
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
[modifier | modifier le code]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
[modifier | modifier le code]Cible à défendre
[modifier | modifier le code]Défense d'infrastructure
[modifier | modifier le code]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
[modifier | modifier le code]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
[modifier | modifier le code]
Basé à la source
[modifier | modifier le code]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
[modifier | modifier le code]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
[modifier | modifier le code]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
[modifier | modifier le code]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
[modifier | modifier le code]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
[modifier | modifier le code]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
[modifier | modifier le code]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
[modifier | modifier le code]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
[modifier | modifier le code]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 |
Techniques contre DDoS d'application
[modifier | modifier le code]Random Port Hopping
[modifier | modifier le code]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
[modifier | modifier le code]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].
Techniques contre DDoS d'infrastructure
[modifier | modifier le code]Filtrage Ingress/Egress
[modifier | modifier le code]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
[modifier | modifier le code]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é
[modifier | modifier le code]À 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
[modifier | modifier le code]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
[modifier | modifier le code]Échelonnage des ressources
[modifier | modifier le code]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
[modifier | modifier le code]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)
[modifier | modifier le code]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
[modifier | modifier le code]- 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
[modifier | modifier le code]- (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
[modifier | modifier le code]- (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.
