Defending against password guessing with Hydra
How guessing shows in logs, rate limits, lockouts and automatic blocking.
Level 201 · 20 lessons · 18 practice labs
Lessons
Understanding guessing attempts
- Hydra: anatomy of a password-guessing attack: You will understand the general logic of password-guessing attacks run with tools like Hydra and the points where a defender can step in.
- How Hydra shows in logs: SSH, HTTP, FTP: You will recognise how the repeated failed login attempts made by tools like Hydra look in SSH, HTTP and FTP logs.
- Reading Hydra’s help and verbose output: You will read Hydra’s help text and verbose output to understand what a test is doing and recognise unauthorised use.
- Short task: count the guessing attempts in the lab logs and find their source
Measuring your own services
- Measuring the resilience of your own lab services with Hydra: You will use Hydra to measure how well your own lab services hold up against repeated wrong attempts and note the weak spots.
- Hydra test pace: concurrent connections and wait times: When testing your own service you will tune concurrent connections and waits, and confirm that your rate limit really kicks in.
- Password-guessing traces on non-standard ports and TLS services: You learn why moving a service to another port is not a defence, and how guessing attempts appear in logs for TLS services.
- Password-guessing traces and lockout on SMB services: You learn how repeated failed logins on a file-sharing (SMB) service appear in logs and how to lock them out.
- A password-defence audit covering many hosts and IPv6: You will audit your own server inventory so that no address, IPv6 included, is left outside lockout and rate-limit protection.
- Finding and removing default passwords (verifying with Hydra): You will find the default passwords left on devices and software in your own inventory, the first thing tools like Hydra try, and remove them.
- Saving Hydra output and resuming an interrupted test: You will save your own service test results to a file and resume an interrupted run to attach as evidence in an audit report.
- Short task: measure and report how resilient the lab services are
Defence
- Strong password policy and length against Hydra: Against tools like Hydra, you will understand why password length matters more than complexity, and be able to write a sensible password policy.
- Predictable organisation-derived passwords and a banned list: You will spot weak passwords built from the organisation’s name and year, and block them with a banned-password list.
- Account lockout and rate limiting against Hydra: You will learn how account lockout and rate limiting slow down tools like Hydra, and which settings do so without annoying real users.
- fail2ban and automatic blocking against Hydra: You will set up fail2ban to catch the repeated failed logins left by tools like Hydra in the logs and automatically block their source.
- Key-based login and multi-factor authentication against Hydra: You will see why key-based login and multi-factor authentication make password guessing with tools like Hydra useless, and apply them to your own lab service.
- Defending against password reuse after a leak: You will set up authorised checks, forced resets and alerts against leaked passwords from other sites being tried on your accounts.
- Alerting and response playbook for Hydra attempts: You will prepare a playbook that says which alert fires when a tool like Hydra is guessing passwords and what the team does, step by step.
- Capstone: harden a service against Hydra guessing attempts: In the capstone you will harden a fictional company's service against password guessing by tools like Hydra and check its logs and alerts.
Practice labs
- Count guessing attempts in the SSH log: Count the failed login attempts in the lab server's auth log and find the source address with the most attempts.
- Find guessing attempts against a web login form in the access log: Extract the burst of POST requests to the login form from Mercanköşk Otelcilik's access log and build a timeline.
- Correlate SSH, FTP and web logs and report one incident: Link attempts from the same source across three service logs and report which accounts were targeted and whether any login succeeded.
- Measure your own SSH service's resistance to guessing: Run a controlled test against the lab SSH service with a small list, measure after how many tries it blocks you and record it.
- Tune the test rate without overloading the service: Vary concurrency and wait time to measure the lab service without tripping its lockout threshold, and justify your settings.
- Report the resistance of non-standard-port and TLS services: Measure a non-standard-port SSH and a TLS web login in the lab network, resume an interrupted test and report the results.
- Find and change the default password on a management panel: Confirm the factory password still works on the lab router simulator's panel, change it and test again.
- Inventory and close default database accounts: List default or empty-password accounts in Ayçiçeği Gıda's lab database, close them and add the list to the report.
- Sweep every lab device for default passwords: Test vendor default passwords across a six-device lab network in a controlled way, close the findings and prove the fix with a retest.
- Set and verify the SSH attempt limit: Lower the per-connection attempt count and login grace time on the lab SSH server and verify the change with a controlled test.
- Add a rate limit to a web login form and measure it: Define a request limit on the lab web server's login path and compare attempts per minute before and after.
- Audit and balance the domain account lockout threshold: Measure the lab domain's lockout policy, propose a threshold that won't cause outages, apply it and retest over SMB.
- Set up automatic blocking for SSH: Write a blocking rule for SSH on the lab server and verify with controlled attempts that the source is banned and later released.
- Extend blocking to the web login and IPv6: Show that the existing blocking rules miss the web login and IPv6 addresses, close the gap and retest.
- Build an alert and response playbook for guessing attempts: Generate alerts from blocking events, write a playbook with thresholds and response steps for Sedirli Hukuk Bürosu and test it with a drill.
- Turn off SSH password login and move to keys: Set up key login for a lab user, disable password login and verify that a password login attempt is refused.
- Ban predictable passwords derived from the company name: Generate a banned list from Pusulaya Sigorta's name, cities and years, enforce it and show a password in that pattern is rejected.
- Harden a service against guessing and measure it again: Apply policy, rate limiting, automatic blocking and a second factor to the lab FTP and SSH services, then write a before-and-after report.
About this course
How guessing shows in logs, rate limits, lockouts and automatic blocking.
What you will learn
- Understanding guessing attempts
- Measuring your own services
- Defence
Prerequisites
Finishing the level 101 courses of the same path, or knowing those topics, is enough.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 201; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.