Firewall Rules and Default-Deny

Step 1: Design the traffic policy

The zone networks from Unit 3 provide isolation, but fine-grained traffic control requires firewall rules. For each zone boundary, document exactly what traffic must flow and why.

Walk through each zone pair:

• Management zone to all zones: monitoring ports only. Grafana and Alloy need to collect metrics and logs from every zone. Define the specific ports.
• Building systems zone outbound to internet: HTTPS only, for firmware updates. No inbound from tenant zone.
• Surveillance zone outbound: port 1194 for the third-party CCTV company's VPN connection. No inbound from tenant zone.
• Everything else: denied.

Every "allow" rule needs a business justification written next to it. "Why is this traffic allowed?" is a design question, not an afterthought. If you cannot justify a connection, it should not exist.

Step 2: Implement iptables rules

Direct AI to write iptables rules enforcing the traffic policy.

The professional approach is default-deny: the FORWARD chain's default policy is DROP. Then add specific ACCEPT rules for each allowed traffic flow. AI commonly generates the opposite -- a default ACCEPT policy with specific DROP rules for things that should be blocked. The default-allow approach leaves every port you did not think to block wide open.

Watch for this. When AI generates the rules, check the default policy first. If it starts with -P FORWARD ACCEPT, that is the wrong approach. The rules should start with -P FORWARD DROP and then enumerate what is allowed.

Access control across layers creates a matrix that must be coherent. A container granted network access to the BMS zone but denied at the application level can still probe the BMS port. A container denied network access never reaches the application layer at all. The network and application layers need to agree on who is allowed to do what.

Step 3: Discover the Docker iptables conflict

After implementing the firewall rules, test them. Attempt a connection from the tenant zone to the BMS zone on a port that is not in the allow list.

If the connection succeeds despite your DROP rules, you have found the Docker iptables conflict. Docker manages its own iptables rules through the FORWARD chain. When Docker creates networks and connects containers, it inserts its own rules that can override yours. Your carefully crafted iptables rules may be bypassed entirely by Docker's network management.

The resolution depends on the Docker version and configuration. Options include configuring Docker to not manage iptables (the --iptables=false daemon flag), inserting rules in the DOCKER-USER chain (which Docker processes before its own rules), or working within Docker's networking model using network-level isolation instead of iptables. Research the approach that works for your environment.

This is a real-world problem. Firewall rules that look correct in the configuration but are overridden by the container runtime's own networking are a common segmentation failure.

Step 4: Test allowed and denied paths

Systematically test every path in the traffic policy:

Denied paths -- attempt each, confirm the connection fails:

• Tenant to BMS: denied
• Tenant to access control: denied
• Tenant to CCTV management: denied
• CCTV to BMS: denied
• CCTV to access control: denied

Allowed paths -- attempt each, confirm the connection succeeds only on specified ports:

• Management to BMS: monitoring ports only
• Management to CCTV: monitoring ports only
• BMS outbound to internet: HTTPS only

Log every test result. This log is evidence for the insurance company and for the remediation plan.

Step 5: Write cross-zone detection rules

Network prevention (firewall rules) stops unauthorized traffic. Detection (Sigma rules) tells you someone tried.

Write a Sigma rule that fires when traffic attempts to cross a zone boundary that should be blocked. The rule watches for connection attempts in the firewall log -- a denied connection from the tenant zone targeting a BMS port.

The detection rule complements the firewall rule. Prevention stops the attack. Detection tells you the attack was attempted. A patched vulnerability with no detection rule means you never know when someone is probing your boundaries.

Test the detection by attempting a cross-zone connection from the tenant container. The firewall blocks it. The detection rule fires in Grafana.

The same event from two perspectives: the tenant container sees "connection refused." Grafana shows "lateral movement attempt detected." Both verify the same thing from different sides.