DDoS (Déni de service distribué) et DoS (Déni de service) Les attaques peuvent être classées en trois catégories en fonction des couches du modèle OSI qu’elles ciblent.: Couche réseau (Couche 3), couche de transport (Couche 4), et couche d’application (Couche 7).

Couche 3 et Calque 4 Les attaques sont généralement moins complexes–même si cela pourrait être très difficile à atténuer–et impliquent d’inonder le réseau et la couche de transport avec du trafic, surcharger les ressources du système cible et le rendre inaccessible aux utilisateurs légitimes. Ces types d’attaques peuvent être lancés à l’aide de diverses techniques telles que les inondations ICMP, Inondations TCP SYN, ou inondations UDP.

Une inondation ICMP par exemple, est un calque 3 attaque dans laquelle un grand nombre de paquets ICMP sont inondés dans le système cible, le rendre insensible. Une inondation TCP SYN, D’un autre côté, est une couche 4 attaque qui exploite les méthodes d’établissement des connexions TCP.

Lors d’une attaque par inondation SYN, l’attaquant envoie de nombreux paquets SYN au système cible, mais n’envoie jamais de paquet ACK pour terminer la connexion. Cela amène le système à allouer des ressources pour chaque tentative de connexion, ce qui finit par surcharger le système et le rendre indisponible pour les utilisateurs légitimes.. Une inondation UDP envoie un grand nombre de paquets UDP à un système cible, consommer ses ressources et le rendre insensible.

Attaques DDoS de la couche applicative

Les attaques de couche applicative sont plus complexes et plus difficiles à atténuer que les attaques de couche 3 et couche 4 Attaques. Ces attaques ciblent la couche applicative (couche 7) du système cible et exploiter les vulnérabilités de l’application elle-même. Couche 7 Les attaques peuvent causer plus de dégâts car elles peuvent avoir un impact direct sur les applications et l’infrastructure sous-jacente. Vous ne pourrez pas atténuer la couche 7 Attaques DDoS avec couche 3 ou couche 4 des outils tels que les pare-feu réseau.

Inondations HTTP, Attaques Slowloris, et les attaques d’amplification DNS sont Layer 7 Attaques par déni de service. Ces attaques nécessitent des défenses plus sophistiquées telles que des pare-feu de couche applicative, Systèmes de prévention des intrusions, et CDN (Réseaux de diffusion de contenu).

Inondations HTTP

Les attaques HTTP floods sont effectuées à l’aide de requêtes GET ou POST pour submerger le serveur cible. Les attaques d’inondation utilisant des requêtes GET sont généralement plus simples et nécessitent moins de ressources car elles ne demandent que des informations au serveur. Demandes POST, D’un autre côté, nécessitent généralement l’envoi de grandes quantités de données.

L’une des raisons pour lesquelles les attaques HTTP flood sont difficiles à atténuer est qu’elles sont souvent lancées à partir d’un grand nombre de sources., rendant difficile l’identification et le blocage de tout trafic malveillant. De plus, les attaquants peuvent utiliser des techniques telles que l’usurpation d’adresse IP pour dissimuler leur véritable identité et rendre encore plus difficile de retracer la source de leurs attaques.

Se défendre contre les attaques HTTP flood peut être compliqué. Différents types d’attaques nécessitent des stratégies d’atténuation différentes. Les défenses courantes contre les attaques HTTP flood incluent la limitation de débit, Liste noire, et pare-feu d’applications Web. Toutefois, Ces techniques peuvent nécessiter beaucoup de ressources et peuvent ne pas être suffisantes pour contrecarrer des attaques plus sophistiquées..

Attaques Slowloris

Slowloris est un type d’attaque d’inondation dans lequel la façon dont les serveurs Web gèrent les connexions client est ciblée. Cette attaque fonctionne en ouvrant un grand nombre de connexions au serveur, mais l’envoi des demandes à un rythme lent, garder chaque connexion ouverte le plus longtemps possible. Ce type d’attaque peut consommer toutes les ressources disponibles du serveur et permet aux attaquants de consommer du CPU, mémoire, ou bande passante réseau, etc. sans même déclencher la limite de débit typique et les mécanismes de filtrage du trafic couramment utilisés pour détecter et bloquer d’autres types d’attaques DDoS.

Pour mener une attaque Slowloris, les attaquants utilisent généralement des scripts ou des outils qui envoient des requêtes HTTP à un serveur, mais retardent délibérément l’envoi des demandes ultérieures. La demande est conçue pour ressembler à une demande légitime, mais avec un en-tête incomplet qui maintient la connexion ouverte indéfiniment. Au fil du temps, Le serveur aura de nombreuses connexions ouvertes en attente de données supplémentaires du client, Provoquer l’arrêt du serveur de répondre au trafic légitime.

Les attaques Slowloris peuvent être difficiles à détecter en raison de leur conception secrète et de leur bande passante relativement faible. Cela en fait un outil efficace pour les attaquants qui veulent saboter leurs serveurs sans déclencher d’alertes ni créer de suspicion. Pour se défendre contre les attaques de Slowloris, Les serveurs Web peuvent mettre en œuvre plusieurs contre-mesures. Par exemple, limiter le nombre de connexions pouvant être établies à partir d’une seule adresse IP ou définir un délai d’expiration pour les demandes incomplètes. Certains pare-feu d’applications Web et services d’atténuation DDoS ont une protection intégrée contre les attaques Slowloris, utiliser des algorithmes capables de détecter et de bloquer ce trafic en temps réel.

Couche 7 Atténuations DDoS

Limitation du débit

La limitation du débit implique la définition d’un seuil sur le nombre de demandes pouvant être effectuées à partir d’une adresse IP spécifique ou d’un agent utilisateur au cours d’une période de temps spécifique.. Le concept est très similaire à la limitation de débit en couche 3 mais il doit être mis en œuvre au niveau de la couche 7.

Le but de la limitation de débit est d’empêcher un attaquant de surcharger l’application Web avec un grand nombre de requêtes, Interruption du serveur. La limitation de débit peut être implémentée à différentes couches de l’architecture de votre application Web, sur un serveur Web, Équilibreur de charge, ou pare-feu applicatif. Les implémentations impliquent généralement le suivi du nombre de demandes effectuées par une adresse IP ou un agent utilisateur particulier et le blocage d’autres demandes lorsqu’un seuil prédéfini est atteint.

Une approche courante pour implémenter la limitation de débit dans les applications Web consiste à utiliser des middleware ou des plugins qui suivent le nombre de requêtes effectuées par chaque client et bloquent les demandes ultérieures lorsque le seuil est dépassé. Ces plugins peuvent être configurés pour appliquer différentes politiques de limitation de débit en fonction de facteurs tels que le type de demande, Agent utilisateur, ou adresse IP du client.

Par exemple, une simple politique de limitation de débit peut limiter les demandes provenant d’une seule adresse IP à un maximum de 10 demandes par minute. Si un client dépasse ce seuil, Les demandes suivantes sont bloquées jusqu’à l’expiration du délai.

Les produits de limitation de débit de la couche applicative sont disponibles pour les serveurs Web et les services cloud courants, y compris:

Apache

Apache dispose de plusieurs modules qui peuvent être utilisés pour limiter le débit, comme mod_limitipconn, ce qui limite le nombre de connexions simultanées à partir d’une adresse IP donnée, Et mod_qos, qui fournit divers contrôles de qualité de service, y compris la limitation de débit.

En outre, Pare-feu d’application Web ModSecurity dispose d’une fonction de limitation de débit qui peut bloquer les clients dépassant un seuil défini. En plus des modules mentionnés ci-dessus, Apache fournit également des mod_evasive. Il s’agit d’un module qui peut être utilisé pour limiter le débit et bloquer les clients qui dépassent un seuil défini. Détecter et bloquer les clients escrocs à l’aide de diverses techniques, y compris le suivi de l’IP et de l’agent utilisateur.

Nginx

Nginx fournit Module ngx_http_limit_req. Cela peut être utilisé pour limiter le taux de demande de certains clients en fonction de l’adresse IP ou d’autres facteurs. Ce module utilise un algorithme de compartiment de jetons pour allouer des jetons à chaque client en fonction d’une politique de limitation de débit. Outre ngx_http_limit_req module, Nginx fournit également ngx_http_limit_conn module. Cela peut être utilisé pour limiter le nombre de connexions à partir de clients ou d’adresses IP spécifiques. Ce module utilise un algorithme de compartiment de jetons pour allouer des jetons en fonction des politiques de limitation de débit.

IIS (en anglais)

Services Internet (IIS) de Microsoft (IIS (en anglais)) comprend un module de limitation IP dynamique qui peuvent être utilisés pour limiter le débit. Ce module peut être configuré pour bloquer les demandes provenant d’adresses IP qui dépassent des seuils prédéfinis et peut également fournir des alertes et des journaux pour la surveillance. En plus du module Dynamic IP Limiting, IIS fournit également un module de filtrage des demandes qui peut être utilisé pour limiter le taux de demande de clients spécifiques en fonction de divers critères tels que l’adresse IP, Agent utilisateur, et méthode de demande.

Les États-Unis

Amazon Web Services (Les États-Unis) offre plusieurs services qui peuvent être utilisés pour limiter le débit, y compris AWS WAF avec limitation de débit en tant que fonctionnalité.

AWS Shield offre une protection DDoS, y compris des règles basées sur le taux qui peuvent bloquer les demandes provenant d’adresses IP au-delà d’un certain seuil. Ajout à AWS WAF et AWS Shield, AWS propose également AWS Elastic Load Balancer. Il inclut diverses stratégies de limitation de débit qui peuvent être configurées pour bloquer les clients au-delà de seuils prédéfinis.

Azur

Microsoft Azure propose plusieurs services qui peuvent être utilisés pour limiter le débit, y compris les passerelles d’application Azure. Il comprend un pare-feu d’application Web qui peut être configuré pour limiter le taux de demandes entrantes. De plus, Offres Azure Front Door une fonction de limitation de débit qui peuvent bloquer les requêtes provenant d’adresses IP supérieures à un seuil prédéfini. En plus d’Azure Application Gateway et d’Azure Front Door, Azure propose également le pare-feu Azure. Cela peut être utilisé pour limiter le débit et bloquer les clients dépassant un seuil défini.

Le

Plate-forme Google Cloud (Le) offres Cloud Armor, un pare-feu d’application Web avec des capacités de limitation de débit qui peuvent bloquer les demandes des clients qui dépassent un seuil défini.

Ces produits de limitation de débit de la couche applicative peuvent atténuer efficacement les attaques HTTP flood en limitant le nombre de requêtes provenant de clients non autorisés.. Toutefois, il est important qu’ils soient correctement configurés pour ne pas bloquer le trafic légitime et utilisés conjointement avec d’autres mesures de sécurité telles que des pare-feu et des services d’atténuation DDoS pour fournir une protection complète contre les attaques DDoS.

Délais d’expiration pour les demandes incomplètes

Vous trouverez ci-dessous quelques méthodes d’atténuation de la couche d’application Slowloris répertoriées pour Apache, Nginx, et serveurs Web IIS, et équilibreurs de charge et fonctionnalités supplémentaires pour AWS, Azur, et les services GCP:

Apache

En plus des modules mentionnés ci-dessus, Apache fournit également un module, mod_reqtimeout, qui peut être utilisé pour définir un délai d’expiration pour les demandes entrantes. Si le client envoie une demande qui prend plus de temps que le délai spécifié, Le serveur fermera la connexion. Cela empêchera les attaques de slowloris.

Nginx

Outre ngx_http_limit_conn module et module ngx_http_limit_req, Nginx fournit également son module ngx_http_request. Cela peut être utilisé pour limiter le temps nécessaire au serveur en amont pour traiter la demande. Si le serveur en amont prend plus de temps que le délai spécifié, Nginx fermera la connexion.

IIS (en anglais)

Ajout aux modules Restrictions IP dynamiques et Filtrage des demandes, IIS fournit également un pilote en mode noyau HTTP.sys. Cela vous permet de définir un délai d’expiration pour les demandes entrantes. Si le client envoie une demande qui prend plus de temps que le délai spécifié, Le serveur fermera la connexion.

Les États-Unis

En plus d’AWS WAF et AWS Shield, AWS offre en outre Elastic Load Balancer, qui incorpore de nombreuses règles de délai d’expiration de connexion qui peuvent être configurées pour fermer les connexions qui prennent plus de temps qu’un seuil prédéfini.

Azur

En plus d’Azure Application Gateway et d’Azure Front Door, Azure fournit également Azure Load Balancer, qui incorpore une caractéristique de délai d’inactivité configurable qui peut être utilisée pour fermer des connexions susceptibles d’être inactives pendant une période prédéfinie.

Le

Plate-forme Google Cloud (Le) offre de nombreuses alternatives de délai d’expiration de connexion pour ses services, qui incluent l’équilibrage de la charge dans le cloud, qui incorpore une caractéristique de délai d’expiration configurable qui peut être utilisée pour fermer les connexions qui prennent plus de temps qu’un seuil prédéfini.

Conclusion

En conclusion, Les attaques DDoS et DoS peuvent être classées en fonction des couches du modèle OSI qu’elles ciblent, tels que la couche réseau (Couche 3), couche de transport (Couche 4), et couche d’application (Couche 7).

Alors que la couche 3 et couche 4 Les attaques inondent le réseau et les couches de transport de trafic, couche 7 Les attaques sont plus complexes et exploitent les vulnérabilités des applications elles-mêmes. Les inondations HTTP et les attaques Slowloris sont des exemples de couche 7 Attaques par déni de service. Les contre-mesures contre ces attaques comprennent la limitation du débit, Liste noire, et pare-feu d’applications Web. L’identification et la maîtrise des attaques en temps réel nécessitent un, Stratégie de défense multicouche incluant la surveillance, détection, et capacités d’intervention.

De plus, Les attaquants peuvent personnaliser leurs techniques et adapter leurs attaques pour échapper à la détection et aux mesures de sécurité. Donc, Il est impératif que les organisations mettent en œuvre un, Stratégie de défense multicouche incluant la surveillance, détection, et des capacités de réponse pour identifier et contenir rapidement les attaques en temps réel. Cela peut inclure l’utilisation d’algorithmes avancés d’apprentissage automatique et d’analyses comportementales pour détecter et bloquer les modèles de trafic malveillants.