Internal network assessment: segmentation that wasn't enforced

Scope

• Target: every live host on the server network, tested from an ordinary laptop on the personal Wi-Fi. That’s where a compromised phone or laptop would sit.
• Rules of engagement: my own network, no denial-of-service, nothing exploited, findings fixed before anything was published. Specific hosts, services and rules are left out of this write-up on purpose.

What held up

• Default credentials: none worked against any web dashboard, API or message broker I tried.
• File shares: anonymous read is denied.
• SSH: patched and current on every host checked.

Finding: HIGH, segmentation not enforced

The networks were split into separate VLANs, but the firewall grouped several of them into a single trust zone, and traffic inside a zone is allowed by default. On paper the networks were segmented; in practice any device on the personal Wi-Fi could reach every server directly.

There was already an allow-list for trusted admin devices. Nothing blocked the devices that weren’t on it, so the allow-list did nothing.

Remediation

Added an explicit deny from the personal network to the server network, with logging, ordered after the admin allow-list.

Verification

• An allow-listed admin device still reaches the management services it needs.
• An untrusted device on the personal network is now blocked.
• Automations that run from the server network out to devices kept working.

Follow-up

This rule caused a regression a week later, covered in INC-0002. Read the two together: the decision was right, but the rule matched more traffic than it should have.

Lesson

VLANs are not security; firewall policy is. Test segmentation from the untrusted side, not from the admin’s laptop.