Lab Setup (Kali / HTB)

// SCENARIO — building a personal / team security lab for AUTHORISED training, CTFs,
// and tool evaluation. Focus on defensive engineering of the lab itself.

// ─── 1) Isolation first — the cardinal rule ────────────────────
//
// • Lab traffic MUST NOT reach the open internet without your explicit intent
// • Lab traffic MUST NOT reach corporate networks
// • Tools that scan ranges MUST be configured for the lab subnet only
//
// Network options (best to worst):
//   1. Air-gapped physical lab (separate router, no Wi-Fi backhaul)
//   2. VMs on a host-only / internal virtual network
//   3. Cloud VPC with NO IGW / NAT (default-deny outbound; SSH bastion only)
//   4. Container network on a personal laptop (least isolated)

// ─── 2) Recommended layout — VMware / VirtualBox / Proxmox ────
//
//   Host
//    └── Internal Network (vmnet1 / 'host-only')
//        ├── Attacker VM (Kali Linux / Parrot)
//        ├── Target: DVWA / Juice Shop / Metasploitable
//        ├── Target: Windows Server (pre-built lab images)
//        └── Optional: pfSense router as a NAT firewall to control outbound
//
// No DHCP/DNS leak to the host; the only way out is via the firewall VM you control.

// ─── 3) Free intentionally-vulnerable targets ──────────────────
//
// Web app:    OWASP Juice Shop, DVWA, WebGoat, bWAPP, Mutillidae
// Network:    Metasploitable 2 / 3, vulnhub VMs (rated by difficulty)
// Windows:    GOAD (Game of Active Directory), TestLab from PowerShell-Suite
// Cloud:      flaws.cloud, AWSGoat, IAM Vulnerable
// Crypto:     CryptoPals challenges
// Container:  Bad Pods, KubeGoat
// Mobile:     OWASP MASVS reference apps
//
// Pull them in your lab and snapshot before touching.

// ─── 4) Snapshot before every exercise ────────────────────────
// • Take a clean snapshot AFTER setup, BEFORE the first scan
// • Snapshot the attacker VM too — so your toolchain state is reproducible
// • Rollback per session = no leftover artefacts, no drift
//
// VirtualBox:  VBoxManage snapshot 'VM' take 'baseline'
// VMware:      vmrun snapshot 'VM.vmx' baseline
// Proxmox:     qm snapshot 100 baseline

// ─── 5) Hosting the lab safely on the cloud ───────────────────
//
// Cloud labs are convenient but risky if misconfigured.
//
// AWS example:
//   • Separate AWS account (use Organizations Sub-account)
//   • VPC with NO internet gateway by default
//   • SSM Session Manager for shell access (no public SSH)
//   • Security Groups: deny all egress except whitelisted endpoints
//   • VPC Flow Logs + CloudTrail enabled for incident review
//   • Auto-stop budgets — never leave compute running
//
// Don't run a scanner against another AWS account, ANYONE'S production, or other Internet IPs.
// Most cloud providers have explicit penetration-test policies — read them before scanning.

// ─── 6) Rules of Engagement (RoE) — even in personal labs ─────
//
// Write down (even one paragraph in a README):
//   • What systems are in scope (IP/CIDR)
//   • What activities are permitted (port scan, brute-force, file write)
//   • What activities are FORBIDDEN (kernel exploits that crash host, modifying host)
//   • Time window (don't leave loud scans running overnight)
//   • Stop conditions (host CPU > 90% for >5 min)
//
// For team labs / CTFs:
//   • Player rules (no DoS, no sharing flags)
//   • Out-of-scope (admin infrastructure, monitoring stack)
//   • Reporting flow (where to file vuln reports if found)

// ─── 7) Authorised testing on REAL systems ────────────────────
//
// • Bug bounty programs (HackerOne, Bugcrowd, Intigriti) — explicit scope + safe harbour
// • Customer engagements — signed contract + RoE
// • Internal company red team — written authorisation
//
// Never test outside an explicit grant of permission. Even with intent to help:
//   • Computer Fraud and Abuse Act (US) / Computer Misuse Act (UK) / similar laws elsewhere
//   • DMCA Section 1201 carve-outs are narrow
//   • Civil liability if you crash a service
//   • Career-ending if you 'fix and tell' to an organisation that didn't ask

// ─── 8) Common tools — pick a baseline ────────────────────────
//
// Recon:        nmap, masscan, amass, gobuster, ffuf, naabu
// Web:          burpsuite, OWASP ZAP, nuclei, sqlmap, dirsearch
// Net:          wireshark, tcpdump, scapy, responder
// Crypto:       hashcat, john, openssl, cryptopals
// Exploit:      metasploit framework, sliver, mimikatz (in lab only)
// Forensics:    volatility3, autopsy, plaso, ftk imager
//
// Kali / Parrot ship most of these pre-installed. Don't run them outside the lab.

// ─── 9) Capture-the-flag platforms — safe practice ────────────
//
// • HackTheBox / TryHackMe — VPN into isolated networks; lawful and sponsored
// • PicoCTF — beginner-friendly; education-focused
// • PortSwigger Web Security Academy — free + curated
// • OverTheWire — UNIX-style wargames
// • CryptoHack — applied cryptography
// • Pwnable.kr / pwn.college — binary exploitation
// • PentesterLab — guided exercises
//
// Use these for skill building; build your home lab for tools you can't run on shared infra.

// ─── 10) Recording + reproducibility ──────────────────────────
//
// • Tmux + asciinema to record sessions — great for write-ups
// • Use one notebook PER engagement (Obsidian, Joplin, Cherrytree)
// • Commands go into the notebook BEFORE you run them (intent + expected outcome)
// • Screenshots into the notebook — Flameshot / Shottr
// • Final write-up = the notebook + raw outputs + your conclusions

// ─── 11) Privacy + opsec inside the lab ───────────────────────
//
// • Use throwaway accounts for any external account creation
// • Don't reuse personal passwords in test users
// • Don't push lab notes to public git without redacting
// • Disable any 'phone home' telemetry on tools running in the lab
// • Treat lab VMs as compromised — never connect personal storage / SSH keys

// ─── 12) Continuing education — staying current ──────────────
//
// • Newsletters: tl;dr sec, Lazy Pentest, AppSec Ezine
// • Conferences: DEFCON, BSides, OWASP Global, recon.cx
// • Blogs: PortSwigger Research, Project Zero, watchTowr
// • CVE feeds via OSV.dev, GitHub Security Advisories
// • Certifications (if helpful for your role): OSCP, OSCE3, GIAC, CRTP
//
// Build a habit of reading post-mortems and CTF write-ups — that's where intuition comes from.

// ─── 13) Reporting lessons home ───────────────────────────────
//
// For each lab session:
//   • What was the goal?
//   • What did you try, in order?
//   • What worked + why?
//   • What detection signals did you trigger? (would a SOC see this?)
//   • What defensive control would have stopped you?
//
// The last two questions transform 'I broke into a thing' into actionable defense.

// ─── 14) Common bugs / mistakes ──────────────────────────────
//
// • Scanning a target IP that turns out to be on the corporate or carrier network
//   → instant abuse complaint; isolate FIRST, scan SECOND
// • Forgetting to disable host-only network when joining VPN → lab traffic leaks
// • Cloud lab left running over the weekend → $$$ + accidental exposure
// • Pushing lab notes (including target IPs / credentials) to GitHub → secret scan flags it
// • Reusing personal SSH key in attacker VM → that key now exists on the 'pwned' targets too
// • Tool installs leak telemetry → block egress at firewall VM
// • CVE article suggests scanning the real product to test — don't; spin up a local copy
// • 'I'll just port scan my friend's site to show them' — illegal in most jurisdictions; ask first

# Build a SAFE lab — never on someone else's network.
# Common starter stacks:
#   - Kali Linux or Parrot OS in a VM
#   - Hack The Box (HTB), TryHackMe (THM) — legal targets, pre-authorised
#   - VulnHub VMs run offline
#   - Local: Juice Shop, DVWA, Metasploitable in an isolated subnet