Chapter 11 — Networks and protocols

Chapter 11 — Networks and protocols

Lesson map

Lesson 11 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["11.1 Paths and observation points"]
  N2["11.2 What protocols reveal"]
  N3["11.3 Loss and sampling"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["11.1 Paths and observation points"]
  N2["11.2 What protocols reveal"]
  N3["11.3 Loss and sampling"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]

[Learning outcomes and connection]
    |
    v
[11.1 Paths and observation points]
    |
    v
[11.2 What protocols reveal]
    |
    v
[11.3 Loss and sampling]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes and connection

After this chapter you can (1) trace a connection path across zones and name every device that could log it; (2) explain what DNS, TLS and session logs can and cannot show; (3) account for packet loss, address translation and time sources when correlating records; and (4) decide which logs support a claim that "host X connected to service Y". It builds on Chapters 3 and 8 and prepares Chapters 22, 34 and 36.

11.1 Paths and observation points

A request from a user's browser to an application crosses a resolver, possibly a proxy, firewalls, a load balancer, a TLS terminator and an application server, and may call an identity service. Each hop is an observation point that may log something different: the resolver logs a name query, the firewall a 5-tuple, the load balancer a client address and backend, the application a user and action. Engineering a response capability begins with this map, because a claim is only as strong as the observation points that independently support it.

11.2 What protocols reveal

DNS logs show that a name was resolved by some client, not that a connection followed. TLS 1.3 (RFC 8446) encrypts most of the handshake after the ClientHello; middleboxes usually see the server name indication (unless encrypted) and certificate metadata only where TLS is terminated. TCP (RFC 9293) state tells you whether a handshake completed; a firewall "allow" log does not prove data was exchanged. Address translation rewrites addresses: the firewall's source address may be a NAT pool, so mapping back to a host requires the NAT table log for that time. Time: correlate with synchronised clocks (RFC 5905) and record offsets.

11.3 Loss and sampling

Flow exporters often sample (1 in N packets); packet captures drop under load; logs are delivered over UDP syslog and can be lost silently (RFC 5424 defines the message format, not reliable delivery). Absence in a sampled source is weak evidence.

EX022 puts a number on how weak that absence is as evidence. With flows sampled at 1 in 1,000, a six-packet probe escapes sampling entirely with probability of about 0.994. A NetFlow record that fails to show the probe therefore says almost nothing about whether it happened. In the citizen-portal example, the claim rests on the NAT log, proxy and endpoint instead, which record every connection rather than a sample.

11.4 Worked example (synthetic): HVSS multi-zone application

HVSS's synthetic citizen portal sits behind a reverse proxy in a DMZ; the application zone calls a remote identity provider over the internet. Claim to test: "workstation W-114 uploaded data to external address 203.0.113.50 at 14:02". (203.0.113.0/24 is a documentation range, RFC 5737.)

Three independent sources (NAT plus firewall, proxy, endpoint) agree within a second after offset correction: the claim is supported. Without the NAT log, the firewall record supports only "some host behind the NAT".

11.5 Errors and limits

• Treating DNS resolution as proof of connection.
• Ignoring NAT when attributing flows.
• Assuming syslog delivery is reliable.
• Correlating unsynchronised timestamps.

The W-114 claim in the worked example shows how each error would mislead an analyst. The resolver entry at 14:01:58 shows only that W-114 looked up files.example.net, not that it sent anything. The egress firewall alone shows only a NAT pool address, and it is the NAT log that maps port 40122 back to W-114. If the proxy's syslog stream had lost the CONNECT record, nothing would have flagged its absence. The one-second agreement between sources is meaningful only after each source's clock offset has been corrected.

Exercises — chapter 11

EX021 — Support a claim. Objective: identify necessary evidence. Inputs: claim "server S-07 received an administrative login from a contractor laptop at 09:15"; S-07 is behind a load balancer that does source NAT. Steps: list the observation points needed and what each must show; name the weakest link. Expected evidence: list and weakest link. Rubric: 3 = includes load balancer logs with original client address (or forwarded header with trust caveat), authentication log on S-07, identity-provider log and laptop identity; weakest link argued; 2 = partial; 1 = one source; 0 = none.

EX022 — Sampling. Objective: reason about sampled flows. Inputs: NetFlow sampled 1:1000; a 6-packet exfiltration probe. Steps: compute the probability that none of the 6 packets is sampled (independent sampling); interpret. Expected evidence: number and sentence. Rubric: 3 = ≈0.994 with interpretation; 2 = number; 1 = attempt; 0 = none.

Chapter synthesis

Map the path, list the observation points, understand what each protocol and device actually records and account for NAT, loss and time. A connection claim is supported when independent observation points agree.

Continue studying — chapter 11 of 50

← Chapter 10 · Course chapter index · Chapter 12 →

Continue to the next authored lesson.