Lab 02 — Range Containment Verifier

Difficulty: 2/5 | Runs locally: yes, standard library only

Pairs with the Phase 00 WARMUP Chapter 6 (network isolation) and the HITCHHIKERS-GUIDE ("Proving Containment").

Why This Lab Exists (Purpose & Goal)

"I used a VM" is not a containment design. A virtual machine is just an operating system that, by default, often has full LAN and internet access through the host — so a vulnerable or malware-laden guest can reach your home network, your employer's network, the cloud metadata endpoint that hands out credentials, or your own management tooling. The purpose of this lab is to make containment a property you can prove with code, not a checkbox you assume. You build the verifier that takes a lab's declared network policy and reports two kinds of failure: a required telemetry flow that is missing (you'd be blind), and a forbidden path that is reachable (you'd be exposed).

The Concept, In the Weeds

Isolation means the only paths that exist are the ones you intend, and you have proven the others are absent. That last clause is the hard part: a diagram claims isolation; only an explicit check proves it. The model has zones — management, attacker, victim, telemetry, mobile, Kubernetes, cloud-proxy, and an OT simulation — and an allow-list of (source, destination, port) flows. The verifier asserts two opposite things at once:

  • Positive obligations — every zone must be able to ship logs to telemetry. A missing flow here is a silent blind spot an attacker exploits (you can't investigate what you never recorded).
  • Negative obligations — the victim must not reach the LAN or the internet; the attacker must not reach the management plane; the OT simulation must not reach the internet. A reachable forbidden path is a containment breach.

The deep idea is defense in depth across independent layers (host firewall → isolated virtual switch → lab router → per-workload egress policy). Any single layer can be misconfigured; independent layers turn one mistake into a near-miss instead of a breach. The verifier is the test that catches the mistake before a live exercise does.

Why This Matters for Protecting the Company

A contained range is the difference between "we safely studied a malware sample" and "we detonated ransomware on the corporate network." The same reasoning protects production: the experiment plane (vulnerable systems, attacker workstation) must never be able to administer or impersonate the management plane (source control, the evidence vault, orchestration, telemetry). If a compromised victim could reach your evidence store, your evidence is no longer trustworthy and your incident is no longer investigable. Proving the absence of paths is exactly how you protect the crown jewels — in a lab, in a cloud account (Phase 07 metadata/SSRF egress controls), and in an OT plant (Phase 10 zones and conduits).

How This Is Used on the Job

This is the kernel of network segmentation review — one of the most common and highest-leverage activities a security engineer performs. Cloud security reviews ask exactly this ("can a workload in the public subnet reach the database subnet?"). Container and Kubernetes reviews ask it (NetworkPolicy + a CNI that actually enforces it). OT assessments ask it (the zone-and-conduit matrix). You are learning to reason about reachability as a bidirectional property: prove the good flows exist and prove the bad flows don't.

Build It

Implement audit_policy(allowed): given the set of allowed (source, destination, port) flows, return a sorted, de-duplicated tuple of findings — one for every missing required telemetry flow and one for every forbidden reachable path (victim→LAN, victim→internet, attacker→management, OT→internet).

LAB_MODULE=solution pytest -q

Validation — What You Should Be Able to Do Now

  • Test the negative path by reflex: from any vulnerable host, prove the home LAN, the metadata endpoint (169.254.169.254), public egress, and the management plane are all unreachable — with a packet or a policy assertion, not a diagram.
  • Explain the canary technique: place a synthetic secret in a forbidden location and confirm the vulnerable host cannot reach it, so denial proves the policy rather than the target merely being absent.
  • Articulate why NAT and VPNs are not containment — they change addressing and confidentiality, not authorization or reachability.

The Broader Perspective

You practiced the most underrated discipline in security: proving a negative. Most engineers can list what a system should do; few rigorously prove what it must never do. That habit — encode the forbidden paths and continuously verify their absence — is what later lets you trust a cloud landing zone, a sandbox, or a segmented OT network. Reachability is policy; verify it, don't assume it.

Interview Angle

  • "How do you prove a lab/VM is actually isolated?" — Enumerate interfaces, routes, DNS, proxies, shared folders, host services, the metadata endpoint, and the management path; test intended and forbidden flows; keep packet/firewall evidence; re-test after reboot and snapshot restore.

Extension (Stretch)

Implement the equivalent rules in real nftables/iptables and a host-only virtual switch, and prove containment with tcpdump captures (Phase 00 HITCHHIKERS, "Proving Containment").

References

  • Phase 00 WARMUP Chapter 6; HITCHHIKERS-GUIDE.
  • NIST SP 800-115 (lab setup); CIS Benchmarks (host/hypervisor hardening).