Chapter 11 — Networks and protocols
Lesson map
Lesson 11 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["11.1 Layers"]
N2["11.2 Addresses and networks"]
N3["Lab — failures by network"]
N4["11.3 Reading the result"]
N5["11.4 HTTPS visibility"]
N6["11.6 Protocol knowledge"]
N7["DNS and time"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["11.1 Layers"]
N2["11.2 Addresses and networks"]
N3["Lab — failures by network"]
N4["11.3 Reading the result"]
N5["11.4 HTTPS visibility"]
N6["11.6 Protocol knowledge"]
N7["DNS and time"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[Learning outcomes]
|
v
[11.1 Layers]
|
v
[11.2 Addresses and networks]
|
v
[Lab — failures by network]
|
v
[11.3 Reading the result]
|
v
[11.4 HTTPS visibility]
|
v
[11.6 Protocol knowledge]
|
v
[DNS and time]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) explain addressing, ports and common protocols; (2) read network telemetry such as flows and web logs; (3) aggregate activity by network; (4) recognise limits of IP-based attribution.
11.1 Layers
Networks move data in layers: physical links, IP addressing and routing, TCP or UDP transport, and applications such as HTTPS. Telemetry exists at each layer: link statistics, flow records, and application logs.
Each layer answers different questions. Link statistics show whether a cable or port is saturated; flow records show who talked to whom, for how long and how many bytes moved; application logs show what was asked for and what came back. During the portal burst, flows reveal the volume from one network, but only the web server logs show which usernames were tried.
11.2 Addresses and networks
IPv4 addresses are grouped into networks by prefix. A /24 network shares its first three octets. Attack traffic from one hosting provider often spans many addresses in a few networks, so aggregating by network reveals bursts that per-address counts hide.
Counting per address can make a distributed attack look harmless: fifty addresses with two attempts each never trip a per-address threshold of five. Grouping by /24 collapses them into one network with a hundred attempts. The choice of prefix length is a trade-off, since a wider prefix catches more spread-out activity but also merges unrelated customers behind the same provider.
Lab — failures by network
"""Count failed portal logins by source /24 network and by distinct usernames (synthetic)."""
from collections import defaultdict
log = [("203.0.113.10","u1","fail"),("203.0.113.11","u2","fail"),("203.0.113.12","u3","fail"),
("203.0.113.13","u4","fail"),("203.0.113.14","u5","ok"),("198.51.100.20","u6","fail"),
("198.51.100.20","u6","fail"),("198.51.100.20","u6","ok"),("203.0.113.15","u7","fail"),
("203.0.113.16","u8","fail")]
fails = defaultdict(int); users = defaultdict(set)
for ip, user, res in log:
net = ".".join(ip.split(".")[:3]) + ".0/24"
users[net].add(user)
if res == "fail": fails[net] += 1
for net in sorted(fails):
print(f"{net:17} failures={fails[net]} distinct_users={len(users[net])}")
Run with python3 lab_failed.py. Verified output:
198.51.100.0/24 failures=2 distinct_users=1
203.0.113.0/24 failures=6 distinct_users=7
11.3 Reading the result
The 203.0.113.0/24 network produced 6 failures, one each against six usernames, and touched 7 distinct usernames in all once u5's success is counted — many accounts, few attempts each, the pattern of credential stuffing. 198.51.100.0/24 shows 2 failures and a success for one user: a customer mistyping a password.
The pattern matters more than the totals. Many usernames with one attempt each suggests someone working through a list of leaked credentials, hoping some customers reused passwords. A single username with a couple of failures and then a success looks like an ordinary person who forgot which password they used. A rule that only counted failures would treat both networks alike and miss that distinction.
11.4 HTTPS visibility
Encrypted web traffic hides content from network sensors; the web server's own logs show paths, status codes and usernames. Choosing where to observe is an engineering decision.
Breaking encryption on the network to inspect content is possible with interception proxies, but it adds risk, cost and privacy concerns. For the portal, the server already sees decrypted requests, so its logs are the natural place to observe logins. Network sensors still help with volume and timing, while the server logs supply the meaning of each request.
11.5 Attribution limits
An address identifies a connection point, not a person. Shared proxies, cloud ranges and address reuse make blocking and attribution imprecise.
Many customers may share one address behind a mobile carrier's gateway, so blocking it can lock out innocent users. Attackers rent cloud servers and abandon them within hours, so an address that was hostile yesterday may belong to someone else tomorrow. SOC reports therefore describe addresses as sources of activity rather than naming who was behind them. Blocks on addresses are given expiry dates.
11.6 Protocol knowledge
Knowing that login uses POST to /login and returns 401 on failure lets Amara write accurate parsing.
Without that knowledge, a parser might count every request to the login page, including people simply loading the form, as an attempt. Knowing the method, path and status codes lets Amara count only submitted credentials and separate failures from successes. She confirms the details with the portal developers rather than guessing from a sample, since a redirect after login could hide the real outcome.
DNS and time
DNS logs show which names hosts look up, often revealing contacts before connections happen. Network devices must share synchronised time so flows, DNS and web logs line up; without it, correlation across layers becomes guesswork.
Worked example
Amara notices that one address, 203.0.113.14, produced the success for u5. She checks the web log: the same session then requested /account/address with a change at 10:07. She adds this to the ticket as a possible account takeover action.
Synthetic case. Addresses use documentation ranges; events are synthetic.
Errors and limits
Aggregating by /24 can merge unrelated users of large providers; confirm with other signals.
Exercises
- EX031 — Network aggregation. Why aggregate failures by /24 network? Rubric: 3 = bursts spread over many addresses appear together; 2 = partial; 1 = no reason; 0 = none.
- EX032 — Stuffing pattern. Which network shows credential stuffing, and why? Rubric: 3 = 203.0.113.0/24: many users, few attempts each; 2 = network only; 1 = wrong; 0 = none.
- EX033 — Follow-up action. What did the successful session do next? Rubric: 3 = requested address change at 10:07; possible takeover; 2 = partial; 1 = vague; 0 = none.
Synthesis
Network telemetry gains meaning through aggregation and protocol knowledge, within the limits of IP attribution.
Continue studying — chapter 11 of 50
← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →