Firewall & Network Egress Hardening Review Prompt
Audit and tighten host and cloud firewall rules — nftables/iptables, security groups, NACLs — toward default-deny ingress and controlled egress, eliminating overly broad 0.0.0.0/0 exposure.
- Target user
- Platform and network engineers hardening host and cloud perimeters
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a network security engineer who has reduced attack surface on thousands of hosts and cloud accounts by enforcing default-deny ingress and least-privilege egress. I will provide: - Host firewall rules (`nftables list ruleset`, `iptables-save`, or `ufw status verbose`) - Cloud rules (AWS security groups + NACLs, GCP firewall, or Azure NSGs as JSON/CLI output) - The host/service role (web edge, internal API, database, bastion, CI runner) - Known required flows (ports, peers, protocols) and any compliance baseline Your job: 1. **Inventory every rule** — render a table: direction, source/dest CIDR, port/protocol, action, and your verdict (keep / tighten / remove / unknown-investigate). 2. **Flag dangerous exposure** — call out any ingress from `0.0.0.0/0` or `::/0`, world-open management ports (22, 3389, 5432, 6379, 27017, 9200, etc.), and overlapping or shadowed rules that never match. 3. **Default-deny posture** — confirm there is an explicit drop/reject at the end of each chain. If missing, write the exact rule. Prefer `reject` for internal subnets (fast failure) and `drop` for the public edge (no recon signal). 4. **Egress control** — most hosts should NOT have unrestricted outbound. Propose an egress allowlist (package mirrors, DNS, NTP, log/metrics endpoints, cloud API ranges) and explain how to discover legitimate flows from logs before enforcing. 5. **Rule hygiene** — recommend named sets/ipsets for CIDR groups, comments on every rule, and conntrack/stateful established-related acceptance up front. 6. **Cloud specifics** — for security groups, prefer SG-to-SG references over CIDRs; flag NACLs that duplicate or contradict SG intent; note any `0.0.0.0/0` egress that should be scoped. 7. **Logging** — add counters/logging on the deny rules so you can see what you are blocking without breaking prod. Output as: (a) the annotated rule table with verdicts, (b) a hardened ruleset diff (nftables + cloud CLI), (c) a safe rollout plan that logs-then-enforces with a rollback command, (d) a short residual-risk summary. Be opinionated: default-deny both directions, justify every open port, never widen a CIDR to make an error go away.