Documentation AEM as a Cloud Service Guide de l’utilisateur

Règles de filtre de trafic incluant des règles WAF

Dernière mise à jour : 25 février 2025

Rubriques :

Créé pour :

Administration

Les règles de filtre de trafic peuvent être utilisées pour bloquer ou autoriser les requêtes au niveau de la couche du réseau CDN, ce qui peut s’avérer utile dans des scénarios tels que :

Limiter l’accès à des domaines spécifiques au trafic interne de l’entreprise, avant la mise en service d’un nouveau site
Définir des limites de débit pour être moins sensible aux attaques par déni de service (DoS) volumétriques
Empêcher les adresses IP connues pour être malveillantes de cibler vos pages

La plupart de ces règles de filtre de trafic sont disponibles pour tous les clientes et clients d’AEM as a Cloud Service Sites et Forms. Elles fonctionnent principalement sur les propriétés de requête et les en-têtes de requête, notamment l’adresse IP, le nom d’hôte, le chemin d’accès et l’agent utilisateur.

Une sous-catégorie de règles de filtre de trafic nécessite une licence Sécurité renforcée ou une licence Protection WAF-DDoS. Ces règles puissantes sont connues sous le nom de règles de filtreag de trafic WAF (pare-feu d’application web, ou règles WAF, en abrégé) et ont accès aux Indicateurs WAF décrits plus loin dans cet article.

Les règles de filtrage du trafic peuvent être déployées par le biais de pipelines de configuration de Cloud Manager vers des types d’environnements de développement, d’évaluation et de production. Le fichier de configuration peut être déployé dans des environnements de développement rapide (RDE) à l’aide de l’outil de ligne de commande.

Suivez un tutoriel pour développer rapidement une expertise concrète sur cette fonctionnalité.

NOTE

Pour obtenir des options supplémentaires relatives à la configuration du trafic sur le réseau CDN, notamment modifier la requête/réponse, la déclaration des redirections et l’établissement d’un proxy vers une origine non AEM, voir l’article Configurer le trafic sur le réseau CDN.

Organisation de cet article

Cet article comprend les sections suivantes :

Vue d’ensemble de la protection du trafic : découvrez votre protection contre le trafic malveillant.
Processus suggéré pour la configuration des règles : découvrez une méthodologie de haut niveau pour la protection de votre site web.
Configuration : découvrez comment paramétrer, configurer et déployer des règles de filtre de trafic, y compris les règles WAF avancées.
Syntaxe des règles : découvrez comment déclarer des règles de filtre de trafic dans le fichier de configuration cdn.yaml. Cela inclut les règles de filtre de trafic disponibles pour l’ensemble de la clientèle Sites et Forms, ainsi que la sous-catégorie des règles WAF pour les personnes qui détiennent une licence pour cette fonctionnalité.
Exemples de règles : consultez des exemples de règles déclarées pour vous lancer.
Règles de limite de débit : découvrez comment utiliser des règles de limitation de débit pour protéger votre site contre les attaques à volume élevé.
Alertes sur les règles de filtrage de trafic : configurez les alertes pour recevoir des notifications lorsque vos règles sont déclenchées.
Alerte de pic de trafic par défaut à l’origine : recevez une notification en cas d’augmentation du trafic à l’origine, ce qui suggère une attaque DDoS.
Journaux du réseau CDN : découvrez les règles déclarées et les indicateurs WAF qui correspondent à votre trafic.
Outils de tableau de bord : analysez vos journaux du réseau CDN pour obtenir de nouvelles règles de filtre de trafic.
Règles de démarrage recommandées : ensemble de règles avec lesquelles commencer.
Tutoriel : connaissances pratiques relatives à la fonctionnalité, notamment à l’utilisation des outils de tableau de bord pour déclarer les règles appropriées.

Adobe vous invite à faire part de vos commentaires ou à poser des questions sur les règles de filtre de trafic en envoyant un e-mail à l’adresse suivante : aemcs-waf-adopter@adobe.com.

Vue d’ensemble de la protection du trafic

Dans le paysage numérique actuel, le trafic malveillant est une menace omniprésente. Adobe reconnaît la gravité du risque et propose plusieurs approches pour protéger les applications clientes et atténuer les attaques lorsqu’elles se produisent.

À la périphérie, le réseau CDN géré par Adobe absorbe les attaques DoS sur la couche réseau (couches 3 et 4), y compris les attaques par inondation et par réflexion/amplification.

Par défaut, Adobe prend des mesures pour empêcher la dégradation des performances en raison de l’explosion inattendue d’un trafic élevé au-delà d’un certain seuil. En cas d’attaque DoS qui affecte la disponibilité du site, les équipes d’exploitation d’Adobe sont alertées et prennent des mesures pour atténuer les attaques.

Les clientes et clients peuvent prendre des mesures proactives pour limiter les attaques de couche d’application (couche 7) en configurant des règles à différents niveaux du flux de diffusion de contenu.

Par exemple, au niveau de la couche Apache, les clientes et clients peuvent configurer l’une des options suivantes : module Dispatcher ou ModSecurity pour limiter l’accès à certains contenus.

Comme le décrit cet article, des règles de filtrage du trafic peuvent être déployées sur le réseau CDN géré par Adobe à l’aide des pipelines de configuration de Cloud Manager. Outre les règles de filtre de trafic basées sur des propriétés telles que l’adresse IP, le chemin d'accès et les en-têtes, ou des règles basées sur la définition de limites de débit, les clientes et clients peuvent également acquérir sous licence une sous-catégorie puissante de règles de filtre de trafic appelées règles WAF.

Processus suggéré

Voici un processus de bout en bout de haut niveau recommandé pour obtenir les règles de filtrage de trafic appropriées :

Configurez les pipelines de configuration hors production et en production, comme décrit dans la section Configuration.
Les clientes et clients qui possèdent une licence pour la sous-catégorie des règles de filtrage du trafic de WAF doivent les activer dans Cloud Manager.
Lisez et testez le tutoriel pour comprendre concrètement comment utiliser les règles de filtrage du trafic, y compris les règles WAF si elles sont sous licence. Ce tutoriel vous guide tout au long des étapes du déploiement de règles dans un environnement de développement, de la simulation du trafic malveillant et du téléchargement des journaux du réseau CDN à leur analyse dans les outils du tableau de bord.
Copiez les règles de démarrage recommandées dans cdn.yaml et déployez la configuration dans l’environnement de production en mode journal.
Après avoir collecté du trafic, analysez les résultats à l’aide des outils du tableau de bord pour voir s’il y a des correspondances. Recherchez les faux positifs et effectuez les réglages nécessaires, en activant les règles de démarrage en mode bloc.
Ajoutez des règles personnalisées basées sur l’analyse des journaux du réseau CDN, d’abord en testant avec du trafic simulé sur les environnements de développement avant de procéder au déploiement dans les environnements intermédiaire et de production en mode journal, puis en mode bloc.
Surveillez le trafic de manière continue, en modifiant les règles à mesure que le paysage de la menace évolue.

Configuration

Créez un fichier cdn.yaml avec un ensemble de règles de filtrage du trafic, y compris les règles WAF.
kind: "CDN" version: "1" metadata: envTypes: ["dev"] data: trafficFilters: rules: # Block simple path - name: block-path when: allOf: - reqProperty: tier matches: "author|publish" - reqProperty: path equals: '/block/me' action: block
Voir la section Utiliser les pipelines de configuration pour obtenir une description des propriétés situées au-dessus du nœud data. La valeur de la propriété kind doit être définie sur CDN et la version doit être définie sur 1.
Si les règles WAF sont sous licence, vous devez activer la fonctionnalité dans Cloud Manager, comme décrit ci-dessous pour les scénarios de programme nouveaux et existants.
1. Pour configurer le WAF sur un nouveau programme, cochez la case Protection WAF-DDOS dans l’onglet Sécurité lorsque vous ajoutez un programme de production.
2. Pour configurer le WAF sur un programme existant, modifiez votre programme et dans l’onglet Sécurité, décochez ou cochez la case WAF-DDOS à tout moment.
Créez un pipeline de configuration dans Cloud Manager, comme décrit dans l’article sur le pipeline de configuration. Le pipeline fera référence à un dossier config de niveau supérieur avec le fichier cdn.yaml placé quelque part en dessous. Voir la section Utiliser des pipelines de configuration.

Syntaxe des règles de filtrage de trafic

Vous pouvez configurer des règles de filtrage du trafic pour établir une correspondance sur des modèles tels que les adresses IP, l’agent utilisateur, les en-têtes de requête, le nom d’hôte, la zone géographique et l’URL.

Les clientes et les clients qui détiennent une licence pour l’offre de sécurité améliorée ou de protection WAF-DDoS peuvent également configurer une catégorie spéciale de règles de filtrage du trafic appelée Règles de filtrage du trafic (ou règles WAF) qui font référence à un ou plusieurs indicateurs WAF.

Voici un exemple d’un ensemble de règles de filtrage du trafic, qui incluent également une règle WAF.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  trafficFilters:
    rules:
      - name: "path-rule"
        when:
          allOf:
            - { reqProperty: path, equals: /block-me }
            - { reqProperty: tier, equals: publish }
        action:
          type: block
      - name: "Enable-SQL-Injection-and-XSS-waf-rules-globally"
        when: { reqProperty: path, like: "*" }
        action:
          type: block
          wafFlags: [ SQLI, XSS]

Format des règles de filtrage du trafic dans le fichier cdn.yaml décrit ci-dessous. Voir quelques autres exemples dans une section ultérieure, ainsi qu’une section distincte sur les Règles de limite de taux.

Propriété

La plupart des règles de filtrage de trafic

Règles de filtre de trafic WAF

Type

Valeur par défaut

Description

name

X

string

-

Nom de règle (64 caractères, ne peut contenir que des caractères alphanumériques et -)

lorsque

X

Condition

-

La structure de base est la suivante :

{ <getter>: <value>, <predicate>: <value> }

voir Syntaxe de la structure de condition ci-dessous, qui décrit les getters, les prédicats et comment combiner plusieurs conditions.

action

X

Action

journal

Objet journal, autoriser, bloquer ou action. Par défaut, il s’agit de journal.

rateLimit

X

RateLimit

non défini

Configuration de limite de débit. La limite de débit est désactivée si elle n’est pas définie.

Vous trouverez ci-dessous une section distincte décrivant la syntaxe rateLimit, ainsi que des exemples.

Structure de condition

Une condition peut être soit une simple condition, soit un groupe de conditions.

Condition simple

Une condition simple est composée d’un getter et d’un prédicat.

{ <getter>: <value>, <predicate>: <value> }

Conditions de groupe

Un groupe de conditions est composé de plusieurs conditions simples et/ou de groupe.

<allOf|anyOf>:
  - { <getter>: <value>, <predicate>: <value> }
  - { <getter>: <value>, <predicate>: <value> }
  - <allOf|anyOf>:
    - { <getter>: <value>, <predicate>: <value> }

Propriété

Type

Signification

allOf

array[Condition]

Opération et. true si toutes les conditions répertoriées renvoient true.

anyOf

array[Condition]

Opération ou. true si l’une des conditions répertoriées renvoie true.

Getter

Propriété

Type

Description

reqProperty

string

Propriété de requête.

L’un de :

path : renvoie le chemin d’accès complet d’une URL sans les paramètres de requête. (utilisez pathRaw pour la variante sans échappement)
url : renvoie l’URL complète, y compris les paramètres de requête. (utilisez urlRaw pour la variante sans échappement)
queryString : renvoie la partie requête d’une URL.
method : renvoie la méthode HTTP utilisée dans la requête.
tier : renvoie l’une des options entre author, preview ou publish.
domain : renvoie la propriété de domaine (telle que définie dans l’en-tête Host) en minuscules.
clientIp : renvoie l’adresse IP du client ou de la cliente.
forwardedDomain : renvoie le premier domaine défini dans l’en-tête X-Forwarded-Host en minuscules.
forwardedIp : renvoie la première adresse IP de l’en-tête X-Forwarded-For.
clientCountry : renvoie un code à deux lettres (Symbole d’indicateur régional) qui identifie le pays dans lequel se trouve le client.

reqHeader

string

Renvoie l’en-tête de requête avec le nom spécifié.

queryParam

string

Renvoie le paramètre de requête avec le nom spécifié.

reqCookie

string

Renvoie le cookie avec le nom spécifié.

postParam

string

Renvoie le paramètre de publication avec le nom spécifié du corps de la requête. Fonctionne uniquement lorsque le corps est de type de contenu application/x-www-form-urlencoded.

Prédicat

Propriété

Type

Signification

est égal à

string

true si le résultat de getter est égal à la valeur fournie.

doesNotEqual

string

true si le résultat de getter n’est pas égal à la valeur fournie.

like

string

true si le résultat de getter correspond au modèle fourni.

notLike

string

true si le résultat de getter ne correspond pas au modèle fourni.

matches

string

true si le résultat de getter correspond à l’expression régulière fournie.

doesNotMatch

string

true si le résultat de getter ne correspond pas à l’expression régulière fournie.

in

array[string]

true si la liste fournie contient le résultat de getter.

notIn

array[string]

true si la liste fournie ne contient pas le résultat de getter.

exists

boolean

true lorsque la valeur est définie sur true et que la propriété existe ou lorsqu’elle est définie sur false et que la propriété n’existe pas.

Remarques

La propriété de requête clientIp ne peut être utilisée qu’avec les prédicats suivants : equals, doesNotEqual, in, notIn. clientIp peut également être comparé à des plages d’adresses IP lors de l’utilisation des prédicats in et notIn. L’exemple suivant implémente une condition pour évaluer si l’adresse IP d’un client ou d’une cliente se trouve dans la plage d’adresses IP 192.168.0.0/24 (de 192.168.0.0 à 192.168.0.255) :

when:
  reqProperty: clientIp
  in: [ "192.168.0.0/24" ]

Adobe recommande d’utiliser regex101 et Fastly Fiddle lorsque vous utilisez l’expression régulière. Vous pouvez également en savoir plus sur la façon dont Fastly traite les expressions régulières dans la Documentation Fastly - Expressions régulières dans Fastly VCL.

Structure d’action

Une action peut être soit une chaîne spécifiant l’action (autoriser, bloquer ou consigner), soit un objet composé à la fois du type d’action (autoriser, bloquer ou consigner) et d’options telles que wafFlags et/ou le statut.

Types d’actions

Les actions sont classées par ordre de priorité en fonction de leurs types dans le tableau suivant, dans l’ordre d’exécution des actions :

Nom

Propriétés autorisées

Signification

autoriser

wafFlags (facultatif), alert (facultatif)

Si wafFlags n’est pas présent, arrête le traitement des règles et passe à la diffusion de la réponse. Si wafFlags est présent, désactive les protections WAF spécifiées et poursuit le traitement des règles.
Si une alerte est spécifiée, une notification du Centre d’actions est envoyée si la règle est déclenchée 10 fois dans un intervalle de 5 minutes. Une fois qu’une alerte est déclenchée pour une règle spécifique, elle ne se redéclenche pas avant le lendemain (UTC).

bloquer

status, wafFlags (facultatif et mutuellement exclusif), alert (facultatif)

Si wafFlags n’est pas présent, renvoie une erreur HTTP en contournant toutes les autres propriétés, le code d’erreur est défini par la propriété de statut ou sur la valeur par défaut 406. Si wafFlags est présent, active les protections WAF spécifiées et poursuit le traitement des règles.
Si une alerte est spécifiée, une notification du Centre d’actions est envoyée si la règle est déclenchée 10 fois dans un intervalle de 5 minutes. Une fois qu’une alerte est déclenchée pour une règle spécifique, elle ne se redéclenche pas avant le lendemain (UTC).

consigner

wafFlags (facultatif), alert (facultatif)

Consigne le fait que la règle a été déclenchée, sinon n’affecte pas le traitement. wafFlags n’a aucun effet.
Si une alerte est spécifiée, une notification du Centre d’actions est envoyée si la règle est déclenchée 10 fois dans un intervalle de 5 minutes. Une fois qu’une alerte est déclenchée pour une règle spécifique, elle ne se redéclenche pas avant le lendemain (UTC).

Liste des indicateurs WAF

La propriété wafFlags, qui peut être utilisée dans les règles de filtre de trafic WAF disponibles sous licence, peut faire référence aux éléments suivants :

Trafic malveillant

ID d’indicateur

Nom de l’indicateur

Description

ATTACK

Attaque

Indicateur utilisé pour identifier les requêtes contenant un ou plusieurs des types d’attaque répertoriés dans ce tableau

ATTACK-FROM-BAD-IP

Attaque provenant d’une adresse IP incorrecte

Indicateur utilisé pour identifier les requêtes de BAD-IP contenant un ou plusieurs des types d’attaque répertoriés dans ce tableau

SQLI

Injection SQL

L’injection SQL est une tentative d’accès à une application ou d’obtention d’informations privilégiées en exécutant des requêtes de base de données arbitraires.

BACKDOOR

Backdoor

Un signal backdoor est une requête qui tente de déterminer si un fichier backdoor commun est présent sur le système.

CMDEXE

Exécution de commande

L’exécution de commande est une tentative de contrôle ou d’endommagement d’un système cible par le biais de commandes système arbitraires au moyen d’entrées de l’utilisateur ou de l’utilisatrice.

CMDEXE-NO-BIN

Exécution de commande, sauf sur /bin/

Fournit le même niveau de protection que CMDEXE lors de la désactivation du faux positif sur /bin en raison de l’architecture AEM.

XSS

Scripts intersites

Les scripts intersites consistent à tenter de détourner un compte d’utilisateur ou d’utilisatrice ou une session de navigation web par le biais d’un code JavaScript malveillant.

TRAVERSAL

Traversée de répertoire

La traversée de répertoire est une tentative de navigation dans des dossiers privilégiés à travers un système dans l’espoir d’obtenir des informations sensibles.

USERAGENT

Outils d’attaque

Les outils d’attaque consistent à utiliser des logiciels automatisés pour identifier des vulnérabilités de sécurité ou pour tenter d’exploiter une vulnérabilité découverte.

LOG4J-JNDI

Log4J JNDI

Les attaques Log4J JNDI tentent d’exploiter la Vulnérabilité Log4Shell présente dans les versions de Log4J antérieures à la version 2.16.0

CVE

Indicateur utilisé pour identifier un CVE. Est toujours associé à un indicateur CVE-<CVE Number>. Contactez Adobe pour en savoir plus sur les CVE contre lesquels Adobe vous protégera.

Trafic suspect

ID d’indicateur

Nom de l’indicateur

Description

ABNORMALPATH

Chemin d’accès anormal

Le chemin d’accès anormal indique que le chemin d’accès d’origine est différent du chemin d’accès normalisé (par exemple, /foo/./bar est normalisé en /foo/bar).

BAD-IP

Adresse IP incorrecte

Indicateur utilisé pour identifier les requêtes provenant d’adresses IP qui sont identifiées comme incorrectes, soit parce qu’il existe des sources identifiées comme malveillantes (SANS, TORNODE), soit parce qu’elles ont été identifiées comme incorrectes par le WAF après avoir envoyé trop de requêtes malveillantes

BHH

En-têtes de saut incorrects

Les en-têtes de saut incorrects indiquent une tentative de passage HTTP via un en-tête de transcodage (TE) ou de longueur de contenu (CL) mal formé, ou un en-tête de TE et de CL bien formé.

CODEINJECTION

Injection de code

L’injection de code est une tentative de contrôle ou d’endommagement d’un système cible par le biais de commandes arbitraires de code d’application à l’aide d’entrées de l’utilisateur ou de l’utilisatrice.

COMPRESSED

Compression détectée

Le corps de la requête POST est compressé et ne peut pas être inspecté. Par exemple, si un en-tête de requête Content-Encoding: gzip est spécifié et que le corps POST n’est pas en texte brut.

RESPONSESPLIT

Fractionnement des réponses HTTP

Identifie le moment où les caractères CRLF sont envoyés en entrée de l’application pour injecter des en-têtes dans la réponse HTTP.

NOTUTF8

Encodage non valide

Un encodage non valide peut entraîner la traduction par le serveur de caractères malveillants d’une requête dans une réponse, provoquant un déni de service ou un XSS.

MALFORMED-DATA

Données incorrectes dans le corps de la requête

Corps de requête POST, PUT ou PATCH incorrect selon l’en-tête de requête « Content-Type ». Par exemple, si un en-tête de requête « Content-Type: application/x-www-form-urlencoded » est spécifié et contient un corps de POST qui est json. Il s’agit souvent d’une erreur de programmation, d’une requête automatisée ou malveillante. Nécessite l’agent 3.2 ou version ultérieure.

SANS

Trafic IP malveillant

Internet Storm Center SANS : liste des adresses IP qui ont été signalées comme ayant participé à une activité malveillante.

NO-CONTENT-TYPE

En-tête de requête « Content-Type » manquant

Requête POST, PUT ou PATCH ne comportant pas d’en-tête de requête « Content-Type ». Par défaut, les serveurs d’applications doivent assumer « Content-Type: text/plain; charset=us-ascii » dans ce cas. De nombreuses requêtes automatisées et malveillantes peuvent ne pas disposer de « Content-Type ».

NOUA

Aucun agent utilisateur

Indique qu’une requête ne contenait pas d’en-tête « User-Agent » ou que la valeur de l’en-tête n’a pas été définie.

NULLBYTE

Octet nul

Les octets nuls n’apparaissent généralement pas dans une requête et indiquent que la requête est incorrecte et potentiellement malveillante.

OOB-DOMAIN

Domaine hors-bande

Les domaines hors-bande sont généralement utilisés pendant les tests de pénétration pour identifier les vulnérabilités dans lesquelles l’accès réseau est autorisé.

PRIVATEFILE

Fichiers privés

Les fichiers privés sont de nature confidentielle, par exemple un fichier Apache .htaccess ou un fichier de configuration susceptible de faire fuiter des informations sensibles.

SCANNER

Scanner

Identifie les services et outils d’analyse les plus utilisés.

Trafic divers

ID d’indicateur

Nom de l’indicateur

Description

CENTRE DE DONNÉES

Centre de données

Identifie la requête comme provenant d’un fournisseur d’hébergement connu. Ce type de trafic n’est généralement pas associé à un utilisateur final réel ou une utilisatrice finale réelle.

DOUBLEENCODING

Encodage double

L’encodage double vérifie la technique d’évasion du double encodage des caractères HTML.

JSON-ERROR

Erreur d’encodage JSON

Corps de requête POST, PUT ou PATCH spécifié comme contenant JSON dans l’en-tête de requête « Content-Type », mais contenant des erreurs d’analyse JSON. Cela est souvent lié à une erreur de programmation ou à une requête automatisée ou malveillante.

TORNODE

Trafic Tor

Tor est un logiciel qui cache l’identité d’un utilisateur ou d’une utilisatrice. Un pic de trafic Tor peut indiquer qu’une personne malveillante essaie de masquer sa localisation.

XML-ERROR

Erreur de codage XML

Corps de requête POST, PUT ou PATCH spécifié comme contenant du code XML dans l’en-tête de requête « Content-Type », mais contenant des erreurs d’analyse XML. Cela est souvent lié à une erreur de programmation ou à une requête automatisée ou malveillante.

Considérations

Lorsque deux règles en conflit sont créées, les règles d’autorisation ont toujours la priorité sur les règles de blocage. Par exemple, si vous créez une règle pour bloquer un chemin d’accès spécifique et une règle pour autoriser une adresse IP spécifique, les requêtes provenant de cette adresse IP sur le chemin d’accès bloqué sont autorisées.
Si une règle est mise en correspondance et bloquée, le réseau CDN répond avec un code de retour 406.
Les fichiers de configuration ne doivent pas contenir de secrets, car ils seront lisibles par toute personne ayant accès au référentiel git.
Les liste d’adresses IP autorisées définies dans Cloud Manager sont prioritaires sur les règles de filtres de trafic.
Les correspondances de règles WAF apparaissent uniquement dans les journaux de réseau CDN pour les échecs et les réussites du réseau CDN, et non les accès.

Exemples de règles

Voici quelques exemples de règles. Voir la section de limite de débit plus bas pour des exemples de règles de limite de débit.

Exemple 1

Cette règle bloque les requêtes provenant de l’IP192.168.1.1 :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  trafficFilters:
     rules:
       - name: "block-request-from-ip"
         when: { reqProperty: clientIp, equals: "192.168.1.1" }
         action:
           type: block

Exemple 2

Cette règle bloque les requêtes sur le chemin d’accès /helloworld lors de la publication avec un agent utilisateur contenant Chrome :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  trafficFilters:
    rules:
      - name: "block-request-from-chrome-on-path-helloworld-for-publish-tier"
        when:
          allOf:
          - { reqProperty: path, equals: /helloworld }
          - { reqProperty: tier, equals: publish }
          - { reqHeader: user-agent, matches: '.*Chrome.*'  }
        action:
          type: block

Exemple 3

Cette règle bloque les requêtes à la publication qui contiennent le paramètre de requête foo, mais autorise chaque requête provenant de l’adresse IP 192.168.1.1 :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  trafficFilters:
    rules:
      - name: "block-request-that-contains-query-parameter-foo"
        when:
          allOf:
            - { queryParam: url-param, equals: foo }
            - { reqProperty: tier, equals: publish }
        action:
          type: block
      - name: "allow-all-requests-from-ip"
        when: { reqProperty: clientIp, equals: 192.168.1.1 }
        action:
          type: allow

Exemple 4

Cette règle bloque les requêtes vers le chemin d’accès /block-me à la publication et bloque chaque requête qui correspond à un modèle SQLI ou XSS. Cet exemple comprend une règle de filtre de trafic WAF, qui fait référence aux indicateurs WAF SQLI et XSS, et requiert donc une licence distincte.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  trafficFilters:
    rules:
      - name: "path-rule"
        when:
          allOf:
            - { reqProperty: path, equals: /block-me }
            - { reqProperty: tier, equals: publish }
        action:
          type: block
      - name: "Enable-SQL-Injection-and-XSS-waf-rules-globally"
        when: { reqProperty: path, like: "*" }
        action:
          type: block
          wafFlags: [ SQLI, XSS]

Exemple 5

Cette règle bloque l’accès aux pays de l’OFAC :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  trafficFilters:
    rules:
      - name: block-ofac-countries
        when:
          allOf:
            - reqProperty: tier
              matches: "author|publish"
            - reqProperty: clientCountry
              in:
                - SY
                - BY
                - MM
                - KP
                - IQ
                - CD
                - SD
                - IR
                - LR
                - ZW
                - CU
                - CI
        action: block

Règles de limite de débit

Il est parfois souhaitable de bloquer le trafic s’il dépasse un certain débit de requêtes entrantes, selon une condition spécifique. Définir une valeur pour la propriété rateLimit limite le débit des requêtes correspondant à la condition de la règle.

Les règles de limite de débit ne peuvent pas faire référence aux indicateurs WAF. Elles sont disponibles pour tous les clientes et clients Sites et Forms.

Les limites de débit sont calculées par POP de réseau CDN. Supposons, par exemple, que les POP de Montréal, Miami et Dublin connaissent des débits de trafic de 80, 90 et 120 requêtes par seconde, respectivement, et que la règle de limite de débit soit définie sur une limite de 100. Dans ce cas, seul le trafic vers Dublin serait limité en débit.

Les limites de débit sont évaluées en fonction du trafic Edge, du trafic d’origine ou du nombre d’erreurs.

Structure rateLimit

Propriété

Type

Par défaut

SIGNIFICATION

limite

entier compris entre 10 et 10 000

obligatoire

Débit de requête (par POP de réseau CDN) dans les requêtes par seconde pour lesquelles la règle est déclenchée.

fenêtre

nombre entier : 1, 10 ou 60

10

Fenêtre d’échantillonnage en secondes pour laquelle le débit de requête est calculé. La précision des compteurs dépend de la taille de la fenêtre (plus la fenêtre est grande, plus la précision est élevée). Par exemple, on peut s’attendre à une précision de 50 % pour la fenêtre d’1 seconde et de 90 % pour la fenêtre de 60 secondes.

pénalité

entier compris entre 60 et 3 600

300 (5 minutes)

Période en secondes pendant laquelle les requêtes correspondantes sont bloquées (arrondie à la minute la plus proche).

nombre

tout, récupérations, erreurs

tout

Évaluer en fonction du trafic Edge (tout), du trafic d’origine (récupérations) ou du nombre d’erreurs (erreurs).

groupBy

tableau [Getter]

aucun

Le compteur de limiteur de taux sera agrégé par un ensemble de propriétés de requête (par exemple, clientIp).

Exemples

Exemple 1

Cette règle bloque un client pendant 5 millisecondes lorsqu’il dépasse un moyenne de 60 requêtes/s (par POP de réseau CDN) au cours des 10 dernières secondes :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  trafficFilters:
    rules:
    - name: limit-requests-client-ip
      when:
        reqProperty: tier
        matches: "author|publish"
      rateLimit:
        limit: 60
        window: 10
        penalty: 300
        count: all
        groupBy:
          - reqProperty: clientIp
      action: block

Exemple 2

Bloque les requêtes sur le chemin d’accès /critical/resource pendant 60 secondes lorsqu’il dépasse une moyenne de 100 requêtes/s à l’origine (par POP de réseau CDN) sur une fenêtre de temps de 10 secondes :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  trafficFilters:
    rules:
      - name: rate-limit-example
        when:
          allOf:
            - { reqProperty: path, equals: /critical/resource }
            - { reqProperty: tier, equals: publish }
        action:
          type: block
        rateLimit: { limit: 100, window: 10, penalty: 60, count: fetches }

Règles CVE

Si WAF est sous licence, Adobe applique automatiquement des règles de blocage pour se protéger contre de nombreuses CVE (vulnérabilités et exposition courantes) connues. Les nouvelles CVE peuvent être ajoutées peu après avoir été découvertes. La clientèle ne doit pas configurer les règles CVE elle-même, cette action étant par ailleurs inutile.

Si une requête de trafic correspond à une CVE, elle apparaît dans l’entrée de journal du réseau de diffusion de contenu correspondante.

Contactez l’assistance Adobe si vous avez des questions à propos d’une CVE particulière ou s’il existe une règle CVE spécifique que votre entreprise souhaite désactiver.

Alertes sur les règles de filtrage du trafic

Une règle peut être configurée pour envoyer une notification du Centre d’actions si elle est déclenchée dix fois pendant une fenêtre de 5 minutes. Une telle règle vous avertit lorsque certains schémas de trafic se produisent afin que vous puissiez prendre les mesures nécessaires. Une fois qu’une alerte est déclenchée pour une règle spécifique, elle ne se redéclenche pas avant le lendemain (UTC).

En savoir plus sur le Centre d’actions, notamment comment configurer les profils de notification requis pour recevoir des e-mails.

Notification du Centre d’actions

La propriété d’alerte peut être appliquée au nœud d’action pour tous les types d’actions (autoriser, bloquer, consigner).

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  trafficFilters:
    rules:
      - name: "path-rule"
        when:
          allOf:
            - { reqProperty: path, equals: /block-me }
            - { reqProperty: tier, equals: publish }
        action:
          type: block
          alert: true

Alerte de pic de trafic par défaut à l’origine

Une notification par e-mail du centre d’actions sera envoyée lorsqu’un trafic important est envoyé à l’origine, et qu’un nombre de requêtes, correspondant à un seuil élevé, provient d’une même adresse IP, ce qui suggère une attaque DDoS.

Si ce seuil est atteint, Adobe bloquera le trafic de cette adresse IP, mais il est recommandé de prendre des mesures supplémentaires pour protéger votre origine, notamment la configuration des règles de filtrage du trafic à des taux limites pour bloquer les pics de trafic à des seuils inférieurs. Voir le tutoriel sur le blocage des attaques DoS et DDoS à l’aide des règles de trafic pour une visite guidée.

Cette alerte est activée par défaut, mais elle peut être désactivée à l’aide de la propriété defaultTrafficAlerts définie sur false. Une fois l’alerte déclenchée, elle ne se redéclenche plus avant le lendemain (UTC).

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  trafficFilters:
   defaultTrafficAlerts: false

Journaux de réseau CDN

AEM as a Cloud Service permet d’accéder aux journaux de réseau CDN qui sont utiles pour les cas d’utilisation, notamment l’optimisation du rapport d’accès au cache et la configuration des règles de filtre de trafic. Les journaux de réseau CDN s’affichent dans la boîte de dialogue Journaux de téléchargement de Cloud Manager, lors de la sélection du service de création ou de publication.

Les journaux de réseau CDN peuvent être retardés jusqu’à 5 minutes.

La propriété rules décrit les règles de filtre de trafic correspondantes et présente le modèle suivant :

"rules": "match=<matching-customer-named-rules-that-are-matched>,waf=<matching-WAF-rules>,action=<action_type>"

Par exemple :

"rules": "match=Block-Traffic-under-private-folder,Enable-SQL-injection-everywhere,waf="SQLI,SANS",action=block"

Les règles se comportent comme suit :

Le nom de règle déclaré par le client ou la cliente de toutes les règles correspondantes est répertorié dans l’attribut match.
L’attribut action détermine si les règles bloquent, autorisent ou consignent.
Si le WAF est sous licence et activé, l’attribut waf répertorie tous les indicateurs WAF (par exemple, SQLI) détectés, que les indicateurs WAF aient été répertoriés dans des règles ou non. Cela permet de fournir des informations sur les nouvelles règles potentielles à déclarer.
Si aucune règle déclarée par le client ou la cliente ni aucune règle WAF ne correspond, la propriété rules est vide.

Comme nous l’avons vu plus haut, les correspondances de règles WAF apparaissent uniquement dans les journaux de réseau CDN pour les échecs et les réussites du réseau CDN, et non les accès.

L’exemple ci-dessous illustre un exemple de cdn.yaml et deux entrées de journal de réseau CDN :

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  trafficFilters:
    rules:
      - name: "path-rule"
        when: { reqProperty: path, equals: /block-me }
        action: block
      - name: "Enable-SQL-Injection-and-XSS-waf-rules-globally"
        when: { reqProperty: path, like: "*" }
        action:
          type: block
          wafFlags: [ SQLI, XSS ]

{
"timestamp": "2023-05-26T09:20:01+0000",
"ttfb": 19,
"cli_ip": "147.160.230.112",
"cli_country": "CH",
"rid": "974e67f6",
"req_ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15",
"host": "example.com",
"url": "/block-me",
"method": "GET",
"res_ctype": "",
"cache": "PASS",
"status": 406,
"res_age": 0,
"pop": "PAR",
"rules": "match=path-rule,action=blocked"
}

{
"timestamp": "2023-05-26T09:20:01+0000",
"ttfb": 19,
"cli_ip": "147.160.230.112",
"cli_country": "CH",
"req_ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15",
"rid": "974e67f6",
"host": "example.com",
"url": "/?sqli=%27%29%20UNION%20ALL%20SELECT%20NULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL%2CNULL--%20fAPK",
"method": "GET",
"res_ctype": "image/png",
"cache": "PASS",
"status": 406,
"res_age": 0,
"pop": "PAR",
"rules": "match=Enable-SQL-Injection-and-XSS-waf-rules-globally,waf=SQLI,action=blocked"
}

Format du journal

Vous trouverez ci-dessous une liste des noms de champs utilisés dans les journaux de réseau CDN, ainsi qu’une brève description.

Nom du champ

Description

timestamp

Heure à laquelle la requête a commencé, après la fin de TLS.

ttfb

Abréviation de Time To First Byte. Intervalle entre le démarrage de la requête et le début de la diffusion du corps de la réponse.

cli_ip

Adresse IP du client ou de la cliente.

cli_country

Code de pays alpha-2 à deux lettres ISO 3166-1 pour le pays du client ou de la cliente.

rid

Valeur de l’en-tête de requête utilisé pour identifier la requête de manière unique.

req_ua

Agent utilisateur responsable de l’exécution d’une requête HTTP donnée.

host

Autorité à laquelle la requête est destinée.

url

Chemin d’accès complet, y compris les paramètres de requête.

method

Méthode HTTP envoyée par le client ou la cliente, telle que GET ou POST.

res_ctype

Type de contenu utilisé pour indiquer le type de média d’origine de la ressource.

cache

État du cache. Les valeurs possibles sont HIT, MISS ou PASS

status

Code d’état HTTP sous la forme d’une valeur d’entier.

res_age

Durée (en secondes) pendant laquelle une réponse a été mise en cache (dans tous les nœuds).

pop

Centre de données du serveur de cache de réseau CDN.

rules

Nom de toute règle correspondante.

Indique également si la correspondance a entraîné un bloc.

Par exemple, « match=Enable-SQL-Injection-and-XSS-waf-rules-globally,waf=SQLI,action=blocked »

Vide si aucune règle ne correspondait.

Outils de tableau de bord

Adobe fournit un mécanisme de téléchargement des outils de tableau de bord sur votre ordinateur pour ingérer les journaux de réseau CDN téléchargés via Cloud Manager. Grâce à ces outils, vous pouvez analyser le trafic afin d’obtenir les règles de filtre de trafic appropriées à déclarer, y compris les règles WAF.

Les outils de tableau de bord peuvent être clonés directement à partir du référentiel GitHub AEMCS-CDN-Log-Analysis-Tooling.

Les tutoriels contiennent des instructions concrètes sur l’utilisation des outils de tableau de bord.

Règles de démarrage recommandées

Vous pouvez copier les règles recommandées ci-dessous dans votre cdn.yaml pour commencer. Commencez en mode journal, analysez votre trafic, puis, une fois que tout est satisfaisant, passez en mode bloc. Vous pouvez modifier les règles en fonction des caractéristiques uniques du trafic en direct de votre site web.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev", "stage", "prod"]
data:
  trafficFilters:
    rules:
    #  Block client for 5m when it exceeds an average of 100 req/sec to origin on a time window of 10sec
    - name: limit-origin-requests-client-ip
      when:
        reqProperty: tier
        equals: 'publish'
      rateLimit:
        limit: 100
        window: 10
        count: fetches
        penalty: 300
        groupBy:
          - reqProperty: clientIp
      action: log
    #  Block client for 5m when it exceeds an average of 500 req/sec on a time window of 10sec
    - name: limit-requests-client-ip
      when:
        reqProperty: tier
        equals: 'publish'
      rateLimit:
        limit: 500
        window: 10
        count: all
        penalty: 300
        groupBy:
          - reqProperty: clientIp
      action: log
    # Block requests coming from OFAC countries
    - name: block-ofac-countries
      when:
        allOf:
          - { reqProperty: tier, in: ["author", "publish"] }
          - reqProperty: clientCountry
            in:
              - SY
              - BY
              - MM
              - KP
              - IQ
              - CD
              - SD
              - IR
              - LR
              - ZW
              - CU
              - CI
      action: log
    # Enable recommended WAF protections (only works if WAF is licensed enabled for your environment)
    - name: block-waf-flags-globally
      when:
        reqProperty: tier
        in: ["author", "publish"]
      action:
        type: log
        wafFlags:
          - TRAVERSAL
          - CMDEXE-NO-BIN
          - XSS
          - LOG4J-JNDI
          - BACKDOOR
          - USERAGENT
          - SQLI
          - SANS
          - TORNODE
          - NOUA
          - SCANNER
          - PRIVATEFILE
          - NULLBYTE

Tutoriels

Deux tutoriels sont disponibles.

Protéger les sites web avec des règles de filtrage du trafic (y compris des règles WAF)

Effectuez un tutoriel pour acquérir des connaissances générales et pratiques, ainsi que de l’expérience sur les règles de filtrage de trafic incluant des règles WAF.

Ce tutoriel vous guide à travers les éléments suivants :

Configuration du pipeline de configuration de Cloud Manager
Utilisation d’outils pour simuler le trafic malveillant
Déclaration des règles de filtre de trafic, y compris les règles WAF
Analyse des résultats à l’aide des outils de tableau de bord
Bonnes pratiques

Bloquer les attaques DoS et DDoS à l’aide de règles de filtrage du trafic

Découvrez en profondeur comment bloquer les attaques par déni de service (DoS) et par déni de service distribué (DDoS) à l’aide de règles de filtrage du trafic limitant le débit et d’autres stratégies.

Ce tutoriel vous guide à travers les éléments suivants :

Comprendre la protection
Recevoir des alertes lorsque les limites de débit sont dépassées.
Analyser des modèles de trafic à l’aide des outils de tableau de bord pour configurer des seuils pour les règles de filtrage du trafic limitant le débit

recommendation-more-help