Chapter 12 — Network and communications security: data flows
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Mapping flows"]
N2["12.2 DNS as a window on flows"]
N3["Lab — DNS summary"]
N4["12.3 Reading the summary"]
N5["12.4 Flows inform rules"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Mapping flows"]
N2["12.2 DNS as a window on flows"]
N3["Lab — DNS summary"]
N4["12.3 Reading the summary"]
N5["12.4 Flows inform rules"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Mapping flows]
|
v
[12.2 DNS as a window on flows]
|
v
[Lab — DNS summary]
|
v
[12.3 Reading the summary]
|
v
[12.4 Flows inform rules]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) identify needed flows; (2) analyse DNS logs; (3) use flows to inform filtering and rules.
12.1 Mapping flows
A data flow is traffic from one group to a service for a purpose. Tomás maps flows by asking users what they do and checking logs Gareth provides. Students use the learning platform, web browsing and printing. Teachers add teaching file shares and projectors. Office staff use the finance and records systems. Each flow is written with source zone, destination, service and reason. This flow list later becomes the firewall policy, so mistakes here become mistakes in the rules, which is why he reviews it with users.
12.2 DNS as a window on flows
Almost every connection starts with a DNS lookup, so DNS logs show what devices try to reach. The school's filtering service blocks categories for students, such as gaming during lessons and newly registered domains, which are often used for malicious sites. NIST SP 800-81-2 discusses DNS security, including protecting resolvers. Tomás analyses a synthetic sample of DNS logs to see how filtering behaves by zone and which blocked lookups repeat, since repeated blocked lookups from one device may indicate malware rather than a curious student.
Lab — DNS summary
"""Summarise synthetic school DNS query logs by zone and blocked category (stdlib only)."""
import collections
log = [("students", "learn.example.edu", "ok"), ("students", "video.example.com", "ok"), ("students", "game.example.net", "blocked:gaming"),
("staff", "mail.example.org", "ok"), ("students", "x1y2z3.example.biz", "blocked:newly-registered"),
("students", "game.example.net", "blocked:gaming"), ("admin", "payroll.example.org", "ok"), ("guest", "news.example.com", "ok"),
("staff", "learn.example.edu", "ok"), ("students", "x1y2z3.example.biz", "blocked:newly-registered"),
("students", "x1y2z3.example.biz", "blocked:newly-registered"), ("guest", "game.example.net", "blocked:gaming")]
by_zone = collections.Counter(z for z, _, _ in log); blocked = [(z, d, r) for z, d, r in log if r != "ok"]
print("queries by zone:", dict(by_zone))
print("blocked by category:", dict(collections.Counter(r.split(":")[1] for _, _, r in blocked)))
print("repeat blocked domains:", {d: n for d, n in collections.Counter(d for _, d, _ in blocked).items() if n >= 3})
print(f"blocked share {len(blocked)}/{len(log)} = {100*len(blocked)/len(log):.1f}%")
Run with python3 lab_dns.py. Verified output:
queries by zone: {'students': 7, 'staff': 2, 'admin': 1, 'guest': 2}
blocked by category: {'gaming': 3, 'newly-registered': 3}
repeat blocked domains: {'game.example.net': 3, 'x1y2z3.example.biz': 3}
blocked share 6/12 = 50.0%
12.3 Reading the summary
In the synthetic sample of twelve lookups, half are blocked: three for gaming and three for a newly registered domain. The gaming lookups come from students and one guest, which is expected curiosity. The newly registered domain is looked up three times by students, an unusual pattern for a random-looking name. Tomás flags it for Gareth to check which device made the lookups. A device repeatedly contacting a newly registered, random-looking domain could be infected and trying to reach a controller, so it deserves attention even if blocking succeeded.
12.4 Flows inform rules
From the flow list, Tomás drafts firewall rules for each zone pair, and from the DNS analysis he recommends that all zones use the school's resolvers, with outbound DNS to other servers blocked. This ensures filtering cannot be bypassed by configuring a different resolver, and that DNS logs remain complete. He notes that guest devices also use the school resolvers but receive lighter filtering, consistent with their internet-only access. Flows, rules and logging are designed together so that each supports the others.
Worked example
Half of twelve synthetic lookups are blocked; a newly registered random-looking domain repeated three times is flagged for investigation.
Synthetic case. Logs are synthetic.
Errors and limits
Allowing devices to use any DNS resolver lets filtering and logging be bypassed.
Exercises
- EX034 — Blocked share. What share of lookups were blocked in the sample? Rubric: 3 = 6 of 12, 50 percent;; 2 = half;; 1 = some;; 0 = none.
- EX035 — Suspicious pattern. Why flag repeated lookups of a newly registered random-looking domain? Rubric: 3 = possible malware contacting controller;; 2 = malware;; 1 = curiosity;; 0 = none.
- EX036 — Resolver rule. Why block outbound DNS to servers other than the school's? Rubric: 3 = prevents bypassing filtering, keeps logs complete;; 2 = bypass;; 1 = speed;; 0 = none.
Synthesis
Flow maps and DNS logs guide rules and highlight devices needing attention.
Continue studying — chapter 12 of 30
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →