◇ OpenCyber Academy
Technologist · Chapter 20 · English

Chapter 20 — Network and communications security: troubleshooting

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 20 — Network and communications security: troubleshooting

Lesson map

Lesson 20 published. Map, example, EX058.

flowchart TD
  N0["Learning outcomes"]
  N1["20.1 A method for problems"]
  N2["20.2 Logs as evidence"]
  N3["20.3 Do not weaken controls"]
  N4["20.4 Communicating with users"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX058"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["20.1 A method for problems"]
  N2["20.2 Logs as evidence"]
  N3["20.3 Do not weaken controls"]
  N4["20.4 Communicating with users"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX058"]

[Learning outcomes]
    |
    v
[20.1 A method for problems]
    |
    v
[20.2 Logs as evidence]
    |
    v
[20.3 Do not weaken controls]
    |
    v
[20.4 Communicating with users]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX058]

Learning outcomes

You will (1) troubleshoot network problems methodically; (2) use logs and tests; (3) avoid weakening controls.

20.1 A method for problems

When something stops working after segmentation, the temptation is to remove rules until it works. Tomás follows a method instead: define the problem precisely, gather evidence from logs and tests, form a hypothesis, test it, fix the cause and verify. For example, "the science lab printer stopped printing at 9 a.m." is precise; "printing is broken" is not. Precise problem statements save time because they point to specific devices, zones and times to examine in the logs. Each step is noted in the ticket.

20.2 Logs as evidence

Denied connection logs are often the fastest way to find a missing flow. When the science lab printer fails, Tomás searches the firewall logs for denies involving its address around 9 a.m. He finds that teachers' laptops are trying to reach it on a port not in the needed-flows list, because this older printer uses a different printing protocol. The fix is a narrow rule allowing that protocol from staff to that printer only, recorded with its reason and owner.

20.3 Do not weaken controls

A common mistake is to fix problems with broad rules: "allow staff to everything in the shared devices zone". This works immediately but undoes segmentation, as the heating controller example showed. Tomás makes each fix as narrow as possible and records it. He also checks whether the problem reveals a gap in the flow list, updating it so the same problem does not recur at another site. Troubleshooting done well improves the design rather than eroding it. Gareth reviews every new rule weekly.

20.4 Communicating with users

During troubleshooting, the affected teacher needs to know what is happening. Tomás tells her the problem has been found and will be fixed within the hour, and suggests a nearby printer meanwhile. After fixing it, he confirms with her that it works. Clear communication reduces frustration and discourages workarounds such as students bringing in their own wireless devices. Gareth adds a simple form for reporting problems, including device, location and time, which makes later diagnosis much faster. The form is linked from the staff intranet.

Worked example

The printer problem is traced through deny logs to a missing protocol and fixed with one narrow rule in under an hour.

Synthetic case. The problem is synthetic.

Errors and limits

Removing rules until things work quickly undoes segmentation.

Exercises

Synthesis

Methodical troubleshooting with logs and narrow fixes restores service without weakening security.

Continue studying — chapter 20 of 30

← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →