Firewalls — Explain firewalls (stateful vs stateless) and rule concepts (allow/deny) (conceptual) - Cyber Security

SECTION 1

Historical Context & Motivation

The concept of a firewall in computer networking emerged from a straightforward but urgent problem: as organizations began interconnecting their private networks with the nascent public Internet in the late 1980s, they needed a mechanism to control which traffic could cross the boundary between trusted internal systems and untrusted external networks. The term itself was borrowed from the construction industry, where a firewall is a physical barrier designed to prevent the spread of fire between sections of a building. In the digital context, a firewall serves an analogous purpose—it prevents unauthorized or potentially malicious network traffic from propagating into protected network segments. The evolution of firewall technology tracks closely with the evolution of network threats, growing from simple packet filters to sophisticated stateful inspection engines and, eventually, deep packet inspection systems.

1988 • First-Generation Packet Filters

Following the Morris Worm incident, engineers at Digital Equipment Corporation (DEC) developed the first commercial packet filter firewall. These early systems examined individual packets against static rules based on IP addresses and port numbers, operating at the network and transport layers of the OSI model.

1991 • Application-Layer Proxies

Researchers at AT&T Bell Labs, including Marcus Ranum, developed application-layer proxy firewalls that could inspect payload contents and make decisions based on application-level semantics. These offered stronger security but introduced significant performance overhead.

1994 • Stateful Packet Inspection

Check Point Software Technologies introduced stateful inspection with their FireWall-1 product. This innovation allowed firewalls to track the state of active network connections, enabling more nuanced and accurate filtering decisions without the overhead of full proxy architectures.

2004–2009 • Next-Generation Firewalls (NGFW)

Companies like Palo Alto Networks introduced next-generation firewalls combining stateful inspection with deep packet inspection (DPI), intrusion prevention systems (IPS), and application awareness. These systems could identify and control traffic at the application layer regardless of port.

2010s–Present • Cloud and Software-Defined Firewalls

With the proliferation of cloud computing and microservices, firewalls evolved into virtual appliances and software-defined solutions. AWS Security Groups, Azure NSGs, and host-based firewalls like iptables/nftables and Windows Defender Firewall now enforce perimeter-less security at scale.

Throughout this evolution, the fundamental question has remained the same: given a stream of network packets arriving at a boundary, how should a system decide which packets to allow and which to deny? The answer involves understanding the distinction between stateless and stateful inspection, the structure of firewall rule sets, and the order in which rules are evaluated. These foundational concepts remain essential to modern network security, whether you are configuring a hardware appliance at a corporate perimeter or defining security group rules in a cloud environment.

SECTION 2

Core Principles & Definitions

Before diving into the mechanics of stateful and stateless inspection, it is important to establish the foundational principles that govern all firewall architectures. A firewall operates as an inline network device—or a software module within an operating system—that intercepts traffic at a defined network boundary and applies a set of ordered rules, commonly called an access control list (ACL) or rule base. Each rule specifies match criteria (such as source IP, destination IP, protocol, and port numbers) paired with an action (allow or deny). The firewall evaluates incoming or outgoing packets against these rules in sequence and applies the action of the first matching rule.

Default Deny (Whitelisting)

A security-first posture in which all traffic is denied by default unless explicitly permitted by a rule. This is the industry-recommended baseline: only traffic that has been deliberately authorized can traverse the firewall.

Default Allow (Blacklisting)

An open posture where all traffic is allowed by default unless explicitly blocked. This approach is less secure because it requires the administrator to anticipate and enumerate every possible threat, leaving the network vulnerable to novel attack vectors.

Principle of Least Privilege

Firewall rules should grant the minimum necessary access for each network flow. Rather than opening an entire port range, rules should be scoped to specific source-destination pairs and specific services. This limits the blast radius of a compromise.

Rule Order Matters

Most firewalls use first-match semantics: the packet is evaluated against rules top-to-bottom, and the action of the first matching rule is applied. An incorrectly ordered rule set can inadvertently permit dangerous traffic or block legitimate services.

Stateless vs. Stateful

A stateless firewall treats each packet independently, while a stateful firewall maintains a connection table tracking active sessions, allowing it to automatically permit return traffic that belongs to an established, legitimate session.

✦

KEY TAKEAWAY

Think of a firewall as a security guard at a building entrance with a clipboard of rules. A stateless guard checks every person's badge against the clipboard each time they walk through the door—even if they just stepped out for a moment. A stateful guard remembers who has already been verified and lets them pass back through without re-checking, but still scrutinizes new arrivals. The 'default deny' policy means the guard turns away everyone not on the list, while 'default allow' means the guard only stops people on a specific blocklist—clearly the former is safer in a high-security environment.

SECTION 3

Visual Explanation — Packet Flow Through a Firewall

The following diagram illustrates how a packet traverses a firewall's rule evaluation pipeline. Understanding this flow is crucial because it clarifies why rule ordering and default policies have such a significant impact on the security posture of a network. Whether the firewall is stateless or stateful, the general evaluation pattern follows a sequential check against an ordered list of rules, terminating at the first match.

This diagram shows the sequential evaluation of firewall rules. A stateful firewall first checks its connection table (purple box). If the packet belongs to a known session, it is immediately allowed. Otherwise, the packet is tested against each rule in order (cyan boxes). The first matching rule's action is applied. If no rule matches, the default policy (typically deny) takes effect.

Notice the critical structural insight in the diagram: the stateful check at the top is what distinguishes a stateful firewall from a stateless one. In a purely stateless configuration, this check does not exist, and every packet—including return traffic from a connection the internal host initiated—must match an explicit rule. This is why stateless firewalls require administrators to create bidirectional rules: one for outbound traffic and a separate rule for the corresponding inbound reply. Stateful firewalls automate this by tracking the state of TCP connections (SYN, SYN-ACK, ACK handshake) and, in more advanced implementations, even UDP and ICMP pseudo-sessions.

SECTION 4

How Firewalls Work — Stateless vs. Stateful Inspection

Stateless Packet Filtering

A stateless packet filter examines each packet in isolation, making a forwarding or dropping decision based solely on header fields visible in that single packet. The evaluation tuple typically consists of five fields extracted from the IP and TCP/UDP headers: source IP address, destination IP address, source port, destination port, and protocol number (TCP = 6, UDP = 17, ICMP = 1). Because the firewall retains no memory of previous packets, it cannot determine whether a given packet is part of an established connection or a new, possibly malicious probe. This means return traffic (e.g., a web server's HTTP response) must be explicitly permitted by a separate rule.

STATELESS RULE MATCHING TUPLE

Rule Match = (src_IP ∈ S) ∧ (dst_IP ∈ D) ∧ (src_port ∈ P_s) ∧ (dst_port ∈ P_d) ∧ (proto = π)

Where S is the set of allowed source IPs, D is the set of allowed destination IPs, P_s and P_d are the permitted source and destination port ranges, and π is the IP protocol number. Each rule is a conjunction of these predicates; a packet matches if and only if all conditions are simultaneously satisfied.

Stateful Packet Inspection

A stateful firewall augments static rule matching with dynamic connection tracking. When an outbound packet matches an allow rule and initiates a new connection (a TCP SYN, for instance), the firewall creates an entry in its state table (also called a session table or connection table). This entry records the 5-tuple of the connection along with the current TCP state machine position (SYN_SENT, ESTABLISHED, FIN_WAIT, etc.). Subsequent packets belonging to that session—including inbound reply packets—are matched against the state table rather than being re-evaluated against the full rule set. This approach is both more secure and more efficient: it eliminates the need for broad inbound allow rules while also reducing the per-packet computational cost for established sessions.

STATEFUL DECISION LOGIC

Decision(pkt) = if lookup(state_table, 5-tuple(pkt)) → ALLOW; else evaluate(rule_base, pkt)

The stateful firewall first performs a hash-based lookup in the state table using the packet's 5-tuple. If a matching entry exists and the packet is consistent with the expected connection state (e.g., TCP flags are valid for the current state), the packet is allowed without rule evaluation. Otherwise, it falls through to the sequential rule base.

⚠

Why State Tables Matter for Security

Without connection tracking, a stateless firewall permitting inbound traffic on high-numbered ports (to receive HTTP responses) inadvertently opens those ports to any external host. An attacker can craft packets with the appropriate port numbers and gain unauthorized access. A stateful firewall closes this gap because it only allows inbound packets that correspond to a connection initiated from within the protected network. This is one of the most significant security advantages of stateful inspection.

SECTION 5

Firewall Rule Structure & Classification

A firewall rule (sometimes called a policy entry or ACL entry) is the atomic unit of a firewall's configuration. Each rule consists of match criteria and an action. Understanding how rules are structured, ordered, and interact is essential for both configuring firewalls correctly and for auditing existing configurations for vulnerabilities. The following diagram and table provide a detailed breakdown of rule components and the evaluation model.

Side-by-side comparison of equivalent firewall configurations. The stateless firewall (left) requires 4 explicit rules to permit two services (HTTPS outbound and SSH inbound) because both outbound and return traffic must be separately authorized. The stateful firewall (right) achieves the same functionality with only 2 rules, because the state table automatically handles return traffic for established connections.

Rule Component	Description	Example Values
Rule Number / Priority	Determines the order in which the rule is evaluated. Lower numbers are evaluated first in most implementations.	`100, 200, 300`
Source IP / CIDR	The originating IP address or subnet. Can be a single host, a CIDR block, or a wildcard (ANY).	`192.168.1.0/24, 10.0.0.5/32, ANY`
Destination IP / CIDR	The target IP address or subnet for the traffic.	`172.16.0.0/16, 0.0.0.0/0`
Protocol	The transport-layer protocol. Common values are TCP (6), UDP (17), and ICMP (1).	`TCP, UDP, ICMP, ANY`
Source Port	The originating port number or range. Often set to ANY for client-initiated connections since clients use ephemeral ports.	`ANY, 1024-65535`
Destination Port	The target port identifying the service. This is the most discriminating field for service-level filtering.	`80 (HTTP), 443 (HTTPS), 22 (SSH)`
Direction	Whether the rule applies to inbound (ingress) traffic, outbound (egress) traffic, or both.	`INBOUND, OUTBOUND`
Action	The disposition of matching packets. ALLOW (permit/accept) forwards the packet; DENY (drop/reject) discards it. DROP silently discards; REJECT sends an error back.	`ALLOW, DENY, DROP, REJECT`

Anatomy of a Firewall Rule

💡

DROP vs. REJECT

When a firewall denies a packet, it can either drop it silently (no response sent to the sender) or reject it by sending back a TCP RST or ICMP Port Unreachable message. DROP is generally preferred for external-facing firewalls because it gives attackers no information about the existence or state of the firewall, while REJECT may be appropriate internally to help administrators quickly diagnose connectivity issues.

SECTION 6

Worked Example — Designing a Firewall Rule Set

Consider a small corporate network with the subnet 10.0.1.0/24. The organization requires three things: (1) all internal hosts should be able to browse the web via HTTPS, (2) an internal web server at 10.0.1.10 must be accessible from the Internet on port 443, and (3) an SSH management server at 10.0.1.20 must be reachable only from the IT admin subnet 10.0.2.0/24. All other traffic should be denied. We will configure this for a stateful firewall.

Configuring a Stateful Firewall Rule Set

1
Step 1 — Identify Required Flows

We enumerate each legitimate traffic flow that the firewall must permit. Flow A: internal hosts (10.0.1.0/24) → any external IP on destination port 443 (TCP). Flow B: any external IP → 10.0.1.10 on destination port 443 (TCP). Flow C: 10.0.2.0/24 → 10.0.1.20 on destination port 22 (TCP). Since we are using a stateful firewall, we do not need to create explicit rules for return traffic.

Three outbound/inbound flows identified; return traffic handled automatically by state table.
2
Step 2 — Write Rules with Specificity Ordering

We place the most specific rules first. Rule 100 permits the IT admin subnet to SSH into the management server—this is the most restrictive rule (specific source and destination). Rule 200 permits any external host to access the public web server—this is moderately specific (any source, specific destination). Rule 300 permits internal hosts to initiate HTTPS connections to any destination—this is the broadest allow rule. Placing specific rules before broad rules prevents the broad rule from inadvertently matching traffic that should be handled by a more specific rule.

Rule ordering: 100 (SSH-admin) → 200 (web-server-inbound) → 300 (internal-HTTPS-out) → Default DENY.
3
Step 3 — Define Each Rule Precisely

Rule 100: Direction = INBOUND, Source = 10.0.2.0/24, Destination = 10.0.1.20/32, Protocol = TCP, Dst Port = 22, Action = ALLOW. Rule 200: Direction = INBOUND, Source = 0.0.0.0/0, Destination = 10.0.1.10/32, Protocol = TCP, Dst Port = 443, Action = ALLOW. Rule 300: Direction = OUTBOUND, Source = 10.0.1.0/24, Destination = 0.0.0.0/0, Protocol = TCP, Dst Port = 443, Action = ALLOW.

Three explicit ALLOW rules, each scoped to least privilege.
4
Step 4 — Set the Default Policy

The implicit final rule—often called Rule 65535 or the default deny—is: Direction = ANY, Source = 0.0.0.0/0, Destination = 0.0.0.0/0, Protocol = ANY, Action = DENY. This ensures that any traffic not explicitly permitted by Rules 100–300 is silently dropped. This is the 'default deny' posture.

Complete rule set: 3 allow rules + 1 default deny = 4 total entries. With a stateless firewall, we would need 6 allow rules (adding return-traffic rules for each) plus the default deny.
5
Step 5 — Verify with Test Packets

Consider a test packet: source = 203.0.113.50, destination = 10.0.1.20, protocol = TCP, destination port = 22. This packet claims to be an SSH connection from an external host to the management server. Rule 100 requires source ∈ 10.0.2.0/24; 203.0.113.50 is not in that range, so Rule 100 does not match. Rule 200 requires destination = 10.0.1.10 on port 443; this fails. Rule 300 is outbound only. No rules match, so the default deny applies and the packet is dropped—exactly as intended.

Unauthorized SSH attempt correctly blocked by the rule set.

SECTION 7

Stateful vs. Stateless — Strengths & Limitations

Both stateful and stateless firewalls have distinct strengths and weaknesses, and modern network architectures often employ both. Stateless filters excel in high-throughput environments where simplicity and speed are paramount—hardware routers performing initial packet filtering at line rate, for example—while stateful inspection provides the nuanced security required at network perimeters and for regulatory compliance.

Criterion	Stateless Firewall	Stateful Firewall
Packet Context	Each packet evaluated independently; no memory of prior packets.	Maintains a state table tracking active connections; return traffic auto-permitted.
Rule Complexity	Requires separate rules for both directions of a connection (outbound + return).	Only requires rules for the initiating direction; return traffic is tracked.
Performance	Very fast; O(n) rule evaluation per packet, no state lookups. Suitable for ASIC/hardware implementation.	State table lookup (typically O(1) hash lookup) for known connections; O(n) rule evaluation only for new connections.
Security Depth	Vulnerable to spoofed packets that match permissive return rules. Cannot detect out-of-state TCP packets.	Rejects packets that don't match expected TCP state machine transitions. Blocks spoofed return traffic.
Resource Usage	Minimal memory; no session tracking structures.	Requires memory for state table; vulnerable to state table exhaustion attacks (e.g., SYN floods).
UDP / ICMP Handling	Treats each datagram independently; no concept of a UDP session.	Creates pseudo-sessions for UDP and ICMP based on timeouts and source/destination tuples.
Common Use Cases	Router ACLs, cloud network ACLs (e.g., AWS NACLs), high-speed backbone filtering.	Perimeter firewalls, host-based firewalls (iptables, Windows Firewall), cloud security groups.

Comprehensive Comparison of Stateless and Stateful Firewalls

🏗️

DESIGN PATTERN IN PRACTICE

In modern cloud architectures like AWS, you typically encounter both types working in tandem: Network ACLs (NACLs) are stateless and operate at the subnet level, while Security Groups are stateful and operate at the instance level. This layered approach—sometimes called defense in depth—combines the speed of stateless filtering with the precision of stateful inspection, analogous to having both a perimeter fence and locked doors within a building.

SECTION 8

Connection to Advanced Theory — Beyond Traditional Firewalls

Traditional stateless and stateful firewalls form the foundation upon which more advanced network security technologies are built. Understanding these fundamentals is essential before studying next-generation firewalls (NGFWs), intrusion detection/prevention systems (IDS/IPS), and zero-trust architectures. The table below maps the concepts covered in this lesson to their advanced counterparts.

Foundational Concept	Advanced Extension	Key Enhancement
Stateless packet filtering (5-tuple)	Deep Packet Inspection (DPI)	Examines payload content beyond headers; can identify applications regardless of port (e.g., detecting BitTorrent on port 443).
Stateful connection tracking	Application-Aware Firewalls (NGFW)	Extends state tracking to Layer 7 application protocols; can distinguish between Skype, Zoom, and generic HTTPS traffic on the same port.
Allow/Deny rule actions	Intrusion Prevention (IPS)	Adds signature-based and anomaly-based detection; can block packets containing known exploit payloads, not just based on header fields.
Perimeter-based trust model	Zero Trust Architecture (ZTA)	Eliminates implicit trust based on network location; every access request is authenticated and authorized regardless of source, using micro-segmentation.
Static rule configuration	Adaptive / ML-Driven Firewalls	Uses machine learning to dynamically adjust rule sets based on observed traffic patterns and threat intelligence feeds.

From Foundational Firewall Concepts to Advanced Security Technologies

As you progress in your study of network security, you will encounter scenarios where traditional firewalls are insufficient. Encrypted traffic (TLS 1.3) renders payload-level inspection impossible without TLS interception proxies, raising both technical and ethical questions. Cloud-native environments with ephemeral containers and service meshes require programmable, API-driven firewall policies that can adapt in milliseconds. The conceptual framework of rule evaluation, state tracking, and default policies, however, remains constant across all these advanced systems. Mastery of these fundamentals will serve as your lens for understanding any network security technology you encounter.

SECTION 9

Practice Problems

Question 1: CONCEPTUAL

A network administrator configures a firewall with a default-allow policy and adds individual rules to block known malicious IP addresses. Explain why this approach is considered less secure than a default-deny policy, and describe a specific attack scenario that this configuration would fail to prevent.

Show answer

A default-allow (blacklisting) policy permits all traffic unless explicitly blocked, which means any threat not anticipated by the administrator passes through freely. This is inherently weaker because the space of possible threats is effectively unbounded—new malicious IPs, novel attack vectors, and zero-day exploits will not appear on any blocklist. A specific scenario: an attacker uses a previously unseen IP address (not on the blocklist) to probe internal services on open ports. Under default-allow, this probing traffic is permitted, potentially revealing exploitable services. Under default-deny, only explicitly authorized traffic flows are permitted, so the attacker's probe would be silently dropped regardless of whether the administrator had prior knowledge of that specific threat.

Question 2: BASIC CALCULATION

A stateless firewall needs to support the following requirements: (a) internal hosts can access external web servers on ports 80 and 443, (b) an internal mail server must receive SMTP connections on port 25 from external hosts, and (c) internal DNS queries must reach an external DNS server on port 53 (UDP). Assuming a default-deny policy, how many explicit rules are required for a stateless firewall versus a stateful firewall? List each rule for the stateless case.

Show answer

For a stateless firewall, each bidirectional flow requires two rules (outbound + return), and each distinct port/protocol combination is a separate flow. Flow count: HTTP outbound (1), HTTPS outbound (1), SMTP inbound (1), DNS outbound (1) = 4 flows. Stateless rules needed: 4 flows × 2 directions = 8 explicit allow rules plus the default deny, totaling 9 entries. Specifically: (1) OUT: internal→any:80/TCP, (2) IN: any:80→internal/TCP, (3) OUT: internal→any:443/TCP, (4) IN: any:443→internal/TCP, (5) IN: any→mail-server:25/TCP, (6) OUT: mail-server:25→any/TCP, (7) OUT: internal→DNS:53/UDP, (8) IN: DNS:53→internal/UDP. For a stateful firewall, only 4 rules are needed (one per flow, plus default deny = 5 entries), because return traffic is automatically allowed by connection tracking.

Question 3: INTERMEDIATE

Consider the following ordered rule set on a stateful firewall: Rule 1: ALLOW TCP from 10.0.0.0/8 to ANY on port 443. Rule 2: DENY TCP from 10.0.1.0/24 to ANY on port 443. Rule 3: ALLOW TCP from ANY to 10.0.0.5 on port 80. Default: DENY ALL. A host at 10.0.1.50 attempts to connect to an external HTTPS server. What happens, and why? How should the rules be reordered to correctly block the 10.0.1.0/24 subnet from HTTPS access while allowing the rest of 10.0.0.0/8?

Show answer

Under first-match semantics, the packet from 10.0.1.50 (which is within 10.0.0.0/8) destined for port 443/TCP is evaluated against Rule 1 first. Since 10.0.1.50 matches the 10.0.0.0/8 CIDR block and the destination port is 443/TCP, Rule 1 matches and the action ALLOW is applied. Rule 2 is never evaluated for this packet. This is a classic rule shadowing problem: Rule 2 is entirely shadowed by Rule 1 because Rule 1's match criteria are a superset of Rule 2's. To fix this, Rule 2 should be moved above Rule 1, making the more specific deny rule take precedence. The corrected order would be: Rule 1: DENY TCP from 10.0.1.0/24 to ANY:443; Rule 2: ALLOW TCP from 10.0.0.0/8 to ANY:443; Rule 3: ALLOW TCP from ANY to 10.0.0.5:80; Default: DENY ALL. The general principle is: place more specific rules before more general ones.

Question 4: APPLIED

You are designing the network security for a small e-commerce company. The architecture includes: a public web server (192.168.1.10), a database server (192.168.1.20) that should only be accessible from the web server, and employee workstations on 192.168.2.0/24 that need internet access (HTTP/HTTPS) and SSH access to the web server for maintenance. Design a complete stateful firewall rule set with proper ordering and a default-deny policy. Justify your rule ordering.

Show answer

The rule set should be ordered from most specific to least specific: Rule 100 (most specific): ALLOW TCP from 192.168.1.10/32 to 192.168.1.20/32 on port 3306 (MySQL)—permits only the web server to communicate with the database. Rule 200: ALLOW TCP from 192.168.2.0/24 to 192.168.1.10/32 on port 22—permits employees to SSH into the web server for maintenance. Rule 300: ALLOW TCP from 0.0.0.0/0 to 192.168.1.10/32 on port 443—permits public HTTPS access to the web server. Rule 400: ALLOW TCP from 192.168.2.0/24 to 0.0.0.0/0 on ports 80,443—permits employee workstations to browse the web. Rule 500 (Default): DENY ALL from 0.0.0.0/0 to 0.0.0.0/0. The ordering is justified because Rule 100 isolates the database (most critical asset); Rule 200 restricts SSH access before the broader web access rule in Rule 300; Rule 400 is the broadest allow rule. A stateful firewall automatically handles all return traffic, so no additional inbound rules are needed for employee web browsing or web-server-to-database responses.

Question 5: CRITICAL THINKING

A stateful firewall maintains a connection table with entries for each active session. An attacker launches a SYN flood attack, sending thousands of TCP SYN packets per second from spoofed source IP addresses to a target behind the firewall. Analyze how this attack affects a stateful firewall differently than a stateless firewall. Discuss the concept of state table exhaustion, propose at least two mitigation strategies, and evaluate whether a purely stateless approach would be more resilient in this specific attack scenario.

Show answer

A SYN flood exploits the stateful firewall's need to allocate memory for each new connection. Each incoming SYN destined for an allowed port causes the firewall to create a state table entry in SYN_RECEIVED status, consuming memory and data structure slots. With thousands of spoofed SYNs per second, the state table can be exhausted, causing the firewall to either crash, drop legitimate new connections, or degrade to an open-fail mode—all of which compromise security. A stateless firewall, by contrast, does not maintain a state table and thus cannot suffer state table exhaustion; it simply evaluates each SYN against its rule set and forwards or drops it. In this narrow sense, a stateless firewall is more resilient to SYN floods. However, this resilience comes at the cost of the security benefits of stateful inspection. Mitigation strategies for stateful firewalls include: (1) SYN cookies, where the firewall does not allocate state until the TCP handshake completes, encoding session information in the initial sequence number; (2) rate limiting, capping the number of new SYN packets accepted per second from any single source or globally; (3) aggressive timeouts, reducing the time a half-open connection occupies the state table; and (4) deploying a stateless filter upstream that rate-limits SYN packets before they reach the stateful firewall, creating a layered defense architecture.

SUMMARY

Lesson Summary

Summary

A firewall is a network security device or software module that enforces an organization's traffic policy by evaluating packets against an ordered set of rules. Each rule specifies match criteria—typically the 5-tuple of source IP, destination IP, source port, destination port, and protocol—paired with an action: allow or deny. Rules are evaluated using first-match semantics, making rule ordering critical: more specific rules must precede broader rules to avoid rule shadowing. The recommended security posture is default deny, where all traffic not explicitly permitted is dropped.

The two foundational architectures are stateless firewalls, which evaluate each packet independently against the full rule set, and stateful firewalls, which maintain a connection state table that tracks active sessions and automatically permits return traffic. Stateless filters are fast and resource-efficient but require bidirectional rules and are vulnerable to spoofed packets. Stateful filters provide stronger security with simpler rule sets but consume memory for session tracking and can be targeted by state table exhaustion attacks. In modern networks, these technologies are deployed in defense-in-depth layers and serve as the foundation for next-generation firewalls, intrusion prevention systems, and zero-trust architectures.