How Firewalls Work

• Explain the three generations of firewalls and what each inspects
• Design an allow-list policy with default-deny posture
• Order rules so review and troubleshooting stay tractable

• Filtering is the boundary control for everything else: exploit traffic, credential stuffing and scanning all begin with a packet that should have been dropped at the edge.
• State tracking is what makes inbound firewalls practically usable for outbound services.
• Rule quality (order, specificity, review) is security quality — sloppy rules create accidental openings.
• Firewall logs are primary source material for incident reconstruction.

Packet filters check your ticket fields at the door; a stateful bouncer also watches who came in and lets the same people out; an NGFW bouncer also cares what you're doing inside the party.

• Rules are ordered (first match wins in most firewalls): each packet/connection is compared top to bottom.
• A simple rule: allow tcp from 10.0.20.0/24 to 10.0.30.0/24 dst port 443; everything else falls to the final default-deny rule.
• Stateful engines keep a session table (5-tuple + state) so return traffic is matched to a legitimate session instead of rule-by-rule.
• NGFW layers identify application/protocol signatures and can enforce them (allow 'HTTP to this server' while patching content policy).
• Firewalls are often deployed with logging at the final default rule so 'deny' traffic is observable.

• A bastion allows port 22 only from the VPN subnet, default-deny for the rest — scanning from the internet returns nothing.
• A web zone allows 80/443 from the WAF, and the WAF inspects and drops exploit payloads before the app sees them.
• Internal segmentation allows 'appAPItier → db tier:5432' only; a compromised app box can't reach other databases.

• Default deny; write allows as specific tuples (source, destination, port).
• Keep rules ordered most-specific-first; document each rule's business purpose and expiry.
• Log denies to a SIEM and tune the noisy-but-innocent ones (scanners, health checks).
• Review the rule base regularly; stale allow rules are a top breach-enabler.
• Test the boundary as an attacker would: scan your own perimeter from authorized test hosts.

• Allowing 'any to any' for a service 'just to be fast' — an invitation.
• Ordering: a broad 'deny all' rule inserted above legitimate allows kills traffic silently.
• Forgetting outbound filtering — egress rules against data exfiltration are often completely absent.
• Assuming NAT alone protects hosts; NAT is not security, and source-spoofed traffic laughs at it (though less with modern egress filtering).

• When something 'works from the office but not the VPN', diff the two paths' rule matches — the difference is the answer.
• Look at the deny counter on the rule you suspect; a climbing counter means your rule, not the app, is blocking it.
• Test with nc/curl from the source to the destination through each trust zone, not just ping.

• Rules that permit 'established' are safe only if spoof-free; ingress filtering (dropping source-spoofed packets) is table stakes.
• Everything the firewall permits becomes attacker-visible: keep the permit surface minimal and monitored.