Chapter 7 — Networks and protocols | Bachelor's Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 07 published. Map, example, EX019.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["7.1 Layering"]
  N2["7.2 DNS"]
  N3["7.3 Transport"]
  N4["7.4 TLS"]
  N5["7.5 Flow records versus packet capture"]
  N6["7.7 Practical activity"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX019"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["7.1 Layering"]
  N2["7.2 DNS"]
  N3["7.3 Transport"]
  N4["7.4 TLS"]
  N5["7.5 Flow records versus packet capture"]
  N6["7.7 Practical activity"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX019"]

[Learning outcomes and connection]
    |
    v
[7.1 Layering]
    |
    v
[7.2 DNS]
    |
    v
[7.3 Transport]
    |
    v
[7.4 TLS]
    |
    v
[7.5 Flow records versus packet capture]
    |
    v
[7.7 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX019]

Learning outcomes and connection

You will be able to (1) place an observation at the correct network layer; (2) read DNS, TCP and TLS evidence and say what each does and does not prove; (3) distinguish flow records from packet captures; and (4) evaluate a connection hypothesis against a trace. Chapter 2 introduced systems and dependencies; here you follow requests across the network that joins them. Chapter 22 returns to network evidence as one source in a provenance map.

7.1 Layering

The layered model separates concerns: link (local delivery), network (IP addressing and routing), transport (TCP, UDP — ports and reliability), and application (DNS, HTTP, TLS-protected protocols). An observation belongs to a layer and proves things only at that layer. A TCP connection from host A to address X on port 443 shows that A exchanged packets with X; it does not show which website, which user, or what data.

Layering also tells you which team holds the evidence: link and network data often sit with infrastructure staff, application logs with the system owner. Ask the right owner for the right layer.

7.2 DNS

The Domain Name System (RFC 1034/1035) maps names to records. A query log shows that a resolver was asked for a name; it does not show that a connection followed. Answers can be cached at several levels, so a host may connect to an address without a fresh query. Time-to-live (TTL) values explain such gaps. Many names can point to one address (shared hosting, content-delivery networks), so an address alone rarely identifies a site.

In the portal example, the DNS log at 02:14:05 shows that the portal asked for cdn-sync.example. The flow one second later is consistent with a connection to the answer, but only the flow record shows that traffic actually moved.

7.3 Transport

TCP connections begin with a handshake (SYN, SYN-ACK, ACK). A SYN without a reply means an attempt, not a connection. Ports are conventions: 443 usually carries TLS, but any service can listen anywhere. UDP has no handshake; a single datagram is not a conversation.

In the portal example the flow shows outbound and inbound bytes over several minutes, which implies a completed handshake and a working conversation. A flow showing only a few small packets outbound and none back would describe an attempt, not a transfer, and would support a much weaker claim. Check the packet counts in both directions before using the word "connection" in a report.

7.4 TLS

TLS (version 1.3 is specified in RFC 8446) encrypts application data. Observers can still see the endpoints, timing, sizes and, in many deployments, the Server Name Indication (SNI) — the hostname the client requested — unless Encrypted Client Hello is used. Certificates identify a server name to the client; a certificate seen in a trace shows which name the server claimed, which is useful but not proof of what content was exchanged.

In the portal example, the SNI in the sampled capture matches the name the DNS log recorded, so two sources agree on the requested hostname, though they do not show what was sent.

7.5 Flow records versus packet capture

Flow records (for example NetFlow/IPFIX) summarize conversations: endpoints, ports, start, duration, byte and packet counts. They are cheap to keep for long periods but contain no payload. Packet capture (pcap) contains packets, possibly payloads, and is expensive and privacy-sensitive. Flows answer "did A talk to X, when and how much?"; pcap can answer "what was said?" if it is unencrypted. Both are subject to sampling and sensor placement: a sensor sees only the traffic that passes it.

In the portal case the flow gives the 18.4 MB figure. The flow tells you that volume and its timing; only payload, which this capture does not hold beyond a short encrypted sample, could tell you what the bytes contained, and that is why the content question stays open.

7.6 Worked example (synthetic): did the portal talk to the suspicious host?

Fictional trace. Hypothesis: the Harbourline patient portal server 10.20.0.15 sent data to 203.0.113.50 (a documentation address, RFC 5737) on 4 March.

Evidence: 1. DNS log, 02:14:05: 10.20.0.15 asked the internal resolver for cdn-sync.example → answer 203.0.113.50, TTL 300. 2. Flow record, 02:14:06–02:19:40: 10.20.0.15:51544 → 203.0.113.50:443, TCP, 18.4 MB outbound, 0.2 MB inbound. 3. TLS ClientHello in a 60-second sample capture: SNI cdn-sync.example. 4. The portal's change log: a new image-synchronization plug-in was installed on 3 March.

What is supported: a TCP session existed from the portal to that address for about 5.5 minutes, carrying about 18 MB outbound (flow, observation). The client requested the name cdn-sync.example (DNS and SNI agree). What is not supported: the content of the 18 MB; that it was patient data; that it was malicious. Competing explanation: the new plug-in synchronizing images. Next bounded checks: the plug-in's documented endpoint and schedule; the portal's file-access log at 02:14; the vendor's confirmation. If the plug-in is documented to use a different domain, the hypothesis strengthens.

7.7 Practical activity

On your own computer, use your operating system's DNS cache or a command like nslookup against a public name to observe a query and its TTL. Record what the output proves and does not prove. Do not capture traffic on networks you do not own or administer.

Run the same lookup twice a minute apart and note whether the TTL decreased, which shows a cached answer. Write two sentences: one stating what the output shows, and one listing what it cannot show, such as whether any connection followed. Compare results with a classmate using a different resolver; differing answers for the same name are normal for content-delivery networks and are a useful reminder that an address alone rarely names a site.

7.8 Common errors and limits

Treating a DNS query as proof of a connection, or an address as proof of a site.
Treating port 443 as proof of HTTPS, or encryption as proof of legitimacy.
Reading byte counts as data content.
Forgetting sensor placement and sampling: absence in a flow log may mean "not seen", not "did not happen".
Reading an absence of SNI as proof of malice; many clients and protocols omit it legitimately.
Comparing timestamps from DNS and flow sensors without checking that their clocks agree.
Reporting a sampled capture as if it covered the whole session; sixty seconds is a fragment, not the conversation.

Exercises — chapter 7

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.

EX019 — Layer placement. Inputs: (a) a DNS query for pay.example; (b) a SYN to port 22 with no reply; (c) an IPFIX record of 2 GB to a cloud storage address; (d) an HTTP request line in a proxy log. Steps: place each in a layer and state the strongest claim it supports. Rubric: 3 = all four correct with modest claims; 2 = one overclaim; 1 = layers wrong; 0 = none.

EX020 — Missing DNS. Inputs: a flow from a workstation to 198.51.100.7:443 with no corresponding DNS query in the resolver log. Steps: give three explanations and the check for each. Rubric: 3 = cached answer (check TTL/previous queries), alternate resolver or DoH (check resolver settings, traffic to known DoH endpoints), hard-coded address (check process/binary); 2 = two; 1 = one; 0 = none.

EX021 — Strengthen the hypothesis. Inputs: §7.6. Steps: list what evidence would make "patient data was exfiltrated" likely, and what would make it unlikely. Rubric: 3 = specific evidence both ways (file-access logs for patient files at 02:14, plug-in documentation, vendor endpoint ownership, size vs image library size); 2 = one side only; 1 = vague; 0 = none.

Chapter synthesis

Each network observation proves something only at its own layer. Correlate DNS, flow and TLS evidence, keep content claims separate from connection claims, and remember that sensors see only what passes them.