◇ 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 Reaching a site"]
  N2["2.2 HTTPS"]
  N3["2.3 DNS control"]
  N4["2.4 Package downloads"]
  N5["2.5 Network controls"]
  N6["2.6 Outbound calls"]
  N7["Email security"]
  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 Reaching a site"]
  N2["2.2 HTTPS"]
  N3["2.3 DNS control"]
  N4["2.4 Package downloads"]
  N5["2.5 Network controls"]
  N6["2.6 Outbound calls"]
  N7["Email security"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX004"]

[Learning outcomes]
    |
    v
[2.1 Reaching a site]
    |
    v
[2.2 HTTPS]
    |
    v
[2.3 DNS control]
    |
    v
[2.4 Package downloads]
    |
    v
[2.5 Network controls]
    |
    v
[2.6 Outbound calls]
    |
    v
[Email security]
    |
    v
[Worked example] --> [Exercise EX004]

Learning outcomes

You will (1) explain how browsers reach hosted apps; (2) describe DNS, HTTPS and content delivery; (3) explain how build services download packages; (4) identify network controls for apps and builds.

2.1 Reaching a site

A visitor types the Greenleaf booking address. DNS translates the name to an address; the browser connects over HTTPS, checking the certificate; a content delivery network may serve images; the request reaches the app server. Each step is a place where something can go wrong for the clinic's visitors. A wrong DNS answer sends them elsewhere, a broken certificate makes the browser warn them away, and a slow app server delays bookings. Diego traces this path once for Greenleaf so he knows which Brightwave account controls each step.

2.2 HTTPS

HTTPS encrypts traffic and lets the browser confirm it reaches the real site. Brightwave renews certificates automatically and monitors expiry. For the Greenleaf booking site this matters because visitors type owners' phone numbers and upload pet records into the page. Without HTTPS, those details would cross networks readable and changeable by anyone on the path. Automatic renewal removes the old risk of a forgotten certificate expiring on a busy clinic morning, and expiry monitoring catches the rare case where renewal itself fails.

2.3 DNS control

Client domains are managed in Brightwave's DNS account with two-person approval and multi-factor sign-in, since a changed DNS record could send visitors to a fake site. One wrong record in this account could redirect the Greenleaf booking page, including its upload form, to a copy run by someone else. Visitors would see the clinic's address in their browser and have no reason to doubt it. That is why changes need a second person's approval rather than resting on a single developer's sign-in, even for small routine edits.

2.4 Package downloads

Build services download packages from public registries over HTTPS. Lockfile hashes let the build check that what arrives is what was recorded. This is where upload-kit entered every affected project: the build fetched it from the public registry exactly as the lockfile recorded. The hash check protects against a changed download, but it does not judge whether the recorded version is safe. A flawed version such as upload-kit 3.1.0 matches its hash perfectly, so integrity checks and advisory checks solve different problems.

2.5 Network controls

App servers accept web traffic only through the hosting platform's load balancer; databases are not reachable from the internet; build machines can reach only package registries and code hosts. Each rule limits what an attacker could reach from one foothold. If a flaw in the Greenleaf app were misused, the database would still accept connections only from the app, and the build machines could not be used to browse arbitrary sites. Diego writes down each rule's purpose so later changes keep it.

2.6 Outbound calls

Some apps call external services (payments, email). Each allowed destination is listed, which limits server-side request forgery (OWASP Top 10:2021 A10). Before Diego's check, Greenleaf's app could connect to any address on the internet, so a flaw that let someone steer its requests would have had no limit. After the change it may reach only the three services it really uses, and anything else is refused. A new external service now needs an explicit list change, which also creates a record of when each destination was added.

Email security

Client sites send booking confirmations by email. Brightwave configures each sending domain with standard email authentication records so receiving servers can check messages really come from the clinic, which makes it harder for others to send convincing fake booking emails in the clinic's name. Diego checks the records for all clients and finds two missing.

Worked example

Diego checks Greenleaf's outbound rules and finds the app can connect anywhere. He lists the three services it actually uses and Aiko restricts outbound traffic to them; the app works normally afterwards.

Synthetic case. Network settings are synthetic.

Errors and limits

Network controls limit damage but cannot fix flaws in the application itself.

Exercises

Synthesis

Control names, connections and downloads; list allowed destinations.

Continue studying — chapter 02 of 30

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