Corregir los límites de intentos de inicio de sesión es un proyecto práctico de Hydra para quienes conocen la entrada básica de comandos y las rutas. En un servicio preparado de préstamo de equipos y reservas de talleres, los fallos repetidos pueden bloquear a otro miembro o dejar sin protección una página alternativa de acceso. Tu tarea consiste en corregir la política y demostrar, mediante solicitudes reales, la protección, el acceso normal y la recuperación natural.
El curso contiene dos laboratorios guiados y un desafío independiente. El primer laboratorio separa el contador de un miembro de las demás cuentas. El segundo hace que ambas páginas de acceso compartan el límite de la misma cuenta. El desafío combina esas decisiones en un portal de reservas con otras rutas, nombres de campos, miembros y registros. Cada unidad comienza de forma independiente. Reserva unos 55, 50 y 45 minutos, respectivamente; son estimaciones del autor que incluyen lectura y errores habituales, no tiempos medidos con principiantes.
Lo que aprenderás
Al terminar este curso, podrás:
- generar con Hydra una secuencia pequeña y autorizada de intentos reales de autenticación, distinguiendo los ajustes del cliente de un límite del servidor;
- diferenciar una contraseña rechazada, una solicitud limitada y una identidad realmente autenticada;
- modificar una política JSON breve para que los fallos repetidos se contabilicen por cuenta sin bloquear a miembros ajenos;
- asociar ambos puntos de entrada POST reales a un contador por cuenta y probar las dos direcciones;
- aplicar una política explícitamente sin reiniciar el servicio ni borrar intentos activos, y demostrar el resultado con eventos de la revisión actual;
- conservar el acceso normal de referencia y los registros originales completos, y demostrar la recuperación cuando el periodo de espera termine de forma natural.
A quién va dirigido este curso
Este curso está dirigido a principiantes en ciberseguridad que quieran evaluar y mejorar un límite de acceso manteniendo utilizable un servicio real.
Requisitos previos: Debes saber introducir comandos en un terminal, reconocer una ruta de archivo y cambiar de pestaña del navegador. No necesitas programar, instalar servicios ni tener experiencia con límites de solicitudes. El primer laboratorio explica los campos POST, las opciones de Hydra, los argumentos entre comillas, la estructura JSON y los comandos de diagnóstico necesarios. Complétalo antes del segundo; el desafío utiliza ambos mecanismos enseñados.
Entorno de aprendizaje: Cada unidad proporciona un terminal Linux preparado en Workstation y un sitio funcional Equipment Desk, o Workshop Desk en el desafío. Todas las cuentas, contraseñas, préstamos y reservas son recursos sintéticos locales de formación. Los documentos están disponibles en inglés y otros ocho idiomas; los sitios en ejecución, las etiquetas de las interfaces y la salida de los comandos permanecen en inglés.
Preguntas frecuentes
¿Tengo que instalar Hydra o crear una aplicación de autenticación?
No. El servicio local y las herramientas están preparados. Tu trabajo consiste en comprender el alcance del contador, editar y aplicar la política permitida y comprobar el resultado real. No desarrollas el servidor ni modificas la configuración de acceso de la plataforma.
¿Estoy intentando descubrir contraseñas?
No. Se proporcionan las credenciales correctas de prueba y referencia, junto con cinco candidatos deliberadamente incorrectos para la cuenta de prueba autorizada. Hydra genera fallos acotados para evaluar la respuesta del servicio. Que no se informe de ninguna contraseña no demuestra por sí solo la protección.
¿Basta con que el archivo de política sea correcto?
No. Debe coincidir con la política en ejecución, y esa revisión debe contar con pruebas reales del límite, del acceso de referencia y de la recuperación. También abrirás los registros originales de ambos miembros. Un informe o una marca de finalización no sustituyen esos resultados.
¿Son los límites pequeños una recomendación para producción?
No. Tres fallos en una ventana de 30 segundos y una espera de 12 segundos forman un contrato de formación controlado. El proyecto utiliza un proceso local con dos puntos de entrada POST; no implementa límites distribuidos, prevención del abuso a escala de producción ni protección contra todos los ataques de autenticación.
