DMZ Web Server Cannot Reach Vendor Updates
A retailer exposes an on-premises storefront through a firewall with three zones: Untrust, DMZ, and Trust. The public IP 203.0.113.10 is statically NATed to the DMZ web server 172.16.50.20. Trust is 10.0.0.0/16. Policies allow Untrust to DMZ on TCP 443 only, DMZ to Untrust on any service, and Trust to DMZ on TCP 443/22. Outbound NAT hides Trust as 203.0.113.11. The web server must download OS packages from vendor.example at 198.51.100.25 over HTTPS. Downloads fail. Firewall logs show the DMZ server initiating TCP 443 to 198.51.100.25, and the outbound policy permits it, but return packets are dropped. A packet capture on the DMZ interface shows the server's source address translated to 203.0.113.10, not 203.0.113.11. The vendor confirms its service is reachable and does not filter by source. The security team also wants to restrict DMZ egress.
1. Explain why the DMZ server's outbound session fails even though the outbound policy permits it.
Read the worked answer
The outbound packet leaves the DMZ with source 172.16.50.20, but the static NAT rule is translating that source to 203.0.113.10, the same public IP used for inbound access to the web server. The vendor replies to 203.0.113.10 on a random high port. That return traffic arrives on the Untrust interface and is evaluated as inbound to the DMZ. The inbound policy only permits TCP 443 to 172.16.50.20; it does not permit the high-port return traffic to 203.0.113.10. The firewall therefore drops the return packets. The outbound policy was not the failing control; the NAT design and the inbound policy interaction were. The capture showing source translation to .10 rather than the Trust hide address .11 is the key clue that the static NAT is matching outbound traffic too broadly.
2. Propose a corrected NAT and policy design that allows vendor updates while enforcing least privilege.
Read the worked answer
Separate inbound destination NAT from outbound source NAT. The static NAT for 203.0.113.10 should match only traffic destined to the DMZ web server, not all traffic sourced from it. Add a no-NAT or dedicated outbound NAT rule for DMZ-originated traffic so the server uses a distinct egress address, or use a forward proxy in the DMZ. Then restrict DMZ egress to the minimum: DNS to internal resolvers, TCP 443 to the vendor's FQDN or 198.51.100.25, and any required package repositories. Deny all other DMZ-originated traffic. If the firewall supports FQDN objects, use them and refresh them, because vendor IPs may change; otherwise document the static exception. Keep logging on the egress rule and review it, since a compromised web server could otherwise use the allowed path for command and control.
3. What residual risk remains with DMZ egress, and how would you detect abuse of the allowed update path?
Read the worked answer
Even a narrow allow rule to the vendor permits a compromised DMZ server to send data or commands over HTTPS to that destination, and TLS inspection may not be feasible. The residual risk is content-based exfiltration or misuse of the vendor domain. Detect it by baselining the volume and timing of update downloads and alerting on large outbound transfers, unusual user agents, or connections outside scheduled patch windows. Use proxy logs or firewall logs with SNI and destination reputation. If the vendor supports it, pin the update server and verify package signatures. Alert on any new destination in the DMZ egress logs and on DNS requests to domains not on the approved list. These controls do not eliminate the risk, but they make abuse visible.