Corriger les limites de tentatives de connexion est un projet pratique avec Hydra destiné aux personnes qui connaissent la saisie de commandes et les chemins de base. Dans un service préparé de prêt de matériel et de réservation d’ateliers, des échecs répétés peuvent bloquer un autre membre ou laisser une page de connexion alternative sans protection. Vous devez corriger la politique et démontrer, à l’aide de requêtes réelles, la protection, le maintien de l’accès normal et le rétablissement naturel.
Le cours comprend deux laboratoires guidés et un défi indépendant. Le premier sépare le compteur d’un membre de ceux des autres comptes. Le second fait partager aux deux pages de connexion la même limite par compte. Le défi combine ces décisions dans un portail de réservation avec d’autres chemins, noms de champs, membres et dossiers. Chaque unité démarre indépendamment. Prévoyez environ 55, 50 et 45 minutes respectivement ; ces estimations de l’auteur incluent la lecture et les erreurs courantes, et ne proviennent pas de mesures auprès de débutants.
Ce que vous apprendrez
À la fin de ce cours, vous saurez :
- produire avec Hydra une petite série autorisée de véritables tentatives d’authentification, en distinguant les réglages du client d’une limite côté serveur ;
- différencier un mot de passe refusé, une requête limitée et une identité réellement authentifiée ;
- modifier une courte politique JSON afin de compter les échecs par compte sans bloquer les autres membres ;
- associer les deux véritables points d’entrée POST au même compteur par compte, puis tester les deux sens ;
- appliquer explicitement une politique sans redémarrer le service ni effacer les tentatives actives, et établir le résultat à partir des événements de la révision actuelle ;
- préserver l’accès normal du compte de référence et les dossiers originaux complets, puis démontrer le rétablissement après l’expiration naturelle du délai de blocage.
À qui s’adresse ce cours
Ce cours s’adresse aux débutants en cybersécurité qui souhaitent évaluer et améliorer une limite de connexion tout en maintenant un véritable service utilisable.
Prérequis : Vous devez savoir saisir des commandes dans un terminal, reconnaître un chemin de fichier et changer d’onglet dans le navigateur. Aucune expérience en programmation, installation de services ou limitation des tentatives n’est nécessaire. Le premier laboratoire explique les champs POST, les options Hydra, les arguments entre guillemets, la structure JSON et les commandes de diagnostic nécessaires. Terminez-le avant le second ; le défi mobilise les deux mécanismes enseignés.
Environnement d’apprentissage : Chaque unité propose un terminal Linux préparé dans Workstation et un site fonctionnel Equipment Desk, ou Workshop Desk pour le défi. Tous les comptes, mots de passe, prêts et réservations sont des ressources synthétiques locales de formation. Les documents sont disponibles en anglais et dans huit autres langues ; les sites en fonctionnement, les libellés des interfaces et les sorties des commandes restent en anglais.
Questions fréquentes
Dois-je installer Hydra ou créer une application d’authentification ?
Non. Le service local et les outils sont prêts. Votre travail consiste à comprendre la portée du compteur, à modifier et appliquer la politique autorisée, puis à tester le résultat réel. Vous ne développez pas le serveur et ne modifiez pas les paramètres de connexion de la plateforme.
Est-ce que je cherche à découvrir des mots de passe ?
Non. Les identifiants corrects des comptes de test et de référence sont fournis, ainsi que cinq mots de passe volontairement incorrects pour le compte de test autorisé. Hydra génère un nombre limité d’échecs afin d’évaluer la réponse du service. L’absence de mot de passe signalé ne suffit pas à prouver la protection.
Un fichier de politique correct suffit-il ?
Non. Il doit correspondre à la politique active, et cette révision doit disposer de véritables preuves de limitation, d’accès du compte de référence et de rétablissement. Vous ouvrez aussi les dossiers originaux des deux membres. Un rapport ou une marque de fin ne remplace pas ces résultats.
Ces petites limites sont-elles recommandées pour la production ?
Non. Trois échecs dans une fenêtre de 30 secondes et un blocage de 12 secondes constituent un contrat de formation contrôlé. Le projet utilise un processus local avec deux points d’entrée POST ; il n’implémente ni limitation distribuée, ni prévention des abus à l’échelle de la production, ni protection contre toutes les attaques d’authentification.
