3.4 Protecting Networks: Firewalls

Think of a firewall as the bouncer at the door of your network. It checks every piece of traffic coming in or going out and decides whether to let it through or turn it away. Without one, anything on the internet could try to reach into your network and poke around. Firewalls give network admins a way to set clear rules about what kinds of connections are okay and which ones get blocked, and they're one of the most important tools for keeping a network safe.

Types of Network-Based Firewalls

A firewall is software that allows or denies network traffic going in or out of a network. The software can run on its own dedicated device (a hardware appliance like a Cisco ASA box) or it can be built into another network device, like a router. Either way, the job is the same: filter traffic based on rules.

There are three main types you need to know, and they build on each other in terms of how much they can actually see and control.

more resources to help you study

practice questions

Stateless Firewalls

A stateless firewall filters traffic by looking only at information in packet headers. That means it checks things like:

• Source IP address (where the packet came from)
• Destination IP address (where it's going)
• Port numbers
• Protocol (TCP, UDP, ICMP, etc.)

Each packet is judged on its own. The firewall doesn't remember anything about packets that came before. It's fast and simple, but kind of dumb. If a packet's header matches an "allow" rule, it gets through, even if the packet is part of a sketchy conversation that the firewall has no memory of.

Stateful Firewalls

A stateful firewall, also called dynamic packet filtering, does everything a stateless firewall does plus tracks the state of network connections passing through it. In other words, it remembers conversations.

Here's why that matters. When your laptop opens a connection to a web server, there's a back and forth: your machine sends a request, the server responds, more packets fly back and forth. A stateful firewall keeps a table of active connections. If a packet shows up claiming to be a response to a connection that was never opened, the firewall blocks it. This catches a lot of attacks where someone tries to sneak packets in that look legitimate at the header level but don't belong to any real conversation.

Stateful firewalls give you more control over what's actually allowed in and out, not just what individual packets look like.

Next-Generation Firewalls (NGFW)

A next-generation firewall (NGFW) has everything stateless and stateful firewalls do, plus advanced features like:

• Intrusion prevention: actively blocking known attack patterns
• Deep packet inspection: looking inside the packet's payload (the actual data), not just the header
• Application-level filtering: telling the difference between, say, regular web browsing and someone using a file-sharing app over port 443

NGFWs are what most enterprises use today because attackers have gotten good at hiding malicious traffic inside what looks like normal web traffic. A stateless firewall would never catch that. An NGFW can.

Access Control Lists (ACLs)

A firewall is only as smart as the rules you give it. Those rules live in an access control list (ACL), which is just the set of instructions the firewall checks every packet against.

A typical ACL rule specifies three things:

1. Direction: is this for inbound or outbound traffic?
2. Criteria: what to filter by (IP addresses, logical ports, services, or applications)
3. Action: permit or deny

So a single rule answers: which direction, matching what, and do I let it through or block it?

Rules Are Checked in Order

This part trips a lot of people up. ACL rules are checked top to bottom, and the first rule that matches is the one that gets applied. After that match, the firewall stops checking. It doesn't keep going to see if a later rule says something different.

That means the order you write your rules in completely changes what your firewall actually does. A correct list of rules in the wrong order can lock out legitimate traffic or accidentally let attackers in.

Where to Place Firewalls

You can't just stick one firewall at the edge of your network and call it done. Effective placement follows a few principles.

Every segment of the network should have its own firewall. If you split your network into segments (say, one for the finance department, one for guest Wi-Fi, one for servers), each one needs a firewall controlling what flows in and out of it. That way if an attacker compromises the guest Wi-Fi, they can't easily move into the finance segment.

Different segments have different security needs. A segment holding patient health records needs much tighter rules than a segment for the break room printer. Because firewalls can be configured independently, you can tune the strictness of each one based on what it's protecting.

Every ingress and egress point with the public internet needs a firewall. Ingress means traffic coming in, egress means traffic going out. Anywhere your internal network touches the public internet is a place an attacker could try to get in or where data could leak out. Each of those connection points needs a firewall standing guard.

In practice, this means a typical company network might have a firewall at the internet boundary, another between the DMZ and the internal network, and additional firewalls between sensitive internal segments.

Configuring a Firewall

Configuring a firewall starts with figuring out what traffic you actually want to allow or deny, then writing ACL rules that match.

Writing Rules

Rules can filter based on:

• Source or destination IP address
• Source or destination port
• Service (like HTTP, HTTPS, SSH)
• Protocol (TCP, UDP, ICMP)
• Application (with NGFWs)

Here are two example rules using the syntax style the CED uses:

</>Code
Allow inbound TCP port 22 from ALL;

This rule allows all inbound TCP traffic with destination port 22. Port 22 is the standard port for SSH (Secure Shell), which admins use to remotely log into machines. So this rule basically says "anyone on the internet can try to SSH into this network."

</>Code
Deny inbound TCP port 80 from 192.168.1.0/24;

This one denies inbound TCP traffic to port 80 (the standard HTTP port) coming from any IP address in the range 192.168.1.0 through 192.168.1.255. The /24 at the end is CIDR notation that defines that range of 256 addresses.

Order Matters (a Lot)

Remember that rules are checked top to bottom and the first match wins. Look at this set:

</>Code
Rule 1: ALLOW inbound TCP port 22 from ALL;
Rule 2: DENY inbound TCP ALL from ALL;

What this does:

• An incoming SSH packet (TCP port 22) hits Rule 1, matches, gets allowed. Done.
• An incoming packet on TCP port 80 (web traffic) hits Rule 1, doesn't match, moves to Rule 2, matches, gets denied.

So this setup allows SSH and blocks everything else over TCP. Exactly what you want if SSH is the only service you're exposing.

Now flip them:

</>Code
Rule 1: DENY inbound TCP ALL from ALL;
Rule 2: ALLOW inbound TCP port 22 from ALL;

Now an incoming SSH packet hits Rule 1, matches (because Rule 1 covers all TCP traffic), and gets denied. Rule 2 never even gets checked. The result: SSH is blocked along with everything else. Rule 2 might as well not exist.

This is why precedence matters so much when you write ACLs. The general approach is to put your more specific "allow" rules first, then your broader "deny" rules later as catch-alls. A common pattern is:

1. Allow the specific services you need
2. Deny everything else with a final blanket rule

A Slightly Bigger Example

Say you're configuring the firewall for a small web server that should accept normal web traffic from anyone but only allow SSH from your office network at 203.0.113.0/24. Outbound, anything goes.

</>Code
Rule 1: ALLOW inbound TCP port 443 from ALL;
Rule 2: ALLOW inbound TCP port 80 from ALL;
Rule 3: ALLOW inbound TCP port 22 from 203.0.113.0/24;
Rule 4: DENY inbound TCP ALL from ALL;
Rule 5: ALLOW outbound TCP ALL from ALL;

Walking through it: HTTPS (port 443) and HTTP (port 80) are open to the world for web traffic. SSH (port 22) is open, but only if the source IP is in your office's range. Anything else inbound gets caught by Rule 4 and dropped. Outbound traffic is unrestricted.

If you accidentally put Rule 4 above Rule 3, your office would lose SSH access to your own server. Same rules, different order, totally different outcome.

Stateless vs Stateful in Configuration

When you write rules on a stateless firewall, you usually need rules for both directions of a conversation, because the firewall doesn't remember that a connection was started. On a stateful firewall, you can write a rule that allows the initial outbound connection, and the firewall automatically allows the return traffic for that specific connection. That's a big reason stateful firewalls are easier to manage for anything beyond the simplest networks.

Getting comfortable reading and writing ACL rules, predicting what a list of rules will do, and spotting ordering mistakes is the core skill for this topic. If you can look at a set of rules and trace what happens to a specific packet, you're in good shape.