Phase 1 showed the leaks: a login readable over Telnet, a password readable over plain HTTP, and one password that opened every door. This phase closes each one, by hand, and then confirms it’s closed.
Nothing here is baked into the lab. You do the hardening, the same way you’d do it on a real host.
You need: Phase 1 finished (its firewall loaded). Phase 2 isn’t required.
| Step | What you'll do | Time |
|---|---|---|
| 0 | Start from Phase 1's end Rebuild the lab, load Phase 1's firewall, and confirm the leaks are still open so the fixes have a clear before and after. | 5 min |
| 1 | Remove Telnet Take the plain-text Telnet service off the server for good. | 5 min |
| 2 | Move the web server to HTTPS Give the web server a certificate, serve the login over HTTPS, and confirm the password no longer shows on the wire. | 15 min |
| 3 | SSH on keys, not passwords Give client-a an SSH key, trust it on the server, and turn password logins off. | 15 min |
| 4 | A separate login for each service Give the web its own login, so the account that opens the web is not the account that opens the shell. | 10 min |
| 5 | Recheck the leaks Go back to the three Phase 1 leaks and confirm each one is now closed. | 10 min |
| 6 | Container hardening (shown, not a task) Understand the hardening a production build would add, and where this lab stops on purpose. | 5 min read |
| 7 | Check your work, and save it as code Confirm every leak is closed, then save the firewall rules so Phase 3 starts the same way every time. | 10 min |
| next | Phase 4: modern remote access |