Chapter 24 — Network and communications security: controls
Lesson map
Lesson 24 published. Map, example, EX070.
flowchart TD
N0["Learning outcomes"]
N1["24.1 From flows to rules"]
N2["24.2 Rule order problems"]
N3["Lab — Rule audit"]
N4["24.3 Reading the audit"]
N5["24.4 Rules need owners"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX070"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["24.1 From flows to rules"]
N2["24.2 Rule order problems"]
N3["Lab — Rule audit"]
N4["24.3 Reading the audit"]
N5["24.4 Rules need owners"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX070"]
[Learning outcomes]
|
v
[24.1 From flows to rules]
|
v
[24.2 Rule order problems]
|
v
[Lab — Rule audit]
|
v
[24.3 Reading the audit]
|
v
[24.4 Rules need owners]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX070]
Learning outcomes
You will (1) write firewall rules from needed flows; (2) find shadowed and redundant rules; (3) apply default deny.
24.1 From flows to rules
A firewall rule names a source, destination, service and action. Priya writes one allow rule for each needed flow, then a final rule denying everything else, following the default-deny approach of NIST SP 800-41r1. Rules are evaluated top to bottom and the first match decides, so order matters. Specific rules belong above general ones. She writes a comment on each rule naming the flow and requirement it serves, which later lets reviewers check that every rule has a reason and every reason has a rule.
24.2 Rule order problems
Two common problems arise from order. A shadowed rule can never match because an earlier rule matches all the same traffic with a different action; it looks active but does nothing. A redundant rule matches only traffic that an earlier rule already handles with the same action; it is harmless but adds clutter. Wool's 2004 study of real firewall configurations found such errors common and more frequent in larger rule sets. Finding them by eye is hard, so Priya writes a small checker.
Lab — Rule audit
"""Find shadowed rules in a synthetic first-match rule list (stdlib only)."""
rules = [(1, "guest", "*", "*", "deny"), (2, "staff", "portal", 443, "allow"), (3, "guest", "portal", 443, "allow"),
(4, "*", "*", 53, "allow"), (5, "staff", "*", "*", "allow"), (6, "staff", "lab", 443, "allow"),
(7, "clinical", "lab", 443, "allow"), (8, "*", "*", "*", "deny")]
def covers(a, b): # rule a matches every packet rule b matches
return all(x == "*" or x == y for x, y in zip(a[1:4], b[1:4]))
for i, b in enumerate(rules):
for a in rules[:i]:
if covers(a, b):
kind = "redundant" if a[4] == b[4] else "shadowed (never reached)"
print(f"rule {b[0]} {kind} by rule {a[0]}"); break
Run with python3 lab_rules.py. Verified output:
rule 3 shadowed (never reached) by rule 1
rule 6 redundant by rule 5
24.3 Reading the audit
The checker finds rule 3, allowing guest devices to the portal on port 443, shadowed by rule 1, which denies all guest traffic. Someone intended guests to reach the portal, but the rule never takes effect. Rule 6, allowing staff to the lab server, is redundant because rule 5 already allows staff everything. The deeper problem is rule 5 itself: a broad staff-to-anything allow defeats the purpose of separating groups. Priya recommends replacing it with specific staff flows, moving rule 3 above rule 1 if guest portal access is truly needed, and removing rule 6.
24.4 Rules need owners
A rule without an owner is never reviewed and rarely removed. Priya records, for each rule, the person or role who requested it and confirms it remains needed. She also notes rule 4, allowing DNS from anywhere to anywhere: it supports a needed dependency but is broader than necessary, since devices should use only the clinic's DNS servers. Narrowing it reduces the chance that malware uses DNS to communicate outside. Regular review with owners keeps a policy aligned with real needs as the clinics change.
Worked example
After fixes, the policy has seven specific allow rules and a final deny, with no shadowed or redundant rules.
Synthetic case. Rules are synthetic.
Errors and limits
Broad allow rules added for convenience quietly undo segmentation.
Exercises
- EX070 — Shadowed rule meaning. Why does rule 3 never take effect? Rubric: 3 = rule 1 denies all guest traffic first;; 2 = earlier deny;; 1 = order;; 0 = none.
- EX071 — Broad staff rule. What is wrong with rule 5? Rubric: 3 = staff-to-anything defeats separation;; 2 = too broad;; 1 = vague;; 0 = none.
- EX072 — DNS rule narrowing. How should the any-to-any DNS rule be narrowed? Rubric: 3 = only to clinic DNS servers;; 2 = specific servers;; 1 = remove;; 0 = none.
Synthesis
Default deny, careful ordering and owned, specific rules make a policy enforce what was intended.
Continue studying — chapter 24 of 40
← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →