Walled gardens, segmentation, and locking down the management VLAN

Least privilege is not only for accounts#

Most security programmes talk about least privilege as an identity problem: who can log in, who is local admin, who has Entra roles. That matters. It is also incomplete.

The same principle applies to packets. If a compromised file server can open outbound HTTPS to the whole internet, talk SMB to every workstation subnet, and reach your switch management IPs, you have already lost half the fight before the attacker types a second command. Identity abuse and living-off-the-land techniques thrive in flat networks because every host is a neighbour of every other host.

The practices below are variations on one idea: each system and each user only gets the network path they need, and nothing more. That is boring to design and invaluable when something goes wrong.

Walled garden firewall rules for servers#

A walled garden for a server means the firewall (host-based, network, or both) treats that server as a captive citizen of your estate, not a free agent on the internet.

What outbound "any/any" actually buys an attacker#

Default allow outbound is still common because it makes builds and troubleshooting easy. It also means a foothold can:

• Pull a second-stage payload from a CDN or paste site
• Beacon to attacker infrastructure over 443 that looks like "updates"
• Exfiltrate data without needing a weird inbound hole
• Reach cloud consoles, package registries, or remote access endpoints that were never part of the server's job

Inbound hardening alone does not stop that. Egress control does.

How to build the garden#

1. Inventory what the server must reach. Windows Update or WSUS / Microsoft Update endpoints, Linux package mirrors you actually use, domain controllers or Entra join endpoints, DNS, NTP, your SIEM or syslog collectors, backup agents, monitoring, and the specific APIs or databases that belong to that workload.
2. Default deny outbound on the server VLAN or host firewall. Prefer destination groups (objects) over scattershot IP lists so the policy stays readable.
3. Allow only those destinations and ports. Prefer proxy or authenticated update paths where you can centralise inspection. Split "this app server talks to SQL on vlan X" from "this app server may browse the open web" — the second one should almost never exist.
4. Log denials. The first week will surface forgotten dependencies. That noise is the point; fix the allow list, then keep the deny.
5. Revisit when the role changes. A new integration is a change ticket and a firewall change, not a silent widening of "any".

Why this is good practice#

Compromise becomes noisier and smaller. C2 that depends on arbitrary egress fails or trips deny logs. Lateral tooling that expects free outbound proxying stalls. You also get a clearer blast radius for incident response: "this host was only allowed to talk to A, B, and C" is a far better starting map than "it could talk to the world."

Pair network egress with host firewall policy and, where licensed, application control so even an allowed destination cannot run unexpected binaries. The garden has walls and a gatekeeper.

Network segmentation: workstations only reach what they need#

Flat "everyone on VLAN 1" networks are still everywhere because they are easy to cable and easy to DHCP. They are also how one phishing click becomes every share, every printer queue, and every poorly patched internal app.

A practical segmentation shape#

Think in roles, not in buildings:

| Zone | Typical members | May initiate to | | --- | --- | --- | | User / workstation | Laptops, VDI pools | Identity, DNS, print, approved app/web tiers, internet via proxy or filtered egress | | Server / app | Line-of-business VMs | Their databases, identity, updates, logging — not the whole user VLAN | | Restricted data | Finance, HR, clinical, crown jewels | Only jump hosts or specific app tiers; users never land here directly | | Guest / BYOD | Visitors, personal phones | Internet only; no RFC1918 | | IoT / OT | Cameras, building kit, PLCs | Vendor clouds or collectors you define; never user file shares |

Direction matters. Users pull from app front ends. Servers should not push new connections into the user VLAN as a habit. Printers and file servers get narrow allows from user subnets on the ports they need — not "permit IP any any" between floors.

East-west is the ransomware problem#

ATT&CK lateral movement (SMB, RDP, WinRM, remote services) assumes the network will carry the session. If workstation A cannot reach workstation B, and neither can RDP to a domain controller except through a controlled path, commodity ransomware playbooks get expensive. Segmentation will not stop every technique, but it forces attackers onto louder, slower paths and gives detection something to chew on.

For home and SMB gear the same design shows up as Main / Guest / IoT on a UniFi or similar gateway. The enterprise version is VRFs, firewall zones, and microsegmentation — same philosophy, bigger switch stack. See also NCSC guidance on network architecture and segmentation.

Management VLAN: lock the keys to the kingdom#

Management planes are a favourite target because they sit above the workloads. Own the hypervisor, the firewall UI, or the switch, and you own the tenants.

What belongs on management#

• Switch and wireless controller management interfaces
• Firewall and load-balancer admin UIs
• Hypervisor and cluster management (vSphere, Proxmox, Hyper-V)
• BMC / iLO / iDRAC / IPMI
• Backup infrastructure consoles
• Monitoring collectors that hold privileged credentials
• Domain controllers' dedicated management paths where you separate them

How to lock it down#

1. Dedicated management VLAN (or out-of-band network) that carries no user traffic and no guest Wi-Fi.
2. No route from user or server VLANs into management except through a jump host / PAM / privileged access workstation path you control.
3. Admin workstations are not browsing machines. Separate privileged access workstations or hardened VDI; no email and no general web on the same session that can reach iLO.
4. MFA and unique credentials for every management plane. Disable default vendor passwords. Prefer certificate or SSO where the platform supports it.
5. Patch and monitor management interfaces like production apps. Log admin logins to the SIEM. Alert on management access from unexpected sources.
6. Disable unused services on gear (Telnet, legacy HTTP, discovery protocols you do not need on the management VRF).

If an attacker on a user laptop can open https://core-switch.mgmt.local, your segmentation theatre ends at the first clever browser tab. Management isolation is how you keep a workstation compromise from becoming an infrastructure compromise.

Same idea, other surfaces worth implementing#

Once you see the pattern — default deny, explicit allow, separate trust tiers — it shows up everywhere. These are high-value cousins of the three practices above.

Identity least privilege and admin tiers#

No standing Domain Admin. Use time-bound elevation (PIM, JIT). Split Tier 0 (identity and management), Tier 1 (servers), Tier 2 (workstations) so a helpdesk account cannot touch domain controllers. Pair with phishing-resistant MFA for privileged roles.

Application and script allow-listing#

On servers and admin workstations, allow only known binaries and signed scripts. That is the host equivalent of a walled garden: even if egress or RDP is abused, arbitrary tooling is harder to run. PowerShell logging and JEA belong here too.

DNS as policy, not just resolution#

Send clients to resolvers you control. Log queries. Use protective DNS to sinkhole known-bad domains. Unexpected NXDOMAIN bursts and odd external names are early signals — especially when egress is already tight and attackers try creative callback paths.

Backup and recovery isolation#

Backups that share credentials and network paths with production get encrypted in the same incident. Separate backup VLAN or account tier, immutable or offline copies, and a restore drill that proves you can recover without trusting the compromised domain.

Certificate and secret hygiene#

Short-lived certs, vaulted secrets, no long-lived keys on jump boxes "for convenience." Compromised static secrets turn your carefully drawn VLAN diagram into a courtesy.

Logging and deny-as-signal#

Fences only help if you notice someone climbing them. Forward firewall denies, management logins, and privileged elevation to a place humans (or MDR) will see. A silent default deny is security theatre; a default deny with alerting is a detection surface.

Vendor and remote access containment#

RMM, VPN, and support tunnels should land in a quarantine or jump zone, not straight onto every server subnet. One approved remote access path beats six overlapping tools with standing access — a lesson that keeps repeating in real incidents.

How to roll this out without melting the helpdesk#

Do not flip default deny on the entire estate on a Friday.

1. Pick one server role (for example domain controllers' egress, or a single app tier) and document required destinations.
2. Pilot segmentation between user VLAN and one sensitive server VLAN; measure broken apps; fix with narrow allows.
3. Stand up management VLAN and jump access before you cut old routes — admins need a working path first.
4. Change control every widen. "Temporarily any/any" has a habit of becoming permanent.
5. Test failure modes: patch Tuesday still works, monitoring still scrapes, backups still run, break-glass still reaches management out-of-band.

Bottom line#

Walled-garden egress, workstation-to-service segmentation, and a locked management VLAN are the same security instinct expressed three ways: assume breach on one node, and make sure that node cannot casually become the whole network.

Add the identity, allow-listing, DNS, backup, and logging cousins and you have a programme that still looks like engineering — allow lists, zones, tiers — rather than a pile of point products hoping a flat LAN will behave. Start narrow, deny by default, and treat every new path as a privilege you are granting the next attacker who gets a foothold.

References#

Sources and further reading for the claims above.

• NCSC, Network architecture (device security guidance)
• NCSC, Preventive DNS and protective monitoring
• CISA, Segmentation guidance and zero trust maturity
• Microsoft Learn, Privileged access workstations
• Microsoft Learn, Privileged Identity Management
• Microsoft Learn, Windows Firewall
• MITRE ATT&CK, Lateral movement
• NIST SP 800-215, Guide to a Secure Enterprise Network Landscape