One Flat Network, a Default-Password NVR and a Ransom Note
Mwenge Skills Centre runs 62 staff laptops, a 300-device student BYOD fleet and three lab servers (a file share on SMB/445, an attendance system on 8080, a print server). Everything sits on 192.168.10.0/24 behind one consumer router doing NAT, with two consumer access points, and the staff SSID and student SSID both bridge onto the same Layer 2 segment. The manager recently bought an IP camera NVR, and the installer forwarded TCP 8080 on the router to it so the manager can watch from home; the NVR administrator password is still the factory default. Last Tuesday the file server logged 4,100 failed SMB logins in six hours from 37 different student devices, and one lab server's data directory was found to contain .docx files renamed with an unfamiliar extension alongside a ransom note. The centre has no capital budget this year, one IT officer and a four-hour maintenance window on Saturday. The manager's stated priorities are: 'the cameras, then the internet speed, then the rest'.
1. The manager's priority order is cameras, speed, everything else. Reorder the work by risk and justify the order in terms he can act on.
Read the worked answer
He has ranked by visibility, not by risk. The ranking still has to be defensible in a written report, so I would restate it and get agreement rather than quietly work in a different order.
- Contain the ransomware and the SMB exposure, today. Renamed .docx files plus a ransom note are an active incident: that loss is irreversible. The file server is still answering on 445 to every device on the flat segment, and 4,100 failed logins from 37 student devices is consistent with a credential-spraying worm or a badly configured scanner. Isolate the affected server from the network but keep it powered for forensics, disable SMBv1, block 445 between client segments, and restore from a backup only after verifying the backup is not encrypted too.
- The NVR, today. Default credentials on a port forwarded to the internet is the highest-likelihood external compromise on site, and it is already discoverable by scanning. It has produced no evidence of loss yet, so it ranks below containment but above speed.
- Segmentation, in Saturday's window. This is what stops the next incident spreading, but it is a change, and changes during an incident create confusion.
- Internet speed last. It is the pain staff feel, but it neither loses data nor creates liability for student records.
How to say it to him: frame items 1 and 2 as 'student records and the camera feed are reachable by anyone on the student Wi-Fi right now; speed comes after that'. Put the agreed order in an email, because if the NVR is compromised over the weekend, the decision record matters.
2. Propose a segmented design with a concrete addressing plan and the inter-segment rules, being honest about what the current hardware can and cannot do.
Read the worked answer
Hardware reality first. The existing /24 can be split only if the router supports 802.1Q subinterfaces and inter-VLAN ACLs; a consumer router usually does not, and cannot filter between segments even if it can tag them. The honest minimum is one managed Layer 3 switch, roughly the price of a mid-range NVR, even in a 'no hardware' year. Say that in the budget note rather than promising segmentation that cannot be enforced.
Addressing on 10.20.0.0/16:
- VLAN 10 Staff: 10.20.10.0/24, 62 laptops plus printers, DHCP pool .100 to .200.
- VLAN 20 Student BYOD: 10.20.20.0/22, 1,022 addresses for 300 devices and growth; client isolation on the SSID.
- VLAN 30 Servers: 10.20.30.0/28, 14 usable addresses for the file share, attendance and print server.
- VLAN 40 Cameras and NVR: 10.20.40.0/28.
- VLAN 99 Management: 10.20.99.0/28, switch and access-point management only.
Inter-segment rules at the Layer 3 device:
- Student to internet: allow. Student to servers: deny all except print (631/9100) and DHCP/DNS. Student to staff and student to cameras: deny both directions.
- Staff to servers: allow 445 and 8080. Staff to cameras: allow 443 to the NVR only.
- Cameras to anything except the NVR and the vendor's update host: deny.
- Management: allow from a single admin workstation only.
Put DHCP on the Layer 3 device with a relay per VLAN. Note that 300 BYOD devices do not fit in any /24 split of the current range, which is the technical reason the present flat design cannot simply be 'VLANed' as it stands.
3. The manager will not give up watching the cameras from home. Describe how you would remediate the NVR without breaking that, and name the trade-off you are asking him to accept.
Read the worked answer
Order matters: fix the exposure before improving the experience, but do not cut his access on a Friday without a replacement ready.
- Change the NVR administrator password to a long unique value, store it in the IT password manager, and create a separate low-privilege viewer account for the manager so the admin account is not used daily.
- Apply the latest vendor firmware. If the model is end-of-life and receives no firmware, that is a written finding, not something to discover later.
- Build the replacement path before removing the port forward: a VPN (WireGuard on the router if it supports it, otherwise a small always-on appliance) with a single peer for his phone.
- Remove the TCP 8080 forward, disable UPnP on the router (which is probably how the forward reappears after a reboot), move the NVR to the camera segment, enable HTTPS on it, and restrict inbound access to 443 from the staff segment only.
- Verify from outside the network that 8080 is closed, that the VPN is the only path in, and that failed logins on the NVR are logged and alerted.
The trade-off to state explicitly: he gains one extra tap, opening the VPN app before the camera app. In exchange the camera feed stops being a publicly reachable host with a guessable password. If he insists on direct access, the honest answer is that no responsible configuration provides it, and the request should be refused in writing rather than implemented and forgotten.