Quand votre page de connexion devient la ligne de front : leçons tirées d'une attaque DDoS

En tant qu'entreprise SaaS spécialisée dans la gestion des identités et des accès (IAM), notre travail reste souvent dans l'ombre, jusqu'à ce qu'un problème survienne. Aujourd'hui, je souhaite vous expliquer comment nous gérons la sécurité au niveau de la première couche commune à tous les systèmes IAM : la page de connexion. Plus précisément, je vais vous présenter un incident que nous avons géré chez Cloud-IAM, où nous fournissons une solution Keycloak gérée, et partager quelques informations sur la sécurisation des systèmes d'authentification contre les menaces DDoS en constante évolution.

Le défi : la sécurité IAM au-delà des MAU

Bon nombre de nos clients sont des passionnés de technologie et des petites entreprises qui souhaitent éviter la complexité liée à la configuration et à la maintenance de Keycloak. Nos clients plus importants, en revanche, exigent une certaine résilience. Cependant, la résilience est souvent mesurée en termes d'utilisateurs actifs mensuels (MAU), sans tenir pleinement compte de l'exposition de leur service.

Prenons l'exemple de deux entreprises hypothétiques :

• Entreprise A : un SaaS pour l'analyse de plants avec un nombre élevé de MAU.
• Entreprise B : une plateforme IoT gérant des caméras de sécurité.

Bien que l'entreprise A ait plus de MAU, l'entreprise B est probablement plus exposée aux attaques en raison de la nature de son infrastructure. Ce facteur d'exposition est rarement pris en compte, mais il joue un rôle essentiel dans la sécurité IAM.

Les attaques sont inévitables, alors nous nous adaptons

Les cyberattaquants exploitent la même logique et les mêmes processus que les utilisateurs normaux, ce qui les rend difficiles à détecter. Plus ils disposent d'informations, mieux ils peuvent se faire passer pour de vrais utilisateurs et contourner les systèmes de détection. De nombreuses entreprises s'appuient sur la limitation du débit des équilibreurs de charge ou les pare-feu de bas niveau, qui constituent tous deux d'excellentes défenses initiales. Cependant, les pirates ont évolué au-delà de ces mesures.

Chez Cloud-IAM, nous adoptons une approche multicouche pour atténuer les attaques :

1. Filtrage et journalisation avancés des serveurs web pour l'apprentissage futur.
2. Filtrage des paquets IP pour atténuer les attaques à un stade précoce.
3. Attribution dynamique de règles en fonction des domaines spécifiques des clients.
4. Protection par pare-feu d'application web (WAF).
5. Détection des règles basée sur l'IA (en cours) pour automatiser et optimiser les règles de sécurité en fonction des menaces en temps réel.

Étude de cas : l'attaque pendant un mois contre un client Cloud-IAM

Tous nos clients fonctionnent selon deux cycles de vie distincts :

• Le cycle de vie du produit client (par exemple, comment un service s'intègre à un IAM pour l'authentification et la sécurité).
• Le cycle de vie du produit IAM (par exemple, les mises à jour, les correctifs, les patchs de sécurité et la résilience de l'infrastructure).

L'un de nos clients, une plateforme SaaS largement utilisée, subit régulièrement des attaques DDoS en raison de sa forte exposition et de ses millions d'utilisateurs actifs mensuels. Dans ce cas particulier, le client avait mis en place une politique de restriction IP spécifique qui a influencé le déroulement de l'attaque.

L'un des principaux défis pour ce client est qu'il doit augmenter sa capacité d'infrastructure à l'avance afin de gérer efficacement les charges élevées d'utilisateurs. Cela signifie qu'il doit anticiper les pics de demande et ajuster la capacité de son infrastructure avant que la charge n'arrive. Par exemple, avant des événements majeurs tels qu'une mise à jour SSO, il anticipe et se prépare à la reconnexion d'un million d'utilisateurs dans un laps de temps très court. Si cela améliore l'expérience utilisateur, cela complique également la détection des attaques, car le trafic malveillant peut se confondre avec l'activité légitime des utilisateurs, ce qui rend beaucoup plus difficile la distinction entre un comportement normal et une attaque.

Cette complexité opérationnelle nécessitait une réponse de sécurité hautement personnalisée.

L'incident : une attaque par énumération furtive et persistante

Phase 1 : les premiers signes de problèmes

• Début janvier, nous avons identifié une erreur de configuration dans Keycloak, qui a révélé des inefficacités dans la manière dont notre système traitait les tentatives d'énumération.
• Les attaquants ont exploité cette faille en envoyant des requêtes à un rythme tel qu'il a saturé le pool de connexions, empêchant ainsi l'établissement de nouvelles connexions.
• Nos systèmes ont détecté le problème avant qu'il n'ait un impact sur le client, ce qui nous a permis d'intervenir de manière proactive.
• Nous avons corrigé la situation avant qu'elle ne dégénère en une impasse totale, garantissant ainsi la stabilité du système.
• En moins de 24 heures, nous avons déployé un correctif pour empêcher que cette vulnérabilité spécifique ne soit à nouveau exploitée.

Phase 2 : la défense silencieuse

• Après le problème initial, les pirates ont intensifié leurs efforts, générant plus de 8 000 connexions par minute.
• Notre système a automatiquement détecté et bloqué ces tentatives de faible niveau, empêchant ainsi tout impact significatif.
• Aucune intervention manuelle n'a été nécessaire, car les blocages automatisés ont efficacement atténué cette phase de l'attaque.

Phase 3 : la tempête s'intensifie

• Deux semaines plus tard, l'attaque s'est intensifiée, devenant trois fois plus importante et durant 100 fois plus longtemps que la phase précédente.
• L'attaque a atteint 2 500 tentatives d'authentification par minute, soit une diminution par rapport à la phase précédente, mais s'est maintenue pendant plus de 12 heures.
• Malgré la nature prolongée de l'attaque, nos systèmes de surveillance ont détecté le schéma tôt, ce qui nous a permis de prendre des mesures rapides.
• Aucune intervention manuelle n'a été nécessaire, car les interdictions automatisées ont efficacement atténué cette phase de l'attaque.

Qu'est-ce qui a rendu cette attaque unique ?

En analysant la stratégie des attaquants, nous avons observé un changement dans leur approche au fil des phases. Au départ, dans la phase 1, ils ont expérimenté des tentatives limitées mais ciblées. Dans la phase 2, ils ont pensé qu'en submergeant le système d'un nombre élevé de requêtes (8 000 par minute), ils parviendraient à percer les défenses. Cependant, cela n'a conduit qu'à des interdictions rapides.

À la phase 3, ils ont changé de stratégie, optant pour une attaque prolongée plutôt qu'une attaque intense et ponctuelle. Même si le taux de requêtes est tombé à 2 500 par minute, le nombre total de requêtes au cours de cette phase a été nettement plus élevé en raison de l'attaque soutenue pendant 12 heures.

Ce changement est évident dans les visualisations suivantes :

• Taux de requêtes pendant les phases de l'attaque DDoS (à gauche) : illustration de la variation des taux de requêtes au cours de chaque phase.
• Nombre total de requêtes pendant les phases de l'attaque DDoS (à droite) : illustration de l'impact beaucoup plus important de la dernière phase en termes de volume, malgré une intensité de requêtes moindre.

Comment nous avons géré la situation ?

1. Apprentissage : notre pile de surveillance a signalé une anomalie.
2. Détection : nous avons identifié l'attaque comme une tentative d'énumération.
3. Bloquer : une approche traditionnelle de pare-feu de bas niveau n'aurait pas fonctionné en raison de
4. la rotation rapide des adresses IP, nous avons donc dû analyser le contexte en temps réel.
5. Activer : nous avons donné à notre équipe et à notre client les moyens de réagir de manière proactive.
6. Partager : nous avons documenté nos conclusions en interne et en externe (d'où cet article !).

Et ensuite ? Une défense basée sur l'IA

Notre objectif n'est pas de devenir un système complet de gestion des informations et des événements de sécurité (SIEM), mais d'intégrer des protections plus intelligentes. Nous développons actuellement un outil basé sur l'IA qui ajuste dynamiquement les règles de sécurité en fonction des demandes des utilisateurs, ce qui permet :

• Une détection plus rapide des modèles d'attaque.
• Des réponses automatisées adaptées aux besoins spécifiques des clients.
• Une meilleure protection sans blocage inutile des utilisateurs légitimes.

Conclusion

La sécurité IAM ne consiste pas seulement à arrêter les attaquants, mais aussi à apprendre, à s'adapter et à se renforcer. L'attaque à laquelle nous avons été confrontés, en janvier 2025, a confirmé que les défenses traditionnelles ne suffisent pas. Une approche multicouche et contextuelle est essentielle pour les systèmes IAM modernes, en particulier dans les environnements à haut risque.

Chez Cloud-IAM, nous sommes fiers de notre résilience, mais la sécurité est un défi en constante évolution. Nous affinons continuellement nos défenses, en tirant les leçons de chaque incident. Il y a toujours matière à amélioration, et nous restons humbles dans notre engagement à garder une longueur d'avance sur les menaces émergentes.

Si vous pensez que nous pouvons nous améliorer dans certains domaines ou si vous souhaitez renforcer la sécurité de votre propre système, n'hésitez pas à nous contacter. Nous sommes toujours ouverts à la collaboration et aux nouvelles idées.

Si vous gérez un service IAM, posez-vous la question suivante : dans quelle mesure protégez-vous votre page de connexion ?