Comment fonctionnent les connexions TCP/IP
Le protocole de contrôle de transmission/protocole Internet (TCP/IP) est une technologie essentielle pour les réseaux informatiques modernes. C’est la façon dont (une grande majorité du temps) votre ordinateur demande et reçoit souvent des informations à travers un réseau et l’Internet. Il est doté d’un système de contrôle des erreurs, de la retransmission des données manquantes/corrompues et de plusieurs autres fonctions importantes qui rendent littéralement l’Internet tel que nous le connaissons fiable et fonctionnel. Cependant, pour comprendre comment il est utilisé de manière abusive, nous devons d’abord comprendre son fonctionnement.
Pour des raisons de brièveté, nous n’allons pas entrer dans le processus complet de connexion TCP/IP. Nous nous concentrerons uniquement sur le processus initial de poignée de main tripartite TCP, car c’est tout ce qui est pertinent pour le sujet de cet écrit.
Les hôtes d’un réseau qui veulent échanger des données à l’aide de TCP doivent d’abord négocier une connexion. C’est là que la poignée de main tridimensionnelle TCP entre en jeu. Le processus de poignée de main permet aux deux hôtes de reconnaître l’envoi et la réception réussis de communications réseau, ainsi que de configurer leur session respective en prévision de l’échange de données d’application.
Fig. 1) Handshake TCP à trois voies
Dans la figure 1, nous voyons un client qui établit une connexion TCP avec un serveur. La première étape consiste pour le Client à envoyer un paquet de synchronisation ou SYN. Ce paquet a deux rôles principaux, le premier est de tester la capacité à atteindre la ressource distante. Si ce paquet est acheminé avec succès, il indique également au serveur qu’un client distant souhaite entamer le processus de négociation de la connexion pour l’échange de données. Le serveur répond en émettant un paquet de synchronisation et d’accusé de réception, ou SYN-ACK, dirigé vers le client qui initie la connexion. La dernière partie de la poignée de main à trois voies consiste pour le client à répondre au SYN-ACK par un paquet d’accusé de réception final, ou ACK. Une fois cette poignée de main terminée, la connexion est prête à être utilisée par l’application pour la transmission bidirectionnelle de données.
La méthode la plus courante pour transporter les communications TCP est le protocole Internet ou IP. Cela signifie que les paquets TCP sont communiqués entre le client et le serveur à l’aide de datagrammes IP, adressés à l’aide d’adresses IP pour chacun des appareils.
Comment fonctionne cette attaque
Les attaquants militarisent ce processus de poignée de main en usurpant les adresses IP sources des paquets SYN. Cette usurpation amène le serveur à envoyer le paquet SYN-ACK à l’IP victime, qui, selon le serveur, a demandé l’initialisation de la session, en agissant comme un réflecteur.
Fig. 2) Réflexion SYN-ACK
Dans la figure 2, vous pouvez voir une visualisation très simple de cette attaque. Cependant, cela ne montre pas à quoi ressemble un véritable scénario d’attaque. La réalité est que TCP a été conçu pour fonctionner sur des réseaux non fiables, ce qui signifie qu’un seul SYN usurpé peut déclencher l’envoi par un serveur de plusieurs SYN-ACK en succession rapide s’il ne reçoit pas l’ACK final de la poignée de main. Le nombre de SYN-ACK à envoyer et la vitesse à laquelle les envoyer est une métrique configurable, il est donc difficile d’estimer exactement combien de SYN-ACK une victime ciblée peut recevoir par rapport au volume de paquets SYN usurpés qui ont été envoyés par les attaquants.
La faible bande passante contre le haut PPS
Les attaques SYN-ACK ne sont pas vos attaques par réflexion typiques. L’un des principaux attraits des attaques par réflexion basées sur UDP est leur facteur d’amplification, ou la taille du paquet qui arrive à la victime par rapport à la taille du paquet qu’un attaquant doit envoyer. Dans de nombreux cas, le facteur d’amplification est plusieurs fois supérieur à celui de la demande initiale. Dans le cas de la réflexion CLDAP, par exemple, le paquet résultant est environ 50-70x plus grand que le paquet que l’attaquant doit envoyer pour déclencher la réflexion. Les attaques par amplification sont souvent considérées comme volumétriques, avec pour objectif typique de saturer les liens réseau utilisés par les serveurs et les applications ciblés.
Dans le cas des réflexions SYN-ACK, la taille du paquet délivré à la victime est presque de la même taille que le paquet envoyé par l’attaquant. Nous disons « presque la même taille » car il est possible, et très probable, que pendant que l’attaquant envoie un paquet SYN de longueur minimale, certains routeurs sur le réseau entre l’attaquant et la victime peuvent également modifier le paquet TCP pour ajouter des informations de liaison supplémentaires, comme l’option TCP Maximum Segment Size (MSS), augmentant la taille absolue du trafic observé par la victime. Cette option représente 4 octets supplémentaires par paquet par rapport à ce que l’attaquant a envoyé.
20:56:32.296905 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xfa7c (correct), seq 1000, win 8192, urg 0, length 0
20:56:32.315637 IP (tos 0x0, ttl 124, id 4894, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6e18 (correct), seq 3609252029, ack 1001, win 60720,
options , length 0
Fig. 3) Amplification de 4 octets de SYN-ACK
Cela ne signifie pas que cette attaque ne constitue pas une menace. Au cours de plusieurs attaques coordonnées contre des clients d’Akamai, de multiples cas d’inondations de paquets par seconde (PPS) élevés utilisant du trafic SYN-ACK réfléchi ont été observés. Si le trafic à faible bande passante est moins susceptible de saturer les liens, le PPS élevé peut poser des problèmes aux équipements de mise en réseau qui tentent de traiter et de router le déluge de SYN-ACKS qui se précipite sur les réseaux.
Ce qu’un attaquant peut et ne peut pas contrôler
Les attaquants SYN-ACK dépendent des configurations TCP de leurs réflecteurs et de la façon dont ils gèrent leurs connexions TCP. Cela signifie que les attaquants sont limités dans ce qu’ils peuvent refléter à la victime. Les chercheurs d’Akamai ont passé du temps à effectuer des tests contre plusieurs services activés par TCP exposés sur des machines à travers Internet pour voir quelle combinaison de drapeaux TCP & options pourrait donner lieu aux scénarios d’attaque les plus impactants. Nous allons couvrir quelques scénarios d’attaque, comment ils diffèrent et comment les attaquants pourraient tirer parti des attaques SYN-ACK à l’avenir.
Options TCP et SYN-ACKS rembourrés
Les attaquants ne peuvent pas contrôler le contenu d’un paquet SYN-ACK. Bien que nous ayons vu des inondations SYN rembourrées depuis des années, l’idée d’un SYN-ACK rembourré n’est pas quelque chose à laquelle nous nous attendons. Dans le monde réel, lorsque des attaques SYN-ACK ont été lancées, les paquets qui arrivaient sur les réseaux des victimes avaient une longueur prévisible de 44 octets. Comme nous l’avons vu précédemment, cela nous indique que les attaquants envoyaient très probablement des paquets SYN de 40 octets sans option, les options MSS étant très probablement définies par le matériel réseau en transit. Il en résulte un faible facteur d’amplification, mais nous voulions tester la taille des SYN-ACKs que nous pouvions obtenir de serveurs réels.
Les tests ont été effectués en utilisant différentes variations des options TCP. L’objectif des tests était de pouvoir identifier les options qui pouvaient être utilisées de manière fiable et donner lieu à une réponse SYN-ACK plus importante de la part de serveurs choisis au hasard sur Internet. Les options qui pourraient être utilisées par un attaquant entraînant des SYN-ACK plus importants sont la taille maximale du segment (MSS), l’horodatage (TS) , l’ACK sélectif (SAckOK), l’échelle de la fenêtre (WScale), & les cookies TCP Fast Open (TFO).
Simplement en utilisant des options valides, un attaquant pouvait consommer environ 62 % de bande passante en plus qu’avec un paquet SYN minimal (72 octets contre 44 octets). En utilisant ces options, les en-têtes diminuent le ratio d’amplification (une amplification de 10 % devient 6-7 %) ; cependant, il est toujours possible d’obtenir une amplification en omettant simplement l’option MSS, car elle sera définie en transit, que l’attaquant l’envoie ou non.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options
, length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win
60192, options , length 0
Fig. 4) Remplissage SYN-ACK avec TFO
Lors des tests, il a été possible d’exploiter le TS, SAckOK, WSCale, & options TFO TCP (et le remplissage NOP) pour émettre un paquet SYN de 68 octets qui a donné lieu à une réponse SYN-ACK de 72 octets qui a été délivrée à la victime, comme on peut le voir sur la figure 4. Si un hôte ne supporte pas TFO, un attaquant peut toujours pousser un paquet SYN de 56 octets qui résulte en un SYN-ACK de 60 octets acheminé vers le réseau de la victime, comme vu ci-dessous dans la figure 5.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options
, length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192,
options , length 0
Fig. 5) Remplissage SYN-ACK moins TFO
Amplification SYN-ACK
Une infime quantité d’amplification est possible en utilisant les attaques SYN-ACK, mais il est possible d’augmenter ce facteur d’amplification en ciblant un espace IP alloué mais inoccupé (ce qui signifie que l’IP est routable mais qu’aucune machine n’est actuellement déployée et/ou gère le trafic réseau). Ce scénario permet aux attaquants de tirer pleinement parti des efforts de retransmission TCP, ce qui augmente les facteurs d’amplification et la consommation de bande passante.
Lorsqu’une machine normale reçoit un SYN-ACK hors état d’un réflecteur, elle répondra par un paquet RST, comme indiqué ci-dessous dans la figure 6. Ce paquet RST sera reçu par le réflecteur, et la session TCP sur le réflecteur sera tuée.
21:33:15.173204 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xfa7b (correct), seq 1000, win 8192, urg 0, length 0
21:33:15.191517 IP (tos 0x0, ttl 124, id 46635, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xb751 (correct), seq 1209013908, ack 1001, win
60720, options , length 0
21:33:15.191558 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 6) un SYN-ACK hors d’état déclenche une réponse RST
Si ce paquet SYN-ACK est destiné à une adresse IP allouée mais inoccupée, le SYN-ACK sera routé (impactant le matériel réseau en cours de route) mais n’atteindra jamais une machine réelle qui émettrait un RST. Cette absence de paquet RST amènera le réflecteur à supposer que la livraison du SYN-ACK a échoué et à commencer des tentatives de retransmission.
Dans les tests, le nombre de tentatives de retransmission est généralement compris entre 5 et 7 paquets SYN-ACK envoyés à la victime pour chaque SYN envoyé. Si nous supposons qu’un attaquant envoie un SYN de 40 octets, nous pouvons nous attendre à ce que 5 à 7 SYN-ACK de 44 octets traversent le réseau des victimes. Dans le pire des cas, avec 7 paquets reçus, cela signifie qu’une requête de 40 octets génère 308 octets de paquets arrivant aux frontières de la victime, soit un facteur d’amplification de 770 %. En utilisant les en-têtes d’options TCP pour générer des SYN-ACK plus importants, un attaquant pourrait pousser ces chiffres à 56 octets, ce qui entraîne 420 octets de trafic réfléchi, un facteur d’amplification de 750%.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options , length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:24.965713 IP (tos 0x0, ttl 124, id 46784, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfd96 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:26.965689 IP (tos 0x0, ttl 124, id 47738, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf5c6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:30.965750 IP (tos 0x0, ttl 124, id 49898, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xe626 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:38.965701 IP (tos 0x0, ttl 124, id 53757, offset 0, flags , proto TCP (6), length 60)
.
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xc6e6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:54.965710 IP (tos 0x0, ttl 124, id 61887, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x8866 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
Fig. 7) SYN entraîne 6 SYN-ACKS
TFO, padding et amplification
TTCP Fast Open (TFO) est abordé plus en détail ici pour couvrir certains cas limites intéressants observés lors des tests. En utilisant les cookies TFO, il est possible de déclencher des réponses plus importantes (12 octets supplémentaires par SYN-ACK) ; cependant, en raison d’oublis dans l’implémentation de TFO, ces mesures peuvent modifier les facteurs d’amplification et, dans différents scénarios, les attaques activées par TFO peuvent être plus souhaitables.
Les attaquants qui tentent d’exploiter les réflecteurs activés par TFO peuvent trouver cela fructueux uniquement dans certaines circonstances. Ces circonstances seraient des cas où il n’y a pas d’espace IP qui n’est pas géré par une machine vivante, si un attaquant doit diriger les paquets SYN-ACK réfléchis vers des machines réelles qui répondront avec des paquets RST, l’amplification de retransmission TCP est essentiellement discutable car le réflecteur cessera d’envoyer des SYN-ACK à la réception de la réponse RST des machines de la victime.
Pour rendre cette proposition encore moins souhaitable, les hôtes activés par TFO n’incluront pas l’option d’en-tête de 12 octets pour le cookie TFO dans les paquets SYN-ACK supplémentaires au-delà du premier paquet émis. En bref, cela signifie que l’amplification dans ce scénario n’est pas une série de paquets de 72 octets frappant la victime. Lors de tests en conditions réelles, il a été observé que le premier SYN-ACK est de 72 octets, mais que les 5-6 tentatives de retransmission suivantes omettent cette option TCP et donnent un paquet de 60 octets. Dans ce cas, un paquet de 72 octets résulte en une réflexion de 432 octets ; essentiellement, le seul avantage est les 12 octets supplémentaires du tout premier paquet par rapport à une réflexion moins l’option de cookie TFO.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options , length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:46.651887 IP (tos 0x0, ttl 124, id 51447, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6bb0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:48.651862 IP (tos 0x0, ttl 124, id 52323, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x63e0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:52.651854 IP (tos 0x0, ttl 124, id 54181, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x5440 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:00.651876 IP (tos 0x0, ttl 124, id 58527, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x3500 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:16.651862 IP (tos 0x0, ttl 124, id 2147, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf67f (correct), seq 3436032873, ack 1001, win 60192, options , length 0
Fig. 8) Omission du cookie TFO après la première réponse
Les hôtes compatibles TFO réinitialisent leurs mesures de cookies de poignée de main à la réception d’un RST de la ou des machines victimes visées. Ce que cela signifie, c’est qu’un attaquant ciblant des machines réelles utilisant des réflecteurs activés par TFO pourrait, de manière fiable, provoquer l’arrivée d’une série de paquets SYN-ACK de 72 octets aux points d’extrémité des victimes.
Le facteur d’amplification est de seulement 4 octets, en supposant qu’une demande de 68 octets de l’attaquant entraîne l’arrivée d’un SYN-ACK de 72 octets à la victime, suivi d’un paquet RST de la victime au réflecteur. Si cela se produit continuellement, alors les sessions TCP initiées sur le réflecteur via l’attaquant aboutiront toujours à un paquet SYN-ACK qui inclut les octets supplémentaires qui constituent l’option du cookie TFO.
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x8762 (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:41.629518 IP (tos 0x0, ttl 124, id 14354, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6ade (correct), seq 3714341928, ack 1001, win 60192, options , length 0
20:54:41.629548 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:42.664171 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xc1bd (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:42.682391 IP (tos 0x0, ttl 124, id 15171, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6d0a (correct), seq 3730789605, ack 1001, win 60192, options , length 0
20:54:42.682440 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:43.781512 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x7dde (correct), seq 1000, win 8192, urg 0, options , length 0
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x7dde (correct), seq 1000, win 8192, urg 0, options , length 0.
20:54:43.800464 IP (tos 0x0, ttl 124, id 15726, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xf5fe (correct), seq 3748251272, ack 1001, win 60192, options , length 0
20:54:43.800534 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 9) Inclusion du cookie TFO après RST
Préoccupations d’atténuation
L’atténuation d’une réflexion SYN-ACK peut être délicate et doit être faite avec soin. Il est très facile de sur-atténuer ce type d’attaque et de causer des dommages auto-infligés aux clients réels et aux sessions TCP à travers les réseaux de production. Ces sessions affectées se traduisent par des problèmes de connectivité, une dégradation des performances et le blocage d’hôtes/utilisateurs légitimes sur vos réseaux. Ces mesures de sur-atténuation peuvent avoir des effets plus longs et plus impactants que l’attaque elle-même.
Dans de nombreux cas, la sur-atténuation des attaques ayant un impact TCP peut également avoir des résultats inattendus pour les victimes. Pendant les SYN floods, par exemple, il est courant que, lorsque les services réels commencent à avoir des problèmes de connectivité, une vague d’attaque secondaire semble gonfler sur le réseau. Dans de tels cas, la » deuxième vague » est tout sauf cela et résulte généralement de clients/utilisateurs réels qui tentent d’établir des connexions légitimes sans succès ; cela se traduit par une houle de paquets SYN supérieure à la normale, car ces clients impactés continuent de tenter de retransmettre les paquets SYN non acquittés.
La sur-atténuation d’une attaque SYN-ACK pourrait probablement causer des problèmes et des résultats similaires, surtout si l’atténuation se produit à un point du réseau où les vrais clients font des demandes sortantes légitimes.
Le VRAI correctif pour les attaques par réflexion
Comme pour la plupart des attaques par usurpation, le vrai correctif n’est pas quelque chose sous le contrôle d’une seule organisation. Pour vraiment s’attaquer à ce problème et aux autres problèmes associés aux capacités de spoofing, nous devons nous tourner vers l’IETF et les opérateurs de réseau. L’IETF a publié le document BCP38, qui explique comment les opérateurs de réseau peuvent identifier et empêcher l’acheminement du trafic d’usurpation. En fin de compte, c’est quelque chose que les opérateurs réseau doivent mettre en œuvre et appliquer si nous espérons vraiment un jour voir ces types d’attaques usurpées/réfléchies disparaître, ou du moins devenir nettement plus difficiles à orchestrer.
Résumé de la conclusion
Les attaques SYN-ACK réfléchies ne sont pas quelque chose de nouveau ; elles sont en fait quelque chose d’aussi vieux que TCP lui-même. Leur manque de popularité a plus à voir avec les autres attaques réfléchies basées sur UDP qui sont bien plus inquiétantes et impactantes et qui constituent généralement un meilleur ensemble d’outils pour les attaquants. Ils ne sont pas un effet secondaire d’une mise en œuvre défectueuse, ils ne sont pas un exploit, ils sont un symptôme de l’usurpation d’IP sur Internet toujours possible près de 20 ans après que la solution proposée aux propriétaires et aux opérateurs de réseaux a été rédigée et finalisée.
Cela dit, les anciennes attaques peuvent toujours être douloureuses, et les SYN-ACK réfléchis ne font pas exception. Les organisations devraient envisager d’examiner leurs capacités et options d’atténuation, car le matériel de réseau peut avoir du mal à gérer les inondations de trafic à PPS élevé à travers les frontières et les réseaux.
Il est important de souligner la possibilité réelle de sur-atténuation pour les attaques de cette nature et de veiller à ce que les tentatives de lutte contre ces types d’attaques ne se traduisent pas par des pannes auto-imposées… une tâche beaucoup plus facile à dire qu’à faire.