haproxy ddos attack protection

Les capacités de sécurité à haute performance de HAProxy sont utilisées comme une ligne de défense clé par de nombreuses entreprises les plus importantes du monde. Les attaques DDoS au niveau des applications visent à submerger une application de requêtes ou de connexions. Dans ce article, nous allons vous montrer comment un répartiteur de charge HAProxy peut vous protéger contre cette menace.

Ce post décrit des techniques qui utilisent les ACL, les tables de correspondance et les tables de persistance. Consultez les articles suivants pour une introduction à ces sujets :

De nos jours, mettez en ligne n’importe quel site Web ou application et vous êtes assuré d’être la cible d’une grande variété de sondes et d’attaques. Votre site Web est un vaisseau qui doit constamment affronter la tempête de diverses menaces, notamment les attaques par déni de service distribué (DDoS), les bots malveillants et les tentatives d’intrusion. Au fil des années, HAProxy a évolué pour naviguer ces eaux périlleuses grâce au développement de modules flexibles pouvant être combinés pour atténuer presque tout type de menace. Ces modules comprennent des listes de contrôle d’accès et des tables de correspondance de haute performance, un suivi en temps réel avec des tables de persistance, un ensemble SSL/TLS performant, un WAF et bien plus encore. Même avec toutes ces capacités supplémentaires, HAProxy conserve les meilleures performances de sa catégorie pour lesquelles il est connu.

L’éventail des entreprises bénéficiant des capacités de sécurité avancées de HAProxy comprend des petites firmes familiales jusqu’au grandes entreprises, en passant par les sociétés d’hébergement gérées et les plateformes de répartition de charge en tant que service servant des millions de requêtes par seconde. Parmi les sites Web les plus importants, citons GitHub, qui utilise HAProxy pour protéger son réseau contre les attaques DDoS au niveau des applications, et StackExchange, qui l’utilise pour détecter et protéger contre les menaces des robots. En outre, Booking.com a choisi HAProxy comme composant central de son infrastructure de périphérie pour ses performances supérieures après l’avoir comparé à d’autres logiciels de répartiteur de charge sur le marché.

Dans cet article, nous allons démontrer comment le répartiteur de charge HAProxy vous protège contre les attaques DDoS au niveau de la couche applicative qui pourraient rendre votre application Web inerte et inaccessible aux utilisateurs ordinaires. Nous aborderons en particulier les inondations HTTP. Une inondation HTTP opère au niveau de la couche applicative et implique une submersion de requêtes Web pour dépasser la capacité de réponse de votre application.

Inondation HTTP

Le danger des attaques par inondation HTTP est qu’elles peuvent être exécutées par n’importe qui. Il n’est pas nécessaire de disposer d’un grand réseau de robots et les outils permettant d’orchestrer l’attaque sont nombreux. Cette accessibilité rend particulièrement importante la mise en place de défenses pour repousser ces attaques.

Ces attaques peuvent se présenter sous différentes formes, mais le schéma le plus courant consiste à ce que les attaquants demandent une ou plusieurs URL de votre site Web avec la fréquence la plus élevée possible. L’approche la plus simple consiste à demander des URL au hasard, tandis que les attaquants plus sophistiqués commenceront par établir le profil de votre site, à la recherche de ressources lentes et non mises en cache qui sont plus vulnérables. Par exemple, ils peuvent cibler les pages de recherche.

Afin d’échapper plus longtemps à la détection, l’attaque peut comporter de nombreuses adresses IP sources différentes. Elle peut être menée par des bots ou par des groupes d’utilisateurs réels travaillant à l’unisson pour faire tomber votre site. C’est ce qui s’est passé avec les attaques Low Orbit Ion Cannon (LOIC) et High Orbit Ion Cannon (HOIC) menées par le collectif d’hacktivistes Anonymous. L’éventail apparemment très large d’adresses IP sources est ce qui caractérise la nature distribuée de l’attaque.

HAProxy est doté de fonctions d’atténuation des inondations HTTP et jouera un rôle essentiel dans votre stratégie de défense globale. Dans cet article, nous utiliserons HAProxy Enterprise en raison de ses fonctions de sécurité supplémentaires, dont nous parlerons plus loin. Cependant, la plupart des solutions que vous verrez fonctionnent également pour l’édition Community avec des ajustements minimes des noms et des chemins.

Surveillance en périphérie

L’endroit idéal pour arrêter une inondation HTTP se trouve à la périphérie de votre réseau. L’arrêt des menaces à cet endroit protège vos applications web en amont en minimisant le trafic et la charge système qui pourraient les affecter, ainsi que les autres sites et services fonctionnant sur ces serveurs. Cela évite également toute confusion inutile lors de l’identification de l’attaque en traçant une ligne de défense claire.

haproxy ddos attack protection

Vous pouvez classer les demandes malveillantes en surveillant la vitesse à laquelle un utilisateur effectue des requêtes ou en signalant les requêtes HTTP présentant des signatures anormales.

Le répartiteur de charge HAProxy reçoit les requêtes provenant d’Internet et les transmet à vos serveurs Web. Vous pouvez ainsi surveiller le périmètre.

Les autres périphériques réseau qui se trouvent entre HAProxy et Internet, notamment les routeurs et les pare-feu, fonctionnent généralement à un niveau trop bas pour permettre l’inspection des requêtes.

LE SAVIEZ-VOUS ? ALOHA, l’appliance plug-and-play HAProxy, peut vous protéger contre les attaques de bas niveau basées sur le protocole, telles que les inondations SYN, au débit de ligne avec notre solution d’atténuation appelée PacketShield. PacketShield est alimenté par NDIV, un cadre de traitement du trafic réseau open-source sur lequel nous travaillons depuis 2013. Nous avons depuis travaillé en étroite collaboration avec l’équipe XDP pour apporter certaines fonctionnalités de NDIV à XDP et faire en sorte que NDIV fonctionne au-dessus de XDP.

Avec HAProxy, vous disposez de deux méthodes très efficaces pour classer les requêtes malveillantes. La première consiste à surveiller la vitesse à laquelle un utilisateur effectue des requêtes. La seconde consiste à signaler les requêtes HTTP dont la signature ne correspond pas à celle d’un utilisateur ordinaire.

Pour obtenir les meilleurs résultats, vous devriez combiner les deux méthodes. La définition de limites de taux de requête vous permet de bloquer les clients qui accèdent trop fréquemment aux ressources de votre site Web, tandis que le refus des requêtes contenant des données anormales réduit le champ des attaquants potentiels.

Définition des limites de taux de requêtes

Le suivi des activités des utilisateurs au fil des requêtes nécessite un stockage de données en mémoire permettant d’identifier les clients qui reviennent et de corréler leurs actions. Il s’agit là d’un élément essentiel pour fixer des seuils de limitation du débit, c’est-à-dire pour savoir combien de requête une personne effectue. HAProxy vous permet de le faire grâce à un stockage de données extrêmement flexible et performant appelé les tables de persistance ou « stick tables », une fonctionnalité unique à HAProxy.

Les tables de persistance fournissent un stockage clé-valeur générique et peuvent suivre divers compteurs associés à chaque client. La clé peut être basée sur tout ce qui se trouve dans la requête. En règle générale, il s’agit de l’adresse IP de l’utilisateur, mais il peut s’agir aussi de quelque chose de plus spécifique comme IP + UserAgent. Les valeurs couramment suivies sont le nombre de requête et le taux de requête sur une période donnée.

Les tables de persistance ont été développées en collaboration avec StackExchange, le réseau de communautés de questions-réponses qui comprend Stack Overflow, qui a initialement contacté HAProxy en 2010 pour mettre en œuvre une limitation de débit basée sur les modèles de trafic. Les tables de persistance sont une technologie extrêmement mature et éprouvée au sein d’HAProxy, qui permet de mettre en œuvre un grand nombre de ses fonctionnalités avancées. Vous pouvez en savoir plus en lisant notre article de blog Introduction aux tables de persistance HAProxy.

Définir le stockage

Créez une table de persistance en ajoutant une directive stick-table à un backend ou un frontend. Dans l’exemple suivant, nous utilisons un backend de type espace réservé nommé per_ip_rates. Le fait de dédier un backend à la définition d’une stick-table vous permet de la référencer à plusieurs endroits dans votre configuration.

Prenons l’exemple suivant :

Ceci configure le stockage qui gardera la trace de vos clients par leurs adresses IP. Elle initialise un compteur qui suit le taux de requête de chaque utilisateur. Commencez à suivre un client en ajoutant une directive http-request track-sc0 à une section frontend, comme indiqué :

Avec cette configuration en place, tous les clients qui visitent votre site web par HAProxy via le frontend fe_mywebsite seront stockés dans la table de persistance per_ip_rates. Tous les compteurs spécifiés dans la définition de la table de persistance seront automatiquement maintenus et mis à jour par HAProxy.

Voyons ensuite comment utiliser ces données à bon escient.

Imaginons que vous souhaitiez bloquer tout client effectuant plus de 10 requêtes par seconde. Le compteur http_req_rate(10s) que vous avez ajouté indiquera le nombre de requêtes sur 10 secondes. Donc, pour plafonner les requêtes à 10 par seconde, définissez la limite à 100.

Dans l’exemple suivant, nous ajoutons la directive http-request deny pour rejeter les clients qui ont dépassé le seuil :

Cette règle demande à HAProxy de refuser toutes les requêtes provenant d’adresses IP dont les compteurs de la table de persistance indiquent un taux de requêtes supérieur à 10 par seconde. Lorsqu’une adresse IP dépasse cette limite, elle reçoit une réponse HTTP 429 Too Many Requests et la demande n’est transmise à aucun serveur backend HAProxy.

Ces requêtes seront faciles à repérer dans le journal des accès HAProxy, car elles auront un état de terminaison PR–, ce qui signifie que la session a été interrompue en raison de l’application d’une limite de connexion :

Si vous souhaitez définir des seuils de limite de débit par URI, vous pouvez le faire en ajoutant une table de correspondance qui associe chaque limite de débit à un chemin URL. Consultez notre article de blog Introduction aux table de correspondance HAProxy pour voir un exemple.

Vous souhaitez peut-être limiter le taux des requêtes POST uniquement ? Il suffit d’ajouter une déclaration qui vérifie la liste de contrôle d’accès intégrée, METH_POST.

Vous pouvez également ralentir les abuseurs afin que leurs requêtes soient rejetées avec un code d’état HTTP 500 avec un délai configurable. La durée du délai est définie par la directive timeout tarpit. Ici, vous retardez toute réponse pendant cinq secondes :

Lorsque le délai d’attente expire, la réponse que le client reçoit après avoir été ralenti est 500 Internal Server Error, ce qui augmente la probabilité qu’il pense que son attaque a réussi.

Les attaques de Slowloris

Avant d’aborder notre deuxième point sur la détection des DDoS, à savoir l’identification de schémas étranges parmi les utilisateurs, examinons rapidement un autre type d’attaque au niveau de la couche applicative : Slowloris.

Slowloris implique un attaquant qui effectue des requêtes très lentement afin de saturer vos créneaux de connexion. Contrairement à d’autres types de DDoS, le volume de requêtes nécessaire pour réussir cette attaque est assez faible. Cependant, comme chaque requête n’envoie qu’un octet toutes les quelques secondes, elle peut bloquer de nombreux créneaux de requêtes pendant plusieurs minutes.

Un répartiteur de charge HAProxy peut maintenir un plus grand nombre de connexions ouvertes sans ralentir que la plupart des serveurs web. En tant que tel, la première étape pour se défendre contre les attaques Slowloris est de définir des valeurs maxconn. Tout d’abord, définissez un paramètre maxconn dans la section global qui laisse suffisamment de marge pour que votre serveur ne soit pas à court de mémoire même si toutes les connexions sont occupées, conformément au guide de dimensionnement. Ensuite, dans la section frontend ou defaults, définissez une valeur maxconn légèrement inférieure à celle-ci pour que si une attaque sature un frontend, les autres puissent toujours fonctionner.

Ensuite, ajoutez deux lignes à votre section defaults :

La première ligne fait en sorte que HAProxy réponde à tout client qui passe plus de cinq secondes entre le premier et le dernier octet de la requête par une erreur HTTP 408 Request Timeout. Normalement, cela ne s’applique qu’à la requête HTTP et à ses en-têtes et n’inclut pas le corps de la requête. Toutefois, avec l’option http-buffer-request, HAProxy stocke le corps de la requête dans un tampon et lui applique le délai d’attente http-request.

Blocage des requêtes par caractéristiques statiques

Vous avez vu comment bloquer les requêtes qui dépassent un nombre maximal de requêtes HTTP. L’autre moyen d’identifier et de stopper les comportements malveillants consiste à surveiller les messages qui correspondent à un modèle. Les modèles sont définis dans HAProxy à l’aide de listes de contrôle d’accès (ACL). Lisez notre article de blog Introduction aux ACLs HAProxy pour savoir comment les utiliser.

Voyons quelques ACL utiles pour arrêter les attaques DDoS.

Utilisation des ACL pour bloquer les requêtes

Un certain nombre d’attaques utilisent HTTP/1.0 comme version du protocole car c’est la version prise en charge par certains robots. Il est facile de bloquer ces requêtes à l’aide de la liste de contrôle d’accès intégrée, HTTP_1.0 :

Vous pouvez également rejeter les requêtes dont les en-têtes User-Agent ne sont pas celles d’un navigateur, par exemple curl.

Cette ligne refusera la requête si le -msub de l’en-tête de requête User-Agent contient la chaîne de caractères curl. Le -i rend la chaîne insensible à la casse. Vous pouvez également vérifier la présence d’autres chaînes telles que phantomjs et slimerjs, qui sont deux navigateurs sans tête pouvant être scriptés et qui pourraient être utilisés pour automatiser une attaque.

Si vous avez de nombreuses chaînes à vérifier, pensez à les enregistrer dans un fichier – à raison d’une chaîne par ligne – et à le référencer comme suit :

Parfois, un attaquant qui utilise un outil automatisé enverra des requêtes qui ne contiennent pas du tout d’en-tête User-Agent. Celles-ci peuvent également être refusées, comme dans l’exemple suivant :

Il est encore plus courant pour les attaquants de rendre aléatoires les chaînes User-Agent qu’ils envoient afin d’échapper plus longtemps à la détection. Souvent, ces chaînes proviennent d’une liste de valeurs authentiques qu’un véritable navigateur utiliserait et rendent plus difficile l’identification des utilisateurs malveillants.

C’est là que le module HAProxy Enterprise Fingerprint s’avère utile. Il identifie de manière unique les clients au fil des requêtes, même lorsqu’ils modifient leur chaîne User-Agent. Il fonctionne en triangulant de nombreux points de données sur un client pour former une signature qui lui est propre. Grâce à ces informations, vous pouvez ensuite identifier et bloquer dynamiquement les abuseurs.

Liste noire et liste grise

Une autre caractéristique que vous pouvez utiliser pour filtrer le trafic potentiellement dangereux est l’adresse IP source du client.

Que ce soit intentionnellement ou non, la Chine semble être à l’origine d’une grande partie du trafic DDoS. Vous pouvez décider de mettre sur liste noire toutes les IP provenant d’un pays particulier en recherchant les blocs d’IP qui lui sont attribués et en les refusant en masse.

Utilisez la méthode d’extraction src pour obtenir l’adresse IP source d’un client. Ensuite, comparez-la à un fichier contenant toutes les plages d’adresses IP que vous souhaitez bloquer.

Votre fichier blacklist.acl pourrait ressembler à ceci :

Pour rationaliser cela, vous pouvez utiliser une base de données GeoIP comme MaxMind ou Digital Element. Lisez notre article de blog, Utilisation d’une base de données GeoIP dans HAProxy, pour savoir comment la configurer. Vous pouvez également effectuer ces recherches directement dans HAProxy Enterprise à l’aide d’un module natif qui permet de mettre à jour les données en direct et ne nécessite pas de scripts supplémentaires pour les traduire en tables de correspondance. Les modules natifs consomment également moins de mémoire dans les cas où les recherches doivent être granulaires, par exemple, sur la base d’une ville.

Si vous ne souhaitez pas interdire des plages entières d’adresses IP, vous pouvez adopter une approche plus indulgente et vous contenter de les inscrire sur une liste grise. Le greylisting permet à ces clients d’accéder à votre site Web, mais leur impose des limites de débit plus strictes.

L’exemple suivant définit une limite de débit plus stricte pour les clients dont les adresses IP sont répertoriées dans greylist.acl :

Si vous utilisez deux ou plusieurs instances de HAProxy pour la redondance, assurez-vous que chacune d’entre elles dispose de la liste des adresses IP que vous avez mises sur liste noire et qu’elles sont mises à jour chaque fois que vous effectuez un changement. C’est ici que l’utilisation de HAProxy Enterprise vous donne un avantage. En utilisant un module appelé lb-update, vous pouvez héberger votre fichier ACL à une URL et faire en sorte que chaque instance HAProxy récupère les mises à jour à un intervalle défini.

Dans l’exemple suivant, nous utilisons lb-update pour vérifier les mises à jour toutes les 60 secondes :

Protection des services TCP (non-HTTP)

Jusqu’à présent, nous avons principalement couvert la protection des serveurs web. Cependant, HAProxy peut également protéger d’autres services basés sur TCP tels que SSH, SMTP et FTP. La première étape consiste à mettre en place une table de persistance pour suivre les conn_cur et conn_rate :

Ensuite, créez ou modifiez un frontend pour utiliser cette table en ajoutant des règles de track et de reject :

Avec le backend habituel :

Désormais, chaque client peut établir une seule connexion SMTP à la fois. S’il essaie d’en ouvrir une deuxième alors que la première est encore ouverte, la connexion sera immédiatement refermée.

Retardement des connexions

Avec la messagerie électronique et d’autres protocoles de type « server-speaks-first » (où le serveur envoie un message dès qu’un client se connecte au lieu d’attendre que le client dise quelque chose, comme avec HTTP), nous pouvons également retarder les connexions en ajoutant les éléments suivants après les règles que nous avons ajoutées pour bloquer :

Cela permet de connecter immédiatement tout client qui n’a effectué qu’une seule connexion au cours de la dernière minute. Un seuil inférieur à deux est utilisé pour que nous acceptions une connexion, mais vous pouvez facilement augmenter ce seuil. Les autres connexions de ce client seront maintenues dans les limbes pendant 10 secondes, à moins que le client n’envoie des données sur le second tuyau, ce que nous vérifions avec req_len. Dans ce cas, HAProxy fermera la connexion immédiatement sans solliciter le backend.

Ce type d’astuce est utile contre les robots de spam ou les robots de force brute SSH, qui attaquent directement sans attendre la bannière. Dans ce cas, ils sont refusés; sinon, ils doivent conserver la connexion en mémoire pendant encore 10 secondes. S’ils ouvrent plus de connexions pour contourner cette limite de débit, les limites conn_cur de la section précédente les arrêteront.

L’agrégateur de table de persistance

L’utilisation des répartiteurs de charge HAProxy actifs-actifs devant vos sites Web augmente votre redondance pour vous protéger au cas où un répartiteur de charge serait hors ligne. Elle fournit également une capacité supplémentaire lors de la résistance à une attaque DDoS basée sur une application. Vous pouvez apprendre comment la configurer en regardant notre webinaire à la demande, Création de clusters ADC hautement évolutifs à l’aide du routage multi-chemins à coût égal BGP.

Dans une configuration HAProxy communautaire standard, chaque instance individuelle de HAProxy ne voit que les requêtes qui lui parviennent. Elle ne voit pas les requêtes reçues par les autres instances du répartiteur de charge. Cela donne à un attaquant plus de temps pour rester sous le radar.

Si vous utilisez HAProxy Enterprise, l’activation du module Stick Table Aggregator (agrégateur des tables de persistance) résout ce problème. Il permet aux serveurs HAProxy d’agréger tous leurs taux de requêtes et leurs statistiques afin de prendre des décisions en fonction du cumul des données.

L’illustration ci-dessous montre l’utilisation de plusieurs répartiteurs de charge appairés pour partager des informations. Notez qu’en ajoutant des niveaux d’agrégateurs de table de persistance, vous pouvez collecter des données à partir de nombreuses instances de HAProxy. Contactez-nous pour savoir comment la configurer.

haproxy peering multiple load balancers

Partage d’informations sur l’activité des utilisateurs grâce à l’appairage de plusieurs répartiteurs de charge

Les modules reCAPTCHA et Antibot

HAProxy ne se limite pas à bloquer purement et simplement une requête. Parfois, vous aurez affaire à des situations où les choses sont plus ambigües : s’agit-il d’un bot ou d’un groupe de visiteurs qui apparaissent avec la même IP uniquement parce qu’ils sont derrière un NAT ? Des réponses plus adaptables s’imposent.
<3>Utilisation d’un backend de moindre priorité

Vous pouvez autoriser les requêtes suspectes sur votre site normalement lorsque la charge est faible, mais les restreindre lorsqu’elle commence à augmenter (ou les rediriger vers une VM dédiée pour le trafic suspect ou vers une version statique de votre site) en utilisant un autre backend.

Pour ce faire, créez un backend avec les nouveaux serveurs, puis utilisez une ligne use_backend pour diriger les requêtes vers celui-ci :

Cela va généralement suivre les règles de http-request deny, qui ont un seuil plus élevé comme 200, de sorte qu’un bot trop abusif obtiendra toujours des réponses d’erreur directes ; tandis que celles qui ont un taux de requête plus faible peuvent obtenir le backend be_website_bots à la place. Si le renvoi d’erreurs même aux taux les plus élevés vous inquiète, vous pouvez ajouter { be_conn(be_website) gt 3000 } pour ne refuser catégoriquement les requêtes que s’il y a plus de 3 000 connexions actives au backend.

Envoi d’un défi Javascript

Le module HAProxy Enterprise Antibot permet de faire en sorte que les clients génèrent une clé pour entrer sur le site, ce qui aidera à identifier les utilisateurs individuels derrière un NAT et à séparer les clients qui supportent Javascript de ceux qui ne le supportent pas.

Le module Antibot demande au client de résoudre un problème mathématique généré dynamiquement. Il repose sur l’idée que de nombreux robots DDoS automatisés ne sont pas capables d’analyser JavaScript. Ou, s’ils le sont, cela les ralentit. Le temps passé par le processeur à résoudre l’énigme consomme souvent les ressources de l’attaquant, qu’il paie à la minute, et l’incite à chercher une cible plus facile ailleurs.

Consultez notre webinaire à la demande, intitulé Attaques DDoS et protection contre les robot avec HAProxy Enterprise, pour en savoir plus et voir une démonstration du module Antibot en action.

Mettre un visiteur au défi de résoudre un Captcha

Le module reCAPTCHA présente au client un défi Google reCAPTCHA v2 qu’un robot ne pourra pas relever. C’est utile dans les cas où un robot utilise un navigateur à part entière, comme Chrome headless ou Selenium. Ce module, comme le module Antibot, élimine les utilisateurs illégitimes, soit en les arrêtant, soit en les ralentissant au point qu’il leur est impossible de poursuivre l’attaque.

Consultez notre webinaire à la demande, intitulé Attaques DDoS et protection contre les robots avec HAProxy Enterprise, pour en savoir plus et voir une démonstration du module reCaptcha en action.

Abandon silencieux des requêtes

Lorsque vos règles indiquent clairement qu’un bot est un bot et qu’il génère simplement trop de trafic, la meilleure chose à faire est d’essayer de le surcharger.

Afin de faire des requêtes, le bot doit garder une trace des connexions TCP, tout comme HAProxy normalement. Ainsi, les deux sont occupés, sauf que HAProxy doit également répondre aux autres visiteurs en même temps. Avec la suppression silencieuse silent-drop, HAProxy indique au noyau d’oublier la connexion mais sans avertir le client. Désormais, HAProxy n’a plus besoin de suivre cette connexion. Cela laisse le client dans l’attente d’une réponse qui ne viendra jamais et il devra garder la connexion dans sa mémoire, en utilisant l’un de ses ports sources, jusqu’à ce qu’elle expire. Pour ce faire, ajoutez http-request silent-drop, comme suit:

Le principal inconvénient est que, en supposant que les règles sont définies de telle sorte qu’aucun client légitime ne soit affecté, tous les périphériques réseau avec état (à savoir les pare-feu) seront confondus par cette manœuvre, car ils ne recevront pas non plus de notification indiquant que la connexion a fermé. Cela amènera ces périphériques à garder une trace des connexions que HAProxy ne suit plus ; en outre, ils consomment de la mémoire sur le pare-feu avec état. Gardez cela à l’esprit si vous utilisez un tel dispositif.

Conclusion

Dans cet article de blog, vous avez appris à défendre vos sites Web contre les attaques de la couche application telles que les inondations HTTP et Slowloris en utilisant les fonctions intégrées à HAProxy pour limiter le débit et signaler les clients suspects. Vous protégez ainsi vos serveurs Web et empêchez le trafic malveillant de pénétrer sur votre réseau.

HAProxy Enterprise vous offre des fonctions indispensables pour agréger les données des tables de persistance et mettre au défi les clients suspects avec des puzzles JavaScript ou reCAPTCHA. Ces fonctions supplémentaires vous permettront d’obtenir une image complète de votre trafic et de vous assurer que les utilisateurs réguliers ne sont pas bloqués par des faux positifs.

Si vous souhaitez mettre en œuvre une solution de protection contre les attaques DDoS avec HAProxy, soutenu par le support et l’expertise d’HAProxy Entreprise, vous pouvez demander votre essai pour HAProxy Enterprise dès maintenant ou nous contacter pour en savoir plus.

Vous avez une idée dont vous aimeriez que nous parlions dans notre blog ? Faites-nous en part dans les commentaires ! Vous voulez être tenu au courant des sujets comme celui-ci ? Inscrivez-vous à notre newsletter et suivez-nous sur Twitter !

The HAProxy Guide to Multi-Layer Security
SHARE THIS ARTICLE