At so many such leading-edge checkpoints in any network, the most significant being what an organization trusts versus everything else, there will be a firewall. Whatever the dividing line (whether it be between an internal network and the public internet or simply an isolated part of a network), traffic crossing that barrier is inspected by the firewall to determine, on a packet-by-packet or connection-by-connection basis, what should be permitted through and what should be blocked.
It might sound simple by that description, but the mechanics behind it have become markedly more complicated since firewalls first emerged on the security landscape. The key to understanding how they work is not simply knowing that firewalls exist, but understanding why they exist and why many organizations layer multiple approaches.
You can read a full breakdown of what is a firewall for networks, which covers the broader category of firewall technologies in more detail than this article focuses on.
The Basic Filtering Decision
A firewall is essentially a set of rules for the traffic over a set of rules usually referred to as a ruleset/policy. A rule is typically defined by certain criteria that may include a source and destination IP, port numbers and the protocol configured. Upon receipt of a packet, the firewall inspects its header information against the ruleset and performs whatever action is described by the matching rule; allowing it through, stopping it silently or with an explicit error message.
Packet filtering is a very simple technique, the first firewall technique that came into practice and also the fundamental layer of many more advanced systems. The reason packet filters are so fast is that they only have to look at the headers of packets, rather than their entire payloads; unfortunately, this tradeoff means that a packet filter alone cannot determine whether a series of permitted packets corresponds to an actual connection, or just something suspicious.
What Stateful Inspection Changed the Equation
The solution to this challenge was stateful inspection, which basically gave firewalls a memory. Unlike a stateless firewall, which evaluates every packet in isolation, a stateful firewall keeps track of the state of each connection that passes through it and uses a table to store information such as which connections have been established, what sequence numbers are expected next (in TCP), and whether traffic is part of another session or an entirely new request.
This matters because many attacks rely on crafting packets that look legitimate in isolation but make no sense in the context of an actual conversation between two systems. A stateful firewall can recognize, for example, that a packet claiming to be a response to a request was never actually preceded by that request, and block it accordingly. This context-aware filtering represented a significant step up from pure packet filtering, and detailed guidance on these distinctions, along with broader firewall policy considerations, appears in the firewall policy guidelines overview published by NIST.
Moving Beyond the Network Layer
Packet filtering and stateful inspection essentially work at the network and transport layers, checking IP addresses, ports, and connection states but not necessarily diving deep into the content of packets as they pass through the firewall. The most advanced type of filtering, application-layer filtering, goes one step further by actually inspecting the data payload itself: an application-level firewall can make decisions based on what that application is really doing and not just which port it’s using at the moment.
The deeper inspection allows firewalls to enforce more granular policies like allowing web traffic in general but barring specific types of websites, or allow legitimate commands for a particular application while blocking commands associated with well-known exploitation techniques. The tradeoff is one of compute: scanning through content will consume a lot more processing than simply looking at headers, which is also part of why application layer inspection (which needs to examine full packet) has historically been coupled with significant hardware acceleration in higher-throughput environments.
A Broad Network Architecture: Where Do Firewalls Fit In?
Firewalls do not work alone or in complete isolation to guard the whole organization on its own with a single rule set. Layered advantage: A layered approach helps most networks where firewalls are deployed at different points to segregate zones of trust. While they both provide the same fundamental filtering mechanisms, a firewall shielding the link to the public internet has a very different function than one separating finance systems from other parts of an internal network.
This zoning approach also limits the damage a single compromised system can cause. If an attacker gains access to one segment of a network, internal firewalls can prevent that access from automatically extending to every other segment. Guidance on how to think through this kind of deployment, including where firewalls add the most value and how they should be evaluated over time, is covered in this discussion of firewall deployment best practices, which emphasizes treating firewalls as one component of a broader security strategy rather than a complete solution on their own.
What Firewalls Cannot Do Alone?
Even though firewalls have a critical importance, by themselves they do not offer a complete solution on secure environments. A firewall will keep all unauthorized network traffic out and disallow traffic that breaches its ruleset, but it generally does not inspect encrypted traffic without supplementary decryption capabilities or protect against threats introduced into the environment through channels outside its purview (like a malicious email attachment that arrives by way of an entitled user who has already gained valid access to the network).
Hence, firewalls are usually placed along with security approaches and not standalone solutions. Firewalls have many good attributes, but you are on data curated up to October 2023), and intrusion detection and prevention systems, endpoint protection and email security tools each fill in what a firewall is not architected to close. As with security in general, understanding these limits enables organizations to avoid treating firewall deployment as the ultimate goal of their security planning, and instead to view it as one requirement of a holistic approach.
Keeping Firewall Policies Current
A firewall is only as good as the ruleset that controls it, and unmanaged rulesets will drift over time away from actual network needs. Temporary rules to fix a problem of the moment sometimes stay in place long after the original justification passed, steadily extending the firewall’s attack surface without anyone realizing.
This is achieved by regularly reviewing firewall rules for orphaned or legacy entries (delisted from DNS, systems that have left the organization etc.), and periodically reassessing whether the placement of the firewall still corresponds with an organization’s network architecture. Firewalls that were properly configured for a given network several years ago no longer necessarily represent how some networks actually work today, especially as organizations adopt new applications, cloud services and remote working arrangements that change the shape of actual traffic in ways that the original ruleset never anticipated.
Frequently Asked Questions
A firewall alone cannot provide complete protection for a network.
No. In addition, a firewall is just one line of defense and performs best when supplemented by other security mechanisms such as intrusion detection and prevention systems (IDPS), endpoint protection, security audits, etc.
Is stateful inspection still relevant given more advanced firewall technologies?
Yes. It is important to note that stateful inspection has always been a fundamental capability and even next-generation firewalls are built on top of this, as connection state still needs to be monitored for differentiating legitimate traffic from suspicious traffic patterns.
Should firewalls be reconfigured as the network changes?
Yes. As with any security controls, firewall rules should be reviewed regularly to remove obsolete entries that could create security holes if they do not align with current applications, services, and network architecture.
