3.4 - Protecting Networks: Firewalls
Network-Based Firewalls
A firewall filters network traffic, allowing or blocking packets based on configured rules, and can run as a dedicated appliance, be built into a router, run as software on a server, or exist as a cloud-based service.
Stateless Firewalls
Stateless firewalls filter based only on what's in each individual packet's header, like source and destination IP, source and destination port, and protocol, evaluating every packet completely independently with no memory of what came before.
Example: a rule allowing outbound traffic to destination port 80 lets an employee's web request out to a server, but the response coming back in (with a source port of 80 and a destination that's some random high-numbered port) doesn't match that same rule, since the firewall has no idea it's actually part of the same conversation, so it can get blocked entirely unless a separate rule accounts for it.
This creates real problems: no way to track whether packets belong to an actual established connection, difficulty allowing legitimate response traffic without opening up high-numbered ports to everyone, blind spots for attacks that span multiple packets, and messy rule sets needed just to handle both directions of traffic. A common workaround is opening up all inbound traffic to high-numbered ports hoping only legitimate responses use them, but that itself creates a security hole attackers can exploit directly.
Stateful Firewalls
Stateful firewalls track the state of each connection instead of looking at packets in isolation, maintaining a table of active sessions and understanding what stage each one is in: NEW (first packet establishing a connection), ESTABLISHED (part of an existing session), RELATED (tied to an existing connection, like an FTP data channel related to its control channel), or INVALID (doesn't match anything known).
Example: an employee's outbound request to a web server gets marked NEW and allowed, creating an entry in the connection table. When the response comes back, the firewall recognizes it as ESTABLISHED, matching that table entry, and allows it automatically, even without an explicit rule permitting inbound traffic to that random high port. A stateless firewall would've needed an explicit rule opening high ports to everyone (a security risk) or a rule for every possible port combination (impractical).
Stateful firewalls simplify rule sets since you don't need explicit rules for response traffic, improve security by only allowing inbound traffic that's actually part of a legitimate outbound-initiated session, block unsolicited inbound attempts even on high ports, and understand complex multi-channel protocols like FTP.
Because a stateful firewall still reads packet headers, it can do all the filtering a stateless firewall does and then add connection-based rules on top. The traffic it allows changes as connections open and close, which is why stateful filtering is also called dynamic packet filtering.
Example: with a simple rule set (allow outbound HTTP/HTTPS, allow established and related inbound, deny everything else), an employee's browsing works fine since responses get automatically allowed as established traffic, but an external attacker trying to connect directly to that same employee's device on some random port gets blocked immediately, since it doesn't match anything in the state table.
Next-Generation Firewalls (NGFW)
NGFWs combine traditional stateless and stateful filtering with much deeper inspection and threat prevention. On top of the basics, they add intrusion prevention that actively blocks known attack patterns, deep packet inspection that examines full payloads rather than just headers, application awareness that identifies specific apps regardless of port, user identity integration tied to systems like Active Directory, SSL/TLS inspection that decrypts and inspects traffic before re-encrypting it, threat intelligence feeds blocking known malicious IPs and domains, and advanced malware protection through sandboxing and behavioral analysis.
Example: instead of a traditional firewall that can only block or allow entire ports (accidentally blocking legitimate business use of things like port 443 along with unwanted apps), an NGFW can specifically identify and block something like Facebook while still allowing other HTTPS traffic through, since it actually recognizes the application itself, not just the port it's using.
Example use case: a company wants employees using company email but not personal webmail, and wants to block large file uploads regardless of app. An NGFW can enforce all of that by application, something a traditional firewall simply can't distinguish.
Deep packet inspection example: an attacker hides malware inside a PDF attachment. A traditional firewall just sees legitimate email traffic and lets it through. An NGFW actually opens up and inspects the PDF's contents, spots the malicious embedded script, blocks the email, and alerts the security team, all before it ever reaches anyone's inbox.
IPS example: an attacker sends crafted HTTP requests attempting SQL injection against a web app. A traditional firewall sees ordinary HTTP traffic on an allowed port and lets it through. An NGFW inspects the actual request contents, recognizes the injection pattern against its signature database, blocks it, logs it, and can even temporarily or permanently block that attacker's IP.
NGFWs make the most sense in high-security environments, places with lots of web applications needing granular control, and anywhere facing sophisticated, persistent threats. They cost more than traditional firewalls, so organizations typically deploy them at the perimeter and DMZ boundaries while using simpler stateful firewalls for internal segmentation.
Side by side:
Firewall type | What it filters on | Example |
Stateless | Each packet's header on its own: source and destination IP addresses, ports, and protocol | Allows any packet headed to TCP port 443, with no memory of earlier packets |
Stateful (dynamic packet filtering) | Everything a stateless firewall checks, plus the state of each connection | Lets a reply back in only because it matches a connection an inside device started |
Next-generation (NGFW) | Everything stateless and stateful firewalls check, plus intrusion prevention, deep packet inspection, and filtering by application type | Blocks one specific app even though it uses the same allowed port as normal web traffic |
Access Control Lists (ACLs)
ACLs are the rule sets firewalls use to permit or deny traffic. Each rule specifies a direction (inbound or outbound), filtering criteria (IPs, ports, protocols), and an action (permit or deny).
The criterion can be an IP address (or a range of them), a logical port, a service, or an application. A logical port is the number that identifies a service, like 22 for SSH. It has nothing to do with the physical ports (jacks) on a switch that port security protects.
Example rules might allow inbound SSH from anywhere, deny inbound web traffic from a specific internal subnet, allow outbound email traffic, and finish with an implicit deny for everything else not explicitly allowed.
Sequential Rule Processing
Firewalls check rules top to bottom, and the very first rule that matches gets applied, with nothing after it evaluated for that packet. This means rule order matters enormously, since the exact same rules in a different order can produce completely different behavior.
Example of correct order: allow SSH from an internal range first, then deny SSH from everywhere else, then allow HTTPS from anywhere, then deny everything else. An SSH attempt from the internal range matches the first rule and gets through. An SSH attempt from outside fails the first rule but matches the second, getting denied. An HTTPS request skips the first two and matches the third, getting allowed.
Example of incorrect order: putting a broad "deny all inbound TCP" rule first, before the specific allow rules that were meant to permit SSH and HTTPS. Since the firewall stops at the first match, that overly broad deny rule blocks everything immediately, and the intended allow rules never even get evaluated, a misconfiguration that would break legitimate access entirely.
Good practice: put the most specific rules first, save broad catch-all rules for the end, place explicit denies before general allows when you're blocking something specific, and always finish with a default deny covering anything not explicitly permitted.
Example of well-ordered rules: specific allows for a known admin IP and a partner network go first, then a specific deny for a known malicious network, then a general allow for HTTPS from anywhere, and finally a catch-all deny at the very end. This way critical access isn't accidentally blocked, known threats get stopped before the general allow rule would've let them through, and everything else not explicitly permitted gets denied by default.
Firewall Placement Strategy
Segmentation Firewalls
Each network segment should have its own firewall managing what flows in and out. This provides defense in depth (bypassing one firewall doesn't grant unrestricted access everywhere), prevents lateral movement between segments, and allows tailored policies per segment.
Example layered setup: a perimeter firewall filters internet traffic aggressively, an internal firewall tightly restricts what the DMZ can reach inside, and separate firewalls sit in front of the user segment, server segment, database segment, and management segment, each enforcing rules appropriate to that zone.
Example containment: an attacker compromises a DMZ web server through a vulnerability. Without segment firewalls, they could freely scan and access the entire internal network. With them in place, scanning attempts toward the corporate network get blocked by the internal firewall, attempts to reach database servers get blocked except for the few specific allowed queries, and any attempt to open a reverse shell back out to the attacker gets blocked by the perimeter firewall. The compromised server stays isolated, and the attacker gets a foothold but can't actually accomplish anything further.
Independent Security Levels
Different segments naturally need different levels of restriction based on data sensitivity, compliance requirements, exposure to the public internet, and normal operational traffic patterns.
Example: a database segment might allow only very specific database ports from specific application servers, require certificate authentication, log every connection attempt, and alert on any denial. A standard user segment might allow file server and business app access along with general internet browsing, with moderate logging. A guest segment might allow DNS and general internet access outbound while completely denying anything toward internal networks, with alerts specifically for any attempt to reach internal systems. Each firewall is tuned to match its own segment's actual role and risk level.
Internet Boundary Protection
Every single point where an internal network touches the public internet (every point of data ingress and egress, where data comes in or goes out) needs its own firewall protection, including the primary ISP connection, any backup ISP links, direct partner connections, and remote access VPN endpoints.
Example: a company has a well-protected primary internet connection but adds a backup ISP link for redundancy without bothering to firewall it, assuming it's "just for emergencies." An attacker eventually discovers that unprotected backup connection and uses it to get into the internal network, completely bypassing the strong primary perimeter. Every connection point needs consistent protection, both for security and often for compliance requirements, and firewalls at each point also provide visibility through logging and monitoring.
Configuring Firewall Rules
Before writing rules, it helps to clearly define what traffic should be allowed (like web browsing, remote admin access, email, and specific business apps), what should be denied (known bad sources, unnecessary protocols, direct access to sensitive systems, peer-to-peer traffic), and where traffic should originate and terminate.
A basic rule format specifies an action, direction, protocol, port, source, and destination. For example, allowing inbound SSH from anywhere permits SSH attempts from any source, which might be intentional if remote access needs to be broadly available (though usually you'd restrict it to specific IPs). Denying inbound HTTP from a specific subnet might be used to keep a guest network from reaching internal web apps. Allowing outbound HTTPS from the internal network lets employees browse securely. Denying outbound SMTP from workstation subnets forces all email through the official mail server, preventing malware from spamming or exfiltrating data directly. Allowing inbound RDP only from a specific partner network to one specific server provides limited, controlled partner access.
Written as rules, the first two examples look like this:
ALLOW inbound TCP port 22 from ALL; DENY inbound TCP port 80 from 192.168.1.0/24;
The first rule allows inbound TCP traffic headed to port 22 (SSH) from any source. The second denies inbound TCP traffic headed to port 80 (HTTP) from any address in
192.168.1.0/24, which means 192.168.1.0 to 192.168.1.255 (see subnetting in 3.3 for how the slash works).Rules name services by port number, so these come up a lot:
Port | Protocol | Used for |
21 | FTP | File transfers |
22 | SSH | Encrypted remote login and administration |
23 | Telnet | Unencrypted remote login (should be disabled) |
25 | SMTP | Sending email between mail servers |
53 | DNS | Looking up domain names |
80 | HTTP | Unencrypted web traffic |
443 | HTTPS | Encrypted web traffic |
445 | SMB | Windows file sharing |
3306 | MySQL | Database connections |
3389 | RDP | Remote desktop |
5900 | VNC | Remote desktop (screen sharing) |
Rule Ordering Impact
As with ACLs generally, order changes everything. A configuration that allows SSH first and then denies all other TCP works correctly, letting SSH through while blocking HTTP and everything else. Reverse those two rules, putting the broad deny first, and SSH gets blocked too, since the firewall stops at that first matching deny rule and never even reaches the allow rule meant for SSH.
A well-ordered complex example: deny everything from a known malicious network first, then allow SSH from just the admin network, then allow HTTPS from everyone else, then deny everything else by default. Testing this shows the malicious network gets blocked immediately regardless of what it tries, the admin network's SSH gets through correctly, general HTTPS access works for everyone else, and any other random traffic gets caught by the final deny rule.
Here's that rule set written out as a table, where
198.51.100.0/24 is the known malicious network and 192.168.5.0/24 is the admin network:Rule | Allow/Deny | Direction | Protocol | Port | Source |
1 | Deny | Inbound | ALL | ALL | 198.51.100.0/24 |
2 | Allow | Inbound | TCP | 22 | 192.168.5.0/24 |
3 | Allow | Inbound | TCP | 443 | ALL |
4 | Deny | Inbound | ALL | ALL | ALL |
To check a packet, start at Rule 1 and stop at the first rule that matches:
Incoming traffic | First matching rule | Result |
TCP port 443 from 198.51.100.7 | Rule 1 | Denied, even though Rule 3 would allow HTTPS |
TCP port 22 from 192.168.5.20 | Rule 2 | Allowed |
TCP port 22 from 203.0.113.9 | Rule 4 | Denied (Rule 2 only covers the admin network) |
TCP port 443 from 203.0.113.9 | Rule 3 | Allowed |
TCP port 3389 from 203.0.113.9 | Rule 4 | Denied (no rule allows RDP) |
Order is what makes this work. Move Rule 4 to the top and every packet is denied. Move Rule 1 below Rule 3 and the malicious network's HTTPS traffic gets through, since Rule 3 matches it first.
Firewall Configuration Best Practices
Document every rule with a clear reason for why it exists. Test thoroughly before deploying anything to production. Review the rule set regularly, ideally quarterly, to clean out anything obsolete. Default to denying everything and only allow what's actually necessary. Log extensively to support both troubleshooting and security monitoring. Keep an eye on performance, since an overloaded firewall can become a bottleneck. And always back up configurations before making changes.
Firewalls are a critical piece of network defense, but they only work as well as their configuration, placement, and upkeep, all three need real attention to actually keep threats out while letting legitimate business run smoothly.