Firewalls, Screened Subnets and Intrusion Detection

Firewalls, Screened Subnets and Intrusion Detection

What you'll learn

• Explain what a firewall filters on, and retell the classic analogy behind it
• Contrast stateless and stateful filtering with a concrete rule-table walkthrough
• Place a DMZ / screened subnet correctly and say what rule makes it safe
• Distinguish IDS from IPS — and read a five-rule ACL without guessing
• Name what NGFWs and zero-trust segmentation added to the book's foundations

What a firewall is

This lesson builds on Chapter 14 of Dr. Tahseen Al-Doori's Network Essentials, with an assist from Chapter 3, where the book first introduces firewalls with a classic analogy from Dr. Al-Doori's course: picture the tugboat captain of a busy harbor, meeting each arriving ship and steering it to a berth where inspectors verify the cargo before a single crate comes ashore. No vessel sails straight to shore; everything passes the checkpoint; what fails inspection never enters the country.

A firewall is that checkpoint for packets. It sits where one network meets another — classically, where your LAN meets the Internet — and every packet crossing the boundary is checked against rules before it may pass. What can the rules look at? Exactly the fields you spent Modules 4 and 5 learning to read: source and destination IP addresses, protocol (TCP, UDP, ICMP), port numbers (the application, in effect — port 443 means web, port 25 means mail), and at the deeper end, payload content — patterns in the data itself. Deny or allow, packet by packet, according to policy: that is the whole job, and lesson 1 told you whose policy it implements.

Two deployment shapes exist, and the book's split is still the real one. A network-based firewall protects a whole network: a dedicated appliance (or firewall software on a router) at the edge, guarding everyone behind it. A host-based firewall runs on the endpoint itself — the built-in firewall on your own laptop (Microsoft Defender Firewall on today's Windows; the book names the products of its own era) — and it travels with the machine to every café and airport. The professional answer to "which one?" is the lesson-1 answer: both. Layers.

Stateless versus stateful: the walkthrough

Early firewalls judged every packet alone — no memory, no context. That is stateless filtering, and its weakness is best seen by trying to write rules for the most ordinary event on any network: one PC browsing one website.

PC 192.168.1.20 opens a connection to a web server at 203.0.113.80 on port 443. Traffic flows in both directions — your requests out, the pages back. A stateless firewall needs a rule for each direction:

Rule 1 is fine. Rule 2 is a scandal. Because the firewall judges packets in isolation, the only way to let the replies in is to allow, permanently, any packet from anywhere whose source port claims to be 443 — and a source port is whatever the sender sets it to. Rule 2 doesn't open a door for your web replies; it props open a door for the entire Internet, provided attackers dress their packets correctly. Stateless filtering forces a choice between breaking replies and trusting costumes.

Stateful filtering fixes this with memory. The firewall keeps a state table — a live list of conversations that inside machines have started (much like the connection listing you'll read with your own eyes via netstat in Module 8). When PC .20 opens its connection, the firewall records it; when packets arrive from 203.0.113.80, it asks not "does a rule allow this?" but "is this a reply to something one of ours began?" Match in the table: pass. No match: drop, whatever the costume says. One rule now suffices — allow outbound web, permit established return traffic — and the standing invitation of rule 2 disappears. Every reply is welcome; nothing uninvited gets in. Stateful inspection is the minimum standard today — but be clear about what you are about to build: a plain extended ACL, including the one in this lesson's lab, is stateless. It judges every packet on its own, which is exactly why your rule will have to name protocols and ports precisely. Stateful behavior on a router needs a different construct — reflexive ACLs, the established keyword, or a zone-based policy firewall — while on a dedicated firewall it is simply how the box works. Build the stateless version first: it is the one that shows you why state had to be invented.

The screened subnet (DMZ): serving the public without exposing the LAN

Now a design problem the firewall alone cannot solve. Suppose the organization runs a public web server. The Internet must reach it — that is its job — but every "allow the Internet in" rule aimed at your LAN contradicts everything this module stands for. The answer is geography: give public-facing servers their own subnet, separate from the private LAN, and firewall both borders. The book teaches this as the DMZ (demilitarized zone); the vendor-neutral name is screened subnet. In text:

                 Internet
                    |
             [ edge firewall ]      allow 80/443 -> web server,
                    |               mail ports -> mail gateway
               DMZ subnet ------ web server, mail gateway
                    |
             [ inner firewall ]     DMZ may NOT start connections
                    |               into the LAN
              private LAN

The edge firewall admits the public — but only to the DMZ, only on the advertised ports. The inner firewall enforces the rule that gives the design its power: the DMZ may not initiate connections into the LAN. Servers that face the public are the servers most likely to be compromised; the screened subnet plans for that day in advance. If the web server falls, the attacker stands in a small, watched pen — not in your file shares. (You will also meet the three-legged variant: one firewall with three interfaces — Internet, DMZ, LAN — enforcing the same two borders with one box. Same idea, smaller budget. And the "DMZ host" option on home routers is this idea's evil twin: it removes protection from one machine. Never confuse them.)

The book also notes DMZs commonly hosting proxy servers, which earns proxies their one modern paragraph. A proxy is a middleman: it terminates your connection and opens its own on your behalf, which once let organizations cache pages and filter content at a single choke point. Then TLS encrypted the web, and a middleman who cannot read the traffic cannot filter much; the classic web proxy declined. Its descendants are the TLS-inspecting firewall and the cloud secure web gateway (SWG) — same choke-point idea, rebuilt for an encrypted era. Awareness level is all this course needs.

IDS and IPS: noticing versus stopping

Firewalls enforce known policy. But some trouble arrives dressed as legitimate traffic — a login storm, a scan, an exploit inside an allowed port. Watching for that is a different job with two variants, and Chapter 14's framing of them still holds.

An intrusion detection system (IDS) observes traffic — typically out-of-band, from a copy of the stream — matches it against attack signatures and behavioral anomalies, and alerts and logs. It stops nothing by itself; it makes sure somebody knows. An intrusion prevention system (IPS) sits inline, in the traffic path, and blocks what matches. The book frames the trade honestly: prevention costs more and takes careful configuration; detection is after-the-fact — but knowing an attack happened, and having its log, beats not knowing at all. Add the modern corollary: an inline blocker with a wrong rule blocks legitimate business — false positives are an IPS's operational tax, which is why the book's remark that the administrator's skill in defining rules is decisive remains the truest sentence in this section. In 2026 you rarely buy either as a separate box: IPS ships inside the firewall. Which brings us to what firewalls became.

Reading an ACL like a professional

The rule sets that firewalls, routers and switches enforce are access control lists (ACLs) — ordered lists of permit/deny rules matched against exactly the fields from this lesson's first section. Two mechanics govern every ACL ever written:

1. Top-down, first match wins. Rules are checked in order; the first rule that matches a packet decides it, and no later rule is consulted.
2. Implicit deny. An invisible "deny everything" sits at the end of every ACL. Whatever no rule permits is dropped.

One notation note and you can read Cisco-style rules: extended ACLs describe addresses with a wildcard mask, which is a subnet mask photographic-negative — 0.0.0.255 means "match the first three octets exactly, ignore the last," i.e. the whole /24. And host 192.168.1.11 means that one address exactly.

Now the practice the heading promised. Here is an ACL applied to traffic leaving a company LAN (192.168.1.0/24); 203.0.113.0/24 is a partner's network:

10  permit tcp 192.168.1.0 0.0.0.255 any eq 443
20  permit tcp 192.168.1.0 0.0.0.255 any eq 80
30  deny   ip  192.168.1.0 0.0.0.255 203.0.113.0 0.0.0.255
40  permit icmp 192.168.1.0 0.0.0.255 any
50  deny   ip any any

Decide the fate of each, then check yourself against the reasoning below:

• (a) PC 192.168.1.25 browses https:// to 198.51.100.7
• (b) PC 192.168.1.25 browses https:// to 203.0.113.15
• (c) PC 192.168.1.25 pings 203.0.113.15
• (d) PC 192.168.1.25 pings 198.51.100.7
• (e) PC 192.168.1.25 opens SSH (TCP port 22) to 198.51.100.7

(a) Permitted by line 10 — TCP to port 443. (b) Permitted — and here is the lesson: line 10 matches (TCP, port 443) before line 30 is ever consulted. First match wins; the deny aimed at the partner network sits too low to catch web traffic. If policy meant to cut off the partner entirely, line 30 must move above line 10 — order is policy. (c) Denied by line 30 — ping is ICMP, not TCP port 443, so nothing above line 30 matches, and line 30 does. (d) Permitted by line 40. (e) Denied — no line matches TCP port 22, so the packet falls through to line 50; and even if line 50 were absent, the implicit deny would do the same, invisibly. An ACL is a bouncer with a guest list: reading one is just asking, rule by rule, "does this describe my packet?" — and remembering who gets asked first.

From the textbook to 2026

The book's foundations — filtering fields, stateful versus stateless, the DMZ, IDS/IPS, ACL mechanics — transfer to 2026 intact; everything above is as true now as then. What changed is what sits on top. The book names the firewall appliances of its era — Cisco's PIX and ASA, SonicWall. PIX is long retired. ASA is not: it lives on as Cisco Secure Firewall ASA software, still developed and still shipping on current hardware beside its NGFW sibling FTD — though the ASA appliances of the book's era have reached end of support. Keep that distinction: a retired box is not a retired software line, and internet-facing firewall software is itself a prized target, as this lesson's edge-device warning makes plain. The category that replaced them is the next-generation firewall (NGFW) (current): still a stateful filter at heart, but application-aware — it can recognize "this is a file-sharing app" inside port 443 rather than judging by port number alone — identity-aware (rules per user or group, not just per address), with IPS and TLS inspection built in. And the placement of firewalls changed with zero trust (lesson 1's arc): instead of one great wall at the edge, segmentation moved inward — firewalls and ACLs between internal zones, host firewalls centrally managed, east-west traffic inspected, so that an intruder who lands inside finds fences everywhere, not open plains. The tugboat captain did not retire; the port simply hired inspectors for every dock.

Watch: What is a Firewall?

Why this video earns its place. PowerCert Animated Videos — the same channel behind earlier animations in this course — compresses the core firewall idea into about six minutes of clean animation: traffic meeting a rule-checking barrier, allow versus deny decisions, and the host-based/network-based split. After the density of rule tables and screened subnets above, it is a well-made visual warm-down — kept deliberately modest here because it is a 2019 high-level explainer: it predates the NGFW-and-zero-trust framing, skips stateful-versus-stateless entirely, and names product examples of its day (ZoneAlarm; "Windows Defender," now Microsoft Defender Firewall). The sections above carry all of that; the video's job is only to make the checkpoint idea move.

As you watch, notice:

• The rule-checking barrier deciding packet by packet — the tugboat checkpoint you just read, animated.
• Rules matching on addresses, ports and protocols — the same fields your ACL practice used.
• The host-based versus network-based split, and the layered use of both — lesson 1's motto applied.
• What the animation leaves out: state, DMZs, IDS/IPS and NGFWs are yours from the prose above, not from the video.

The video reinforces visually what you just learned — the lesson is complete without it.

Lab: Packet Tracer #4 — An extended ACL, rule by rule

You will build the two-network router shape from Module 5's Packet Tracer work, then write an extended ACL that blocks exactly one PC from browsing the web server — while its pings still succeed and its neighbor browses freely. Surgical, verifiable, and entirely yours.

Objective. Configure and verify an extended ACL that denies HTTP from one host to one server while permitting everything else.

Setup. Packet Tracer (installed since Module 3). New blank file.

Steps.

Build and baseline.

1. Place: one 2911 router, one 2960 switch, two PCs, one Server. Cable with Copper Straight-Through: PC0 and PC1 to the switch; switch to router port GigabitEthernet0/0; server to router port GigabitEthernet0/1.

2. Address the LAN side: PC0 = 192.168.1.11, PC1 = 192.168.1.12, mask 255.255.255.0, default gateway 192.168.1.1 on both.

3. Address the server: IP 192.168.2.100, mask 255.255.255.0, gateway 192.168.2.1.

4. Bring up the router. Click it, open the CLI tab, press Enter, then:

   codeCopy

   enable
   configure terminal
   interface gigabitEthernet 0/0
   ip address 192.168.1.1 255.255.255.0
   no shutdown
   interface gigabitEthernet 0/1
   ip address 192.168.2.1 255.255.255.0
   no shutdown
   end
   

5. Baseline — prove everything works before filtering. From PC0's Command Prompt: ping 192.168.2.100 (succeeds). From PC0's Web Browser (Desktop tab): open http://192.168.2.100 — the server's sample page loads (the HTTP service is on by default; if not, check the server's Services tab). Repeat both from PC1. Four successes: that is your baseline.

Write the ACL.

6. On the router CLI:

   codeCopy

   enable
   configure terminal
   access-list 100 deny tcp host 192.168.1.11 host 192.168.2.100 eq 80
   access-list 100 permit ip any any
   interface gigabitEthernet 0/0
   ip access-group 100 in
   end
   

   Read your own rules back in English before moving on: line one — deny TCP from exactly PC0 to exactly the server when the destination port is 80 (HTTP); line two — permit everything else (without it, the implicit deny would drop all remaining traffic); then the list is attached to Gi0/0 inbound — judging LAN traffic as it arrives at the router.

Prove the boundary.

7. From PC0's browser: http://192.168.2.100 → Request Timeout. The very page from step 5.
8. From PC0's Command Prompt: ping 192.168.2.100 → succeeds. Ping is ICMP — your rule named TCP port 80, and nothing else changed.
9. From PC1's browser: http://192.168.2.100 → loads. The deny named PC0's address alone.
10. Ask the router for its own account. In the CLI: show access-lists. You will see both lines with match counters — the deny line's count climbed with PC0's browser attempts, the permit line with everything else. Then show ip interface gigabitEthernet 0/0 and find the line reporting that the inbound access list is 100. Counters plus placement: that is what "verified" means professionally.
11. Save as m7-pt4.

Expected result. Baseline all-green; after the ACL: PC0 cannot load the page but can ping; PC1 does both; show access-lists shows a climbing deny counter.

Verify. You can point at the deny line's counter and explain each increment; you can state why ping survived (protocol and port precision) in one sentence.

Questions.

1. In step 7, PC0's browser waits and fails — at which device did the packets die, and which single word of your deny line would you change to block the ping instead?
2. Try https://192.168.2.100 from PC0 (the server's HTTPS service is on by default). It loads. Why — and is that a bug in your ACL or a demonstration of its precision?
3. Remove the permit ip any any line mentally: what would PC1's browser experience, and which invisible rule explains it?
4. Your ACL sits inbound on Gi0/0. What would change if you had attached it inbound on Gi0/1 instead?

(Answers: 1 — at the router, inbound on Gi0/0, matched by the deny line; changing tcp ... eq 80 to icmp — deny icmp host ... host ... — would target ping instead. 2 — HTTPS rides TCP port 443, and your rule named port 80 only; it is precision, and whether it is a bug depends on the policy — if the intent was "no web at all," the policy needs a second deny line for 443, which is a policy question exactly as the lesson said. 3 — total blackout for both PCs toward the server and beyond: with no permit line, every packet falls to the implicit deny at the end of the list. 4 — inbound on Gi0/1 judges traffic arriving from the server's side, so PC0's outbound requests would never be filtered on their way in from the LAN; the deny would miss its target — placement and direction are part of the rule.)

If it goes wrong.

• Everything stopped working after step 6. Almost always a missing permit ip any any — the implicit deny is eating the rest. Numbered ACL lines cannot be edited singly on this IOS: no access-list 100, then re-enter both lines in order.
• PC0 still loads the page. Check show access-lists — if the deny counter is zero, the list is not applied (ip access-group 100 in missing, or applied to the wrong interface/direction), or the deny names the wrong host (compare with PC0's ipconfig).
• PC1 is blocked too. The deny line's source is not host 192.168.1.11 — re-check for a network-plus-wildcard where a host was intended.
• Baseline (step 5) never worked. Interfaces likely down: no shutdown missing (link lights red), or an address typo — show ip interface brief on the router settles it in one screen.
• Browser fails on both PCs even without an ACL. The server's HTTP service is off — Server > Services tab > HTTP > On.

Reset/cleanup. Keep m7-pt4.pkt — the capstone's security-review phase asks you to write ACLs against your own design, with this file as the reference.

Check yourself

1. A stateless firewall guards a LAN. The administrator, wanting web replies to reach users, allows inbound packets whose source port is 443. Explain the hole this opens, and name the mechanism that lets a stateful firewall retire that rule entirely.
2. Your company launches a public booking site. A colleague proposes running it on the office file server "since the firewall already allows 443." Counter with this lesson's design, including the one rule that makes it work.
3. An alert-only sensor logged an exploit against the DMZ web server at 2 a.m.; nothing blocked it. Management asks why the expensive security system "did nothing." Explain the IDS/IPS distinction — and one honest reason a business might still choose alert-only in some places.
4. Reorder this intent into a correct ACL: "Partner network 203.0.113.0/24 must never be reached at all; web to everywhere else is fine; nothing else is allowed." Write three lines in the lesson's notation and defend the order.
5. An NGFW reports "file-sharing application blocked" on a connection to port 443. What is it doing that the classic firewall of this lesson's rule tables could not, and why did that ability become necessary?

Answers

1. Source ports are set by the sender — any attacker can stamp 443 on hostile packets, so the rule admits the whole Internet in costume. A stateful firewall keeps a state table of connections its own users initiated and admits only packets matching an existing conversation — replies get in because they are replies, not because of what they wear.
2. Public services belong in a screened subnet (DMZ): a separate subnet holding the booking server, with the edge firewall admitting the public only to it, only on 443 — and the inner border enforcing the load-bearing rule that the DMZ may not initiate connections into the LAN. When the public-facing server is eventually attacked, the blast stays in the pen — not in the file shares it would have shared a subnet with.
3. An IDS observes (usually a copy of traffic), detects and alerts — it is not in the path and stops nothing; an IPS sits inline and blocks matches, at the price of false positives blocking legitimate business and of being an in-path failure point. Alert-only is a defensible choice where wrongly blocking traffic costs more than a delayed response — provided someone actually reads the alerts.
4. 10 deny ip any 203.0.113.0 0.0.0.255 · 20 permit tcp any any eq 443 (add a line for port 80 if plain HTTP is policy) · implicit deny handles the rest (write deny ip any any if you want its counter visible). The partner deny must sit first: with first-match-wins, any permit above it that also describes partner-bound traffic (as web permits would) silently defeats the policy — order is policy.
5. It identified the application inside the encrypted-web port instead of trusting the port number. Necessary because the web era pushed nearly everything onto 443 — when one port carries email, file-sharing, chat and malware alike, port-based rules stopped describing policy, and application awareness became the only honest way to enforce it.

Key terms

• Firewall — the rule-enforcing checkpoint between networks, filtering on addresses, protocols, ports and content.
• Network-based / host-based firewall — edge appliance guarding a network vs. software guarding one endpoint; use both.
• Stateless filtering — judging each packet in isolation; forces reply-admitting rules that trust forgeable fields.
• Stateful inspection — tracking conversations in a state table; replies to inside-initiated traffic pass, the uninvited do not. Today's minimum.
• DMZ / screened subnet — a separate firewalled subnet for public-facing servers; its load-bearing rule: no connections initiated from DMZ into LAN.
• Proxy / secure web gateway (SWG) — the middleman choke point; the classic web proxy declined with TLS, reborn as TLS-inspecting gateways.
• IDS / IPS — out-of-band detect-and-alert vs. inline block; false positives are the IPS's tax.
• ACL (access control list) — ordered permit/deny rules; top-down, first match wins.
• Implicit deny — the invisible drop-everything rule ending every ACL.
• Wildcard mask — inverse-mask notation in extended ACLs (0.0.0.255 = match the /24).
• NGFW (next-generation firewall) — stateful core plus application and identity awareness, IPS and TLS inspection built in (current).
• Zero-trust segmentation — firewalls and ACLs between internal zones, not just at the edge; fences everywhere an intruder might land.

Summary

• A firewall is the network's inspection checkpoint — the book's tugboat-and-harbor teaching — filtering on the addresses, protocols and ports you learned in Modules 4 and 5.
• Stateless filtering judges packets alone and ends up trusting forgeable costumes; stateful inspection remembers conversations, admitting replies because they are replies. Stateful is the modern minimum.
• Public services live in a screened subnet: the public reaches the DMZ only, and the DMZ may not reach into the LAN — a design that plans for its own bad day.
• IDS notices and logs; IPS sits inline and stops — at the cost of false positives. In 2026 both usually live inside the firewall itself.
• ACLs read top-down with first-match-wins and end in an implicit deny; order is policy, and show access-lists counters are how you prove a rule earns its keep.
• NGFWs added application and identity awareness because port 443 came to carry everything; zero trust moved segmentation inward, putting checkpoints between internal zones too.
• You built a live ACL that blocks one host's HTTP while sparing its pings and its neighbor — filtering precise enough to point at, counter by counter.

Next lesson

Firewalls decide who may talk; encryption decides who may understand. Next: symmetric and asymmetric keys, the fall of DES and the reign of AES, how two strangers agree on a secret across a hostile Internet — and the certificate system your browser consults on every page load.

Sources and further study

• Al-Doori, T., Network Essentials, Chapters 3 and 14 — the firewall introduction and analogy; stateful/stateless, DMZ, IDS/IPS and ACL foundations.
• Cisco, "What Is a Firewall?" — https://www.cisco.com/site/us/en/learn/topics/security/what-is-a-firewall.html — a current vendor-neutral-enough overview reaching to NGFWs.
• PowerCert Animated Videos, "What is a Firewall?" — the lesson's optional visual complement, discussed in the Watch section.