◇ OpenCyber Academy
Technologist · Chapter 2 · English

Chapter 2 — Networks and internet services

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

Chapter 2 — Networks and internet services

Lesson map

Lesson 02 published. Map, example, EX004.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Services residents use"]
  N2["2.2 Resolver logs"]
  N3["2.3 Passive DNS data"]
  N4["2.4 Mail flow"]
  N5["2.5 Documentation addresses"]
  N6["2.6 Ports and protocols"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX004"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Services residents use"]
  N2["2.2 Resolver logs"]
  N3["2.3 Passive DNS data"]
  N4["2.4 Mail flow"]
  N5["2.5 Documentation addresses"]
  N6["2.6 Ports and protocols"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX004"]

[Learning outcomes]
    |
    v
[2.1 Services residents use]
    |
    v
[2.2 Resolver logs]
    |
    v
[2.3 Passive DNS data]
    |
    v
[2.4 Mail flow]
    |
    v
[2.5 Documentation addresses]
    |
    v
[2.6 Ports and protocols]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX004]

Learning outcomes

You will (1) explain how DNS, web and email services expose indicators; (2) read a resolver log line; (3) use public DNS data passively; (4) understand the role of address ranges reserved for documentation.

2.1 Services residents use

Residents reach CMS through the website, the permits portal and email. Each depends on DNS records that CMS publishes. Attackers imitate these names with lookalike domains to trick residents into paying fake fees.

A resident who receives a message with a link has no easy way to tell corvale-permits-pay.example from a name CMS really publishes. Lena keeps a list of the council's genuine names, so a new lookalike can be compared against it. The fraud aims at residents, but CMS learns about it from residents' reports and from its own logs.

2.2 Resolver logs

A resolver log line typically records time, client, queried name and answer. Lena reads lines such as "08:03 ws-114 pay-portal.example". The client tells her which machine asked; the name tells her whether it matches an indicator.

If pay-portal.example is on an indicator list, the line shows that ws-114 at least looked up the name at 08:03. It does not show that the machine connected or entered anything, so Lena treats it as a lead to check, not proof of harm.

2.3 Passive DNS data

Some services publish historical DNS resolutions collected from many resolvers. Looking up a name there is passive: CMS does not contact the suspicious server. Lena may use services CMS has approved and whose terms allow this use.

Being passive matters because contacting a suspicious server could alert its operator or expose CMS's interest. A passive lookup answers questions such as when a name first resolved, without any CMS system touching it. Lena uses only approved services because their terms set what she may look up and how results may be shared.

2.4 Mail flow

Email enters through CMS's gateway, which logs sender, recipient, subject and attachment names. Phishing (T1566) indicators — sender domains, subjects, attachment hashes — are checked here.

The gateway log lets Lena check whether a phishing indicator from MCX has already reached CMS mailboxes. A matching sender domain or attachment hash shows which staff received the message and when. Her log-source notes say who can query the gateway, so she knows at once whether to search it herself or ask its owner. Attachment names in the log help when MCX shares a file name but no hash, though names are easy for attackers to change.

2.5 Documentation addresses

This course uses the ranges 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24, which RFC 5737 reserves for documentation, and the .example domain. Real addresses never appear in teaching material, so nobody blocks or investigates an innocent party by copying an example.

Using these ranges means an example in this book, such as 198.51.100.23, can be pasted into a search or a block list without harming anyone, because no real system uses that address. The 203.0.113.300 value in the chapter 3 lab is deliberately invalid as well as reserved, so it tests the validation step without pointing anywhere real.

2.6 Ports and protocols

Web services use 443 (HTTPS); mail uses 25 between servers. Traffic from office desktops to unusual ports is worth noting, but council applications sometimes use odd ports legitimately — check with owners before treating it as suspicious.

A council planning application might use an unusual port for its database, which looks odd in a log but is normal. Asking the owner first avoids sending an alert, or worse a block, against a service the council depends on. Lena records each confirmed exception so the same question is not asked again every time the port appears.

Worked example

Residents report a text message linking to "corvale-permits-pay.example". Lena checks passive DNS through the approved service: the name first resolved three days ago. The resolver log shows two staff machines also looked it up after receiving the same text on work phones. She reports both findings to her supervisor.

Synthetic case. The message and domain are invented.

Errors and limits

Passive DNS coverage is incomplete; absence of records does not prove a name is unused.

Exercises

Synthesis

DNS, web and mail logs reveal indicator contact; use passive data through approved services and teach only with reserved examples.

Continue studying — chapter 02 of 30

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →