Chapter 2 — Networks and protocols

Chapter 2 — Networks and protocols

Lesson map

Lesson 02 published. Map, example, EX005.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Mapping connections"]
  N2["2.2 Restricting exposure"]
  N3["2.3 Verifying connectivity safely"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX005"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Mapping connections"]
  N2["2.2 Restricting exposure"]
  N3["2.3 Verifying connectivity safely"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX005"]

[Learning outcomes]
    |
    v
[2.1 Mapping connections]
    |
    v
[2.2 Restricting exposure]
    |
    v
[2.3 Verifying connectivity safely]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX005]

Learning outcomes

You will (1) map network connections; (2) restrict exposure of node services; (3) verify connectivity safely.

2.1 Mapping connections

Aiko lists every network connection in the service: borrowers to the web front end over encrypted web traffic, the application server to the database, the deposit service to one node's programming interface, nodes to each other through peer connections, and the monitoring server to all components. For each she records the port and protocol. A complete connection map makes it possible to check that only intended connections exist. She notes that encrypted protocols protect data in transit, while the map shows who should be allowed to connect to whom in the first place.

2.2 Restricting exposure

Node programming interfaces can submit transactions, so they must be reachable only by trusted services. Aiko checks firewall rules and finds that node three's interface accepts connections from the whole office network, not just the deposit service. She reports it, and Mr Kowal approves a change restricting it. Peer ports are limited to the other nodes' addresses. NIST IR 8202 explains that permissioned ledgers rely on controlling participation and access. Restricting exposure reduces the number of ways anything can go wrong, whether by mistake or misuse.

2.3 Verifying connectivity safely

After the change, Aiko verifies that the deposit service still reaches node three and that an office computer no longer can. She uses simple connection tests from authorised machines only, within the scope Mr Kowal approved in writing. She does not probe systems outside the library's own network. She records the tests and results. Verification confirms that a security change achieved its purpose without breaking the service. Technicians often skip this step, and Mr Kowal warns that unverified changes are a common cause of both outages and false confidence.

Worked example

Aiko restricts node three's interface from the whole office network to the deposit service and verifies both outcomes from authorised machines.

Synthetic case. The network and change are synthetic; NIST IR 8202 is a real source.

Errors and limits

Making a firewall change without verifying it can break the service or leave exposure unchanged.

Exercises

• EX005 — Map contents. What does Aiko record for each connection? Rubric: 3 = port and protocol;; 2 = ports;; 1 = colour;; 0 = none.
• EX006 — Exposure found. What exposure did she find? Rubric: 3 = node three's interface open to the office network;; 2 = node three;; 1 = peer ports;; 0 = none.
• EX007 — Verification scope. What limits Aiko's connectivity tests? Rubric: 3 = authorised machines within written scope;; 2 = written scope;; 1 = vague;; 0 = none.
• EX008 — Unverified change risk. Why verify changes? Rubric: 3 = unverified changes cause outages and false confidence;; 2 = confirm effect;; 1 = habit;; 0 = none.

Synthesis

Connection maps, restricted exposure and safe verification secure node networking.

Continue studying — chapter 02 of 18

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