The Core Idea
A Rule-Based Checkpoint Between Networks
A firewall sits at a boundary between networks (commonly between a private internal network and the public internet) and inspects traffic attempting to cross that boundary, comparing it against a defined set of rules to decide whether to allow or block it. Rules are typically based on criteria like source/destination IP address, port number, and protocol — 'allow traffic to port 443 (HTTPS) from anywhere, but block all traffic to port 3389 (remote desktop) except from these specific trusted IP addresses.'
Firewalls have evolved through several generations of increasing sophistication, each able to inspect and reason about traffic at a deeper level than the last — from simply checking individual packet headers, to tracking entire connections, to actually understanding the application-level content being transmitted.
💡 Memory Trick
Think of a building's security checkpoint evolving over time. An early PACKET-FILTERING checkpoint just checks each individual visitor's ID badge against a static allow/deny list, one badge at a time, with no memory of who's already inside. A STATEFUL checkpoint remembers who it already let in and is specifically watching for their expected, matching exit — rejecting anyone claiming to be 'just leaving' who was never actually let in to begin with. An APPLICATION-LAYER checkpoint goes further still, actually inspecting the CONTENTS of what each visitor is carrying in their bag, not just checking their badge.
The Firewall Types
Increasing Levels of Inspection
1
Packet-Filtering Firewall
Examines each individual packet in isolation, checking its header information (source/destination IP, port, protocol) against a static rule list, with no memory of previous packets or ongoing connections. Fast and simple, but can't distinguish a legitimate response to an established connection from an unsolicited, potentially malicious packet claiming to be one.
2
Stateful Firewall
Tracks the state of active connections (which outbound requests were legitimately initiated from inside the network), and only allows inbound traffic that's a genuine, matching response to one of those tracked, established connections — blocking unsolicited inbound traffic even if it superficially matches an allow rule, because it doesn't correspond to any connection the stateful firewall actually initiated or is tracking.
3
Application-Layer (Next-Gen) Firewall
Inspects traffic content at the application layer (Layer 7 of the OSI model), understanding specific application protocols well enough to detect and block malicious patterns within otherwise-permitted traffic — like blocking a SQL injection attempt hidden inside an HTTP request to a web application, something a packet-filtering or purely stateful firewall (which only look at headers and connection state, not actual application content) simply cannot see.
Where Firewalls Sit
Network-Level vs. Host-Level Deployment
A network firewall protects an entire network segment by sitting at its boundary (like between a company's internal network and the internet), inspecting all traffic crossing that single choke point. A host-based firewall instead runs directly on an individual device (like a personal computer or a specific server), controlling traffic to and from that one machine specifically — useful as an additional layer of defense even when a network firewall is already in place, since it can stop malicious traffic that somehow already made it past the network perimeter, or traffic between two devices on the SAME internal network.
Real-world security architectures typically layer multiple firewall types together (defense in depth) — a network firewall at the perimeter, plus host-based firewalls on individual sensitive machines, plus application-layer inspection for public-facing web applications — rather than relying on any single firewall to catch every possible threat.
🖥️ Applied Scenario
Your company's web application, protected only by a basic packet-filtering firewall allowing traffic on port 443 (HTTPS), is compromised by an attacker sending malicious SQL injection payloads disguised as normal HTTPS requests.
1
You confirm the packet-filtering firewall correctly allowed this traffic through, since it only inspects packet headers (source/destination, port) — it has no visibility into the actual application-level content of the HTTPS requests, so it couldn't have detected anything wrong.
2
You recognize that even a stateful firewall wouldn't have helped here, since the malicious requests were part of legitimately-established connections — the problem isn't about connection state, it's about the CONTENT within an otherwise valid connection.
3
You deploy an application-layer (next-gen) firewall in front of the web application specifically, configured to recognize and block common SQL injection patterns within HTTP request content.
4
Conclusion: because the attack exploited application-level content rather than anything visible at the packet-header or connection-state level, only an application-layer firewall — capable of actually inspecting that content — could have detected and blocked it.
📌 Exam Application
Exam questions frequently ask you to distinguish packet-filtering, stateful, and application-layer firewalls by exactly what information each one inspects and what kinds of threats each can or cannot detect. You may also be asked to identify which firewall type is needed to stop a described attack, based on whether the malicious element is visible at the header level, connection-state level, or only within the application-layer content itself.
⚠️ Most Common Firewalls Mistakes
The most common mistake is assuming a stateful firewall provides meaningfully more security against application-level attacks (like SQL injection or cross-site scripting) than a simple packet-filtering firewall — stateful inspection improves security specifically against attacks that exploit connection-state confusion (like certain spoofing attempts), but it still has no visibility into application-layer content, so it offers no protection against attacks embedded within otherwise legitimate, established connections. Another frequent error is assuming a firewall alone is sufficient network security — firewalls control what traffic is allowed to pass based on defined rules, but they don't inherently detect all forms of malicious content within allowed traffic, encrypted threats, or attacks originating from an already-compromised internal device, which is why they're typically deployed as one layer among several in a broader security strategy.
✓ Quick Self-Test
Can you explain the key difference between what a packet-filtering firewall and a stateful firewall each track and inspect? Given a described attack, can you identify which type of firewall (if any) would actually be capable of detecting and blocking it?
→
← All Networking Lessons