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
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.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
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) 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 afficheront de nombreux événements de journalfp, fu et fcoa. Pour en savoir plus, consultez le Breached Password guide d’intervention d’Auth0.
Attaque par pulvérisation de mots de passe
Des attaquants essaient de nombreux mots de passe courants (TT1110.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 journalfp, fu et fcoa dans vos journaux.
Bourrage d’identifiants
Le bourrage d’identifiants (TT1110.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 journalfp 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), 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 journalfs, ss et signup_pwd_leak.
Détection à l’aide de l’Auth0 Management API
L’Auth0 Management API permet d’interroger les journaux du tenant à l’aide de la syntaxe de requête de recherche dans les journaux 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 , la période d’attaque potentielle est indiquée sous la formedate:[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
Pour une protection optimale contre les attaques, envisagez les stratégies suivantes :- 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.