Avant de commencer
Vous devez configurer Brute Force Protection et mettre en place les logs et les alertes de seuils.
Repérer les événements de journal pertinents
Types d’événements de journal
Types d’événements de journal
f: Échec de connexion de l’utilisateurfu: Échec de connexion de l’utilisateur en raison d’un nom d’utilisateur invalidefp: Échec de connexion de l’utilisateur en raison d’un mot de passe invalidepwd_leak: Tentative de connexion avec un mot de passe compromis par une fuitesignup_pwd_leak: Tentative d’inscription avec un mot de passe compromis par une fuitelimit_wc: Adresse IP bloquée pour >10 tentatives de connexion échouées sur un seul comptelimit_sul: Utilisateur bloqué pour >20 connexions par minute à partir de la même adresse IPlimit_mu: Adresse IP bloquée pour >100 tentatives de connexion échouées ou >50 tentatives d’inscriptionfcoa: Authentification inter-origines échouéescoa: Authentification inter-origines réussie
Devinette de mots de passe
fp, fu et fcoa. Pour en savoir plus, consultez le Breached Password guide d’intervention d’Auth0.
Attaque par pulvérisation de mots de passe
fp, fu et fcoa dans vos journaux.
Bourrage d’identifiants
fp et pwd_leak.
Attaques d’inscription
fs, ss et signup_pwd_leak.
Détection à l’aide de l’Auth0 Management API
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 :
Stratégies d’atténuation
- Activez 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.
- 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, pour bloquer les IP abusives, les numéros de système autonome, les emplacements géographiques, les clients TLS ou les éléments d’en-tête HTTP comme les chaînes
user-agent, et envisagez d’utiliser un proxy inverse. - Resserrez les seuils de Brute Force et de Suspicious IP 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 (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
fcoaetscoafréquents afin d’éliminer une surface d’attaque inutilisée. - Appliquez le step-up MFA aux comptes compromis, jusqu’à exiger 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 ou Webauthn 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 de Twilio, lorsque vous utilisez la MFA par SMS/appel vocal.