> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Guide d’intervention pour utiliser la fonctionnalité de surveillance Brute Force d’Auth0 dans le Security Center
# Guide d’intervention Brute Force Protection
Vous devez configurer [Brute Force Protection](/docs/fr-ca/secure/attack-protection/brute-force-protection) et mettre en place les logs et les [alertes de seuils](/docs/fr-ca/secure/security-center/security-alerts).
Des attaquants peuvent recourir à des techniques de force brute ([TT1110](https://attack.mitre.org/techniques/T1110/)) pour accéder à des systèmes sensibles. Bien que souvent peu sophistiquées, la plupart des attaques par force brute sont faciles à contrer, mais leur défense peut nécessiter beaucoup de ressources. Vous trouverez ci-dessous quelques techniques courantes d’attaque par force brute, ainsi que des indications pour détecter et analyser des attaques potentielles visant votre tenant.
### Repérer les événements de journal pertinents
Avant de bloquer des adresses IP ou de réagir autrement à une attaque, repérez les compromissions en passant au crible les messages de journal pertinents. L’attaque peut provenir d’un nombre limité d’adresses IP, d’un seul numéro de système autonome ou d’un seul pays.
Les types d’événements de journal ci-dessous sont pertinents pour enquêter sur une attaque par force brute. Ils se trouvent dans les [journaux du tenant Auth0](/docs/fr-ca/secure/attack-protection/view-attack-protection-events).
1. `f`: Échec de connexion de l’utilisateur
2. `fu`: Échec de connexion de l’utilisateur en raison d’un nom d’utilisateur invalide
3. `fp`: Échec de connexion de l’utilisateur en raison d’un mot de passe invalide
4. `pwd_leak`: Tentative de connexion avec un mot de passe compromis par une fuite
5. `signup_pwd_leak`: Tentative d’inscription avec un mot de passe compromis par une fuite
6. `limit_wc`: Adresse IP bloquée pour >10 tentatives de connexion échouées sur un seul compte
7. `limit_sul`: Utilisateur bloqué pour >20 connexions par minute à partir de la même adresse IP
8. `limit_mu`: Adresse IP bloquée pour >100 tentatives de connexion échouées ou >50 tentatives d’inscription
9. `fcoa`: Authentification inter-origines échouée
10. `scoa`: Authentification inter-origines réussie
### Devinette de mots de passe
Des attaquants ayant peu de connaissances préalables des politiques de votre tenant peuvent tenter à répétition de deviner des mots de passe ([TT1110.001](https://attack.mitre.org/techniques/T1110/001/)) pour accéder à des comptes. Comme ils ne font qu’essayer de déterminer si un utilisateur existe et quel est son mot de passe, vos [journaux Auth0](/docs/fr-ca/deploy-monitor/logs/log-event-type-codes) afficheront de nombreux événements de journal `fp`, `fu` et `fcoa`. Pour en savoir plus, consultez le [Breached Password guide d’intervention](/docs/fr-ca/secure/attack-protection/playbooks/breached-password-playbook) d’Auth0.
### Attaque par pulvérisation de mots de passe
Des attaquants essaient de nombreux mots de passe courants ([TT1110.003](https://attack.mitre.org/techniques/T1110/003/)) pour accéder à des comptes d’utilisateur légitimes. Ces tentatives déclenchent souvent les mécanismes de protection d’Auth0 contre les attaques par force brute et génèrent de nombreux événement de journal `fp`, `fu` et `fcoa` dans vos journaux.
### Bourrage d’identifiants
Le bourrage d’identifiants ([TT1110.004](https://attack.mitre.org/techniques/T1110/004/)) est particulièrement efficace contre les tenants qui utilisent des mots de passe, sans facteurs supplémentaires. En exploitant des fuites de mots de passe et en tentant de se connecter au compte d’une victime à l’aide d’un dictionnaire de mots de passe divulgués, les attaques de bourrage d’identifiants génèrent des événements de journal `fp` et `pwd_leak`.
### Attaques d’inscription
Les attaquants peuvent tenter de créer un grand nombre de comptes dans un court laps de temps dans le cadre d’une attaque d’énumération de noms d’utilisateur ([T1087](https://attack.mitre.org/techniques/T1087/)), où ils cherchent à déterminer si un compte d’utilisateur existe dans votre tenant, ou dans le cadre de campagnes de fraude à l’inscription. L’objectif est de créer de nombreux comptes pour profiter d’incitatifs à l’inscription ou de créer des comptes anciens en vue d’attaques ultérieures. Les attaques d’inscription génèrent les événements de journal `fs`, `ss` et `signup_pwd_leak`.
### Détection à l’aide de l’Auth0 Management API
L’[Auth0 Management API](/docs/fr-ca/deploy-monitor/logs/retrieve-log-events-using-mgmt-api) permet d’interroger les journaux du tenant à l’aide de la [syntaxe de requête de recherche dans les journaux](/docs/fr-ca/deploy-monitor/logs/log-search-query-syntax) pour les types de journaux compris dans la plage de temps voulue. Pour des cas d’utilisation plus avancés, vous pouvez utiliser des outils d’agrégation de journaux comme des entrepôts de données ou des SIEM en tirant parti des flux de journaux Auth0.
Lorsque vous utilisez l’Auth0 management API, la période d’attaque potentielle est indiquée sous la forme `date:[startdate to enddate]` au format `YYYY-MM-DD`. Par exemple, `2024-10-01`. Utilisez `*` pour représenter la date actuelle.
En limitant la période visée à une fenêtre d’attaque potentielle, vous pouvez récupérer tous les événements de journal du type recherché. Voici un exemple de requête qui cherche les attaques par force brute du 1er octobre 2024 à aujourd’hui :
```text wrap lines theme={null}
date:[2024-10-01 TO *] AND (type:"f" OR type:"fu" OR type:"fp" OR type:"pwd_leak" OR type:"limit_wc" OR type:"limit_sul" OR type:"limit_mu" OR type:"fcoa")
```
Pour une analyse approfondie ou pour faire correspondre les activités de connexion avec des applications en dehors d’Auth0, activez la diffusion des journaux vers l’outil externe de votre choix. Consultez la [documentation de la Management API](https://auth0.com/docs/api/management/v2/logs/get-logs) pour comprendre comment extraire un sous-ensemble des événements de journal de votre tenant à des fins d’analyse.
#### Stratégies d’atténuation
Pour une protection optimale contre les attaques, envisagez les stratégies suivantes :
* Activez [Breached Password Detection](/docs/fr-ca/secure/attack-protection/breached-password-detection) ou Credential Guard pour vous protéger contre les identifiants compromis avec un minimum de friction pour l’utilisateur, en gardant à l’esprit qu’aucun des deux ne protège contre les attaques par dictionnaire.
* Activez CAPTCHA pour un ou plusieurs flux et augmentez sa fréquence au besoin, mais n’oubliez pas que CAPTCHA est un moyen de dissuasion, pas une solution.
* Changez de fournisseur CAPTCHA si des attaquants contournent votre CAPTCHA actuel, ou envisagez de migrer vers Auth Challenge d’Auth0 ou un autre [fournisseur pris en charge](/docs/fr-ca/secure/attack-protection/bot-detection/configure-captcha).
* Désactivez temporairement la création de comptes pour tout le monde, y compris les acteurs malveillants.
* Modifiez les règles du pare-feu de votre application web chez votre fournisseur de périphérie, ou utilisez des [listes de contrôle d’accès du tenant](/docs/fr-ca/secure/tenant-access-control-list), pour bloquer les IP abusives, les numéros de système autonome, les emplacements géographiques, les [clients TLS](/docs/fr-ca/customize/custom-domains/self-managed-certificates/tls-ssl) ou les éléments d’en-tête HTTP comme les chaînes `user-agent`, et envisagez d’utiliser un [proxy inverse.](/docs/fr-ca/customize/custom-domains/self-managed-certificates#configure-reverse-proxy)
* Resserrez les seuils de [Brute Force](/docs/fr-ca/secure/attack-protection/brute-force-protection) et de [Suspicious IP](/docs/fr-ca/secure/attack-protection/suspicious-ip-throttling) afin de réduire les limites de connexions autorisées et d’atténuer les attaques par force brute.
* Si votre application ne dépend pas des endpoints d’[authentification inter-origines](/docs/fr-ca/authenticate/login/cross-origin-authentication) (par exemple, si vous utilisez uniquement Universal Login, ou si vos flux embedded utilisent directement le Token endpoint OAuth 2.0), désactivez ces endpoints lorsque vous observez des événements `fcoa` et `scoa` fréquents afin d’éliminer une surface d’attaque inutilisée.
* Appliquez le [step-up MFA](/docs/fr-ca/secure/multi-factor-authentication/step-up-authentication) aux comptes compromis, jusqu’à exiger MFA pour les comptes potentiellement compromis.
* Migrez vers des options MFA plus robustes en remplaçant la MFA par SMS ou par appel vocal par [OTP](/docs/fr-ca/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-otp-notifications-for-mfa) ou [Webauthn](/docs/fr-ca/secure/multi-factor-authentication/fido-authentication-with-webauthn/configure-webauthn-device-biometrics-for-mfa) afin d’atténuer le SMS pumping ou la fraude aux appels surtaxés.
* Mettez en place des protections antifraude de sécurité pour votre fournisseur SMS/appel vocal, comme [Preventing Fraud in Verify](https://www.twilio.com/docs/verify/preventing-toll-fraud) de Twilio, lorsque vous utilisez la MFA par SMS/appel vocal.