Après avoir ajouté votre service web à Anti-DDoS Proxy, si le site subit une attaque par saturation HTTP, vous pouvez analyser les caractéristiques des champs HTTP et configurer des règles ciblées pour améliorer la détection et le blocage de ces attaques. Cela s'applique à des scénarios tels que la protection contre le hotlinking et la sécurisation des interfaces d'administration du site. Cette rubrique explique comment configurer des politiques d'atténuation des saturations HTTP.
Produits qui protègent contre les attaques par saturation HTTP
Une attaque par saturation HTTP (également appelée attaque Challenge Collapsar ou CC) est un type d'attaque par déni de service distribué (DDoS) qui cible généralement la couche application. Les attaquants contrôlent des hôtes pour envoyer continuellement des requêtes HTTP ou HTTPS falsifiées à un serveur web cible. Par exemple, ils sollicitent de manière répétée une page de recherche ou une page de connexion qui consomme d'importantes ressources serveur. Cela épuise les ressources du serveur ou la bande passante réseau, ralentit le site web et l'empêche de traiter les requêtes des utilisateurs légitimes.
Contrairement aux attaques DDoS traditionnelles au niveau du réseau, les attaques par saturation HTTP sont plus difficiles à détecter car elles imitent les requêtes d'utilisateurs légitimes. Pour renforcer la sécurité des services web, Alibaba Cloud propose Anti-DDoS Proxy et Web Application Firewall afin de se défendre contre les attaques par saturation HTTP.
Anti-DDoS Proxy
Anti-DDoS Proxy se concentre sur la défense contre les attaques volumétriques. Il garantit que l'infrastructure réseau n'est pas affectée par l'épuisement de la bande passante ou des ressources, et est généralement déployé en périphérie du réseau. Anti-DDoS Proxy offre une protection intelligente et des politiques personnalisées d'atténuation des saturations HTTP pour lutter contre ces attaques.
Protection intelligente : grâce aux capacités de big data d'Alibaba Cloud, cette fonctionnalité apprend la ligne de base du trafic de votre service web, analyse les anomalies d'attaque à l'aide d'algorithmes, génère automatiquement des règles de contrôle d'accès précis et ajuste dynamiquement le modèle de protection. Elle vous aide à détecter et bloquer au plus tôt les attaques web malveillantes, telles que celles provenant de bots malveillants et les attaques par saturation HTTP. Après avoir ajouté un site web à Anti-DDoS Proxy, la protection intelligente est activée par défaut. Pour plus d'informations, consultez Utiliser la fonctionnalité de protection intelligente.
Politiques personnalisées d'atténuation des saturations HTTP : le contenu décrit dans cette rubrique. Lorsque votre site subit une attaque par saturation HTTP, vous pouvez analyser les caractéristiques des champs de requête HTTP et configurer des règles de contrôle d'accès précis ou des règles de contrôle de fréquence pour le site. Des mesures telles que le contrôle de fréquence, l'analyse comportementale et les listes noires d'adresses IP vous aident à mieux vous défendre contre les attaques DDoS.
Web Application Firewall (WAF)
Le WAF analyse le trafic HTTP et HTTPS atteignant la couche application. Il identifie et protège contre les caractéristiques malveillantes présentes dans le trafic des sites web et des applications, empêchant ainsi les intrusions malveillantes sur les serveurs web qui pourraient entraîner des problèmes de performance. Le WAF utilise plusieurs méthodes pour identifier et contrer les attaques au niveau de la couche application, notamment la validation des entrées, des ensembles de règles pour des vulnérabilités spécifiques, le suivi de session et des mécanismes de protection tels que CAPTCHA, les défis JavaScript et la vérification des cookies. Le WAF est généralement déployé près du serveur. Cela permet au WAF de surveiller plus étroitement le trafic arrivant au serveur et d'appliquer des politiques de sécurité au niveau de la couche application.
Ces deux produits se concentrent sur différents aspects de la protection. Si vous souhaitez uniquement vous défendre contre les attaques par saturation HTTP et que le volume d'attaque est élevé (par exemple, le site web est inaccessible), nous recommandons Anti-DDoS Proxy. Si le volume d'attaque n'est pas élevé (par exemple, le site web répond simplement lentement), nous recommandons Web Application Firewall. Toutefois, pour une protection optimale, nous vous conseillons de déployer les deux produits afin de garantir que votre service web ne soit pas endommagé par du trafic malveillant et par les attaquants.
Recommandations de configuration pour les politiques d'atténuation des saturations HTTP
Nous vous recommandons de configurer cette fonctionnalité lorsque votre site web subit une attaque par saturation HTTP. La fonctionnalité renforce la protection en autorisant ou en filtrant le trafic présentant des caractéristiques spécifiées. Nous ne recommandons pas l'utilisation de cette fonctionnalité pour une protection routinière.
Vous pouvez utiliser les méthodes suivantes pour vérifier si les requêtes HTTP contiennent des caractéristiques évidentes, telles qu'une même adresse IP source ou un même champ dans l'URI, et configurer des politiques d'atténuation des saturations HTTP en fonction de ces caractéristiques.
Sur la page Attack Analysis, consultez les événements HTTP Attack enregistrés par Anti-DDoS Proxy. Les détails des événements incluent des informations telles que l'adresse IP source de l'attaque, l'User-Agent, le Referer, la méthode HTTP et l'empreinte digitale du client. Pour plus d'informations, consultez Analyse des attaques.
Sur la page Log Analysis, examinez les champs tels que
real_client_ip,http_user_agent,http_refereretrequest_methoddans les journaux d'Anti-DDoS Proxy. Pour connaître la signification des champs, consultez Champs inclus dans les journaux complets.
Présentation des politiques d'atténuation des saturations HTTP
-
Selon que l'option Rate Limiting est activée lors de la configuration d'une règle, les règles sont classées comme règles de contrôle d'accès précis et règles de contrôle de fréquence. Les règles de contrôle d'accès précis sont évaluées en premier, puis les règles de contrôle de fréquence. Lorsqu'une requête correspond à une règle, aucune autre règle suivante n'est évaluée.
NotaLes règles de contrôle d'accès précis générées automatiquement par la protection intelligente d'Anti-DDoS Proxy, c'est-à-dire les règles préfixées par
smartcc_, suivent également cette logique de correspondance. Pour améliorer la protection par défaut contre les attaques par saturation HTTP, le moteur de protection intègre deux règles de contrôle de fréquence. Ces règles s'affichent dans la zone de configuration des règles de contrôle de fréquence et sont nommées Built-in HTTP Flood Mitigation Rule - Based on Request Frequency of Clients et Built-in HTTP Flood Mitigation Rule - Based on Response Codes of Origin Servers. Seules les opérations view et delete sont prises en charge.
|
Élément |
Règle de contrôle d'accès précis |
Règle de contrôle de fréquence |
|
Description |
L'action est exécutée lorsque les conditions de correspondance sont remplies. Nota
Si vous trouvez des règles préfixées par |
L'action est exécutée uniquement lorsque l'objet statistique remplit les conditions de correspondance et atteint le seuil défini pendant la période statistique. Importante
Une règle intégrée d'atténuation des saturations HTTP ne peut pas être récupérée après sa suppression. Agissez avec prudence. Si vous confirmez vouloir supprimer la règle, nous vous recommandons de configurer ensuite des règles de contrôle de fréquence personnalisées en fonction de la fréquence d'accès et des caractéristiques des noms de domaine ou des interfaces importants que vous souhaitez protéger. Cela améliore la protection contre les attaques par saturation HTTP. |
|
Période de validité de la règle |
Définie par vos soins. Vous pouvez définir la période de validité comme permanente ou choisir une durée personnalisée comprise entre 5 et 120 minutes. Nota
Si vous spécifiez une durée personnalisée, la règle est automatiquement supprimée à l'expiration de cette durée. |
Permanente. |
|
Principe de correspondance |
Toutes les règles sont évaluées. Si une requête correspond à plusieurs règles, l'action de la règle située le plus haut dans la liste est exécutée. Par exemple, si une requête correspond à la fois à la règle ① et à la règle ②, l'action de la règle ① est exécutée.
|
Toutes les règles sont évaluées. Si une requête correspond à plusieurs règles, l'action de l'une des règles correspondantes est exécutée de manière aléatoire. |
|
Limites |
Nombre maximal de règles de contrôle d'accès précis pouvant être configurées pour chaque nom de domaine :
|
Nombre maximal de règles de contrôle de fréquence pouvant être configurées pour chaque nom de domaine :
|
Insertion de cookies
L'insertion de cookies dans les services de couche 7 intervient dans les deux scénarios suivants.
-
Scénario 1 : La mitigation des attaques HTTP flood est activée dans la politique de protection DDoS pour le service web associé au nom de domaine.
Une fois la politique de mitigation des attaques HTTP flood activée, Anti-DDoS Proxy insère un cookie côté client (par exemple, dans un navigateur) afin de différencier et de comptabiliser les clients. Lorsqu'un utilisateur accède au site web, le cookie inséré est inclus dans le message HTTP. Anti-DDoS Proxy se sert des résultats statistiques pour déterminer si le trafic du service subit des attaques HTTP flood et déclenche la politique de nettoyage correspondante.
-
Scénario 2 : L'action d'une règle de mitigation des attaques HTTP flood est définie sur le mode challenge.
Après avoir activé l'action challenge pour une politique de mitigation des attaques HTTP flood, un cookie est ajouté à l'en-tête du message HTTP pour recueillir les informations d'empreinte numérique du navigateur client. Les données d'empreinte collectées incluent le champ host du message HTTP ainsi que la height et la width du navigateur. Lorsque le trafic correspond à la règle, Anti-DDoS Proxy envoie une sonde challenge au client et exploite les statistiques d'empreinte du navigateur pour détecter d'éventuelles anomalies. Cette méthode permet d'identifier les attaques HTTP flood provenant de clients anormaux.
Pour empêcher Anti-DDoS Proxy d'insérer des cookies dans votre service, accédez à la page dans la console, cliquez sur Edit dans la colonne Actions, puis désactivez le commutateur Cookie Settings dans la configuration du site web. Notez toutefois qu'Anti-DDoS Proxy ne pourra plus détecter ni bloquer activement les attaques HTTP flood via le module de politique de mitigation des attaques HTTP flood.
Configurer une politique d'atténuation des attaques par saturation HTTP
Prérequis
Un service web a été ajouté à Anti-DDoS Proxy. Pour plus d'informations, consultez la rubrique Ajouter des sites web.
Procédure
Connectez-vous à la console Anti-DDoS Proxy.
-
Dans la barre de navigation supérieure, sélectionnez la région de votre instance.
Anti-DDoS Proxy (Chinese Mainland) : choisissez la région Chinese Mainland.
Anti-DDoS Proxy (Outside Chinese Mainland) : choisissez la région Outside Chinese Mainland.
Dans le volet de navigation de gauche, accédez à .
Sur la page General Policies, cliquez sur l'onglet Protection for Website Services et sélectionnez le nom de domaine que vous souhaitez configurer dans la liste des noms de domaine située à gauche.
-
Localisez la zone de configuration HTTP Flood Mitigation, cliquez sur Settings, puis sur Create Rule dans le coin supérieur droit. Une fois la configuration terminée, cliquez sur OK.
Paramètre
Description
Rule Name
Nom de la règle. Il peut contenir des lettres, des chiffres et des traits de soulignement (_), et ne doit pas dépasser 128 caractères.
Match Conditions
Conditions de correspondance de la règle. Pour plus de détails sur les champs, consultez l'Annexe 1 : Champs de requête HTTP pris en charge.
Nota-
Le champ Field Value est obligatoire. Le contenu de correspondance des règles de contrôle d'accès précis est sensible à la casse, tandis que celui des règles de contrôle de fréquence ne l'est pas.
-
Vous pouvez configurer jusqu'à cinq conditions de correspondance. Si vous ajoutez plusieurs conditions, une requête n'est considérée comme correspondante que si elle satisfait à toutes les conditions.
Rate Limiting
Indique s'il faut activer la vérification de la fréquence.
-
Interrupteur désactivé : la règle est une règle de contrôle d'accès précis.
-
Interrupteur activé : la règle est une règle de contrôle de fréquence. Après avoir activé l'interrupteur, vous devez configurer l'Statistical Object (IP, en-tête personnalisé, session, cookie personnalisé et paramètre de requête personnalisé sont pris en charge), la Duration (Seconds) et le Threshold (Occurrences). Vous pouvez également configurer des règles plus précises en fonction du nombre ou de la proportion de codes de réponse.
Action
Opération effectuée sur une requête lorsque celle-ci satisfait aux conditions de correspondance. Valeurs possibles :
-
Allow : autorise la requête.
-
Block : bloque la requête.
-
JavaScript Challenge : vérifie l'adresse IP source de la requête à l'aide d'un algorithme de défi.
-
Monitor : enregistre dans les journaux les requêtes correspondant à la règle de surveillance et les autorise.
NotaLorsque les paramètres de fréquence sont activés, l'Action ne prend en charge que Block, JavaScript Challenge et Monitor.
Validity Period
-
Lorsque l'interrupteur de paramétrage de la fréquence est désactivé : durée de validité de la règle de contrôle d'accès précis. Les durées permanentes et personnalisées de 5 à 120 minutes sont prises en charge.
NotaSi vous spécifiez une durée personnalisée, la règle est automatiquement supprimée à l'expiration de cette durée.
-
Lorsque l'interrupteur de paramétrage de la fréquence est activé : période pendant laquelle l'action de la règle est appliquée après la mise en correspondance de la règle de contrôle de fréquence. Seules les durées personnalisées de 1 à 1 440 minutes sont prises en charge.
Advanced Settings
Lorsque les paramètres de fréquence sont activés, la déduplication lors de la collecte des statistiques est prise en charge. L'objet statistique peut être défini sur IP, Header ou URI.
-
Scénario 1 : Mode de déduplication activé
Dans l'illustration suivante, lorsque les conditions de correspondance sont remplies et que la même adresse IP source accède à 200 URI différents ou plus dans un délai de 30 secondes, l'action spécifiée est exécutée et les requêtes provenant de cette adresse IP sont bloquées. Étant donné que le mode de déduplication est activé, lorsque la même adresse IP source accède plusieurs fois au même URI, le nombre d'accès est compté comme 1.
-
Scénario 2 : Mode de déduplication non activé
Dans l'illustration suivante, lorsque les conditions de correspondance sont remplies et que la même adresse IP source envoie 200 requêtes ou plus dans un délai de 30 secondes, l'action spécifiée est exécutée et les requêtes provenant de cette adresse IP sont bloquées. Étant donné que le mode de déduplication n'est pas activé, si la même adresse IP source accède 10 fois au même URI, le nombre d'accès est compté comme 10.
La règle est déclenchée, mais le trafic reste élevé
Si vous avez configuré une règle de contrôle de fréquence pour l'atténuation des attaques par saturation HTTP, mais qu'un grand nombre de requêtes apparaissent toujours dans les journaux d'accès, suivez les étapes ci-dessous pour résoudre le problème :
Vérifiez si la règle est effective : examinez les codes d'état de réponse dans les journaux d'accès. Si le code d'état correspondant à Block apparaît, ou si une page de vérification humaine s'affiche, la règle est effective et l'action correspondante a été exécutée.
Recherchez un trafic provenant d'adresses IP dispersées : une règle de contrôle de fréquence compte le nombre de requêtes provenant d'un objet statistique, tel que l'adresse IP de la requête, au cours de la période statistique, et bloque les requêtes uniquement lorsqu'un seul objet statistique dépasse le seuil. Si le trafic d'attaque provient d'un grand nombre d'adresses IP sources dispersées et que le nombre de requêtes envoyées par chaque adresse IP est inférieur au seuil, la règle ne bloque pas ces requêtes. Par conséquent, un grand nombre de requêtes non bloquées apparaissent toujours dans les journaux.
Resserrez le seuil : vous pouvez réduire la période statistique de 60 secondes (valeur par défaut) à 10 secondes, et abaisser le seuil de 20 à 3. Une période statistique plus courte et un seuil plus bas permettent plus facilement au nombre de requêtes provenant d'une seule adresse IP dispersée d'atteindre la condition de blocage. Ajustez les paramètres en fonction des caractéristiques réelles du trafic de votre service afin d'éviter de bloquer les requêtes légitimes.
Utilisez le mode de défi pour réduire le risque de faux positifs : si vous craignez que le resserrement du seuil n'affecte les utilisateurs légitimes, vous pouvez modifier l'action de la règle de Block à JavaScript Challenge. Les requêtes correspondant à la règle déclenchent alors une page de vérification humaine au lieu d'être directement bloquées.
-
Revenez à la zone HTTP Flood Mitigation et activez l'interrupteur Status.
Annexe 1 : Champs de requête HTTP pris en charge
|
Champ de correspondance |
Description du champ |
Opérateurs logiques |
Exemple de champ |
|
IP |
Adresse IP source de la requête. La valeur prend en charge plusieurs adresses IP ou des adresses IP avec masques. |
appartient à, n'appartient pas à, figure dans la liste, ne figure pas dans la liste |
10.10.10.10 |
|
URI |
URI de la requête. Exemple : |
contient, ne contient pas, est égal à, n'est pas égal à, la longueur est inférieure à, la longueur est égale à, la longueur est supérieure à, le préfixe correspond, fait partie de, ne fait pas partie de Nota
Si l'opérateur logique est « est égal à » ou « n'est pas égal à », la valeur doit commencer par |
/action/member/id.php?id=1&td=2 |
|
User-Agent |
Informations sur le navigateur du client qui envoie la requête, telles que l'identifiant du navigateur, l'identifiant du moteur de rendu et les informations de version. |
contient, ne contient pas, est égal à, n'est pas égal à, la longueur est inférieure à, la longueur est égale à, la longueur est supérieure à, fait partie de, ne fait pas partie de |
Mozilla/5,0 (Windows NT 10.0; Win64; x64) AppleWebKit/537,36 (KHTML, like Gecko) Chrome/119,0.XX.XX Safari/537,36 |
|
Cookie |
Informations de cookie incluses dans la requête. |
contient, ne contient pas, est égal à, n'est pas égal à, la longueur est inférieure à, la longueur est égale à, la longueur est supérieure à, n'existe pas, fait partie de, ne fait pas partie de |
cna=Z87DHXX/jXIBASQBsYAimToU; sca=234ea940; yunpk=177699790**** |
|
Referer |
URL source de la requête, indiquant la page à partir de laquelle la requête a été redirigée. |
contient, ne contient pas, est égal à, n'est pas égal à, la longueur est inférieure à, la longueur est égale à, la longueur est supérieure à, n'existe pas, fait partie de, ne fait pas partie de |
https://example.aliyundoc.com/ |
|
Content-Type |
Type de contenu HTTP de la réponse spécifié par la requête, correspondant aux informations de type MIME. |
contient, ne contient pas, est égal à, n'est pas égal à, la longueur est inférieure à, la longueur est égale à, la longueur est supérieure à, fait partie de, ne fait pas partie de |
text/plain;charset=UTF-8 |
|
X-Forwarded-For |
Adresse IP réelle du client qui envoie la requête. Format : |
contient, ne contient pas, est égal à, n'est pas égal à, la longueur est inférieure à, la longueur est égale à, la longueur est supérieure à, n'existe pas, fait partie de, ne fait pas partie de |
36.18.XX.XX,192,18.XX.XX |
|
Content-Length |
Nombre d'octets contenus dans la requête. |
la valeur est inférieure à, la valeur est égale à, la valeur est supérieure à |
806 |
|
Post-Body |
Informations de contenu de la requête. |
contient, ne contient pas, est égal à, n'est pas égal à, fait partie de, ne fait pas partie de |
Content-Type: application/x-www-form-urlencoded name=John&age=25&email=**** |
|
Http-Method |
Méthode de la requête. Valeurs valides : GET, POST, DELETE, PUT, OPTIONS, CONNECT, HEAD et TRACE. |
est égal à, n'est pas égal à, fait partie de, ne fait pas partie de |
POST |
|
Header |
Informations d'en-tête de la requête, utilisées pour personnaliser les champs d'en-tête HTTP et faire correspondre le contenu. |
contient, ne contient pas, est égal à, n'est pas égal à, la longueur est inférieure à, la longueur est égale à, la longueur est supérieure à, n'existe pas, fait partie de, ne fait pas partie de |
*text/html,application/xhtml+xml,application/xml;q=0,9,image/webp,image/**** |
|
Params |
Partie des paramètres dans l'URL de la requête, qui désigne généralement la partie située après |
contient, ne contient pas, est égal à, n'est pas égal à, la longueur est inférieure à, la longueur est égale à, la longueur est supérieure à, fait partie de, ne fait pas partie de |
action=login |
|
Raw-URI |
URI non encodé, qui conserve la séquence de caractères d'origine. Un Raw-URI peut contenir des caractères spéciaux et des espaces. Toutefois, il doit être encodé avant utilisation pour éviter toute ambiguïté ou erreur lors de la transmission réseau et de l'analyse. |
contient, ne contient pas, est égal à, n'est pas égal à, la longueur est inférieure à, la longueur est égale à, la longueur est supérieure à, correspond à l'expression régulière, l'octet contient, l'octet est égal à, fait partie de, ne fait pas partie de |
GET /images/logo.png HTTP/1,1 |
|
Tls-Fingerprint |
Valeur d'empreinte du client identifiée et calculée à l'aide d'un algorithme propriétaire Alibaba Cloud basé sur l'empreinte TLS du client qui envoie la requête. Cette valeur sert à faire correspondre et protéger contre les requêtes. Vous pouvez consulter les empreintes des clients de différentes manières :
|
est égal à, n'est pas égal à |
74dcbf6b790160370bb6b7bea98d5978 |
|
HTTP/HTTPS |
Type de protocole de la requête. HTTP et HTTPS sont pris en charge. |
est égal à, n'est pas égal à |
HTTP |
|
Version HTTP |
Version du protocole HTTP. HTTP/1,0, HTTP/1,1 et HTTP/2,0 sont pris en charge. |
est égal à, n'est pas égal à, fait partie de, ne fait pas partie de |
HTTP/1,0 |
|
Empreinte HTTP/2,0 |
Empreinte HTTP/2,0 générée en traitant l'empreinte originale du client HTTP/2 avec l'algorithme MD5. L'empreinte permet d'analyser et d'identifier différents clients pour une communication plus sécurisée et efficace. |
est égal à, n'est pas égal à |
ad8424af1cc590e09f7b0c499bf7fcdb |
|
Empreinte JA3 |
Anti-DDoS Proxy traite les paramètres clés de la négociation TLS, notamment la version TLS, les suites de chiffrement, les algorithmes de compression et les extensions TLS, à l'aide de l'algorithme de hachage MD5 pour générer une chaîne représentant la configuration TLS du client. Cette chaîne correspond à l'empreinte JA3. Les empreintes JA3 permettent d'identifier et de différencier les clients TLS de différents types, tels que les navigateurs web, les applications mobiles et les logiciels malveillants. |
est égal à, n'est pas égal à, fait partie de, ne fait pas partie de |
eb6f49e8db7ad1809f885d12232f4855 |
|
Empreinte JA4 |
Les empreintes JA4 intègrent davantage d'informations contextuelles et d'algorithmes, tels que la version du navigateur et le système d'exploitation, ce qui réduit les problèmes de duplication pouvant survenir avec les empreintes JA3. Les empreintes JA4 permettent de distinguer plus précisément les utilisateurs réels des usurpateurs et de réduire le taux de faux positifs. |
est égal à, n'est pas égal à, fait partie de, ne fait pas partie de |
f436b9416f37d134cadd04886327d3e8 |
|
Continent/Pays |
Emplacement géographique de l'adresse IP source. |
Sélection de liste noire géographique |
Europe |
Annexe 2 : Exemples de configuration
Les exemples suivants fournissent des suggestions de configuration pour des scénarios de service courants. Configurez les règles en fonction des besoins réels de votre service. Ces exemples sont fournis à titre indicatif uniquement.
Bloquer des requêtes d'attaque spécifiques
Dans la plupart des cas, les services légitimes n'envoient pas de requêtes POST vers le répertoire racine. Si votre site web subit une attaque par saturation HTTP et que vous constatez un grand nombre de requêtes POST vers le répertoire racine dans les requêtes clients, évaluez la validité de ces requêtes. Si vous confirmez qu'elles ne proviennent pas de services légitimes, configurez la règle suivante.
Bloquer les robots d'indexation web
Si vous observez un grand nombre de requêtes de robots d'indexation dans le trafic de votre site web sur une période donnée, et que vous ne pouvez pas exclure que des zombies d'attaque simulent des robots pour lancer des attaques par saturation HTTP, bloquez les requêtes des robots. La figure suivante illustre un exemple de configuration de règle.
Protection contre le hotlinking
Lorsqu'un navigateur accède à une page web, il transmet le champ Referer pour informer le serveur de la page depuis laquelle la requête est liée. En configurant une règle de contrôle d'accès pour le champ Referer, vous pouvez bloquer le hotlinking provenant de sites web spécifiques. Par exemple, si vous constatez que « https://example.aliyundoc.com » effectue fréquemment du hotlinking d'images depuis votre site web, configurez la règle suivante.
Configurer une limite de débit pour un User-Agent
Par exemple, si un User-Agent accède aux URI préfixés par /game/all_ plus de 30 fois en 10 secondes, l'action de défi est appliquée aux requêtes provenant de ce User-Agent.
Configurer une limite de débit pour les connexions
Par exemple, pour protéger l'interface de connexion contre des attaques malveillantes par bourrage d'identifiants à haute fréquence, configurez l'adresse de l'interface de connexion et bloquez les requêtes lorsque plus de 20 requêtes sont envoyées en 60 secondes.
Configurer des règles de contrôle de fréquence basées sur les codes de réponse du serveur d'origine
En configurant des conditions de déclenchement basées sur le nombre ou la proportion de codes de réponse du serveur d'origine, vous pouvez améliorer la précision de la protection au-delà de la politique de protection par fréquence existante et réduire le risque de faux positifs pour les services légitimes. Lorsque le nombre de requêtes provenant d'un objet statistique dépasse le seuil pendant la période statistique et que les codes de réponse du serveur d'origine configurés dépassent le nombre ou la proportion spécifiés, l'action correspondante est déclenchée.
200
Lorsque le serveur d'origine dispose de capacités de traitement élevées et répond toujours normalement aux requêtes à haute fréquence des attaquants, traitez les adresses IP qui dépassent la fréquence de requête normale de votre service en fonction des caractéristiques de celui-ci. Cela limite le taux de requêtes et protège la disponibilité du serveur d'origine ainsi que celle de votre service. Reportez-vous à la configuration suivante :
404
Lorsque les attaquants lancent des attaques par balayage d'URI ou demandent continuellement des chemins qui n'existent pas sur le serveur d'origine, ce dernier répond souvent par un grand nombre de codes d'état 404. Configurez une politique pour ajouter les adresses IP des attaquants à une liste de blocage. Reportez-vous à la configuration suivante :
403
Lorsque les attaquants lancent des attaques web et qu'un produit de protection tel que WAF est déployé derrière Anti-DDoS Proxy, configurez des règles basées sur les codes de réponse renvoyés par l'autre produit de protection pour les requêtes bloquées. Par exemple, Alibaba Cloud WAF bloque les attaques web et répond avec le code 403. Configurez une politique pour ajouter préalablement les adresses IP des attaquants à une liste de blocage côté Anti-DDoS Proxy. Reportez-vous à la configuration suivante :
429
Si le serveur d'origine possède ses propres configurations de limitation de débit ou de vérification de service, il répond par le code 429 Too Many Requests ou par un code de réponse personnalisé lorsque les requêtes des attaquants correspondent à ces règles de limitation ou de vérification. Configurez une politique pour ajouter les adresses IP des attaquants à une liste de blocage et réduire la pression sur le serveur d'origine. Reportez-vous à la configuration suivante :
502
Lorsque le serveur d'origine met beaucoup de temps à traiter les requêtes en raison d'une augmentation soudaine du trafic et renvoie des réponses 502 anormales, configurez une politique pour ajouter les adresses IP effectuant des requêtes à haute fréquence à une liste de blocage et garantir la disponibilité du serveur d'origine. Reportez-vous à la configuration suivante :
555
Si le serveur d'origine possède une logique de service spéciale et répond par un code d'état personnalisé tel que 555 pour les requêtes inattendues, traitez les adresses IP envoyant ces requêtes inattendues côté Anti-DDoS Proxy en fonction de cette caractéristique. Reportez-vous à la configuration suivante :
Bloquer les empreintes digitales de client invalides
Les attaquants forgent des empreintes digitales de client pour simuler de vrais clients et tentent d'établir un grand nombre de connexions ou d'envoyer un grand nombre de requêtes HTTP, ce qui entraîne le plantage du serveur ou un refus de service. Vérifiez et identifiez les empreintes digitales de client pour refuser ces connexions.
Par exemple, lors d'une attaque volumétrique par saturation HTTP, si les attaquants utilisent le même script ou le même outil, le nombre ou la proportion de requêtes contenant la même valeur d'empreinte digitale augmente brusquement. Sur la page Security Overview, cliquez sur l'onglet Domain Names pour afficher les données principales relatives à l'Client TLS Fingerprint. Utilisez ensuite le champ ssl_client_tls_fingerprinting_md5 dans les journaux Log Analysis pour afficher la proportion des principales empreintes digitales de client, analyser le comportement des requêtes, détecter les valeurs d'empreinte suspectes dès que possible et configurer des politiques.