

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Attaques contre la couche d'infrastructure
<a name="infrastructure-layer-attacks"></a>

 Les attaques les plus courantes, à savoir DDoS les attaques par réflexion du protocole User Datagram (UDP) et SYN les inondations, concernent la *couche d'infrastructure*. Un attaquant peut utiliser l'une ou l'autre de ces méthodes pour générer de gros volumes de trafic susceptibles d'inonder la capacité d'un réseau ou d'immobiliser des ressources sur des systèmes tels que des serveurs, des pare-feux, un système de prévention des intrusions (IPS) ou un équilibreur de charge. Bien que ces attaques puissent être faciles à identifier, pour les atténuer efficacement, vous devez disposer d'un réseau ou de systèmes capables d'augmenter la capacité plus rapidement que le flot de trafic entrant. Cette capacité supplémentaire est nécessaire pour filtrer ou absorber le trafic d'attaque, libérant ainsi le système et l'application pour répondre au trafic légitime des clients. 

# UDPattaques par réflexion
<a name="udp-reflection-attacks"></a>

 UDPles attaques par réflexion exploitent le fait qu'il UDP s'agit d'un protocole sans état. Les attaquants peuvent créer un paquet de UDP requête valide répertoriant l'adresse IP de la cible de l'attaque comme adresse IP UDP source. L'attaquant a désormais falsifié (usurpé) l'adresse IP source du paquet de requêtes. UDP Le UDP paquet contient l'adresse IP source falsifiée et est envoyé par l'attaquant à un serveur intermédiaire. Le serveur est incité à envoyer ses paquets de UDP réponse à l'adresse IP de la victime ciblée plutôt qu'à l'adresse IP de l'attaquant. Le serveur intermédiaire est utilisé car il génère une réponse plusieurs fois supérieure au paquet de demande, amplifiant ainsi efficacement le volume de trafic d'attaque envoyé à l'adresse IP cible. 

 Le facteur d'amplification est le rapport entre la taille de la réponse et la taille de la demande, et il varie en fonction du protocole utilisé par l'attaquant : DNS Network Time Protocol (NTP), Simple Service Directory Protocol (SSDP), Connectionless Lightweight Directory Access Protocol (CLDAP), [Memcached](https://memcached.org/), Character Generator Protocol (CharGen) ou Quote of the Day (). QOTD 

 Par exemple, le facteur d'amplification pour DNS peut être de 28 à 54 fois le nombre d'octets d'origine. Ainsi, si un attaquant envoie une charge utile de requête de 64 octets à un DNS serveur, il peut générer plus de 3 400 octets de trafic indésirable vers une cible d'attaque. UDPles attaques par réflexion sont responsables d'un volume de trafic plus important que les autres attaques. La figure suivante illustre la tactique de réflexion et l'effet d'amplification. 

![\[Schéma illustrant une attaque par UDP réflexion\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-best-practices-ddos-resiliency/images/udp-reflection-attack.png)


 Il convient de noter que les attaques par réflexion, bien qu'elles fournissent aux attaquants une amplification « gratuite », nécessitent une fonction d'usurpation d'adresse IP et, à mesure que de plus en plus de fournisseurs de réseaux adoptent la validation des adresses source partout (SAVE) ou que cette fonctionnalité est supprimée [BCP38](https://www.ietf.org/rfc/bcp/bcp38.html), obligeant les fournisseurs de DDoS services à mettre fin aux attaques par réflexion ou à se relocaliser vers des centres de données et des fournisseurs de réseaux qui ne mettent pas en œuvre la validation de l'adresse source. 

# SYNattaques liées aux inondations
<a name="syn-flood-attacks"></a>

 Lorsqu'un utilisateur se connecte à un service Transmission Control Protocol (TCP), tel qu'un serveur Web, son client envoie un SYN paquet. Le serveur renvoie un paquet d'accusé de réception de synchronisation (SYN-ACK), et finalement le client répond par un paquet d'accusé de réception (ACK), qui complète la triple poignée de main attendue. L'image suivante illustre cette poignée de main typique. 

![\[Schéma illustrant une poignée de SYN main à trois\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-best-practices-ddos-resiliency/images/syn-three-way-handshake.png)


 Lors d'une attaque par SYN inondation, un client malveillant envoie un grand nombre de SYN paquets, mais n'envoie jamais les derniers ACK paquets pour terminer les poignées de main. Le serveur est laissé dans l'attente d'une réponse aux TCP connexions semi-ouvertes et l'idée est que la cible finira par manquer de capacité pour accepter de nouvelles TCP connexions, ce qui empêche les nouveaux utilisateurs de se connecter au serveur, mais l'impact réel est plus nuancé. Les systèmes d'exploitation modernes implémentent tous SYN des cookies par défaut comme mécanisme pour empêcher l'épuisement des tables d'états suite à des attaques par SYN inondation. Une fois que la longueur de la SYN file d'attente atteint un seuil prédéterminé, le serveur répond par un SYN - ACK contenant un numéro de séquence initial contrefait, sans créer d'entrée dans sa SYN file d'attente. Si le serveur reçoit ensuite un accusé de réception ACK contenant un numéro d'accusé de réception correctement incrémenté, il est en mesure d'ajouter l'entrée à sa table d'état et de procéder normalement. L'impact réel des SYN inondations sur les équipements cibles est généralement lié à la capacité et à CPU l'épuisement du réseau, mais les périphériques intermédiaires tels que les pare-feux (ou le [suivi des connexions](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) des groupes de EC2 sécurité) peuvent être épuisés dans la table des TCP états et interrompre les nouvelles connexions. 

# TCPréflexion de la boîte intermédiaire
<a name="tcp-middlebox-reflection"></a>

 Ce vecteur d'attaque relativement nouveau a été révélé pour la première fois dans un [livre blanc universitaire](https://www.usenix.org/system/files/sec21fall-bock.pdf) en août 2021, qui expliquait comment le TCP non-respect des pare-feux des États et du commerce pouvait amener ces derniers à devenir des vecteurs d'amplification. TCP Nous avons été témoins de ces attaques « dans la nature » depuis le début de 2022 et nous continuons d'en être témoins aujourd'hui. Le facteur d'amplification varie en fonction des différentes manières dont les fournisseurs ont implémenté cette « fonctionnalité », mais il peut dépasser l'amplification MemcachedUDP. 