Règles de filtre de trafic incluant des règles WAF traffic-filter-rules-including-waf-rules
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 dans des programmes de production (hors sandbox). 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é.
Organisation de cet article how-organized
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 traffic-protection-overview
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 du pipeline de configuration de Cloud Manager. Outre les règles de filtrage 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 encore les 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 filtrage du trafic appelées règles WAF.
Processus suggéré suggested-process
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 setup
-
Créez un fichier
cdn.yaml
avec un ensemble de règles de filtrage du trafic, y compris les règles WAF.code language-none 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 sur1
. -
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.
-
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.
-
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 fichiercdn.yaml
placé quelque part en dessous. Voir la section Utiliser des pipelines de configuration.
Syntaxe des règles de filtrage de trafic rules-syntax
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.
string
Condition
{ <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
RateLimit
Vous trouverez ci-dessous une section distincte décrivant la syntaxe rateLimit, ainsi que des exemples.
Structure de condition condition-structure
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> }
array[Condition]
array[Condition]
Getter
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.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 entreauthor
,preview
oupublish
.domain
: renvoie la propriété de domaine (telle que définie dans l’en-têteHost
) en minuscules.clientIp
: renvoie l’adresse IP du client ou de la cliente.clientCountry
: renvoie un code à deux lettres (Symbole d’indicateur régional) qui identifie le pays dans lequel se trouve le client.
string
string
string
string
application/x-www-form-urlencoded
.Prédicat
string
string
string
string
string
string
array[string]
array[string]
boolean
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édicatsin
etnotIn
. 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 action-structure
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 :
wafFlags
(facultatif), alert
(facultatif)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).
status, wafFlags
(facultatif et mutuellement exclusif), alert
(facultatif)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).
wafFlags
(facultatif), alert
(facultatif)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 waf-flags-list
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 :
/bin/
CMDEXE
lors de la désactivation du faux positif sur /bin
en raison de l’architecture AEM./foo/./bar
est normalisé en /foo/bar
)..htaccess
ou un fichier de configuration susceptible de faire fuiter des informations sensibles.Considérations considerations
-
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 examples
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’adresse IP 192.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 ratelimit-structure
Exemples ratelimiting-examples
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 cve-rules
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 traffic-filter-rules-alerts
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.
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 traffic-spike-at-origin-alert
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 cdn-logs
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 cdn-log-format
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.
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 dashboard-tooling
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 recommended-starter-rules
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 tutorial
Deux tutoriels sont disponibles.
Protéger les sites web avec des règles de filtrage du trafic (y compris des règles WAF) tutorial-protecting-websites
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 tutorial-blocking-DDoS-with-rules
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