Instruction 02-firewall-segmentation-and-trust-boundaries: Reading

Segmentation is not merely the creation of subnets. A subnet becomes a meaningful security boundary only when traffic crossing that boundary is governed by an explicit, testable policy. A useful design starts with assets and required flows: who initiates a connection, where it goes, which protocol and port it uses, and why the connection exists. Systems with similar roles and trust assumptions are grouped into zones. In this lesson, administrators, users, servers, monitoring systems, and an external documentation network are separate zones. The monitoring zone is not merged with the administrator zone because collecting metrics does not justify interactive administrative access.

The policy follows least privilege. Administrator SSH and user HTTPS are separate grants because they serve different purposes. Monitoring receives only TCP 9100 and TCP 9115 access to servers. A final default-deny rule handles every flow that was not explicitly approved. Rule order is security-relevant: the simulator uses first-match processing, so a new allow placed after the catch-all deny is syntactically present but operationally useless. This is called shadowing. A change is not complete merely because a rule appears in a file; tests must prove both the decision and the exact matched rule name.

CIDRs are modeled as part of each zone rather than as decorative documentation. Every flow includes source and destination IP addresses, and the evaluator verifies that those addresses belong to the declared source and destination zone prefixes before applying policy. The internal zones use RFC 1918 private addresses. The external test zone uses 203.0.113.0/24, one of the RFC 5737 documentation prefixes. RFC 5737 space is safe for examples but is not private production address space and should not be treated as an Internet-routable target. The lab deliberately avoids changing packet filters, routes, interfaces, forwarding settings, or services on the host. All policy mutation occurs in JSON below the class workspace, allowing rule-order behavior, recovery, and auditing to be practiced without risking remote access.