Chapter 2 — Networks and internet services
Lesson map
Lesson 02 published. Map, example, EX004.
flowchart TD
N0["Learning outcomes and connection"]
N1["2.1 The request path"]
N2["2.2 What network evidence can and cannot tell you"]
N3["2.3 Time and addressing"]
N4["2.4 Containment points and side effects"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX004"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["2.1 The request path"]
N2["2.2 What network evidence can and cannot tell you"]
N3["2.3 Time and addressing"]
N4["2.4 Containment points and side effects"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX004"]
[Learning outcomes and connection]
|
v
[2.1 The request path]
|
v
[2.2 What network evidence can and cannot tell you]
|
v
[2.3 Time and addressing]
|
v
[2.4 Containment points and side effects]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX004]
Learning outcomes and connection
You will be able to (1) trace how a resident's request reaches a Fernmoor service through DNS, load balancers, firewalls and TLS; (2) identify which network records exist at each hop and how long they are kept; and (3) choose network containment points and predict their side effects. Chapter 1 mapped components; this chapter connects them and asks where evidence and control live on the path.
2.1 The request path
A typical request: the browser resolves appointments.fernmoor.example through DNS (RFC 1035), opens a TLS 1.3 connection (RFC 8446) to a content-delivery or load-balancing edge, which forwards to an application host inside a segmented network, which queries the database on another segment. Each hop can log: DNS query logs, edge access logs (client address, URL, status, bytes), firewall connection logs, application logs, database logs. Each hop is also a possible control point. In the permit enumeration case, the edge access logs supplied the volume, sequence and source of the requests, and the firewall logs confirmed that only the edge talked to the app tier. Without both hops logged, the duty lead could not have ruled out direct access to the application hosts.
2.2 What network evidence can and cannot tell you
Network logs show who connected to what, when and how much data moved. They usually do not show content, because TLS encrypts it; decryption at an edge is a design choice with privacy implications. Source addresses may be shared (carrier NAT, proxies, cloud egress) or spoofed for connectionless traffic. A flow record summarizes a connection (addresses, ports, bytes, duration). NIST SP 800-92 discusses log management, including the need to plan retention and protect integrity. The permit enumeration showed the limit clearly: the logs proved that 41,000 requests came from one range with sequential ids, but not who was behind them or why.
2.3 Time and addressing
Correlating hops needs synchronized clocks; NTP (RFC 5905) keeps hosts aligned, and timestamps written in RFC 3339 form with an explicit offset remove ambiguity. Documentation in this book uses the address ranges reserved by RFC 5737 (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) and the example domain so that no real system is implied. Clock problems are not theoretical. If the edge logs in local time and the application in UTC without saying so, the same request appears an hour apart in two sources, and a responder may treat it as two events. Before correlating hops, Fernmoor's analysts check each source's zone and record it with the export, so later readers know which correction was applied to which file.
2.4 Containment points and side effects
Options include blocking an address at the edge, blocking a URL path, disabling a DNS record, isolating a host's network segment, or cutting an egress route. Each has a blast radius: blocking a shared egress address may block an entire mobile carrier's customers; removing a DNS record stops every user. A technologist pre-builds the common containment actions, records their side effects and their rollback, and tests them in a non-production environment. In the permit enumeration case, the rate limit at the edge was chosen first because it was reversible in seconds and left the public lookup working. Disabling the endpoint stopped the exposure completely, but only after the service owner accepted the loss of the public permit lookup.
2.5 Worked example (synthetic): enumeration of permit records
Fictional. Fernmoor's permit portal shows edge access logs with 41,000 requests in one hour to /api/permits/{id} from 203.0.113.0/24, with ids increasing sequentially and 98% 200 OK. Firewall logs confirm only the edge talks to the app tier. Application logs show no authentication on that endpoint for "public" permits, but the responses include applicant phone numbers.
Analysis: the network evidence shows volume, sequence and source; it cannot show whether the requester was a researcher, a competitor or a criminal. Containment options: (a) rate-limit the path at the edge — low side effect, reversible in seconds; (b) block 203.0.113.0/24 — fast but bypassable and could block a legitimate shared egress; (c) disable the endpoint — stops the exposure entirely but breaks the public permit lookup. The duty lead chose (a) immediately and (c) after the service owner agreed, while application owners removed phone numbers from the response. Edge logs were exported before rotation for the case (Chapter 17).
2.6 Common errors and limits
- Treating an IP address as an identity.
- Blocking at the narrowest point you can reach rather than the point with the best side-effect profile.
- Forgetting that edge logs often rotate in hours; export first.
- Relying on log times without knowing the clock source.
The permit enumeration case avoided all four. The duty lead did not treat the source range as a single attacker, chose a rate limit for its side effects rather than its reach, exported the edge logs before rotation, and relied on synchronized clocks when lining up edge and application records. Each of those choices is recorded in the case so a reviewer can check it later.
Exercises — chapter 2
Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.
EX004 — Hop table. Steps: for the permit portal path, list each hop, the log it produces, a typical retention to verify, and one control action. Rubric: 3 = DNS, edge, firewall, app, DB each with log, retention-to-verify and control; 2 = four hops; 1 = two; 0 = none.
EX005 — Side effects. Steps: for options (a)–(c) in the permit-enumeration worked example, state side effect, rollback and time to apply. Rubric: 3 = all three with plausible side effects and rollback; 2 = two; 1 = one; 0 = none.
EX006 — Limits of evidence. Steps: write three sentences for the case record stating what the network logs establish and what they do not. Rubric: 3 = facts (volume, pattern, source range, status codes) vs unknowns (identity, intent, content beyond logged fields), no attribution; 2 = mixes one inference; 1 = attributes intent; 0 = none.
Chapter synthesis
Know the request path hop by hop: what each hop logs, how long it keeps it, and what control it offers. Choose containment by side-effect profile and reversibility, export volatile logs first, and keep network facts separate from conclusions about identity or intent.
Continue studying — chapter 02 of 30
← Chapter 01 · Course chapter index · Chapter 03 →
Continue to the next authored lesson.