◇ OpenCyber Academy
Bachelor's · Chapter 7 · English

Chapter 7 — Networks and protocols

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 7 — Networks and protocols

Lesson map

Lesson 07 published. Map, example, EX019.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Ports are not services"]
  N2["7.2 TLS"]
  N3["7.3 Dangerous experiments"]
  N4["7.4 Documentation ranges"]
  N5["7.5 Capture ethics"]
  N6["7.6 ATT&CK"]
  N7["7.7 Applied note"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX019"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Ports are not services"]
  N2["7.2 TLS"]
  N3["7.3 Dangerous experiments"]
  N4["7.4 Documentation ranges"]
  N5["7.5 Capture ethics"]
  N6["7.6 ATT&CK"]
  N7["7.7 Applied note"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX019"]

[Learning outcomes]
    |
    v
[7.1 Ports are not services]
    |
    v
[7.2 TLS]
    |
    v
[7.3 Dangerous experiments]
    |
    v
[7.4 Documentation ranges]
    |
    v
[7.5 Capture ethics]
    |
    v
[7.6 ATT&CK]
    |
    v
[7.7 Applied note]
    |
    v
[Worked example] --> [Exercise EX019]

Learning outcomes

You will (1) read ports and services carefully; (2) explain TLS roles; (3) avoid protocol experiments on live TRB systems.

7.1 Ports are not services

Port 443 often means HTTPS but may not. Inventory names and certificates matter. A service on 443 at TRB might be the online banking front end, an admin console or an internal API exposed by mistake. Sam identifies it from the asset register, the certificate's subject names and the owner's description before choosing any method card. Treating every 443 as 'the website' leads to wrong scope decisions, such as testing an admin console under rules written for the public site. The owner's answer is recorded in the scope file beside the port.

7.2 TLS

Protects confidentiality and integrity in transit; does not fix broken authorization in the app. An encrypted session to online banking still lets a logged-in customer request another customer's statement if the application fails to check ownership. Sam therefore reports TLS weaknesses and authorization weaknesses as separate findings with separate owners: the platform team for certificates and protocol settings, the application team for access checks. Good TLS is necessary but tells nothing about what the server does once the request arrives.

7.3 Dangerous experiments

Sending malformed packets to the ledger VLAN to "see what happens" is out of bounds. The ledger hosts are fragile, change-controlled and outside ordinary scope, so an unplanned reaction such as a crash or a stuck transaction could affect real payments. Even where the ROE allows some network testing, malformed-packet experiments need a named method card, a maintenance window and the owner's explicit approval. Without those, the right action is to record the question and raise it with the ledger owner.

7.4 Documentation ranges

Labs use 198.51.100.0/24 and 203.0.113.0/24 so examples cannot hit the real Internet. These ranges, reserved for documentation, are not routed on the public internet, so a typo or copied example sends nothing anywhere real. TRB's synthetic scope, 198.51.100.0/26 with SWIFT at .20, uses them for the same reason. Using real-looking addresses in course material risks a learner pasting them into a tool on a live network. The 203.0.113.0/24 range plays the attacker's or partner's side in examples. If a lab printout ever shows an address outside these ranges, treat it as a defect in the material and report it.

7.5 Capture ethics

Packet captures need ROE clauses; they often contain customer data. A capture on TRB's web tier can contain session data, account numbers or statement contents. The ROE must say who may capture, on which segments, for how long the files are kept and how they are deleted. Without that clause, Sam does not capture at all, and he prefers configurations and logs because they answer most questions with far less customer data. Any capture taken is hashed, stored in FindingsDesk and deleted on schedule.

7.6 ATT&CK

T1190 Exploit Public-Facing Application describes abuse of internet-facing services — named for detection design, not as a how-to. Linking a finding to T1190 tells the monitoring team which detections to check, such as unusual errors or requests on the online banking front end, without describing how the weakness was triggered. Sam adds the technique ID in FindingsDesk so PulseMap can show coverage by technique, and the report never includes steps. Detection owners can then test their rules against synthetic requests in staging.

7.7 Applied note

Capture ROE clauses specify retention hours and who may run wireshark. Sam's default ask is "configs and logs first; packets only if those fail". Most TRB web findings never need packets; when they do, the clause is already written. Writing the clause in advance means an urgent capture request during a window does not lead to an improvised decision about customer data. The clause also names who deletes the files when the retention hours expire. The named person confirms deletion in the capture ticket when the retention hours expire, so nobody assumes the files are gone.

7.8 Banner humility

Banners feed inventory, not severity theatre. Sam files version exposure as low unless paired with a reachable vulnerable path under ROE — which this course still will not exploit in the wild. A banner showing an old version may be patched by the vendor's backport, so the version alone does not prove a weakness. Recording it as inventory lets owners plan upgrades without inflating a report with alarming but unverified findings. If a reachable weakness is later confirmed under ROE, severity is re-scored with that evidence.

7.9 Doc-range lint

Examples in docs are linted to ensure IPs are documentation ranges. Sam's lint failed a blog draft using a real TRB address; good catch. The real address would have revealed part of TRB's network layout and could have invited readers to probe it. The lint runs on every documentation change and blocks publication until the address is replaced with a documentation-range example, such as one from 198.51.100.0/24. The blog draft was corrected and the original address reported to the network owner.

7.10 Redirecting a FIN-scan request

A learner asks to try a TCP FIN scan on staging "for the coursework". Sam shows the ROE forbidden-methods list and the course boundary page. They run an offline PCAP quiz instead. Curiosity is redirected, not shamed — and not indulged on bank networks. The quiz uses synthetic captures, so the learner still sees how packets look without any traffic touching a TRB network. Sam also logs the request as a teaching note, without the learner's name, because it shows where the course boundary needs to be explained earlier.

PCAP quiz answers never include payload bytes from real customers. Synthetic captures are generated with documentation-range addresses and invented payloads, so no customer data can leak through teaching material. Answers describe headers, timing and flow patterns, which is what learners need for detection reasoning. Sam regenerates the quiz files when the course changes rather than editing captures by hand, so their provenance stays clear. Each regenerated file is hashed and the hash published with the quiz.

Worked example (synthetic TRB)

Sam's scope lab rejects 203.0.113.9 as OUT OF SCOPE using only local IP math.

Synthetic case — Riverstone Transit Bank (TRB). The bank, Sam Ito, TrackScope/FindingsDesk/PulseMap and all figures are invented for teaching.

Errors and limits

This book grants no authority to test real banks or payment systems. Labs use documentation-range addresses and synthetic data only; exploit code is never provided.

Exercises

Synthesis

Protocol literacy without live experimentation; captures only under ROE.

Continue studying — chapter 07 of 40

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →