Stateless Packet Filtering
Examines each packet in isolation against a set of rules based on source/destination IP, port, and protocol. Fast and low overhead, but has no knowledge of connection state — cannot distinguish a legitimate reply packet from an unsolicited inbound connection.
- Rules evaluated top-down; first match wins
- No TCP handshake awareness
- Easily bypassed by crafting packets that match allow rules
- Still used at high-speed core routers (ACLs)
Stateful Packet Inspection (SPI)
Maintains a connection tracking table. A packet is allowed only if it belongs to an established, expected connection. Inbound packets that are not part of an outbound-initiated session are dropped automatically.
- Tracks TCP state: SYN, SYN-ACK, ESTABLISHED, FIN
- UDP "pseudo-state" tracked by timeout
- Default behavior in all modern firewalls
- Implicit deny: anything not explicitly allowed is dropped
Network vs. Host-Based Firewalls
Network firewalls sit at the perimeter and protect entire network segments. Host-based firewalls (Windows Firewall, iptables/nftables, ufw) run on individual endpoints and protect that single system — critical for east-west threat containment.
- Network FW: protects many hosts, single point of control
- Host FW: survives network firewall bypass, zero trust essential
- Both are needed in defense-in-depth
- Cloud security groups act as distributed network firewalls
DMZ Architecture
A demilitarized zone places publicly accessible servers (web, mail, DNS) in a separate network segment between the external firewall and the internal network. Compromise of a DMZ host does not directly expose internal systems.
- Two-firewall DMZ: separate external and internal firewall devices
- Three-legged firewall: single device with 3 interfaces
- DMZ hosts initiate outbound to internal only for specific services
- Internal to DMZ traffic still requires firewall rules
| Firewall Type | Works At | Inspection Level | Example Products |
|---|---|---|---|
| Packet Filter | L3/L4 | IP header, port, protocol | iptables, router ACLs |
| Stateful Inspection | L3/L4 | Connection state + headers | ASA, Check Point, pfSense |
| Application-Layer (Proxy) | L7 | Full payload, protocol decode | Squid, HAProxy, Blue Coat |
| NGFW | L2–L7 | Application ID, user, TLS content | Palo Alto, Fortinet, Cisco Firepower |
| Host-Based | L3/L4 | Per-process, local traffic | Windows Firewall, iptables, ufw |
| Cloud Security Group | L3/L4 | Stateful, per-instance rules | AWS SG, Azure NSG, GCP Firewall Rules |
NGFWs extend stateful inspection into Layer 7, identifying applications regardless of port — a web app using port 443 is identified as "Salesforce" or "BitTorrent", not just "HTTPS". This enables policy decisions based on application identity and user identity rather than just IP and port.
Deep Packet Inspection (DPI)
Inspects the full payload of packets, not just headers. Identifies applications by their traffic signatures, behavioral patterns, and protocol decode — even when running on non-standard ports.
- App-ID: identifies 3,000+ applications (Palo Alto approach)
- Protocol decode: validates protocol compliance
- File type identification independent of extension
- Encrypted traffic analyzed via certificate metadata (pre-decryption)
SSL/TLS Inspection
NGFWs act as a man-in-the-middle: they terminate inbound TLS from clients, inspect the decrypted payload, re-encrypt, and forward to the server. This enables DPI on HTTPS traffic but introduces privacy and certificate trust considerations.
- Forward proxy: inspect outbound (employees to internet)
- Inbound: inspect traffic to internal servers
- Certificate pinning breaks TLS inspection — requires exceptions
- Privacy exemptions required for banking, healthcare URLs
User Identity & Policy
Integrates with Active Directory, LDAP, and RADIUS to map traffic to named users rather than just IP addresses. Policies can restrict applications per department, job function, or group membership.
- User-ID agent reads AD login events
- Captive portal for unauthenticated hosts
- "Block P2P for all except IT" expressed as a single rule
- Audit trails show user name + application + bytes transferred
Integrated IPS & Threat Prevention
Modern NGFWs bundle IPS signatures, antivirus scanning, URL filtering, and DNS security into a single platform, reducing latency compared to separate appliance chains. Threat intelligence feeds are updated continuously.
- Inline IPS blocks exploits without separate hardware
- Sandboxing: detonate unknown files (WildFire, FortiSandbox)
- URL category filtering: block malware, phishing, adult content
- Continuous signature updates (daily or more frequent)
| Feature | Palo Alto PA-Series | Fortinet FortiGate | Cisco Firepower | pfSense / OPNsense |
|---|---|---|---|---|
| App-layer identification | App-ID (native) | Application Control | Cisco AVC | Snort/Suricata plugin |
| TLS Inspection | Yes (forward & inbound) | Yes (SSL/SSH) | Yes | Yes (manual cert install) |
| Integrated IPS | Threat Prevention sub | IPS module | Snort-based (Firepower) | Snort / Suricata package |
| Cloud-managed | Panorama / Strata Cloud | FortiManager / FortiCloud | Cisco Defense Orchestrator | Community / self-managed |
| Best for | Enterprise, consistent policy | Mid-market, price/performance | Cisco-heavy environments | SMB, home lab, open source |
| Licensing model | Feature subscriptions | Bundles (UTM/ENT) | Subscriptions per feature | Free (hardware cost only) |
A WAF operates at Layer 7, specifically parsing HTTP/HTTPS requests and responses to detect and block web attacks — SQL injection, XSS, path traversal, remote code execution, and more. Unlike NGFWs that protect the network perimeter, WAFs protect specific web applications.
OWASP ModSecurity Core Rule Set
The ModSecurity CRS is the industry-standard rule set for open-source WAFs, targeting OWASP Top 10 attacks. CRS 4.x (released 2023) reduced false positives significantly while adding improved detection for Log4Shell-style attacks.
- Paranoia levels 1–4: higher = more rules, more false positives
- Anomaly scoring mode: accumulate score, block above threshold
- Runs on Apache mod_security2, Nginx + ModSecurity, HAProxy
- OWASP CRS is included in many cloud WAF managed rule groups
WAF Evasion & Bypass Techniques
Attackers actively work to bypass WAFs using encoding tricks, HTTP protocol quirks, and logic flaws. Understanding bypass techniques is essential for WAF operators to tune rules correctly.
- URL encoding, double encoding, Unicode normalization
- HTTP parameter pollution (duplicate parameters)
- Case variation and whitespace injection in SQL
- Chunked transfer encoding to split payloads
- JSON/XML body parsing inconsistencies
Rate Limiting & Bot Protection
Modern WAFs integrate rate limiting (requests per IP, per session, per endpoint) and bot management to stop credential stuffing, scraping, and account takeover — attacks that don't trigger traditional WAF signatures.
- IP-based rate limiting: crude, bypassed with IP rotation
- Fingerprinting: TLS JA3, HTTP/2 settings fingerprint
- Behavioral scoring: mouse movement, keystroke timing
- CAPTCHA / JS challenge for suspicious traffic
| Dimension | Self-Hosted WAF (ModSecurity / Coraza) | Cloud WAF (Cloudflare / AWS WAF / Azure) |
|---|---|---|
| Cost | Free software; hardware + ops labor cost | Pay-per-request or flat subscription; no hardware |
| Management overhead | High — rule tuning, updates, scaling are manual | Low — vendor manages infrastructure and base rules |
| Performance | Latency depends on local hardware; no global PoPs | Edge-processed at 200+ PoPs globally; low latency |
| Customization | Full control: custom rules, Lua scripting (ModSec) | Limited to vendor's rule language; improving rapidly |
| DDoS integration | Separate DDoS appliance or ISP service needed | Bundled with DDoS protection at same edge |
| Visibility | Full access to raw logs and traffic | Logs available via API; some privacy tradeoffs |
The Perimeter Model Is Broken
Traditional security assumes that traffic inside the network perimeter is trustworthy. This assumption is false. Lateral movement after an initial breach, insider threats, supply chain compromises, and cloud workloads that span perimeters all render the "castle and moat" model obsolete. The perimeter model assumes the inside is trusted — it isn't.
Death of the Perimeter
The traditional model — hard external shell, soft internal network — fails because attackers routinely bypass the perimeter. Phishing delivers malware past the firewall. VPNs grant broad internal access. Cloud workloads exist outside any physical perimeter.
- 95%+ of breaches involve compromised credentials
- Lateral movement exploits implicit trust between internal hosts
- Remote work dissolved the concept of a physical perimeter
- SaaS apps mean corporate data lives outside the perimeter entirely
Micro-Segmentation
Divides the network into small zones with explicit, granular allow-lists between them. East-west traffic (server-to-server, VM-to-VM) is inspected and controlled. A compromised host can only reach resources explicitly permitted to that workload.
- Software-defined networking (SDN) enables dynamic segmentation
- VMware NSX, Illumio, Guardicore (Akamai) for data center
- Cloud: security groups + network policies per workload
- Kubernetes NetworkPolicy for container east-west control
Software-Defined Perimeter (SDP)
SDP (BeyondCorp model, pioneered by Google) authenticates and authorizes the device and user before establishing any network connection to a resource. The resource is invisible ("dark") until a policy engine grants access.
- Controller authenticates user + device posture before any TCP
- Resource is not routable/discoverable without prior auth
- Eliminates VPN-style broad network access grants
- Cloudflare Access, Zscaler ZPA, Palo Alto Prisma Access implement SDP
East-West Traffic Inspection
Most firewalls sit at the north-south perimeter. Zero trust requires inspecting and controlling traffic between internal hosts — the east-west flows that attackers use for lateral movement after an initial breach.
- Traditional deployment: all east-west traffic unfiltered
- Host-based firewalls enforce policy at each endpoint
- Service mesh (Istio, Linkerd): mTLS between all microservices
- Distributed firewalls in hypervisors (VMware NSX, AWS SG)
In a zero trust architecture, firewalls are not eliminated — they shift in placement and purpose. Perimeter firewalls focus on denying all inbound by default. Internal firewalls enforce micro-segmentation. NGFWs with user-identity and application-awareness enforce least-privilege access. The combination of ZTNA for remote users, micro-segmentation for east-west, and perimeter firewalls for external-facing surfaces creates a layered zero trust posture.
Rule Bloat Is a Security Risk
Firewall rule sets grow over time as new rules are added and old rules are never removed. Organizations routinely have hundreds or thousands of rules, many of which are redundant, shadowed, or grant more access than intended. An untested firewall rule is an untrusted firewall rule — audit and review regularly.
Rule Review Cadence
Firewall rules should be reviewed on a scheduled basis, not only when problems arise. PCI DSS requirement 1.3 mandates firewall rule reviews at least every six months. Best practice is quarterly for perimeter firewalls and annually for internal segmentation rules with low-risk.
- Tag rules with owner, ticket number, and expiry date
- Temporary rules ("open port 8080 for testing") frequently become permanent
- Disable before deleting — watch for 30 days for traffic hits
- Document the business justification for every allow rule
Shadow Rules & Rule Bloat
A shadow rule is a rule that can never be matched because a preceding rule already covers that traffic. Shadow rules create false confidence — the administrator believes a block rule exists, but it never fires. Rule analysis tools identify these automatically.
- Example: "allow any any" at rule 5 shadows all rules below it
- Redundant rules: two rules that permit identical traffic
- Overly broad rules: /16 prefix where /24 was intended
- Unused rules: no traffic matches in 90+ days
Automated Rule Analysis Tools
Purpose-built tools analyze firewall rule sets across multi-vendor environments, identify policy violations, compliance gaps, and optimization opportunities without requiring manual rule-by-rule inspection.
- Tufin: enterprise multi-vendor policy management
- AlgoSec: risk analysis + change automation
- FireMon: continuous compliance monitoring
- Open source: Fwbuilder, policy-based tools for iptables/nftables
Change Management for Firewall Rules
Every firewall rule change should go through a formal change management process: request, risk assessment, approval, implementation, verification, and documentation. Emergency changes should still be documented retroactively.
- Four-eyes principle: no single admin approves their own changes
- Test in staging before production (where possible)
- Roll-back plan defined before any change window
- SIEM alerting on firewall configuration changes
| Compliance Framework | Firewall Requirement | Specifics |
|---|---|---|
| PCI DSS v4.0 | Req 1.2, 1.3 | Document all connections; review rules every 6 months; restrict inbound/outbound to that necessary |
| NIST SP 800-41 | Guidelines for Firewalls | Default deny; document all rules; annual review; log all denied traffic |
| CIS Controls v8 | Control 12 (Network Infrastructure Management) | Manage network infrastructure using MFA, encrypted admin protocols, change tracking |
| ISO 27001 | Annex A 8.20 | Network controls to protect information systems; documented access control rules |