Firewall Pro

---
name: firewall-pro
description: Design, implement, and audit firewall policy — rule hygiene, segmentation, change control, and continuous compliance.
category: security
---

## Overview

Firewalls remain the primary enforcement point for network segmentation: deciding which traffic may flow between zones, users, and the internet. Their effectiveness comes entirely from policy discipline — a firewall with 5,000 stale any-any rules is a very expensive router. Professional firewall practice is rule hygiene, least-privilege policy, and change control.

This skill covers firewall architecture, rule lifecycle management, auditing, and the operational habits that keep policy tight over time.

Firewall policy is organizational memory written in allow rules — and like memory, it degrades. Every 'temporary' rule, every troubleshooting exception, every forgotten project leaves residue. The discipline is not in the initial design, which everyone gets right, but in the ten thousand small decisions afterward. Hygiene processes are the real firewall.

## When to use

- Designing network segmentation (DMZ, internal zones, OT separation).
- Auditing and cleaning up accumulated firewall rules.
- Implementing change control for firewall modifications.
- Preparing firewall evidence for audits (PCI DSS, ISO 27001).
- Evaluating NGFW features (IPS, app control, TLS inspection) vs complexity.

## Core concepts

- **Default deny:** the only sane default. Every allow rule needs a business justification, owner, and review date.
- **Zones and conduits:** segment by trust and function (internet, DMZ, app tier, data tier, management, OT). Traffic between zones is explicitly allowed or it does not flow.
- **Rule hygiene:** no unused rules, no overly broad rules (any-any, /8s for single hosts), no expired temporary rules, no duplicate/shadowed rules. Review at least semi-annually; automate the reporting.
- **Change control:** every rule change is a ticket with requester, justification, risk review, implementation, and verification. Emergency changes get post-implementation review within days.
- **NGFW capabilities:** application awareness, IPS, and TLS inspection add value but also complexity and privacy considerations — deploy deliberately, with documented scope for inspection.
- **Management-plane security:** firewall admin interfaces are prime targets — restrict to a management network/VPN, require MFA, log all admin actions.

- **Implicit rules and rule order.** Most firewalls process top-down with hidden defaults — audit the effective policy (simulated traffic tests), not just the visible rule list.
- **Stateful inspection understanding.** Know what your firewall actually inspects per protocol; 'allow HTTPS' on a next-gen firewall and a packet filter are very different controls.
- **Cloud security groups as firewalls.** In cloud, security groups and NACLs are your firewall — apply the same hygiene, change control, and auditing to them.

## Practical workflow

1. **Design the zone model:** map data flows to zones; define allowed inter-zone conduits. Keep the model simple enough to actually enforce — 5 clear zones beat 20 confusing ones.
2. **Write least-privilege policy:** each rule specifies source, destination, service, action, justification, owner, and expiry/review date. Start from default deny and add only what is needed.
3. **Implement with verification:** deploy during change windows; verify the intended traffic flows *and* that unintended traffic is blocked (test both directions of the assumption).
4. **Audit on cadence:** quarterly automated reports — unused rules (no hits in 90+ days), overly broad rules, expired temporaries, shadowed rules. Remediate or re-justify each.
5. **Control changes:** ticketed workflow with peer review for high-risk changes (internet-facing, any-any, management access). Emergency path with mandatory retro-review.
6. **Monitor and alert:** log denies at zone boundaries to the SIEM; alert on denies to crown-jewel zones, management-plane access attempts, and policy pushes outside change windows.

### Rule audit checklist

- [ ] Default-deny posture confirmed on all policies
- [ ] No any-any allow rules; no unused rules (>90 days no hit)
- [ ] No expired temporary rules; all rules have owner + justification
- [ ] No shadowed/duplicate rules; rule order reviewed
- [ ] Management access restricted + MFA + logged
- [ ] Change tickets exist for all recent modifications
- [ ] Deny logs feeding SIEM with boundary alerts

### Sustaining the practice

- Automate the quarterly hygiene report; manual audits get skipped
- Re-certify all allow rules annually with business owners
- Test the effective policy with simulated traffic after major changes
- Track mean-time-to-implement for approved changes as an ops metric

### Metrics that prove it works

- Unused and over-broad rule counts, trended down quarterly
- % of changes with completed tickets and peer review
- Audit finding recurrence rate (same finding twice = process failure)
- Mean time to implement approved emergency changes

## Common pitfalls

- **Rule sprawl.** Temporary rules become permanent. Every temporary rule needs an expiry date enforced by process, not memory.
- **Any-any for "troubleshooting."** The fastest way to permanently weaken segmentation. Use time-boxed, logged, reviewed exceptions instead.
- **Auditing once a year.** Policy decays continuously; annual audits find a year's worth of rot. Automate quarterly hygiene reports.
- **Unrestricted management plane.** Admin interface on the internet or flat LAN is an invitation. Isolate it.
- **TLS inspection without governance.** Decrypting traffic has privacy, legal, and trust implications — scope it, document it, and handle the CA properly.
- **Firewall as the only control.** Segmentation helps, but assume-breach design (identity controls, EDR, monitoring) must back it up.
- **Emergency changes without retro-review.** The emergency path needs a mandatory post-implementation review within days, or it becomes the standard path.
- **IPv6 rules forgotten.** Dual-stack environments with v4-only policy leave v6 wide open. Audit both stacks.
- **Allowing the firewall team to be the bottleneck.** Slow change processes drive shadow exceptions and firewall bypasses. Make the secure path fast.
- **No lab for rule testing.** Testing complex rules directly in production causes outages. Maintain a staging firewall or simulation capability.