This post explains, with practical steps and real-world examples, how to configure firewall rules and subnetworks to isolate publicly accessible services so they meet the intent of FAR 52.204-21 and CMMC 2.0 Level 1 control SC.L1-B.1.XI — isolating public services from internal networks while preserving necessary access and auditability.
Design patterns for isolating public services
Start with a simple, repeatable network architecture: place internet-facing servers in a dedicated public subnet (DMZ) and everything else (application servers, databases, admin systems) in private subnets with no direct inbound access from the Internet. Use a NAT gateway (cloud) or outbound-only gateway (on-prem) for private hosts to reach the Internet for updates. Define clear CIDR blocks for each subnet — e.g., Public: 10.0.1.0/24, App: 10.0.2.0/24, DB: 10.0.3.0/24 — and prevent route propagation that would allow direct lateral access from the public subnet to private resources.
Key architectural elements
Implement at least these components: perimeter firewall (stateful) or cloud firewall service, subnet ACLs or Network Security Groups for per-subnet control, host-based firewall on each server (iptables, Windows Firewall), and a bastion/jump host or VPN for administrative access into private subnets. For typical small-business deployments a managed UTM, a cloud-managed firewall, or a single-purpose virtual appliance can provide these capabilities without large engineering overhead.
Cloud examples — AWS, Azure, GCP
AWS: put web servers in a public subnet with an Internet Gateway and associate an Elastic IP/NAT for outbound; use Security Groups as instance-level firewalls and NACLs for subnet-level controls. Example rules: Web-SG inbound allow tcp:80,443 from 0.0.0.0/0; Web-SG inbound allow tcp:22 only from Management-SG or your office IP; DB-SG inbound allow tcp:3306 only from App-SG (security-group-to-security-group), no 0.0.0.0/0 rules for DB. Enable VPC Flow Logs and AWS Config rule checks for open DB ports. Azure: use Azure Firewall or NSGs — example NSG entries with priorities: allow Internet->PublicSubnet tcp:80/443 priority 100; deny Internet->PrivateSubnets priority 200; allow ManagementSubnet->PrivateSubnets tcp:22/3389 priority 110. GCP: use firewall rules scoped to network and tags — example gcloud rule: gcloud compute firewall-rules create allow-http --direction=INGRESS --priority=1000 --network=prod-net --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=web-server.
On-premises and small business scenarios
For on-prem or hybrid small-business environments: use VLANs to separate DMZ and internal LAN, place the external-facing devices behind a firewall/UTM (pfSense, OPNsense, Cisco ASA), and avoid hairpin routing that allows DMZ hosts to reach internal hosts directly. Example pfSense approach: create WAN, LAN, DMZ interfaces; NAT only the DMZ services you intend to expose (port-forward HTTPS to internal web server); restrict management GUI to VPN connections; configure firewall rules to allow DMZ->LAN only for specific, logged flows (e.g., syslog port to a central log host) and block all other traffic.
Practical firewall rule details and best practices
Follow least privilege: only open ports needed for the service and only to required source ranges. Use explicit allow rules and a default-deny fallback. Prefer stateful firewalls so return traffic is automatically allowed rather than broad egress rules. Examples of concise rules: allow TCP 443 to WebSubnet from 0.0.0.0/0; allow TCP 22 from CorporateMgmtIP/32 only; allow TCP 3306 to DBSubnet from AppSubnet only. Apply egress filtering: block common tunneling ports or restrict outbound destinations to patch servers, SaaS endpoints, and whitelisted cloud services. Implement rate-limiting and connection thresholds on the perimeter to reduce exposure to DDoS or brute-force attempts.
Operational controls: logging, testing, and change management
Logging and alerting are required to demonstrate compliance: enable firewall logs, VPC Flow Logs, NSG flow logs or equivalent; forward logs to a centralized SIEM or log collector with retention configured per policy. Test the configuration regularly: internal vulnerability scans, authenticated port scans, and simple external scans from an external IP to verify only intended ports are accessible. Maintain change control: any firewall or subnet change should be documented in a ticket, include the reason and rollback plan, and be reviewed quarterly. For small teams, perform runbook-based reviews and keep screenshots or exported rule sets for audit evidence.
Checklist mapped to Compliance Framework (FAR 52.204-21 / CMMC SC.L1-B.1.XI)
Use this practical checklist to demonstrate compliance: 1) Public-facing services located in a dedicated public subnet or DMZ; 2) Firewall rules explicitly allowing only required inbound ports and sources; 3) Private subnets with no inbound Internet routes to sensitive systems; 4) Instance-level firewall/NACLs or NSGs configured to enforce least privilege; 5) Administrative access limited to VPN or bastion hosts and restricted source IPs; 6) Logging of firewall/flow data with retention and review schedule; 7) Periodic scans and change-control records for all rule changes. Mark each item as implemented, date of last test, responsible owner, and evidence location in your compliance tracker.
Risks of not isolating public services
If public services are not isolated, attackers who compromise a web server can pivot laterally to application servers, exfiltrate data from databases, or access internal management interfaces. Unrestricted egress can enable beaconing to command-and-control infrastructure. Lack of logging and change control increases the chance issues go undetected and makes forensic investigation and audit responses difficult, risking contract penalties under FAR and failing CMMC assessments.
Summary: implement a simple DMZ + private subnet architecture, enforce least-privilege firewall rules (both network- and host-based), restrict administrative access to VPN/bastion hosts, enable logging/monitoring, and maintain a checklist and change-control evidence to demonstrate FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI compliance; these practical steps protect public services while minimizing attack surface and providing auditable controls for small businesses.
