2026
Firewall: Controlling What Gets In and Out
A firewall sits in the path of network traffic and decides which packets are allowed to pass. Here is how rule evaluation works, what stateful inspection actually means and where firewalls fit in a layered security model.
Every device connected to a network is reachable from somewhere. That reach needs limits. A firewall is what applies them. It sits in the path of network traffic and decides, based on a set of rules, which packets are allowed to pass through and which are not.
The idea is straightforward but the details matter. Where the firewall sits, what layer it operates at, what it can actually see about the traffic passing through it — these things determine what it can protect against. A firewall that only checks IP addresses cannot stop a malicious HTTP request. A firewall that inspects full request bodies introduces latency. The right choice depends on what you are trying to defend.
What a firewall actually does
At its core a firewall evaluates traffic against a rule set and produces one of two outcomes: allow the packet through or drop it. Some firewalls add a third option — reject — which sends an explicit refusal back to the sender rather than silently discarding the packet. Dropping is generally preferred for inbound traffic from the internet because it gives less information to whoever is probing the host.
Rules are evaluated in order. The first rule that matches the packet wins. This ordering is important. A broad allow rule placed before a narrow deny rule will catch everything the deny rule was meant to block. Most rule sets are written with specific allows at the top and a default deny at the bottom covering everything that did not match anything else.
Simplified rule evaluation
Packet arrives at the firewall
↓ compared against rule 1
↓ no match → compared against rule 2
↓ no match → compared against rule 3
↓ no match → default policy applies
Packet is allowed or dropped
The default policy is either allow or deny. A default allow policy means unknown traffic passes. A default deny policy means only explicitly permitted traffic passes. Almost every security-conscious environment uses default deny. The burden is on administrators to define what should be allowed rather than reacting to what should be blocked.
Types of firewall
Firewalls are not all the same. They differ in what they can inspect, which shapes what they can enforce.
Packet filter
The oldest form of firewall. It inspects each packet individually and decides whether to allow it based on source IP, destination IP, port numbers and the protocol field in the header. It has no memory of previous packets. Each decision is made in isolation. Fast to process, but easy to fool if an attacker can craft packets that look legitimate on their own.
Stateful firewall
A stateful firewall tracks the state of active connections. When a new TCP connection starts with a SYN packet, the firewall records it. Subsequent packets belonging to that same connection are checked against the state table rather than evaluated from scratch. This means a packet arriving without a matching connection entry can be dropped even if its headers would otherwise look fine.
Application layer firewall
These firewalls operate at Layer 7. They can read the actual content of HTTP requests, DNS queries, SMTP envelopes and other application protocols rather than just looking at ports. A packet destined for port 80 could carry anything. An application layer firewall can tell whether it is valid HTTP and whether that request is trying to do something it should not.
Next-generation firewall (NGFW)
A marketing term that stuck. NGFWs combine stateful inspection with application awareness, intrusion prevention, TLS inspection and often some form of threat intelligence feed. The idea is that a single device can enforce policy at multiple levels simultaneously rather than requiring separate appliances for each concern.
Stateful versus stateless inspection
The difference between stateful and stateless inspection comes down to memory. A stateless firewall treats every packet as if it appeared out of nowhere. A stateful firewall remembers what happened before.
Consider an outbound HTTP request. The client sends a SYN. The server replies with a SYN-ACK. A stateless firewall evaluating the SYN-ACK sees an inbound TCP packet. Whether it is allowed depends entirely on the rules for inbound TCP at that port. A stateful firewall knows a SYN went out first. The SYN-ACK belongs to an existing conversation. It passes automatically.
The state table is also where connection tracking helps with protocols that open secondary channels. FTP in active mode instructs the server to initiate a data connection back to the client on a negotiated port. A stateless firewall has no way to know that the inbound connection was expected. A stateful firewall watching the control channel knows to allow it.
Connection states tracked by a stateful firewall
NEW — first packet of a connection not yet in the state table
ESTABLISHED — part of a connection that has been fully set up
RELATED — associated with an existing connection (e.g. FTP data channel)
INVALID — does not match any known state — drop this
Where a firewall sits in the network
Firewalls show up at several points in a network topology at once. Each position enforces a different boundary.
Common firewall positions
Internet
↓
Perimeter firewall
↓ controls traffic entering the organisation
DMZ (web servers, reverse proxies, mail servers)
↓
Internal firewall
↓ controls traffic between zones inside the network
Internal network (databases, services, workstations)
↓
Host-based firewall
↓ rules applied at the individual server level
Application
The DMZ pattern puts internet-facing servers in a separate zone. If one of those servers is compromised, the internal firewall still blocks direct access to the database network. The attacker has a foothold in the DMZ but needs to get through a second boundary to reach anything more sensitive. Layered controls mean a single failure does not expose everything.
Common rule patterns
Most firewall rule sets are built from a small number of patterns that repeat across different environments.
Allow established connections
Allow packets that belong to a connection the firewall already accepted. Without this, a stateful firewall would block the reply traffic from every outbound connection.
Allow inbound HTTPS
Accept TCP packets destined for port 443 from any source. This is the minimum needed for a public web server to be reachable.
Block inbound traffic by default
A default deny rule sits at the bottom of most rule sets. Anything that did not match an explicit allow rule is dropped. This is the correct default. Allowing everything except known-bad traffic tends to leave large gaps.
Restrict management access by source IP
SSH and admin interfaces should only accept connections from known addresses. Exposing port 22 to the entire internet invites constant scanning. Binding it to a specific management subnet reduces that surface area immediately.
iptables on Linux
On Linux, the kernel's netfilter framework handles packet filtering. The iptables command is the traditional interface to it. Rules are organised into chains. The three default chains for a host are INPUT for traffic destined for the host itself, OUTPUT for traffic originating from the host and FORWARD for traffic passing through the host to somewhere else.
Allow established and related traffic
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Permits replies to connections initiated from inside. Without this, the host would receive responses but drop them.
Allow inbound SSH from a specific subnet
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j ACCEPT
Restricts SSH access to the 10.0.0.0/24 subnet. Any connection attempt from outside that range hits the default policy.
Allow inbound HTTPS
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Opens port 443 to all sources. Combine with rate limiting if the host is exposed directly to the internet.
Default deny for INPUT
iptables -P INPUT DROP
Sets the default policy for the INPUT chain to DROP. Anything that does not match a preceding rule is silently discarded.
nftables is the newer replacement for iptables. It uses a single tool for all filtering rather than separate commands for IPv4, IPv6 and ethernet. The concepts are the same. Rules live in chains inside tables. The default policy on a chain determines what happens to packets that match nothing.
What a firewall cannot do
A firewall controls which connections are permitted. It does not control what those connections carry once they are allowed through.
A rule allowing inbound HTTPS traffic to a web server will pass every request on port 443 regardless of what the request contains. SQL injection attempts, path traversal attacks, malformed JSON payloads — these all arrive through a port the firewall was told to allow. The firewall has no basis to distinguish them from legitimate traffic at the network layer.
Insider threats and compromised credentials are similarly outside the firewall's scope. A connection from an authorised IP on an authorised port carrying traffic that looks correct will pass. What the person making that connection is actually doing is a question for application logging, monitoring and access controls rather than for the firewall.
Encrypted traffic presents a specific challenge. A standard stateful firewall cannot inspect the payload of a TLS connection without breaking and re-establishing the session using its own certificate. Many NGFWs offer TLS inspection for exactly this reason. It requires the firewall's certificate authority to be trusted by the clients behind it, which typically means it is only practical on managed devices in a controlled environment.
Where it fits
A firewall is not a security strategy on its own. It is one control in a set of controls. It enforces network-level boundaries. It keeps services that should not be reachable from being reached. It limits the blast radius when something inside the network is compromised by preventing lateral movement to other segments.
The value is in the defaults. A host with no firewall accepts connections on every port where something is listening. A host with a default deny firewall accepts connections only where you explicitly decided it should. The second host is easier to reason about. When something unexpected happens, the list of things that could have reached it is known.
Most of the time a firewall is quiet. Rules that are doing their job generate no alerts. The connections they block never complete. That is the point. The firewall is most visible when it is misconfigured — either blocking traffic that should get through or allowing traffic that should not. Getting the rule order right and keeping the default deny in place is what makes it useful.