haproxy bot protection

HAProxy est un répartiteur de charge haute performance qui offre des capacités de défense avancées pour détecter et protéger votre site Web contre le trafic bot malveillant. La combinaison de ses systèmes uniques ACL, tables de correspondance et tables de persistance avec son puissant langage de configuration vous permet de suivre et d’atténuer le spectre complet des menaces bot actuelles. Lisez la suite pour savoir comment.

Lisez notre article de blog intitulé « Protection contre les attaques DDoS au niveau de la couche applicative avec HAProxy » pour savoir pourquoi HAProxy est une ligne de défense essentielle contre les attaques DDoS utilisée par un grand nombre des plus grandes entreprises du monde. Pour en savoir plus sur la limitation de débit en général, lisez notre article de blog Quatre exemples de limitation de débit HAProxy.

On estime que les bots représentent près de la moitié du trafic sur Internet. Par bot, on entend un programme informatique qui automatise une tâche banale. Les activités typiques d’un bot comprennent l’exploration de sites Web en vue de leur indexation, comme c’est le cas pour Googlebot qui trouve et catalogue vos pages Web. Vous pouvez également vous inscrire à des services qui recherchent des billets d’avion bon marché ou qui regroupent des listes de prix pour vous proposer les meilleures offres. Ces types de robots sont généralement considérés comme bénéfiques.

Malheureusement, une grande partie des bots sont utilisés pour des raisons malveillantes. Leurs intentions comprennent le raclage de sites Web, le spamming, l’inondation de requêtes, le forçage brutal et l’analyse de vulnérabilités. Par exemple, les robots peuvent récupérer vos listes de prix afin que vos concurrents puissent systématiquement vous vendre moins cher ou élaborer une solution concurrentielle à partir de vos données. Ils peuvent aussi essayer de localiser des forums et des sections de commentaires où ils pourront envoyer du spam. Dans d’autres cas, ils analysent votre site à la recherche de failles de sécurité.

HAProxy dispose des meilleures capacités de défense pour détecter et protéger contre de nombreux types de trafic bot indésirable. Ses systèmes uniques ACL, table de correspondance et tables de persistance, ainsi que son langage de configuration flexible, sont les éléments constitutifs qui vous permettent d’identifier tout type de comportement de bot et de le neutraliser. En outre, HAProxy est réputé pour maintenir ses hautes performances et son efficacité tout en exécutant ces tâches complexes. Pour ces raisons, des entreprises comme StackExchange ont utilisé HAProxy comme un élément clé de leur stratégie de sécurité.

Dans cet article de blog, vous apprendrez à créer une configuration HAProxy pour la protection contre les robots. Comme vous le verrez, les bots ont généralement un comportement unique et pour les attraper, il suffit de reconnaître les modèles. Vous apprendrez également comment mettre les bons robots sur une liste d’autorisés.

Répartiteur de charge HAProxy

Pour créer une configuration HAProxy pour protéger contre les robots, vous devez d’abord installer HAProxy et le placer devant vos serveurs d’application. Tout le trafic sera acheminé à travers lui afin d’identifier les modèles de clients. Ensuite, des seuils appropriés peuvent être déterminés et des politiques de réponse peuvent être mises en œuvre.

Dans cet article de blog, nous allons examiner le nombre de pages uniques qu’un client visite au cours d’une période donnée et déterminer si ce comportement est normal ou non. S’il franchit le seuil prédéterminé, nous prendrons des mesures à la périphérie avant qu’il n’aille plus loin. Nous allons également découvrir comment détecter et bloquer les robots qui tentent de forcer votre écran de connexion et les robots qui recherchent des vulnérabilités.

Stratégie de protection contre les bots

Les bots peuvent être repérés parce qu’ils présentent un comportement non humain. Examinons un comportement spécifique : le raclage de sites web. Dans ce cas, les robots parcourent souvent un grand nombre de pages uniques très rapidement afin de trouver le contenu ou les types de pages qu’ils recherchent. Un visiteur qui demande des dizaines de pages uniques par seconde n’est probablement pas humain.

Notre stratégie consiste à configurer le répartiteur de charge HAProxy pour observer le nombre de requêtes effectuées par chaque client. Ensuite, nous vérifierons combien de ces demandes concernent des pages que le client visite pour la première fois. N’oubliez pas que les robots racleurs de sites Web veulent parcourir de nombreuses pages en peu de temps. Si le rythme auquel ils demandent de nouvelles pages dépasse un certain seuil, nous signalons cet utilisateur et refusons ses demandes ou les acheminons vers un autre backend.

Il faut cependant éviter de bloquer les bons robots comme Googlebot. Vous verrez donc comment définir des listes d’autorisés qui permettent le passage de certaines adresses IP.

Détecter le raclage Web

Les tables de persistance stockent et incrémentent les compteurs associés aux clients lorsqu’ils effectuent des requêtes sur votre site Web. Pour une introduction plus approfondie, consultez notre article de blog « Introduction aux tables de correspondance HAProxy ». Pour en configurer une, ajoutez une section backend à votre fichier de configuration HAProxy, puis ajoutez-y une directive stick-table. Chaque backend ne peut avoir qu’une seule définition de stick-table. Nous allons définir deux tables de correspondance, comme suit :

La première table, qui est définie dans votre backend per_ip_and_url_rates, indique le nombre de fois qu’un client a demandé la page Web actuelle au cours des dernières 24 heures. Les clients sont suivis par une clé unique. Dans ce cas, la clé est une combinaison de l’adresse IP du client et d’un hachage du chemin qu’il demande. Remarquez que le type de la table de correspondance est binary pour que la clé prenne en compte cette combinaison de données.

La deuxième table, qui se trouve dans un backend appelé per_ip_rates, stocke un compteur à usage général appelé gpc0. Vous pouvez incrémenter un compteur à usage général lorsqu’un événement personnalisé se produit. Nous allons l’incrémenter chaque fois qu’un client visite une page pour la première fois au cours des dernières 24 heures.

Le compteur gpc0_rate nous indique à quelle vitesse le client visite les nouvelles pages. L’idée est que les robots visitent plus de pages en moins de temps qu’un utilisateur normal. Nous avons fixé de façon arbitraire la période de taux à trente secondes. La plupart du temps, les bots seront rapides. Par exemple, le robot bien connu Scrapy est capable d’explorer environ 3 000 pages par minute. D’autre part, les robots peuvent être configurés pour explorer votre site au même rythme qu’un utilisateur normal. Gardez à l’esprit que vous pouvez modifier la période de référence de trente secondes à un délai plus long, comme 24 heures (24h), en fonction du nombre de pages qu’un utilisateur normal est susceptible de consulter dans ce laps de temps.

Ensuite, ajoutez une section frontend pour recevoir les requêtes :

La ligne http-request track-sc1 ajoute le client au stockage de la table de persistance. Elle utilise une combinaison de son adresse IP et de la page visitée comme clé, que vous obtenez avec la méthode d’extraction intégrée url32+src. Une méthode d’extraction recueille des informations sur la requête en cours.

De nos jours, les pages Web contiennent de nombreux fichiers de soutien : scripts JavaScript, feuilles de style CSS, images. En ajoutant une instruction unless à la fin de votre ligne http-request track-sc1, vous pouvez exclure ces types de fichiers du décompte des nouvelles requêtes de pages. Ainsi, dans cet exemple, les requêtes de fichiers JavaScript, CSS, PNG, JPEG et GIF ne seront pas comptabilisées.

La ligne http-request track-sc1 met automatiquement à jour tous les compteurs associés à la table de persistance, y compris le compteur http_req_rate. Ainsi, dans ce cas, le compteur de requêtes HTTP pour la page augmente de un. Lorsque le compteur est exactement égal à un pour une adresse IP source et une page données, cela signifie que l’utilisateur actuel visite la page pour la première fois. Dans ce cas, l’instruction conditionnelle if { sc_http_req_rate(1) eq 1 } de la dernière ligne devient vraie et la directive http-request sc-inc-gpc0(0) incrémente le compteur gpc0 dans notre deuxième table de persistance.

Maintenant que vous incrémentez un compteur polyvalent chaque fois qu’un client, identifié par son adresse IP, visite une nouvelle page, vous obtenez également le taux auquel ce client visite les nouvelles pages via le compteur gpc0_rate(30s). Combien de visites de pages uniques sur trente secondes sont considérées comme trop nombreuses ? Des outils tels que Google Analytics peuvent vous aider grâce à la métrique Pages/Session. Disons que 15 premières requêtes de pages sur cette période constituent un comportement de type bot. Vous définirez ce seuil dans la section suivante.

Définition d’un seuil

Maintenant que vous suivez les données, il est temps de fixer un seuil qui permettra de distinguer les robots des humains. Les robots demandent des pages beaucoup plus rapidement, sur une période plus courte. Votre première option est de bloquer purement et simplement la requête. Ajoutez une directive http-request deny à votre section frontend :

Ainsi, tout utilisateur qui demande plus de 15 pages uniques au cours des trente dernières secondes recevra une réponse 403 Forbidden. En option, vous pouvez utiliser deny_status pour transmettre un code alternatif tel que 429 Too Many Requests. Notez que l’utilisateur ne sera interdit que pour la durée de la période de taux, soit trente secondes dans ce cas, ensuite le compteur sera remis à zéro. C’est parce que nous avons ajouté !exceeds_limit à la fin de la ligne http-request sc-inc-gpc0(0) de sorte que si l’utilisateur continue à accéder à de nouvelles pages pendant la période de temps, le compteur ne continuera pas à s’incrémenter.

Pour aller encore plus loin, vous pourriez utiliser une balise polyvalente (gpt0) pour baliser les bots présumés afin de les interdire à partir de ce moment-là, même après que leur taux de requêtes de nouvelles pages ait diminué. Cette interdiction durera jusqu’à l’expiration de leur entrée dans la table de persistance, soit 24 heures dans ce cas. L’expiration des enregistrements est définie avec le paramètre expire sur la stick-table. Commencez par ajouter gpt0 à la liste des compteurs stockés par la table stick per_ip_rates :

Ensuite, ajoutez http-request sc-set-gpt0 (0) à votre frontend pour définir la balise sur 1, en utilisant la même condition que précédemment. Nous allons également ajouter une ligne qui refuse tous les clients pour lesquels cet indicateur est défini.

Vous pouvez également envoyer toutes les adresses IP balisées à un backend spécial en utilisant la directive use_backend, comme indiqué:

Ce backend pourrait, par exemple, servir une version en cache de votre site ou avoir des directives de server avec une limite maxconn inférieure pour s’assurer qu’ils ne peuvent pas submerger les ressources de votre serveur. En d’autres termes, vous pourriez autoriser le trafic des robots, mais leur accorder une priorité moindre.

Observer la collecte des données

Vous pouvez utiliser l’API d’exécution pour voir les données à mesure qu’elles arrivent. Si vous ne l’avez jamais utilisée auparavant, consultez notre article de blog intitulé Dynamic Configuration with the HAProxy Runtime API (Configuration dynamique avec l’API d’exécution HAProxy) pour en savoir plus sur la variété des commandes disponibles. En bref, l’API d’exécution écoute sur un socket UNIX et vous pouvez lui envoyer des requêtes en utilisant socat ou netcat.

La commande show table [nom de la table] renvoie les entrées qui ont été enregistrées dans une table de persistance. Après avoir défini votre configuration HAProxy et effectué quelques requêtes sur votre site Web, examinez le contenu de la table de correspondance per_ip_and_url_rates, comme suit :

J’ai fait une requête à /foo et cinq requêtes à /bar ; toutes à partir d’une source IP de 127.0.0.1. Bien que la clé soit au format binaire, vous pouvez voir que les quatre premiers octets sont différents. Chaque clé est un hachage du chemin que j’ai demandé et de mon adresse IP, il est donc facile de voir que j’ai demandé différentes pages. Le taux http_req_rate vous indique combien de fois j’ai accédé à ces pages.

Le saviez-vous ? Vous pouvez également saisir des adresses IPv6 avec cette configuration, en utilisant la même méthode d’extraction url32+src.

Utilisez l’API d’exécution pour inspecter la table per_ip_rates également. Vous verrez les valeurs gpc0 et gpc0_rate :

Ici, les deux requêtes de pages uniques au cours des dernières 24 heures sont signalées par la valeur gpc0=2. Le nombre de celles qui ont eu lieu au cours des trente dernières secondes était également de deux, comme l’indique la valeur gpc0_rate(30000).

syncing multiple peers

Synchronisation de plusieurs pairs par l’intermédiaire des agrégateurs de tables de persistance

Si vous exploitez plusieurs instances d’HAProxy, il est essentiel de combiner les compteurs collectés par chacune d’elles pour obtenir une image précise de l’activité des utilisateurs. HAProxy Enterprise assure un suivi à l’échelle du cluster grâce à une fonction appelée un agrégateur de table de persistance ou « Stick Table Aggregator ». Cette fonction partage les données de la table des persistance entre les instances à l’aide du protocole peers, additionne les valeurs, puis renvoie les résultats combinés à chaque instance de HAProxy. De cette manière, vous pouvez détecter des modèles en utilisant un ensemble plus complet de données. Voici une représentation de la façon dont plusieurs peers peuvent être synchronisés :

Vérification des utilisateurs réels

Le risque de limiter le taux est de bloquer accidentellement les utilisateurs légitimes sur votre site. HAProxy Enterprise possède le module reCAPTCHA qui est utilisé pour présenter une page de défi Google reCAPTCHA v2. Ainsi, vos visiteurs peuvent résoudre une énigme et accéder au site si jamais ils sont signalés. Dans l’exemple suivant, nous utilisons le module reCAPTCHA Lua pour éviter que les visiteurs ne se voient refuser l’accès au site sans aucun moyen d’y revenir.

Désormais, une fois qu’une IP est marquée comme étant un bot, le client ne recevra que des défis reCAPTCHA jusqu’à ce qu’il en résolve un, ensuite il pourra revenir à la navigation normalement.

HAProxy Enterprise possède une autre fonctionnalité intéressante : le module Antibot. Lorsqu’un client se comporte de manière suspecte en demandant un trop grand nombre de pages uniques, HAProxy lui envoie un défi JavaScript. De nombreux robots ne sont pas en mesure d’analyser le JavaScript, ce qui les arrête net. Cette méthode a l’avantage de ne pas perturber les utilisateurs normaux et de garder une bonne expérience client.

Au-delà des racleurs

Jusqu’à présent, nous avons parlé de la détection et du blocage des clients qui accèdent très rapidement à un grand nombre de pages uniques. Cette méthode est particulièrement utile contre les racleurs, mais des règles similaires peuvent également être appliquées pour détecter les robots qui tentent de forcer les connexions et de rechercher des vulnérabilités. Elle ne nécessite que quelques modifications.

Bots de force brute

Les robots qui tentent de forcer une page de connexion présentent quelques caractéristiques uniques : Ils effectuent des requêtes POST et frappent la même URL (une URL de connexion) pour tester à plusieurs reprises de nombreuses combinaisons de noms d’utilisateur et de mots de passe. Dans la section précédente, nous suivions les taux de requêtes HTTP pour une URL donnée sur une base par IP avec la ligne suivante :

Nous avons utilisé http-request sc-inc-gpc0(0) pour incrémenter un compteur à usage général, gpc0, dans la table de persistance per_ip_rates lorsque le client visite une page pour la première fois.

Vous pouvez utiliser cette même technique pour bloquer les accès répétés à la même URL. Le raisonnement est le suivant : un robot qui cible une page de connexion enverra un nombre anormal de requêtes POST à cette page. Vous devriez surveiller uniquement les requêtes POST.

Tout d’abord, puisque la table de persistance per_ip_and_url_rates surveille une période de 24 heures et collecte les requêtes GET et POST, créons une troisième table de persistance pour détecter les activités de force brute. Ajoutez la définition de stick-table suivante :

Ajoutez ensuite une ligne http-request track-sc2 et une ligne http-request deny au frontend :

Vous disposez maintenant d’une table de persistance et de règles qui détecteront les requêtes POST répétées vers l’URLlogin, comme on pourrait le voir lorsqu’un attaquant tente de trouver des identifiants valides. Notez comment l’ACL { path /login } limite cette détection à une URL spécifique. Cette option est facultative, car vous pourriez limiter tous les chemins vers lesquels les clients POST en l’omettant. Lisez notre article Introduction aux ACLs HAProxy pour plus d’informations sur la définition de règles personnalisées à l’aide des ACLs.

En plus de refuser la demande, vous pouvez également utiliser l’une des réponses décrites dans la section Débloquer les utilisateurs réels ci-dessus afin de donner une autre chance aux utilisateurs valides qui se retrouvent pris dans ce filet.

Scanners de vulnérabilité

Les scanners de vulnérabilité sont une menace à laquelle vous êtes confronté dès que vous exposez votre site ou votre application à l’Internet. Les scanners de vulnérabilité génériques sonderont votre site par de nombreux chemins différents, en essayant de déterminer si vous exécutez des applications tierces vulnérables connues.

De nombreux propriétaires de sites se tournent, à juste titre, vers un pare-feu d’application Web pour faire face à de telles menaces, comme le WAF que HAProxy Enterprise fournit en tant que module natif. Cependant, de nombreux experts en sécurité s’accordent à dire qu’il est avantageux de disposer de plusieurs couches de protection. En utilisant une combinaison de tables de persistance et d’ACL, vous êtes en mesure de détecter les scanners de vulnérabilité avant qu’ils ne soient transmis au WAF.

Lorsqu’un robot scanne votre site, il essaie généralement d’accéder à des chemins qui n’existent pas dans votre application, comme /phpmyadmin et /wp-admin. Comme le backend répondra par des 404 à ces requêtes, HAProxy peut détecter ces conditions en utilisant l’extraction http_err_rate. Cela permet de suivre le taux de requêtes que le client a fait et qui ont donné lieu à un code de réponse 4xx de la part du backend.

Ces scanners de vulnérabilité effectuent généralement leurs requêtes assez rapidement. Cependant, comme les taux élevés de 404 sont assez rares, vous pouvez ajouter le compteur http_err_rate à votre table de persistance per_ip_rates existante :

Maintenant, avec ce compteur supplémentaire, et le http-request track-sc0 déjà en place, vous avez le taux de 4xx pour les clients, que vous pouvez visualiser via l’API d’exécution. Bloquez-les simplement en ajoutant la ligne suivante :

Vous pouvez également utiliser le compteur gpc0 que nous utilisons pour les racleurs afin de les bloquer pendant une période plus longue :

Désormais, les mêmes limites qui s’appliquent aux racleurs pourraient s’appliquer aux scanners de vulnérabilités pour les bloquer rapidement avant qu’ils ne parviennent à trouver des failles.

Vous pouvez également bloquer ces clients et envoyer leurs requêtes à un backend de type « pot de miel » (honeypot), ce qui ne donnera aucune raison à l’attaquant de croire qu’il a été bloqué (shadowban). Par conséquent, il ne tentera pas de contourner le blocage. Pour ce faire, ajoutez ce qui suit à la place du deny http-request ci-dessus. Veillez à définir le backend be_honeypot :

Autoriser les bons robots

Bien que notre stratégie soit très efficace pour détecter et bloquer les robots malveillants, elle permet également d’attraper Googlebot, BingBot et d’autres robots de recherche bénins avec la même facilité. Vous aimeriez accepter ces robots, et non les bannir.

La première étape pour remédier à ce problème est de décider quels sont les bots que vous voulez afin qu’ils ne soient pas bloqués. Vous établirez une liste de bonnes adresses IP de robots, que vous devrez mettre à jour régulièrement. Ce processus prend un certain temps, mais il en vaut la peine ! Google fournit un tutoriel utile. Suivez ces étapes :

  1. Faites une liste des chaînes trouvées dans les en-têtes User-Agent des bons robots (par exemple, GoogleBot).
  2. Recherchez les chaînes ci-dessus dans vos journaux d’accès et extrayez les adresses IP sources.
  3. Effectuez une requête DNS inverse pour vérifier que l’IP est bien un bon robot valide. Il y a beaucoup de robots malveillants qui se font passer pour des bons.
  4. Vérifiez le forward DNS de l’enregistrement obtenu à l’étape 3 pour vous assurer qu’il renvoie à l’adresse IP du robot, car un attaquant pourrait héberger de faux enregistrements reverse DNS pour vous confondre.
  5. Utilisez whois pour extraire la plage d’IP de la liste whois afin de couvrir un plus grand nombre d’IP. La plupart des entreprises veillent à ce que leurs robots de recherche et leurs proxies restent dans leurs propres plages d’adresses IP.
  6. Exportez cette liste d’IP dans un fichier avec une IP ou un masque de réseau CIDR par ligne (par exemple 192.168.0.0/24).

Maintenant que vous avez un fichier contenant les adresses IP des bons robots, vous voulez l’appliquer à HAProxy pour que ces robots ne soient pas affectés par vos règles de blocage. Enregistrez le fichier sous le nom de whitelist.acl et modifiez la ligne http-request track-sc1 comme suit :

Désormais, les moteurs de recherche ne verront pas leurs pages vues comptabilisées comme du scraping. Si vous avez plusieurs fichiers, comme un fichier pour autoriser les utilisateurs de l’administration, vous pouvez les ordonner comme ceci :

Lorsque vous utilisez des fichiers de liste d’autorisés, assurez-vous qu’ils sont distribués à tous vos serveurs HAProxy et que chaque serveur est mis à jour pendant l’exécution. Un moyen facile d’y parvenir est d’acheter HAProxy Enterprise et d’utiliser son module lb-update. Cela vous permet d’héberger vos fichiers ACL à une URL et de demander à chaque répartiteur de charge de récupérer les mises à jour à un intervalle défini. De cette façon, toutes les instances sont synchronisées à partir d’un emplacement central.

Identifier les bots par leur localisation

Lorsqu’il s’agit d’identifier les bots, l’utilisation des données de géolocalisation pour classer les différents clients en catégories peut s’avérer très utile. Vous pourriez décider de fixer une limite de taux différente pour la Chine, par exemple, si vous étiez en mesure de savoir quels clients proviennent de ce pays.

Dans cette section, vous verrez comment lire les bases de données de géolocalisation avec HAProxy. Ceci peut être fait avec HAProxy Enterprise ou HAProxy Community, mais de manière différente.

Géolocalisation avec HAProxy Enterprise

HAProxy Enterprise fournit des modules qui lisent nativement les bases de données de géolocalisation de MaxMind et Digital Element. Vous pouvez également les lire avec HAProxy Community, mais vous devez d’abord les convertir en tables de correspondance, puis les charger dans HAProxy.

Voyons comment faire cela avec MaxMind en utilisant HAProxy Enterprise.

Maxmind

Tout d’abord, chargez la base de données en ajoutant les directives suivantes à la section global de votre configuration :

Dans votre frontend, utilisez http-request set-header pour ajouter un nouvel en-tête HTTP à toutes les requêtes, qui saisit le pays du client :

Désormais, les requêtes adressées au backend comprendront un nouvel en-tête qui ressemblera à ceci :

Vous pouvez également ajouter la ligne maxmind-update url https://example.com/maxmind.mmdb pour que HAProxy mette automatiquement à jour la base de données à partir d’une URL pendant l’exécution.

Digital Element

Si vous utilisez Digital Element pour la géolocalisation, vous pouvez faire la même chose que pour MaxMind en ajoutant ce qui suit à la section global de votre configuration:

Ensuite, dans votre frontend, ajoutez une ligne http-request set-header :

Cela ajoute un en-tête à toutes les requêtes, qui contient le pays du client :

Pour que HAProxy mette automatiquement à jour la base de données Digital Element pendant l’exécution, ajoutez netacuity-update url https://example.com/netacuity_db à votre section global.

Lisez la section suivante si vous utilisez HAProxy Community, sinon passez à la section Utilisation des informations de localisation.

Géolocalisation avec HAProxy Community

Si vous utilisez HAProxy Community, vous devrez d’abord convertir la base de données de géolocalisation en une table de correspondance. Dans l’exemple suivant, nous vous montrons comment convertir la base de données de villes MaxMind en une table de correspondance HAProxy.

Tout d’abord, créez un fichier nommé read_city_map.py avec le contenu suivant :

Ensuite, téléchargez la base de données Maxmind City (avec des modifications mineures, ce script fonctionnera pour les bases de données pays uniquement). Les fichiers CSV de la base de données GeoLite City ou de la base de données payante City produiront le même résultat. Ensuite, extrayez le fichier zip.

Lorsque vous exécutez ce script avec un CSV de Blocks comme premier argument et un CSV Locations comme second argument, il produira les fichiers country_iso_code.map, city_name.map et gps.map.

Utilisez http-request set-header pour ajouter un en-tête HTTP, comme nous l’avons fait dans les exemples Entreprise précédents :

De nouveau nous nous retrouvons avec un en-tête contenant le pays du client.

Nous l’utiliserons dans la section suivante.

Utilisation des informations de localisation

Que vous ayez utilisé HAProxy Enterprise ou HAProxy Community pour obtenir les informations de géolocalisation, vous pouvez désormais les utiliser pour prendre des décisions. Par exemple, vous pouvez diriger les clients qui déclenchent trop d’erreurs vers un backend spécial, un pot de miel. Avec les données de géolocalisation, le seuil que vous utilisez peut être plus ou moins élevé pour certains pays.

Comme ces informations sont stockées dans un en-tête HTTP, votre serveur backend y aura également accès, ce qui vous permettra de prendre des mesures supplémentaires à partir de là. Nous n’en parlerons pas ici, mais HAProxy prend également en charge la détection des appareils et d’autres types de bases de données d’intelligence applicative.

Conclusion

Dans cet article de blog, vous avez appris comment identifier et bannir les robots malveillants de votre site Web en utilisant le puissant langage de configuration du répartiteur de charge HAProxy. En plaçant ce type de protection contre les robots devant vos serveurs, vous vous protégez contre les robots qui tentent de racler du contenu, de forcer des attaques brutes et de rechercher des failles de sécurité.

HAProxy Enterprise vous offre plusieurs options quant à la manière de traiter ces menaces, vous permettant de les bloquer, de les envoyer vers un backend dédié ou de leur présenter un défi. Vous avez besoin d’aide pour élaborer une configuration HAProxy pour la détection et la protection des bots qui s’adapte à votre environnement unique ? Contactez-nous pour en savoir plus ou pour vous inscrire à un essai gratuit. L’équipe d’experts de HAProxy Technologies possède plusieurs décennies d’expérience dans l’atténuation de nombreux types de menaces de bots. Ils peuvent vous aider à trouver une approche adaptée à vos besoins.

Utilisez-vous HAProxy pour votre défense contre les robots ? Faites-nous en part dans la section des commentaires ci-dessous ! Vous voulez être tenu au courant de nos publications sur des sujets similaires ? Abonnez-vous à ce blog et suivez-nous sur Twitter !

The HAProxy Guide to Multi-Layer Security
SHARE THIS ARTICLE