## Chapter 7 — Networks and protocols ### Lesson map Lesson 07 published. Map, example, EX019. ```mermaid flowchart TD N0["Learning outcomes"] N1["7.1 Addresses and locations"] N2["7.2 DNS"] N3["7.3 HTTP and HTTPS"] N4["7.4 Email protocols"] N5["7.5 Reading sign-in logs"] N6["7.6 DNS as evidence"] N7["Ports and services"] N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 N7 --> EX["Worked example"] EX --> Q["Exercise EX019"] ``` ### Logical drawing ```mermaid flowchart LR N0["Learning outcomes"] N1["7.1 Addresses and locations"] N2["7.2 DNS"] N3["7.3 HTTP and HTTPS"] N4["7.4 Email protocols"] N5["7.5 Reading sign-in logs"] N6["7.6 DNS as evidence"] N7["Ports and services"] N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX019"] ``` ```text [Learning outcomes] | v [7.1 Addresses and locations] | v [7.2 DNS] | v [7.3 HTTP and HTTPS] | v [7.4 Email protocols] | v [7.5 Reading sign-in logs] | v [7.6 DNS as evidence] | v [Ports and services] | v [Worked example] --> [Exercise EX019] ``` ### Learning outcomes You will (1) explain IP addressing, DNS, HTTP and email protocols; (2) read sign-in and mail logs at the protocol level; (3) reason about geolocation and its limits; (4) recognise network evidence of phishing. ### 7.1 Addresses and locations Every connection has a source IP address. Identity providers often add a geolocation (country) guessed from the address. Geolocation is approximate: VPNs, mobile networks and cloud services can place users in the wrong country. In the case, a student who signed in from home over a mobile network appeared to be in another country for a few minutes, because the operator routed traffic through a gateway abroad. Lucas therefore treats a single odd country as a lead, not a conclusion, and looks for supporting signs such as a new mailbox rule or an unusual client application. ### 7.2 DNS DNS translates names such as riverton.example.ac.uk into addresses. The phishing page used riverton-library.example.net, a look-alike name. DNS logs from campus resolvers show which devices looked it up. The look-alike domain was chosen to pass a quick glance: it contained the university's name and the word library, but sat under a different parent domain that Riverton did not own. Lucas checks a suspicious name by reading it from the right, since the part just before the final suffix shows who actually controls it. Here, that was not Riverton. ### 7.3 HTTP and HTTPS Web pages use HTTP over TLS. The fake sign-in page received passwords by HTTPS POST; network sensors see only the destination name, not the password. For the SOC, this means network sensors cannot confirm which students typed their passwords; they can only show that a device connected to the fake page. Confirmation came from the other end, when a stolen password was used at the identity provider. The fake page itself had a valid certificate, so a padlock in the browser proved nothing about the site's honesty. ### 7.4 Email protocols Mail travels between servers by SMTP. Message headers record each server hop. Authentication results — SPF, DKIM and DMARC — show whether the sending domain authorised the message; the phishing email failed DMARC for its claimed sender. Lucas reads the headers from the bottom up, since each server adds its line at the top. The lowest received line showed the message entering from a hosting provider unrelated to Riverton or the library. The failed DMARC result confirmed the sender's address was forged, which helped the mail team write a filter blocking the remaining copies. ### 7.5 Reading sign-in logs A sign-in record shows time, user, IP, country, client application and result. s2047's 02:14 sign-in came from an address geolocated to the Netherlands using a desktop mail protocol. Two details made this record stand out. The country was unusual for a student who had only ever signed in from the United Kingdom, and the client was a desktop mail protocol rather than the web browser s2047 normally used. Older mail protocols often skip the second factor, which is one reason attackers prefer them after stealing a password. ### 7.6 DNS as evidence Campus DNS logs show 41 lookups of the look-alike name from university Wi-Fi, a lower bound on clicks from campus. It is a lower bound for two reasons noted in the worked results: lookups made off campus are not logged, and a device that looked the name up once may have clicked several times without repeating the query because of caching. Lucas reports the figure with both caveats, so nobody reads it as the total number of clicks. It still shows the campaign reached many devices on campus. ### 7.7 Limits Network evidence shows connections, not intentions; it needs context from other logs. A DNS lookup of the fake domain could come from a curious analyst checking the link, not a victim; a sign-in from the Netherlands could be a student on exchange. Lucas pairs each network record with account evidence, such as a rule change or a burst of sent mail, before calling an account compromised. Network data narrows the search; account data confirms it. Each conclusion in his notes names both. ### Ports and services Services listen on ports: 443 for HTTPS, 25 for server-to-server mail. Unusual ports in connection logs prompt questions. ### Worked example Lucas checks whether the Netherlands address could be a student's VPN. The address belongs to a hosting provider, and s2047's owner confirms she was asleep in Riverton. Combined with the click and the new mailbox rule, the evidence supports compromise. > **Synthetic case.** Addresses, names and counts are invented. ### Errors and limits Geolocation errors are common; never base a decision on country alone. ### Exercises - **EX019 — Geolocation limits.** Why is sign-in country unreliable on its own? *Rubric:* 3 = VPNs, mobile, cloud can misplace users; 2 = partial; 1 = reliable; 0 = none. - **EX020 — DMARC.** What does a DMARC failure tell analysts? *Rubric:* 3 = claimed sending domain did not authorise the message; 2 = partial; 1 = vague; 0 = none. - **EX021 — DNS lower bound.** Why are 41 DNS lookups a lower bound on campus clicks? *Rubric:* 3 = only campus resolvers; caching and off-campus clicks missed; 2 = partial; 1 = exact; 0 = none. ### Synthesis Protocol knowledge turns network logs into evidence, provided geolocation and visibility limits are respected. ### Continue studying — chapter 07 of 40 [← Chapter 06 (draft)](#ch-06) · [Course chapter index](../SUBJECTS.md) · [Chapter 08 (draft) →](#ch-08) ## Worked answers **EX019.** Because VPNs, mobile networks and cloud services can make addresses appear in the wrong country. **EX020.** That the sender's claimed domain had not authorised the message, a sign of spoofing. **EX021.** Only campus resolvers are logged, and caching or off-campus clicks are not counted, so the real number may be higher.