Bootcamp hub · Prev: Module 8
Learning goals
- Apply a defensive baseline on a lab VM, in an order that doesn’t lock you out
- Explain SSH key-only auth and least privilege in plain terms, the way you would in an interview
- Inventory listening ports and justify, in one sentence each, why every open port needs to be open
Required posts
- SSH hardening checklist — the order of operations that avoids locking yourself out.
- Users & permissions — the foundation everything else in this module assumes.
- API security basics — the same discipline, applied to services instead of shells.
- OWASP API Top 10 ops view — what an ops person, not an appsec specialist, should actually watch for.
- fail2ban vs security groups — two different layers that people mix up.
Baseline checklist (defensive only)
This is a floor, not a ceiling. Every item on it is something an automated scanner or attacker will check for shortly after finding your IP address, often within hours, not months.
- Documented patch cadence. Even “every Sunday night” beats “whenever I remember”, because it turns a vague intention into something you can be asked about and answer.
- Unique human accounts, no shared root SSH. A shared root login means an audit log that cannot say who did what, which turns every incident into a guessing game.
- SSH keys over passwords. A password-authenticated SSH server on the public internet gets thousands of automated guesses a day. A key cannot be brute-forced in any practical sense.
- Host firewall aligned with cloud security groups. Cloud security groups protect the network path; a host firewall protects the box even if a security group is ever misconfigured. Use both, and make sure they agree with each other.
- Only required ports exposed. A port you cannot explain in one sentence is a port you should close, or at least be able to justify to yourself before someone else asks.
- Readable logs with retention. Logs you cannot search are decoration. Logs that rotate out after a day are gone exactly when an incident review needs them.
- Backups tested, per Module 7. A security baseline without a tested restore is a plan to lose data slowly instead of quickly.
Lab ethics
Practice only on systems you own, or that you have written permission to test. No scanning random hosts, and no exploit drills against shared infrastructure you do not control. Everything in this bootcamp is framed around defence: hardening your own systems, reading your own logs, understanding what an attacker looks for so you can close it first. If your interest runs toward offensive security, that is a legitimate and valuable specialism, but it needs its own authorised scope, its own legal groundwork, and its own learning path separate from this one.
Lab
- Harden SSH on a lab VM while deliberately keeping a second way in, such as your cloud provider’s console access, so a mistake in
sshd_configcannot lock you out entirely. - Find and remove a world-writable directory you created earlier in this bootcamp. Explain to yourself why it was a risk before you delete it, not just that a checklist said to.
- Inventory every listening port with
ss -ltunp(theupulls in UDP alongside TCP) and write one line per port explaining what it is and why it needs to be reachable. Listening locally isn’t the same as reachable from outside — cross-check against your firewall and security group rules too. - Write a one-page “new VM baseline” you could hand to a colleague, covering the seven checklist items above in your own words.
FAQ
How long should this module take?
Plan one focused evening for reading plus one for the lab. The SSH hardening step deserves care: rushing it is exactly how people lock themselves out of a real server.
Do I need production access?
No. Use your lab. Every drill in this module is designed to teach the reasoning on a machine where a mistake costs nothing.